浅谈12306核心模型设计思路和架构设计

   浅谈12306核心模型设计思路和架构设计

出处：观察者网站+cnblogs

网址：http://m.guancha.cn/Science + http://www.cnblogs.com/netfocus

1月11日起，12306网站开始销售除夕当日火车票。每到此时，铁路系统唯一的官方购票网站12306就会成为众矢之的。知乎网站曾有问答，辨析如果将12306 外包给阿里巴巴、IBM 等大企业做是否可行，网站如下：http://www.zhihu.com/topic/19793213/top-answers；下面摘录了两篇相关文章，讨论了12306的核心设计思路及架构设计。

---

第一篇：前淘宝工程师发帖谈12306：曾嗤之以鼻 现在认为几乎是奇迹

本人淘宝技术专家，2012年在一家百强民企做电商副总，当时在极为艰苦的条件下带队开发了一个B2C（企业针对个人开展的电子商务活动——观察者网注）网站，走支付宝和银联支付通道，年营业额千万级（作者注：当然实在太少了，我只是说这个网站投入了实际的运营）。

也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足12306的需求。 

在平时，12306也就是个正常的电商网站。但一到黄金周，12306就是一个全站所有商品都秒杀，所有SKU都是动态库存的变态。即使不考虑线下既有的电话、代售点等渠道，要实现一个12306，最少最少也是千万级别的硬件投入（作者注：这是当时的估算，没有精算，可能与实际相差较大，总之，我说得不一定对，12306的业务也许没我说的那么复杂，但也绝不是某些人喷的那么简单），软件和人力另算。那些叫嚣只要40台服务器、只要2个架构师4个程序员、大谈分库分表和前端CDN的人们，只是纸上谈兵罢了。所谓初生牛犊不怕虎，做了三年CMS和BBS，就以这个经验来喷12306，未免太天真了。

媒体人喷12306，是他们不懂技术，没有能力和耐心来分析背后的难度。技术人员喷，则是因为大部分的技术人员在短时间思考时，容易陷入过于乐观的误区，经典的例子就是估算工作量，程序员们往往容易估算出一个超短的工期，把写程序的工作乐观地想象成了打字员照稿敲键盘的工作。

知乎那篇文章，我觉得不是洗地。排名第一和第二的答案都说得很客观。淘宝技术是比12306强大很多倍，淘宝现在的系统也是花了10倍于12306的钱、时间和人才做起来的。根本原因还是铁路运力不能满足春运需求，淘宝也解决不了这个问题。

12306这一年来进步非常大。从前段动画验证码、分时段抢票，到后端去小型机、虚拟化、内存数据库的运用。可以说，12306是中国政府机关做的最强大的网站（电商系统），能在短短一两年内做出这样的改变，几乎是个奇迹，就连一些市场化的民企都望尘莫及，甚至一些上市公司都比不上它！（比如51job和ctrip）。

事非经过不知难，在网上批判12306的人，大部分还是形成了【国企=垄断+腐败+低效】的思维定势。小部分是真的轻视了它的难度。

至于12306一期工程3个亿（含硬件）贵不贵我不评价，我只提供一个数字供参考，百度一年的研发费用（不含硬件）是10亿，这个数字来自百度财报。网上能查到。3亿看起来好大一个数字，真用到超大型的电商系统、搜索引擎系统里面，其实也不算什么天文数字了。

再解释一下，为什么秒杀压力大，以及为什么12306的动态库存很复杂。

先说秒杀。2013年12月25日前后，天猫搞了一个圣诞季积分兑换活动，持续几天。25号上午10点12分，放出了15000个天猫魔盒（淘宝集市有人卖，大概190-230块），从成交记录上看，是19秒内全部抢完。

实际上，我也参加秒杀了，那天的题目特别简单（请输入xxx汉字的拼音首字母），我应该是5秒内答题完成并提交订单，结果告诉我排队的人太多，挤不进去，并提示14秒以后重试。人太多就是因为题目太简单了，门槛越低，5秒内挤进去的人也越多嘛，如果题目换成【2克浓度为3%的U235在大亚湾核电站能发多少KW的电】，5分钟之内也不会有1万5千人跟我竞争。

我想，14秒以后哪还有我的事情呀，于是重新答题秒杀，结果出现了服务器错误的页面。反复刷新几次，就告诉秒杀结束了。在群里问了一下同事，有不到10个人回答我，都说没秒到（也可能秒到的人闷声发大财，不回复我）。

