针对12306.cn网站应用架够的一些看法

winston

背景

针对最近比较热点的列车网上订票系统频繁出现的系统问题，提出了一些自己的看法。

分析

几经分析考虑，认为可能存在几个系统瓶颈。

1.关联系统的系统负载能力比较弱。

2.网上支付的负载能力不够

3.网站本身吞吐量问题

4.网站出口带宽不足

方案

针对以上分析的一些可能的问题点，提出了一些自己的想法

1.关联系统接口问题的话，我的想法是采用排队制。用户登录以后根据车次取号排队，排到后进行订票付款，这样可以减少并发数，保证系统可用率

2.网上支付系统负载不足，可以采用异步。用户订完票以后进入队列，因订票时候是根据实时的数据订票的，因此不会说支付后无票取的情况。队列中的用户可以一次取支付系统允许的人数进行支付操作。完成后用短信或者邮件通知下一批用户登录系统进行操作。在系统可用率提高的情况下，减少了因错误不停操作带来的压力

3.网站服务器问题，可以将重点的功能，如登录和订票两个分出来，投入较多的服务器，其他查询等功能因可使用缓存可减少服务器投入。各个服务之间用sso。登录oid或服务器采用master slave，注册网master 登录等查询用slave

4.网站出口带宽问题，这个没有好办法，可以用在主要的几个城市各部署一套。因铁道部门系统应该是全国联网，因此接口不成问题。这样可以充分利用网络带宽资源。

以上就是我分析出的一些结论，谨用于理论分析探讨。欢迎高人赐教。

思考

关于分流和其他电子商务网站类比。

    这几天我在网站上也看到很多关于12306.cn的讨论，其中有方案是借鉴成功电子商务网站如淘宝，京东的经验。还有一个就是类似于机票订购的分流。

    对于这两个方案我也有一些思考，除去商业上的一些利益关系。从技术角度上去分析，认为方案有待商榷。

    1.首先说下c2c和b2c型电子商务网站，有个特点，就是商品缺货时可以进货。而机票，火车票这种特殊的商品一天就那么多，没办法在增加。因此在逻辑上是不同的，前者在订单的控制上显的比较宽松，而后者就比较严谨。

    2.再来看下火车票是否可以借鉴订机票的方案，抛去铁老大是否愿意和分销商分享这块蛋糕。抛去分销商绞尽脑汁去想办法分享这块蛋糕，但从技术角度上去考虑。我在考虑了相当长一段时间认为也不是很可行。

    对于第2点有点改进的地方是各分销商网站可以自行支付，这点上确实可以缓解支付的压力。但是火车和飞机这个压力不是一个数量级的。飞机一天多少航班？春运期间火车多少列次？从乘客数量上讲（数量就是系统压力的来源）更不是一个层次。那航信的原始接口走socket协议，是否能够集中承受那么大的压力也是个疑问。不用说经过webservice/rmi之类封装过的接口了。

    总之，我还是认为能够控制系统核心功能的访问量是一个方面。因为在没有经过实际使用时是不知道有多大的并发量。就算知道了春运的客流量也不等于就知道了系统的访问量，并发数。而且在技术能力有限的情况下能够很好的控制用户的访问并发也是一个办法。这个和系统性能优化并不冲突。当然系统优化后控制的口径可以放宽。但系统的性能也是有峰值的，并不是无限大的，因此还是需要一个控制阀来控制。这样才不至于系统出现服务无法使用的情况。

----

回复网友留言：

回复1楼 falconfei

    falconfei 您好，手写感谢您的留言。我说一下我的观点

    网站只是一种订票的渠道，因此我猜可能是调用接口，不会直接操作数据库，如果这样订票的核心逻辑应该是早以前就有的，因为还有柜台和电话系统在使用，因此逻辑应该不会改。

    任何系统都有一定的负载值的,一般来讲再厉害的票务数据库也无法承受如此夸张的访问，越是订不到越是点击，越是点击宕的更快。这个恶性循环会一直下去。
所以要只允许所能承受的一部分进来操作，一批完以后再进行下一批。就如火车站春运拿到车票的2小时内发车的先进站。走完一批，下一批再进站。如果不控制，再大的火车站候车厅也难以承受。
取号机制就可以过滤掉一批没有必要的人。取到号的就等着订票，没有号的干脆就不要让他进去点了。只让他随时关注有无余票可取号就OK，读操作肯定强过些操作。而且是没有目的的盲目的写操作。

