“12306”的架构到底有多牛逼？

12306比淘宝复杂多了。。。。

可后台架构逻辑确实牛啊

淘宝是整卖，12306是零卖，比如一盒饼干，淘宝直接卖一盒，而12306是拆开卖，比如100盒饼干，里面200片饼干，同时很多人不同需求，有的只买1-6片，有的只买9-20片就算并发，淘宝最多也就200个组合，12306最多会有100*200个组合

业务量最大的春运，热门的线路，比如北京始发出来的，好多都是区间限售。这样的话，这种拆开卖的问题会好一些吗？

一直有个疑问。我理解12306库存和淘宝不一样。但是服务器压力最大的春运时期，最热门的线路，放票的那一刻，好多都是区间限售。例如有时候放票那一刻，不能买中途站上下车的票。这样算来，库存变化复杂的问题会有改善吗？如果没有是为什么，如果有改善，又是有多大的改善？

每一条列车一次运营方向每一段每一个位置当成一个SKU,库存是1,全部Load到内存,CAS扣减,如果A站到D站,先从原子读出ABCD的SKU,库存任意一个没有就立即返回失败,库存在就CAS扣减ABCD,任意一个扣减失败(CAS比较原值不为1)则CAS回滚(原子增),全部扣减成功后写异步日志，异步写库命令（DPDK发到专门写库的服务器）,这样不存在锁,可以并发进行操作,但需要小心处理ABA问题,这样只需要几条通道(得用DPDK来做)接入这个库存扣减的服务器就行。不同的路线就复制一套这样的系统来处理。当然，高频多核单机高性能，当然宕机可能会损失部分异步没有发出写库命令的订单。

java知音专栏怎么都是go的代码[捂脸]

12306各区间的分配是业务控制的，一趟路线有多少种运行区间就有多少个库，各库之间互不关联。
同理退改签也是业务控制的，窗口售票和互联网售票也是分开的。我为什么会发现这个事情，因为我有两次在火车站买票，恰好都是在退票窗口隔壁，恰好都遇到人退票，恰好都是我要去的站。恰好售票员跟我说，你稍等一下隔壁把票退了我卖给你。

不同车辆完全独立吧，一个车的不同座位也完全独立吧，这一下不就分很细了吗？

能调查下再写吗？是靠美国的一种内存数据库才扛住的