最近铁道部购票已经成为了热点话题，毛病多得一塌糊涂，如果让你来设计铁道部购票网站，你会怎么做？
这样的网站属于实时性要求较高、并发性要求非常高、容量要求一般的类型，以下是我简单的想法：
1、部署是基于 CDN 的，对于车票查询的环节来说，这是没有问题的。
2、数据库表设计上面，应当有一张车次表，每行代表一趟车，至少有这样的字段：还剩多少张，已被锁定多少张。
3、每次发生订票操作时，先去查询当前是否有余票，有的话锁定一张等待用户操作，如果半小时内无法完成，锁定票放回。
4、查询部分，集群中放置分布式缓存，存放数据的静态页面，但由于车票查询实时性有一定要求，可以设置每个查询页面有 10 分钟的生命周期，缓存文件管理算法用 LRU 就可以，被动更新。如果车票信息在本地，数据库节点应该会是瓶颈，好的缓存设计会很讨巧，可以大大减小数据库压力。
5、应用节点的负载分担是一定要做的，查询和订票操作可以分开集群，有条件的要做硬件负载。
6、静态资源合并，落到单独的域名服务器上。
7、流量控制部分，不能只给出用户提示，应当给出用户当前在等待队列中的位置，定时更新当前位置，在排队到达后，要页面通知到用户来完成操作。
8、订票当次处理成功以后，接下去的出票等等操作放在队列中进行，等待银行把款转过来，这部分也有一定实时性的要求，应当和响应用户的应用服务器分开，免得互相干扰。
还有一些疑问也值得讨论，很有意思，比如遇到那些抢票机器怎么处理。
——————————————————————————————————————————-
2012-1-14，根据大家的讨论摘选有意义的进行补充：
1、车次票需要包含若干个区间票。
2、倘若按照 10 分钟的页面缓存过期时间，用户很可能还是不愿意接受的，需要把数据直接写到内存里面，查询在内存里面查询，数据库只做适当时机下的持久化和数据同步用。
3、关于和淘宝相比的访问量，不见得有淘宝的大，见日均 IP 的统计：
关于 PV，这句话很有道理：
“12306 真的有这么大的 PV 量吗？现在的 PV 这么大，那是因为我查询 100 次，1 次也查不成功，所以我就不断的刷，这本身就是在逼迫全国人民对其进行 Dos 攻击。如果查询的成功率、订单的成功率提升了，估计 PV 会直线下降。”
所谓恶性循环变指此吧。
4、关于数据库要不要集群，从目前的系统看，瓶颈不在此，而在考虑了采用内存数据存储和直接命中以后，似乎还没有这个必要。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》