51Testing资深工程师深度解析铁道部12306网站

看起来像好人

最近看到了很多关于12306网站的报道，自己也在软件测试领域摸爬滚打了很多年，从技术的角度发表一下自己的看法。前一阵在成都与51Testing的刘德宝老师讨论了12306网站的问题，正好跟08年奥运会门票系统崩溃的事情有很多相似的问题，大家都认为的问题应该没有想象中那么困难， 下面大概分析一下，欢迎各位讨论！

   从目前前端页面来看，12306的网站使用的是J2EE架构开发，具体web服务器不晓得是啥，估计Web服务器是Websphere，数据库可能是用铁道部以前老的数据库，如果是这种情况，如果我们做性能测试的话，我觉得可以从以下几个方面进行考虑：


    1、首先是系统架构设计。从12306网站来看，如果所有用户发出的请求是先查询车次，再看余票信息，然后购买，那么可以根据IP进行负载均衡处理，分发到各个节点上，而动态请求，真正的业务处理可以在节点完成。这样，在处理请求的时候就减轻主服务器的压力。具体业务请求由Websphere进行处理，经过中间件与数据库进行交互，从目前来看，如果数据库用的是老系统的话，应该是没有啥问题，问题可能就在中间件和websphere的处理上（以前售票点的数据库应该也是联网，速度也没现在的慢。所以，老数据库应该还不错）


    2、并发处理方面，系统应该设计容纳的最大并发数量，防止用户过多产生堵塞，可以采用排队机制，就像我们打电话约出租车一样，避免大量用户请求涌入，这样保证服务器有足够的时间处理业务。并且排好队后大家心里就有数了，也不会出现用户一直刷一直刷的情况。其实几年前的奥运会门票系统崩溃给了我们这么多教训，现在还是不去改进。


   3、通过使用httpwatch进行查看，每个页面上的资源文件都比较大，这样是不利于数据传递的，所以，还可以优化文件的大小，减少客户端请求的数量及数据包大小从而提升下载速度，减少带宽占用。


    4、针对这样的系统，是否可以将大量的数据库查询，调用数据的过程放在缓存中，与内存交互。另外订票流程也是有问题的，存在一个记录锁定的问题，这样的话，数据锁定时间过长，会导致大量票被锁定，其他用户无法进行购买（实际上并没有支付），这样的话，就导致票信息被锁定时间太长，会造成更大量的访问了。因为成功率下降，用户尝试次数会增加，如果在付款流程设计成余额支付是否会好些。比如在他查询车次信息的时候，就自动检查他的余额信息，让他先充值再买。


5、其实像淘宝，像腾讯，像京东商城等这些公司也完全有能力提供一些建议，多像民营企业请教经验，又有什么关系呢。


   总结下，从架构，业务逻辑，客户端数据几个方面，分析下来，12306网站优化的地方有很多，看了新闻说已经增加了带宽，速度上去了，我试了试，没啥变化，纯粹指望硬件来提升，很难的，也很费钱，不过他们有钱，呵呵。

¤伊⊥琦¤

看来楼主是高手

噼里啪啦

真的假的哦 呵呵