淘宝是什么技术水平呢，淘宝有至少4000技术人员，至少4万台服务器（这都是两年前的公开数据了，按规定可以谈论），2013年11月11日成交额351亿，2012年全年成交额超过1万亿。淘宝拥有各种自主研发团队：服务器、交换机（网上可以搜索到淘宝公开的绿色服务器开放标准）；操作系统（LinuxKerneltaobao版，yunos手机操作系统是阿里云的，暂时不计入）、Web服务器（Tengine）、Java语言虚拟机（JVMtaobao版）、数据库（MySQL内核taobao版，google和facebook也有自己的版本，HBase淘宝版、还有自己全部从头 开发的OceanBase）、负载均衡器（LVS，LVS始创人就在淘宝，担任研究员）、Java运行容器（Jboss，其创始人之一，王文彬，也在淘宝，担任副总裁）。淘宝还有数不清的开源项目和中间件，如高性能Java通信中间件HSF、分布式数据库中间件TDDL、异步消息系统notify等等等等。

以淘宝这样的技术水平，也不能做到秒杀时让每个用户都没有拥挤感，为什么呢？一是要尊重物理原理，一台服务器一秒钟能承受的计算量是有极限的，任你怎么优化，采用多高效的算法和编程语言，都突破不了某个极限，比方说汽车发动机驱动的F1赛车至今也不能突破400公里的时速（超音速推进号那个1千多公里的时速不能算，那是飞机引擎驱动的）。再往深了说，就不容易懂了。感兴趣的可以从著名的C10K问题开始看起。

二是要考虑经济效益，十一黄金周的时候，北京主城区到八达岭长城的路堵得严严实实，但不能因为黄金周的高峰，就把这段路修成长安街那样10车道的高速公路。否则的话，花费天文数字（真的是天文数字，12306那3个亿大概只够修1-3公里）。修了一段路，黄金周是可以飙到80公里/小时了，可平时呢，拿来给两边的居民晒谷子？

淘宝目前的硬件和带宽数量，已经超出日常运营的需求了，就是留了相当大的余量给大促销（众所周知的是双十一，双十二，其实基本每个季度都有大促销，每个月都有促销，甚至天天都在促销——聚划算）。amazon当年就是为了应对黑色星期五的大促销购置了大量的服务器，平时订单量没那么大了，amazon就把富余的服务器拿来搞云计算了。顺便说一下，阿里云是当今中国第一世界数一数二的云计算服务商，和amazon走的路也有点像。

再说动态库存。

淘宝秒杀天猫魔盒的时候，只有一个商品（行话叫做SKU），它的库存是15000个。有一个人秒杀到了，库存就减1，19秒卖完的，一秒要成功产生789个订单（下订单的请求可能是8万个，只是可能啊，非实际数字，也可能是1万个，用于说明一下壮观程度）。想象一下，你在广场上卖火车票，一秒钟有8万人举着钱对你喊：卖给我！

上过大学的人都知道，比秒小的时间单位还有毫秒、皮秒、飞秒。但交易系统登记一个交易可不像原子绕着原子核跑一圈那么简单，它要做这些事：检查是否恶意访问、取到系统时间、取到顾客默认收货地址、核对顾客秒杀资格（当时的规定是天猫T2.T3达人）、生成订单号、把顾客ID系统时间订单号收货地址写入订单系统、扣除顾客天猫积分、商品库存减一、给顾客打标记（每人只能秒一个，下次不能秒了）等等，这每一件事都要花费毫秒级别的时间，这些操作加起来的时间可能是接近1秒级别的，但由于淘宝的服务器比较强悍，而且采用了分布式和集群技术，结果比1秒理想一点。但即使有1万台服务器，也不能把这个时间稀释成万分之一秒，因为，商品只有一种，它有15000个库存，对应的数据库记录只有一行，所有的交易请求都要到这里来处理。

能不能把这15000个拆分成5000个商品并分配到5000台服务器上呢？那样不就可以5000台服务器同时处理了吗？答案是不能，首先，5000个商品，意味着有5000个商品详情页，5000个购买按钮，这对前期的营销、引流是个灾难。基本上就没法做引流入口了，显然这违背了商业管理原则，人为增加了信息混乱程度。其次，天猫魔盒秒杀也不是啥大事，即使按官方标价399元来计算，也就6百万的交易。如果6百万的交易要花费那么大的配套成本，那就太不划算了。再次，淘宝有十几亿商品，这十几亿商品的展示交易和管理，本来就是分布到上万台服务器上去了。没有必要再把每个商品按库存拆成多个商品了。

这789人抢到了，还不一定会付款（99积分换天猫魔盒还好一点，不需要去网银，成本也极低，大部分是会付款的，3999秒杀iPhone5S就不一定，有人可能网银有问题，有人可能改变主意不想要了），所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们，会认为还有机会，继续在前台刷一会儿，最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。

