我的12306春运之整体解决方案

铁道部的12306订票网站是近期的一个热点，在iteye已经有几个帖子讨论了。

看了大家的讨论，有些观点我很受启发。同时我又有自己的一些想发，这里专门开个帖子阐述一下我的解决方案：

1、 整体采用排队的思路，化并发为串行。假设有10台排队服务器，每台用NoSQL数据库和内存队列可以满足100万人的排队。而到数据库的并发数就降低到了10。如果Oracle每秒处理的票数为100的话，每天可以卖出1000万张票。如果铁道部几千万的单子采购的硬件做不到的话，那真的要拉出来打屁屁了。

有个帖子说了排队的缺点，我后面会阐述如何解决这些缺点。

2、采用预付费的付款方式。购票人通过网银预先存好购票款，买到票的时候从预付款里扣；留好退钱的帐号，任何时候都可以退钱。

预付费的好处包括：
  一，把多系统很难实现的事务转为单个数据库实例上的事务，杜绝出现钱扣了票没买到的现象；
  二，可以架个单独的账务服务器，分流网络流量；
  三，减少出现一个人排多个队这种情况。

3、购票人一次排队可以为最多5个人买票，但是这5个人是绑定的，就是要么都买到，要么都买不到（为家庭考虑）。购票人可以购买往返票。往返均可以设定5种购票选项，比如：优先选择19日上午10点D111次，其次19日下午15点D222次，再次20日上午10点D111次，等等。这样解决了有人说的排队排到了票却没了的问题。

4、后台服务器要根据票的剩余情况，维护排队服务器的队列。要采用类似LinkedHashMap的数据结构，当某趟车没票了，要能很方便的把受影响的排队号找出来，把它们的购票选项去除。当一个排队号的所有购票选项都没有了，就把它从队列中移除。

要开通短信通知平台（每个排队收个0.5~1元短信费，应该都能接受吧？），及时通知购票者购票的变动情况，比如：买到了，没票了等。这也能减少购票者去频繁刷新网站。

5、其它的再有就是采用静态页面+二进制的AJAX(hessian,protocol buffer)等方式，减轻大家查询余票信息的网站的压力。

12306最大的问题应该是大并发访问情况下的负载均衡
例如，单纯的登录页面，不存在算法问题，完全是大并发情况如何负载的问题。
总结一下我的看法，大家可以讨论：
1、接入点负载。实现多域名接入，避免单一一点接入。
2、应用负载。应用系统是处理事务的核心，也是负载的最大地方，动静分离、CDN、大规模服务集群都应该考虑，必须按最坏的打算来做设计；
3、应用架构或算法。售票算法相信铁道部已经有非常成熟的算法了，不多说了。诚如LZ所说，NOSQL、内存缓冲、高效队列都有用武之地。
4、数据库分布与负载。高并发情况下的，DB的负荷也会非常之大，因此使用集群数据库部署是需要的。

你这个排队需要预先填写车次、张数？
排队前填这么多操作，感觉不好。
类似于摇号，只不过随机变成了时间排序。感觉还不如随机，可以安心的慢慢的提前填写好车次、张数。

0.5-1元短信，很不能接受。凭什么系统有问题，反过来还能赚上亿的钱？

恩，有点道理，思路挺清晰

排队不合适，黑幕问题严重，而且窗口售票也没法参与排队，会造成不公平。

看我的实时方案：http://guzz.iteye.com/blog/1344740

排队和摇号有本质区别，排队可以体现公平的特点，先到先得；排队还可以做到心中有数，可以查现在排在哪里，估算大概还要多久才到我。人的心理怕的就是对未来的未知数。这样也可以减少有的人不停的刷网站。如果是随机的话，大家都会拼命的刷网站。

填写选项单是为了避免排队排到了但是单选的车次没票了，又得重排。这个就像交待别人帮忙买票：帮我买xx号的，没有的话买xx号的，再没有买xx号的。提交前多花个几分钟总比没票了重排要好吧？

至于短信收费服务是可选的，可以不要。不过我估计很多人都会选的。

真有黑幕实时的也没用，实时的就不能作假了吗？这不是技术所能解决的。

你的博文我看了，说实在的，感觉不太合适。就说一个锁表再网银付款，卖机票可以，卖火车票不现实。

想法和现实有很大差距. 最大问题就是腐.败

您的文章当中包含了敏感关键词'腐.败'，属于有关部门规定的有害信息，为了保护您和ITeye网站的安全，我们建议您不要发表这篇文章，有关部门一旦认为你的文章是有害信息，会要求我们提供你的IP地址

你怎么确定哪些票没了然后把人从队中清除，难道每卖出一张票都要去几百万排队者中遍历并检查一次票吗？这比卖一张票花的时间多多了。
而且票数不是固定的，受买票者的乘坐区间影响，不能简单按总数减一减一来算还有没有票

我觉得思路挺好的。不过排队也许不是一个好办法，但是在你所述思路里我觉得是可行的。考虑到nosql数据库的高并发，是不是考虑把排队换成“行锁”的办法来解决，nosql数据库从几百万数据里面通过索引来查询数据，那也是非常非常快的事