一年前，12306“迅速”推出了网络购票平台，在经历了拥挤的春运之后，大家逐渐接受了这个东西，对12306不满意的反馈越来越少，时值运行一年之际，系统进行了一次大的升级，等来的不是说好的选座位系统，而是一个对于网络购票群体来说非常麻烦的排队系统。昨晚及今晨，恰逢本人需要订购近期和十一期间的火车票，所以体验了一把这个排队系统，后又对排队系统的前端代码进行了研究。
先说一下系统是怎么回事，看图
该图是根据各种媒体的描述和信息，以及本人的专业知识，绘制的。左侧是网络订票系统（12306），下侧是电话订票系统（95105105），网关（防火墙）后侧则是真正的售票系统。当然还有传统途径的售票系统，应该是直接接入总后台，而电话系统，是否也通过网关接入总后台，不好说，或者是另外一个网关接入总后台，这个无关紧要。
先说网络系统。春运的时候一直拥挤，根据系统结构图，目测是因为网络系统本身的前端容量受限，以及通往网关的容量有限导致的。前端容量，可以通过提到网页代码质量，提高网站入口带宽解决，但总体来说，治标不治本，因为所有数据都要通过网关与总后台进行交互。所以春运之中、之后，上网站没问题（前台容量增大），但到关键时刻（如查票、订票）还有困难（网关仍有限制），此后的平日，由于订票需求不大，因此日常订票基本无障碍。所以这一次升级就容易理解了，引入排队机制，解决网关的拥挤。
另外再说这个排队系统，本人研究了前台的代码，情况是这样的：前台有一个关键值，和一个辅助值，关键值是进行倒计时之用，在本地计算（因此可以本地修改），而辅助值则是定期通过网络调用服务器数据并修正关键值。于是整个系统可见是双端维护倒计时，因此即便修改了本地值，也无法解决远端的倒计时问题。然后倒计时完毕之后，本地页面的动作是刷新本页，这个最关键，因为一旦所有数据来自服务器，那将意味着本地无可作为，只能无限制地刷——这就又回到了前段系统容量的问题。
btw，发帖此刻本人仍无法打开12306的所有功能，就是因为前段页面容量有问题。以上说的是页面问题，然后说排队本身。前边说了网关容量问题，以前是拥挤，所以为了解决拥挤，就只能排队。刚才也说到了服务器端也维护了一套排队倒计时功能。根据昨天和今天的订票经验（昨天19人排队30+分，今天16人排队5分钟以内），个人推断目前新闻所说的“只有在热门车次热门时刻才会激活排队”这个说法不成立，也就是说这个排队很有可能是个总排队，至于倒计时的计算，应该与网关的容量和排队人数综合计算出来的（因为没有相关数据，所以本人无法进行判断这个计算是否合理），但有个问题，人的时间维度一般最低到秒级，而计算机系统的时间维度最低是到毫秒级的，那么个人认为出现30+分钟的排队，时间系统设计得有一些消极了，系统再差、网络再挤，也不可能一秒钟才处理一个订单，更何况以前还没有排队系统。
然后就是这个排队系统的推出时间，此正值十一前夕，而且万年难遇的中秋十一又蹦在了一起，这正是一个最佳的验证用例，所以9月15日，流程麻烦的排队系统上线了。那么我想，经过十一的检验与反馈，在接下来的两三个月内逐步修正问题，春运的时候就能妥妥地虐你不商量。
以上是对网络系统的分析外加吐槽，最后说一下电话系统。本次升级，最有意思的就是电话系统比网络系统好用了（昨晚和今晨两次订票，电话系统均一次成功，今晨还是放票的关键时刻），那么也说明了电话系统跟网络系统彼此独立，而且刚才去代售点取票，也佐证了这一点。由于彼此独立（估计开发维护团队也是彼此独立），网络上了排队系统，电话则没有上（而且个人估计客观也不具备条件上，总不能让人拿着电话等30分钟吧，电话费谁给报销？！），但电话系统也有一个先天优势，在于总容量，不同于网络系统——大家一起挤，因为HTTP网络协议的无状态性，即便挤进去了，也未必能持续地互动——电话系统是有状态的，挤进去了就一切顺畅，挤不进去就接着挤，这也算是另外一种排队，把问题前移了吧。还有另外一个有意思的事情，这属于上层总系统构架的问题，我们知道原则是当日当次一个证件只能出一张票，但是神奇的电话系统和网络系统居然能够并行，实现当日当次单证购两张票，所以只能说，首先总后台没有验证这个事情，其次两个系统各自为政，另外如果从购票系统直接购票，估计会有所验证（这个没有证实，我期待着三个系统能出三张票）
|
发表于 2012-9-20 12:10:55
楼主