一分钟过去了，服务器终于可以喘口气了吧？等等，还有超卖，原来，某两台服务器在同一毫秒都拿到了锁，都去减了库存，15000个库存，被下了15500个订单，又得取消一部分订单。。。如果采用单线程独占锁，是可以做到同时只有一个服务器线程减库存的，但那样就对并发高峰的能力就差了好多了。8万人举着钱，可能只有8个人能下单成功，这个拥挤狂热的抢购就要持续10分钟以上。平时秒个天猫魔盒，10分钟也就10分钟吧，双十一就惨了，收银台一下子减少了90%，还想做到350亿，要么做梦，要么再加10倍服务器和带宽。所以，商业是不完美的，要在绝对正确和绝对的快速之间做个取舍，保证相对快速又极为正确，允许一定的库存错误和超卖（具体允许多少我也不知道）。

好了，讲了这半天淘宝，可以说12306了吧？我以北京西到深圳北的G71次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫G72），它有17个站（北京西是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员（包括某些中等规模公司的专家、CTO）就是在这里栽第一个跟头的。

实际上，G71有136*3=408种商品（408个SKU），怎么算来的？请看：

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

好了，再看出票时怎么减库存，由于商务、一等、二等三种座位数是独立的，库存操作也是一样的，下文我就不再提座位的差别的，只讨论出发与到达站。另外，下文说的是理论世界的模型，不是说12306的数据库就是这么设计的。

旅客A买了一张北京西（01号站）到保定东（02号站）的，那【北京西到保定东】这个商品的库存就要减一，同时，北京西到石家庄、郑州、武汉、长沙、广州、虎门、深圳等15个站台的商品库存也要减一，也就是说，出一张北京到保定东的票，实际上要减16个商品的库存！

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

当然，也不是每一张票都的库存都完全这样实时计算，可以根据往年的运营情况，在黄金周这样的高峰时段，预先对票做一些分配，比如北京到武汉的长途多一点，保定到石家庄的短途少一点。我没有证据证实铁道部这样做了，但我相信，在还没有12306网站的时候，铁道部就有这种人工预分配的策略了。

想象一下，8万人举着钱对你高喊：卖给我。你好不容易在钱堆里找到一只手，拿了他的钱，转身找120个同事，告诉他们减库存，而这 120个同事也和你一样被8万人围着；也和你一样，每卖出一个商品要找几十个人减库存……这就是12306动态库存的变态之处。比你平时买东西的任何网站的库存机制都复杂几十上百倍。 

再说一下抢票插件，机器永远比人快，当你好不容易从8万人里突出重围，来到了柜台前，你发现，我操，来了10万根绑着钱的竹竿，而且当有退票出来的时候，你要闯过3层人肉才能接近柜台，竹竿在8个人身后一伸，钱就到了柜台前。你低头看了一眼手机，票就没了，竹竿却永远在那里伸着，永不低头，永不眨眼。如果没有这10万根竹竿，虽然你很可能还是抢不到票，但不至于沮丧成这样：我TM为什么总是手最慢的一个？！！

防机器人抢票，也不是加个图片验证码那么简单。我写过文章系统性分析过，图片验证码有6种机器暴力破解的办法，抢票插件用的是我说的第三种，OCR识别。Google采用的Wave波形字母已经能比较好地防住机器OCR了，ems.com.cn上的验证码就是反面教材，机器OCR成功率接近100%，12306的比ems的图片验证码强一点。不过，验证码设置得复杂一点吧，人们要喷：这只是便宜大学生和办公室白领，农民工连26个字母都认不齐，怎么搞？搞动画验证码吧，也有人喷，视力不好的人怎么办？最后验证码搞得太简单了，皆大欢喜了，其实最高兴的是开发抢票插件的公司。

就算采用了机器完全不可能识别的验证码，也防不住社会工程学的破解办法。招募一堆网吧打游戏的青少年朋友，每成功输入50个验证码给1块钱，或者等值的虚拟货币、游戏装备，我保证想赚这个钱的人数不胜数。这点钱对转卖车票的利润而言，是可以接受的成本。有没有什么技术可以防住社会工程学的破解办法呢？能防住网吧青少年的验证码只有【2克浓度为3%的U235在大亚湾核电站能发多少KW的电】。

以上讨论只是把12306当成和淘宝一样没有历史包袱从零起步的交易系统，实际上，它不是，它后面的票池，还有电话售票、火车站售票、代售点售票等多个传统渠道要服务。除了客运服务，12306还有全国最大（很可能也是全球最大）的大宗物资货运系统。

