12306相关问题讨论记录

        缘起：事情起源于网上的一篇文章，宣称要为12306说几句公道话。其中有一段是这么说的：

实际上，G71有136 * 3 = 408种商品（408个SKU），怎么算来的？请看： 如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品， 同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136种票：16+15+14....+2+1=136。每种票都有3种座位，一共是408个商品。

    

这 还不是最复杂的，如果旅客B买了一张北京西（01号站）到深圳北（17号站）的票，除了【北京西到深圳北】这个商品的库存要减一，北京西到保定东、石家 庄、郑州、武汉、长沙、广州、虎门等15个站台的商品库存也要减1，保定东到石家庄、郑州、武汉、长沙、广州、虎门、深圳北等15个站台的商品库存要减 1。。。总计要减库存的商品数是16+15+14+。。。。+1=120个。

        看完我就惊呆了，这也太复杂了吧！难怪人家说就是淘宝、京东的工程师架构师聘来也无济于事，因为这东西本身就复杂到令人乍舌的地步。

        （原文网址：[转帖]身为码农，为12306说两句公道话）

        刚看完的时候，我也有点晕，可回过头仔细想想又觉得不大对味儿，复杂度应该没那么高吧？应该有办法解决吧？然后就有了第一篇短文：

        12306 售票仓储结构的设计

        文章发出后收到许多质疑，有说带宽问题的，有说并发锁问题的，还有说数据库问题的，但我觉得最有价值的还是座位号和灾备问题，这都是我最初没有认真考虑的问题。当时只是觉得有办法解决这个所谓的“难题”。

        

        既然有人提问，就只好一一作答，于是陆续又有了后面的几篇文章。

        续篇：12306 火车售票系统的仓储结构设计

      再续：12306 火车售票系统的仓储引擎设计

        再再续：一张图搞定 12306 

        继续：12306