对12306网站实现的一些想法

 

        最近在微博上对12306亿元招标的议论很多，技术类帐号很多都认为用那么多钱做出如此访问速度和操作效果的站点实在不应该。很多人提出了各种各样的解决方案，而这些方案大多来自互联网电商的实现架构，例如淘宝应对双11或京东商城与苏宁价格战中对海量访问支持方案等。但是似乎大家忽略了一个问题，铁道部的互联网订票系统是在已有车票票务系统基础上发展起来的。从铁道部的新闻稿中可以看出，目前的车票票务订票系统已经开发了尽10年时间。在系统开发的大部分时间里，都是以满足各车站订票窗口和分布在大中城市里的订票点使用作为目标。这样一套系统的访问终端数量可控，访问终端的刷新频率可控。如果这套终端系统是C/S结构，客户端只需要从票务数据库服务器中获取少量数据就可以进行大部分查询操作，然后在最终订票时对数据锁定做写操作就可以。这套系统的成功应用使我们可以在全国任何一个售票窗口买到任何车次任何城市出发的车票，然而也正是这套系统的存在使得12306在实现互联网订票上变得举步维艰。

 

        首先12306的功能实现一定不能影响到现有车票票务系统的使用，如果12306与现有票务系统的数据分离存储，这两部分数据之间的同步，实时大并发下两部分数据写操作锁的实现都会成为难点。所以不妨大胆猜测一下，12306系统订票写操作与现有票务系统订票写操作访问的是同一中央数据库，而为了保证现有票务系统对数据库访问速度，来自12306系统的链接数是有最大值限制的，而且此最大值是远远低于安全阀值的。如此一来如果中央数据库的处理能力得不到提升，12306在WEB端做的任何努力都是无意义的。

 

        如果以上前提成立，那么为了中央数据库的安全考虑，12306的主服务器应该就在铁通的网络里，国内网络运营商之间的互连互通做的如何，大家都是有目共睹的。所以网络原因也会大致很多用户在访问12306时反应缓慢。

 

         这种状况下最简单的处理方式可能就是下血本去更换高处理能力的数据库服务器，提高数据库存储和操作的计算能力，以满足海量高并发访问请求。但是这样投入的资金可能会是天文数字但是却收效甚微。而另外的做法就是从数据库的结构上做调整，满足海量并发请求操作，但是如此底层修改可能会牵扯到现有票务系统的修改，12306与现有票务系统是否为同一家企业开发实现不得而知，对现在已经正常运行并且已经通过某某验收奖励的系统做出重大更改，可能也是铁道部所不愿意的。

 

        所以如果一定要下一个结论的话，那就是12306这个海量事务高速处理系统并不如大部分人设想的那样很容易就可以实现。即使铁道部真的如大家希望的那样公开招标，引入其他有经验的开发企业，当这些企业进驻时会发现，有些并不仅仅是技术实现的问题。