架空政策（包括定价政策、警方打击黄牛政策、身份验证政策）谈技术，是不可能解决春运抢票困局的，要想让春运的时候每个人在12306抢票都毫无拥挤感（但不一定能抢到票，铁路运力摆在那），那就是逼着12306买一大堆服务器对付春运，春运过去后，成为跟amazon一样牛逼的云计算服务商。和逼北京修一条10车道的高速公路去八达岭长城一个道理。

目前的12306技术上是还有问题，比如，抢票高峰，输入个身份证号和图片验证码都卡得要死（本人亲测），服务器端繁忙，你浏览器端卡什么呀。

但人家在进步。相信2014年春运的时候，技术已经不再是一票难求的主要问题。在铁路运力不可能神速增加的情况下，要做到春运更公平地买票，需要停靠政策调整。

下文针对的是春节国庆这种非常暑期。其它时期，大部分线路保持现状就行了，问题不大，极少部分票源紧张的线路可以按春运处理：

1、拍卖法，价高者得之

当硬座票拍出飞机票价格的时候，相信票就不难买了（可惜就是贵了），也没有那么多黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的，淘宝的拍卖系统可以帮忙，浙江省高院在淘宝拍卖一年多，成交26亿。

可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了，何况是拍卖。再说，火车票毕竟是生存之刚需，票价20年来不涨本来就有照顾补贴的成分在里面，全拍卖可能也是不妥当。

2、抽签法，运气好者得之

开车前2个月开放报名，开车前7天抽签，中途可取消。预存票款，抽不中退款。上传身份证和正脸自拍照，机器核对。这样的话，拦截黄牛的成功率就高很多了，黄牛可以预存票款，可以找到大量真实身份证号，你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给你试试？即使有人真想找黄牛，给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多，黄牛成本提高，还不一定搞得到票。反正都是碰运气，我想真正的消费者还是会选择自己先去碰运气吧。

这个方法实施难度也大，无论怎么设计抽签规则，必然有人大叫“有黑幕，不要相信政府”。

开车前7天出抽签结果，改变行程的人应该在7天前就能决定改还是不改了。没抽到的也还有时间想别的办法。当然不一定是7天，15天，10天也可以，具体几天要有数据模型来算。

3、拍卖+抽签

软卧、高铁商务座等高价位的，拍卖，反正买这个的是经济能力相对较强的。那就拼谁经济能力更强吧。

4、凭身份证进站，车票跟发票一样，是报销凭证，不是进站凭证；退票后钱进入12306账户，不可提现，只可该乘客下次乘车用；黄金周期间，个人账号最多订购10张票。这个办法可以打击黄牛囤票再转卖；运行一段时间后，按账户余额弄个排行榜就知道谁是黄牛，可惜这个需要车站设备改造配合。

第二篇：浅谈12306核心模型设计思路和架构设计

春节期间，无意中看到一篇文章， 文中讲到12306的业务复杂度远远比淘宝天猫这种电商网站要复杂。后来自己想想，也确实如此。所以，很想挑战一下12306这个系统的核心领域模型的设计。一般的电商网站，购买都是基于商品的概念，每个商品有一定量的库存，用户的购买行为是针对商品的。当用户发起购买行为时，系统只需要生成订单并对用户要购买的商品减库存即可。但是，12306就不是那么简单了，具体复杂在哪里，我下面会进一步分析。

另外一个让我写这篇文章的原因，是我发现也许是否是因为目前12306的核心领域模型设计的不够好，导致用户购票时要处理的业务逻辑异常复杂，维护数据一致性的难度也几百倍的上升，同时面对高并发的订票也难以支持很高的TPS。我觉得，越是复杂的业务，就越要重视业务分析，重视领域模型的抽象和设计。如果不假思索，凭以往经验行事，则很可能会被以往的设计经验先入为主，陷入死胡同。我发现技术人员往往更注重技术层面的解决方案，比如一上来就分析如何集群、如何负载均衡、如何排队、如何分库分表、如何用锁，如何用缓存等技术问题，而忽略了最根本的业务层面的思考，如分析业务、领域建模。我认为越是复杂的业务系统，则越要设计一个健壮的领域模型。如果一个系统的架构我们设计错了，还有补救的余地，因为架构最终沉淀的只是代码，调整架构即可（一个系统的架构本身就是不断演进的）；而如果领域模型设计错了，那要补救的代价是非常大的，因为领域模型沉淀的是数据结构及其对应的大量数据，对任何一个大型系统，要改核心领域模型都是成本非常高的。

本文的重点不是在如何解决高并发的问题，而是希望从业务角度去分析，12306的理想模型应该是怎么样的。网上目前谈12306的文章貌似都是千篇一律的只谈技术，不谈业务分析和如何建模的。所以我想写一下自己的设计和大家交流学习。

