转变思路让12306不瘫痪

对12306来讲，是困难也是机遇，如果通过成功的解决这样的访问量，对于相关技术人员将是一种前所未有的成就感，本人一直从事技术工作，回家订票也是犯难，高并发压力这个是业界难题，想从技术方面进行根本解决，当前比较有效的就是分布式计算模式，但是这种对现在软件体系变革比较大，特别是一些采购、维护以及研发模式并不太适合于部委级现有信息化体制；
对于当前铁路客票系统，我思考了几天，觉得可以基于现有技术水准，只是通过页面内容的调整，来提升铁路客票处理能力。
在说思路之前，先说一下我认为当前面临的几个问题：
（1）用户第一分钟登录的高并发压力会特别大，所有人一上系统先登录，这种模式不可取，再成熟的系统可扛不住上亿人的登录（考虑买一张票，可能是全家出动，5，6个人在登录）
（2）大量的基于用户查询，这种查询重复度特别高，特别是登录成功后，不断的查，这样的压力对于数据库即便只是可读的也是不太可取，完全没有必要这样来设计；可以通过全方位数据推送，即后台 间隔生成静态各车次的余票信息，以静态页面的推送来替代大量的自动化查询；

当然这是我接下来提出的几个原则，相信将能够极大缓解后台系统压力；
（1）减少用户主动查询： 通过自助导航+余票推送模式替代用户大量实时查询；
（2）减少用户登录： 发现有余额时才允许用户登录，来降低用户刚开始的登录冲动；

具体简述一下解决思路：

（1）用户打开12306后，点击购票后，会打开一个导航页面，这个页面基于导航的模式，将各铁路局为模块，包括其下的各车站，每一个车站（或一些大站以方向为子站）形成一个导航链接；
如下示意图：
车站导航站
北京铁路局：北京南 北京 北京北 北京西（上海方向）北京西（东北方向）
上海铁路局：上海 XXX XXX XXX....
XX铁路局： XX XXX XXX ....
....
（2） 用户点击上述导航页面，只需点击自己自己出发的车站，这样省去了大量的用户查询（导航页面是纯静态的），点击后会打开一个页面，这个页面内容包括这个车站相关的所有车次，以及车次余票信息，并以时间预售期为分栏
例如： 车次余票页面
导航栏： 1月20号（当前选中） 1月21号 1月22号 XXXX
车次 首发站 到达站 有无票 预订
101 北京南 上海 5 预订（输入个数，最多三张）[ ]（登录）
X X X X 1 预订（输入个数，最多三张）[ ]（登录）
....

（3）当用户发现存在余票时，输入预定张数，才允许点击登录；每登录成功后，相应余票自行减去预定的张数；并且形成针对该车次、该天的新的预票静态页面；

注解：
页面1是纯静态页面，不会有改动，因此访问效能会最高；
页面2是定期生成的静态页面，可以每五秒生成一个有关本车站从今天到预售12天的所有相关车次的余票信息，这个是生成一次，供全国同步推送使用；
页面3是用户点击登录成功后，先假设能够定成功，先对余票减去要预定的，当余票减完时，这个车次停止预订，后面的用户只能不断的刷新页面2，等待登录成功的用户没有订成功，自己再进行登录；

好处：
用上述的方式，避免所有用户第一时间大量的去登录，造成不必要的并发，因为有的登录成功也解决不了问题；第二就是不断的动态查询，带来对数据库的不必要压力；另外通过静态页面，即便是访问达到数10亿，也不会有太大的问题，因为CDN与各地代理缓存机制。

验证：
作一个假设，如果有1000万用户同时来访问这个站点，这样第一时间的压力不在登录上了，主要为集中在页面二，在页面二设计时，因为存在部分大站车次比较多，因此可以建议在大站中在设方向，例如北京西，下面再设几个子链接，分别链接东北方向，西北方向等，打开后只显示这一方面的车次；用这种自服务加主动推送的模式，这样用户登录的压力有可能会减少很多，因为一个车次不管发送过来的登录请求有多少，只需对排队到达的前3000个进行处理（车票总数），后面的连接直接返回[已预定完毕，请等待用户退票]，这种技术判断可以基于JS脚本本地判断（不占服务器带宽）或对于已到达服务器请求由服务器返回，当然后面的登录请求，如果没有余票就不允许登录；