这个是我的观点

回复5楼 ycc5617

               ycc5617您好，非常高兴看到您的留言。

         对于您提出的疑问，我认为可以在发出通知用户付费的邮件后，规定用户需要在一定时间内（例如5分钟）登录系统支付，如未在规定时间内登录系统，可以认为用户自动放弃，可以回收订单。用户登录后，订单时间调整为固定的时间如2小时，因为电话订票不止2个小时，因此认为2个小时也是恰当的，或者可以1个小时。因为真正有效的用户操作，因此系统更稳定，用户只要操作1次或几次就可以付款。付款收到返回信息后订票成功，否则超过1或2小时，自动解锁释放车票。在队列中可以不记时间，这就意味着锁的时间可能会更长，这个要看支付的吞吐量和速度，然后设定队列的大小和优先级。队列满了，可以让用户排队。

其实一个操作熟练的网友可以在10分钟之内就完成支付，如果是对网络部署的用户1个小时应该也足够了（前提是系统可用性要高）。

         欢迎继续讨论，多谢

回复6楼 ihxwangcong

        ihxwangcong您好，您的留言我已自信看过。您说的架构和事务并发确实是根本性问题，但问题在于解决这个问题不是在个别系统上就能解决的。铁道部的系统也类似于企业系统，是由很多系统构成的。保守估计核心类系统不止一个。从根本上解决这个问题确实是最好的办法。但也是一个耗时耗力的过程。去年我公司进行银行系统的整体改造升级，大大小小的系统几百个。经过几百IT精英差不多一年不休的努力才能够勉强上线。只是备用方案的指定和预演就经过了很长的时间。因此涉及到核心的东西不是不能改，是要谨慎改。在铁道部那边我是这样认为的。暂时宁可舍弃网站这部分，不会丢掉在他们看来比较稳定的核心。除非是遇到很大的问题，无法支撑下去，否则轻易不会动的。

回复8楼 jingyexiaoyue

      DDos是关于网络安全方面的问题了。这方面有不少硬件防火墙可以根据一定的规则过滤掉或屏蔽掉不满足三次握手的网络包。
      对于这种情况属于基础架构的层次了。这个铁老大凭借强大的经济实力如果有个懂的专家应该可以做的不错。实际情况来看也确实还可以。

      现在网络上的讨论我看过很多，很大一部分是从应用的设计上去讨论的。而且有个大的也是比较热的论点就是事务上。这个我也比较赞同。但是这个问题就脱离了电子商务网站的范围，我一直不认为网站会直接操作铁老大的核心数据库。因为网站没有经过大规模的试运行，无法知道会给核心造成何种影响，因此我一直认为是网站调用了核心系统的接口这种设计。而且核心的逻辑是原本存在的，已经供至少两个售票渠道在使用

     1.柜台（包括车站窗口和代售点）

     2.电话订票

这样的话，就是在原本的系统上要扩展出一个渠道子系统来。

我曾经也遇到过类似的情况。公司外购了一个系统，但是这个系统不够能满足公司的实际需要，仅此做二次开发。如果运气不好，找到的是第三方代理商。这个就很痛苦，因为代理商并不是真正的系统开发商。他只具有一定的开发能力，但涉及到系统底层的核心逻辑他就吃不透。如果动了，问题随之就来了，各种莫名其妙的错误甚至宕机。

     这次我认为也类似上面这种情况。核心逻辑因各种原因没有进行重构，因为向这样的逻辑重构也是有巨大风险的。因此我判断是为了规避风险而用了不是很适合的原有的售票逻辑。

一些题外话：

        我所描述的方案只是从一定程度上缓解系统的压力的方案，并不是提高系统性能的方案。

当然，我没有参与过铁道部系统的设计和开发，以上所述都是本人凭借6年开发设计的经验的一些推断。网友所说之上谈兵也是对的。因为不清楚铁道部系统里的道道，因此所有谈这个问题，有没有接触过的人都是纸上谈兵。

       我的原意不在于是否之上谈兵，而是通过这个事件看能得到些什么启发，能想到些什么，然后在从大家的集思广益中能概括出有用的东西，并应用到今后的工作和生活中。

       再次感谢每位留言的网友！

作者：m13666368773 发表于2012-1-13 11:16:20 原文链接