需求概述

12306这个系统，核心要解决的问题是网上售票。涉及到2个角色使用该系统：用户、铁道部。用户的核心诉求是查询余票、购票；铁道部的核心诉求是售票。购票和售票其实是一个场景，对用户来说是购票，对铁道部来说是售票。因此，我们要设计一个在线的网站系统，解决用户的查询余票、购票，以及铁道部的售票这3个核心诉求。看起来，这3个场景都是围绕火车票展开的。

查询余票：用户输入出发地、目的地、出发日三个条件，查询可能存在的车次，用户可以看到每个车次经过的站点名称，以及每种座位的余票数量。

购票：购票分为订票和付款两个阶段，本文重点分析订票的模型设计和实现思路。

其实还有很多其他的需求，比如给不同的车次设定销售座位数配额，以及不同的区段设置不同的限额。但相比前面两个需求来说，我觉得这个需求相对次要一些。

需求分析

确实，12306也是一个电商系统，而且看起来商品就是票了。因为如果把一张票看成是一个商品，那购票就类似于购买商品，然后每张票都有库存，商品也有库存的概念。但是如果我们仔细想想，会发现12306要复杂很多，因为我们无法预先确定好所有的票，如果非要确定，那只能通过穷举法了。

我们以北京西到深圳北的G71车次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫G72），它有17个站（北京西是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员（包括某些中等规模公司的专家、CTO）就是在这里栽第一个跟头的。实际上，G71有136*3=408种商品（408个 SKU），怎么算来的？如下：

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

为了方便后面的讨论，我们先明确一下票是什么？一张票的核心信息包括：出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证，该凭证表示持有它的人可以坐某个车次的某个座位号，从某地到某地。所以，一张票，对用户来说是一个凭证，对铁道部来说是一个承诺；那对系统来说是什么呢？不知道。这就是我们要分析业务，领域建模的原因，我们再继续思考吧。

明白了票的核心信息后，我们再看看G71这个车次的高铁，可以卖多少张票？讨论前先说明一下，一辆火车的物理座位数（站票也可以看成是一种座位，因为站票也有数量配额）不等于可用的最大配合。所有的物理座位不可能都通过12306网站来销售，而是只会销售一部分，比如40%。其余的还是会通过线下的方式销售。不仅如此，可能有些站点上车的人会比较多，有些比较少，所以我们还会给不同的区间配置不同的限额。比如D31北京南至上海共有765张，北京南有260张，杨柳青有80张，泰安有76张。如果杨柳青的80张票售完就会显示无票，就算其他站有票也会显示无票的。每个车次肯定会有各种座位的配额和限额的配置的，这种配置我目前无法预料，但我已经把这些规则都封装近车次聚合根里了，所有的配置策略都是基于座位类型、站点、区间配置的。关于票的配置抽象出来，我觉得主要有3种：1）某个区段最多允许出多少张；2）某个区段最少允许出多少张；3）某个站点上车的最多多少张；当用户订票时，把用户指定的区段和这3种配置条件进行比较，3个条件都满足，则可以出票。不满足，则认为无票了。下面举个例子：

ABCDEFG，这是所有站点。座位总配额是100，假设B站点上车，E站下车的人比较少，那我们就可以设定BE这个区段最多只能出10张票。所以，只要是用户的订票是在这个区段内的，就最多出10张。再比如，一列车次，总共100个座位配额，希望全程票最少满足80张，那我们只要给AG这个区段设定最少80张。那任何订票请求，如果是子区间的，就不能超过100-80，即20张。这两种条件必须同时满足，才允许出票。

但是，不管如何做配额和限额，我们总是针对某个车次进行配置，这些配置只是车次内部售票时的一些额外的判断条件（业务规则），不影响车次模型的核心地位和对外暴露的功能。所以，为了本文讨论的清楚起见，我后续的讨论都不涉及配额和限额的问题，而是认为任何区段都可以享受火车最大的物理座位数。

