一种奥运门票网络系统设计方案

这些天来，很多网友给我来信，表达了他们的愿望，就是让我给出一份设计方案。我本庸才，不敢在众多
专家学者面前班门弄大斧，但对网友的热情难却，凑个热闹，也吼两声自己的丑陋看法，纯属瞎写，别见笑。

但我还是那句话，在高性能系统不宜使用数据库，只在数据管理中才会使用。
由于我对该系统的具体需求不清楚，只能假设一些需求，但基本思路都是一样的。

首先，由后台系统生成一个静态页面，上面标注了票的信息，比如那些有下拉框的地方，决不能通过数据库
查询出来，而是直接生成静态页面。页面上的所有的选项都是这样的方案。保证大家在打开网页时，
不会操作数据库。
例如：某个列表是这样的

id info
0 羽毛球
1 兵乓球
2 足球
3 篮球
4 拳击

然后在中间服务器的地方开辟一个大数组。如下构成：
int info[5];

0 2000
1 1000
2 20000
3 10000
4 2000

0表示数组下标，2000表示0代表的羽毛球的票数。当线程处理一个请求时，会判断报文的包头的协议类型，只要该
协议类型表示“我要订羽毛球票”1张，立刻将0对应的2000减1变成1999，如果另外的1999个同样的报文
发送过来，第2001个就会直接返回失败，表示羽毛球票已经定完。
接着，上述的报文会再根据“比赛项目”分发到对应的服务器上，可以用tcp协议，
例如ip指向192.168.128.111,port:9000的羽毛球数据存储服务器

在后台羽毛球数据存储服务器当中，为比赛项目，如羽毛球单建一个我称之为“数组链表”的数据结构。
如下结构

若干线程同时操作以下结构。P*为指向“羽毛球信息”的指针。
0 P*
1 P*
2 p*
3 P*
4 p*
5 p*
6 p*
7 p*
8 p*
9 p*

随机选择一个数组下标，把记录连接到后面的指针上，使每个数组下表后面都接一个链表。其实完全
可以用一个链表，只是这样做会减少线程同步带来的性能瓶颈（但是每个小一些的链表不能避免线程同步）。
如果设计时间充足，我觉得应该还有更好的算法。

这样，关于羽毛球的订票报文就全部被奥运门票系统接收了。接下来，羽毛球数据存储服务器就不会接收
报文了，可以从容的向数据库插入数据了，这一点可以人工控制，也可以批处理，总而言之就好办了。

最后，数据库归档以后，通过邮件向每个购买者确认即可。

建议类似羽毛球，兵乓球，篮球，110米栏热门项目单建服务器，其他像拳击等项目可以一起放到一个
服务器上。

建议后台数据存储的分布以项目来分，这样便于评估压力和性能需求。在上面没有用到任何数据库技术，用
单独设计的算法和数据存储结构即可实现高性能。这也是我一直强调的不要在高性能系统中使用数据库的原因。

在高性能系统设计当中，一般情况下真是很少使用数据库的。这个设计是随便想到的，如果给足够时间，
应该能设计出更好的系统。