January 17, 2012

铁路订票系统的平民技术思路

虽然今年不打算春节走铁路回家，但看了12306.cn的种种传奇还真是感觉很震撼，证实自己一贯的看法，电子商务的关键是商务（商品、服务、供需关系），电子只是配角。

又读了几篇很有意思的技术文章

值得记录我自己的粗浅想法（没有海量处理、排队异步啥的高档技术，都是平民思路）。

基本的数据量是这样估算的

  • 2012年春运客流量预计将达到31.58亿人次，比2011年增长9.1%，创历史新高。全国铁路将发送旅客2.35亿人次，同比增加1352万人次，增长6.1%，日均588万人次，同比增加34万人次。
  • 600万人/天/(1000人/车次/天）= 6000车次
  • 经过北京共有635列列车通过[ctrip.com]，与前面的总车次估算基本没有大矛盾。

这样的话，解决查票、订票的流程中的数据层的资源抢占的瓶颈，以我理解的业务场景去设计是这样的

  • 不考虑一个客户同时买很多不同车次的情况，除非黄牛。那就没啥购物车、订购清单之类的汇总计算。所以不同车次的数据随便拆分。这样就可以直接将不同车次的数据服务水平拆分到100到1000台服务器上，这些服务器之间没啥数据同步的需要，崩了一两个也没关系不影响大局。
  • 也没有“查全国所有车次剩余票数清单”之类的对车次进行实时汇总计算需求，也没有什么“买T16/Z13组合优惠”之类的车此间将官关系，所以按上面的划分方式问题不大。做到最土，各个铁路局自己搞个几个服务器随便咋做，要求给个统一的web service接口对单独的车次进行访问和操作也完事了。土鳖局做得烂也不影响全国大局。
  • 每个车次每一天的一趟，都可以抽象成一个独立的产品，卖光了就完事。用分区表、分区视图区分开没个车次的每一趟，土一点每天自动生成一个新表也无所谓。1000个人的车次算10万人抢票，关系数据库的锁定和资源抢占也不算啥大事，至少不影响其他车次和本车次不是这一趟的业务。

前端的HTTP服务，搞一些CDN和分布式，搞搞优化，用平民级别的手段，再大的PV也不会死到哪去。

总之还是觉得火车票还是很简单的电子商务模型，没什么复杂型号、组合销售、协议折扣之类的幺蛾子；每个客户都是盯准目标直接来拿货的；每个货（车次当天的一趟）有效期都有固定的区间，固定的数量。总之给我这种善于糊弄客户和老板的民企专家很大的想象空间去琢磨各种大胆的tradeoff。欢迎铁道部采用我的方案，再出问题的时候你们再来找我去编一套骗人的嗑儿，我经验更丰富，保证不像你们自己整的那么欠揍。

* Filed by charlie at 12:51 am under Engineer,Life
* 2 Comments

Random posts