并且，为了讨论问题方便，我们减少一些站点来讨论。假设某个车次有A,B,C,D四个站点。那001这个人购买了A,B这个区间，系统会分配给 001一个座位x；但是因为001坐到B站点后会下车，所以相当于x这个座位又空出来了，也就是说，从B站点开始，系统又可以认为x这个座位是可用的。所以，我们得出结论：同一个座位，其实可以同时出售AB,BC这两张票。通过这个简单的分析，我们知道，一列火车虽然只有有限的座位数，比如1000个座位。但可以卖出的票远远不止1000个。还是以A,B,C,D四个站点为例，假如火车总共有1000个座位，那AB可以卖1000张，BC也可以卖1000张，同样，CD也可以卖1000张。也就是说，理论上最多可以卖出3000张票。但是如果换一种卖法，所有人都是买ABCD的票，也就是说所有的票都是经过所有站点的，那就是最多只能卖出1000张票了。而实际的场景，一定是介于1000到3000之间。然后实际的G71这个车次，有17个站，那到底可以卖出多少个票，大家应该可以算了吧。理论上这17个站中的任意两个站点之间所形成的线段，都可以出售为一张票。我数学不好，算不太清楚，麻烦有数学好的人帮我算算，呵呵。

通过上面的分析，我们知道一张票的本质是某个车次的某一段区间（一条线段），这个区间包含了若干个站点。然后我们还发现，只要区间不重叠，那座位就不会发生竞争，可以被回收利用，也就是说，可以同时预先出售。

另外，经过更深入的分析，我们还发现区间有4种关系：1）不重叠；2）部分重叠；3）完全重叠；4）覆盖；不重叠的情况我们已经讨论过了，而覆盖也是重叠的一种。所以我们发现如果重叠，比如有两个区间发生重叠，那重叠部分的区间（可能夸一个或多个站点）是在争抢座位的。因为假设一列火车有100个座位，那每个原子区间（两个相邻站点的连线），最多允许重叠99次。

所以，经过上面的分析，我们知道了一个车次能够出售一张车票的核心业务规则是什么？就是：这张车票所包含的每个原子区间的重叠次数加1都不能超过车次的总座位数，实际上重叠次数+1也可以理解为线段的厚度。

模型设计

上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型，来快速实现购票的需求，重点是怎么设计商品聚合以及减库存的逻辑。

传统电商的思路

如果按照普通电商的思路，把票（站点区间）设计为商品（聚合根），然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多（上面的G71就有408个）；另一方面，即便枚举出来了，一次购票也一定会影响非常多其他聚合根的库存数量（只要被部分或全部重叠的区间都受影响）。这样的一次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里，这不是为难数据库吗？而且，这种设计必然带来大量的事务的并发冲突，很可能导致数据库死锁。总之，我认为这种是典型的由于领域模型的设计错误，导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题，只能排队单线程处理，但是仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。听说12306是采用了Pivotal Gemfire这种高大上的内存数据库，我对这个不太了解。我不可想象要是不使用内存数据库，他们要怎么实现车次内的票之间的数据强一致性（就是保证所有出售的票都是符合上面讨论的业务规则的）？

所以，这种设计，我个人认为是思维定势了，把火车票看成是普通电商的商品来看待。所以，我们有时做设计又要依赖于经验，又要不能被以往经验所束缚，真的不容易，关键还是要根据具体的业务场景多多深入分析，尽量分析抽象出问题的本质出来，这样才能对症下药。那是否有其他的设计思路呢？

我的思路

聚合设计

通过上面的分析我们知道，其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。我们看看一个车次包含了哪些信息？一个车次包括了：1）车次名称，如G71；2）座位数，实际座位数会分类型，比如商务座20个，一等座200个；二等座500个；我们这里为了简化问题，可以暂时忽略类型，我认为这个类型不影响核心的模型的设计决策。需要格外注意的是：这里的座位数不要理解为真实的物理座位数，很有可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过12306来出售，而是只出售一部分，具体出售多少，要由工作人员人工指定。3）经过的站点信息（包括站点的ID、站点名称等），注意：车次还会记录这些站点之间的顺序关系；4）出发时间；看过GRASP九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过DDD的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。

经过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部自然可以维护所有的原子区间，以及每个原子区间的可用票数（相当于是库存数）。当一个原子区间的可用票数为0的时候，意味着火车针对这个区间的票已经卖完了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说，这很简单，因为只是几次简单的内存操作而已，耗时可以忽略。一列火车假如有ABCD四个站点，那原子区间就是3个。对于G71，则是16个。

 

怎么判断是否能出票

基于上面的聚合设计，出票时扣减库存的逻辑是：根据订单信息，拿到出发地和目的地，然后获取这段区间里的所有的原子区间。然后尝试将每个原子区间的可用票数减1，如果所有的原子区间都够减，则购票成功；否则购票失败，提示用户该票已经卖完了。是不是很简单呢？知道了出票的逻辑，那退票的逻辑也就很简单了，就是把这个票的所有原子区间的可用票数加1就OK了。如果我们从线段的厚度的角度去考虑，那出票时，每个原子区间的厚度就是+1，退票时就是减一。就是相反的操作，但本质是一样的。

所以，通过这样的思路，我们将一次订票的处理控制在了一个聚合根里，用聚合根内的强一致性的特性保证了订票处理的强一致性，同时也保证了性能，免去了并发冲突的可能性。传统电商那种把票单做类似商品的核心聚合根的设计，我当时第一眼看到就觉得不妥。因为这违背了DDD强调的强一致性应该由聚合根来保证、聚合根之间的最终一致性通过Saga来保证的原则。

还有一个很重要的概念我想说一下我的看法，就是座位和区间的关系。因为有些朋友和我讲，考虑座位号的问题，虽然都能减1，座位号也必须是同一个。我觉得座位是全局共享的，和区段无关（也许我的理解完全有误，请大家指正）。座位是一个物理概念，一个用户成功购买了一张票后，座位就会少一个，一张票唯一对应一个座位，但是一个座位有可能会对应多张票；而区间是一个逻辑上的概念，区间的作用有两个：1）表示票的出发地和目的地；2）记录票的可用数额。如果区间能连通（即该区间内的每个原子区间的可用数额都大于0），则表示允许拥有一个座位。所以，我觉得座位和票（区间）是两个维度的概念。

如何为票分配座位

我觉得车次聚合根内部应该维护所有该车次已经售出的票，已经出售的票的的本质是区间和座位的对应关系。系统处理订票时，用户提交过来的是一段区间。所以，系统应该做两个事情：

1. 先根据区间去判断是否有可用的座位；

2. 如果有可用座位，则再通过算法去选择一个可用的座位；

当得到一个可用座位后，就可以生成一张票了，然后保存这个票到车次聚合根内部即可。

下面举个例子：

假设现在的情况是座位有3个，站点有4个
座位：1,2,3
站点：abcd

票的卖法1：
票1：ab,1
票2：bc,2
票3：cd,3
票4：ac,3
票5：bd,1
这种选座位的方式应该比较高效，因为总是优先从座位池里去拿座位，只有在万不得已的时候才会去回收可重复利用的票。上面的4，5两个票，就是考虑回收利用的结果。

票的卖法2：
票1：ab,1
票2：bc,1
票3：cd,1
票4：ac,2
票5：bd,3
这种选座位的方式应该相对低效，因为总是优先会去扫描是否有可回收的座位，而扫描相对直接从座位池里去拿票总是成本相对要高的。上面的2，3两个票，就是考虑回收利用的结果。

但是，优先从座位池里拿票的算法有缺陷，就是会出现虽然第一步判断认为有可用的座位，但是这个座位可能不是全程都是同一个座位。举例：
假设现在的情况是座位有3个，站点有4个
座位：1,2,3
站点：abcd

票的卖法3：
票1：ab,1
票2：bc,2
票3：cd,3

现在如果有人要买ad的票，那可用的座位有2，或者3。但是无论是2还是3，都要这个乘客中途换车位。比如卖给他座位2，那他ab是坐的座位2，但是bc的时候要坐座位1的。否则拿票2的那个人上车时，发现座位2已经有人了。而通过优先回收利用的算法，是没这个问题的。

所以，从上面的分析我们也知道选座位的算法该怎么写了，就是采用优先回收利用座位的算法。我认为不管我们这里怎么设计算法，都不影响大局，因为这一切都只发生在车次聚合根内部，这就是预先设计好聚合根，明确出票职责在哪个对象上的好处。

 

模型分析总结

1. 我认为票不是核心聚合根，票只是一次出票的结果，一个凭证而已。

2. 12306真正的核心聚合根应该是车次，车次具有出票的职责，一次出票具体做的事情有：

   • 判断是否可出票；

   • 选择可用的座位；

   • 更新一次出票时所有原子区间的可用票数，用于判断下次是否能出票；

   • 维护所有已售出的票，用于为选择可用座位提供依据；

通过这样的模型设计，我们可以确保一次出票处理只会在一个车次聚合根内进行。这样的好处是：

1. 不需要依赖数据库事务就能实现数据修改的强一致性，因为所有修改只在一个聚合根内发生；

2. 在保证数据强一致性的同时还能提供很高的并发处理能力，具体设计见下面的架构设计；

 

架构设计（非本文重点，没兴趣的朋友可以略过）

我觉得12306这样的业务场景，非常适合使用CQRS架构；因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用CQRS架构。而且应该使用数据存储也分离的CQRS。这样CQ两端才可以完全不需要顾及对方的问题，各自优化自己的问题即可。我们可以在C端使用DDD领域模型的思路，用良好设计的领域模型实现复杂的业务规则和业务逻辑。而Q端则使用分布式缓存方案，实现可伸缩的查询能力。

订票的实现思路

同时借助像ENode这样的框架，我们可以实现in-memory + Event Sourcing的架构。Event Sourcing技术，可以让领域模型的所有状态修改的持久化统一起来，本来要用ORM的方式保存聚合根最新状态的，现在只需要简单的通用的方式保存一个事件即可（一次订票只涉及一个车次聚合根的修改，修改只产生一个事件，只需要持久化一个事件（一个JSON串）即可，保证了高性能，无须依赖事务，而且通过ENode可以解决并发问题）。我们只要保存了聚合根每次变化的事件（事件的结构怎么设计，本文不做多的介绍了，大家可以思考下），就相当于保存了聚合根的最新状态。而正是由于Event Sourcing技术的引入，让我们的模型可以一直存活在内存中，即可以使用in-memory技术。不要小看in-memory技术，in-memory技术在某些方面对提高命令的处理性能非常有帮助。比如就以我们车次聚合根处理出票的逻辑，假设某个车次有大量的命令发送到分布式消息队列，然后有一台机器订阅了这个队列的消息，然后这台机器处理这个车次的订票命令时，由于这个车次聚合根一直在内存，所以就省去了每次要去数据库取出聚合根的步骤，相当于少了一次数据库IO。这样的好处是，因为一个车次能够真正出售的票是有限的，因为座位就那么几个，比如就1000个座位，估计一般正常情况也就出个2000个左右的票吧（具体能出多少张票要取决于区间的相交程度，上面分析过）。也就是说，这个聚合根只会产生2000个事件，也就是说只会有2000个订票命令的处理是会产生事件，并持久化事件；而其余的大量命令，因为车次在内存计算后发现没有余票了，就不会做任何修改，也不会产生领域事件，这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。

另外一个问题我觉得还需要提一下，因为用户订票成功后，还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下，系统会自动释放该用户之前订购的票。所以基于这样的需求，我们在业务上需要支持业务级别的2pc。即先预扣库存，也就是先占住这张票一定时间（比如15分钟），然后付款成功后再真实给你这张票，系统做真正的库存修改。通过这样的预扣处理，可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类似，我就不多展开了，我之前写的Conference案例也是这样的思路，大家有兴趣的可以去看一下我之前录制的视频。

查询余票的实现思路

我觉得余票的查询的实现相对简单。虽然对于12306来说，查询的请求占了80%，提交订单的请求只占20%。但查询由于对数据没有修改，所以我们完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的key即可；缓存key的多少要看成本，如果所有可能的查询都设计对应的key，那时间复杂度为1，查询性能自然高；但代价也大，因为key多了。如果想key少一点，那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后，缓存的更新无非就是：自动失效、定时更新、主动通知3种。通过CQRS架构，由于CQ两端是事件驱动的，当C端有任何状态变化，都会产生对应的事件去通知Q端，所以我们几乎可以做到Q端的准实时更新。

同时由于CQ两端的完全解耦，Q端我们可以设计多种存储，如数据库和缓存（Redis等）；数据库用于线下维护关系型数据，缓存用户实时查询。数据库和缓存的更新速度相互不受影响，因为是并行的。对同一个事件，可以10台机器负责更新缓存，100台机器负责更新数据库。即便数据库的更新很慢，也不会影响缓存的更新进度。这就是CQRS架构的好处，CQ的架构完全不同，且我们随时可以重建一种新的Q端存储。不知道大家体会到了没有？

关于缓存key的设计，我觉得主要从查询余票时传递的信息来考虑。12306的关键查询是：出发地、目的地、出发日期三个信息。我觉得有两种key的设计思路：1）直接设计了该查询条件的key，然后快速拿到车次信息，直接返回；这种方式就是要求我们系统已经枚举了所有车次的所有可能出现的票（区间）的缓存key，相信你一定知道这样的key是非常多的。2）不是枚举所有区间，而是把每个车次的每个原子区间（相邻的两个站点所连成的直线）的可用票 数作为key。这样，key就非常少了，因为车次假如有10000个，然后每个车次平均15个区间，那也就15W个key而已。当我们要查询时，只需要把用户输入的出发地和目的地之间的所有原子区间的可用票数都查出来，然后比较出最小可用票数的那个原子区间。则这个原子区间的可用票数就是用户输入的区间的可用票数了。当然，到这里我提到考虑出发日期。我认为出发日期是用来决定具体是哪个车次聚合根的。同一个车次，不同的日期，对应的聚合根实例是不同的，即便是同一天，也可能有多个车次聚合根，因为有些车次一天有几班的，比如上午9点发车的一班，下午3点发车的一般。所以，我们也只要把日期也作为缓存key的一部分即可。