问如何看待春运票务系统的架构优化？

感觉题主上面说的太简单了些。

如上所说一般的电商网站，购买都是基于商品的概念，每个商品有一定量的库存，用户的购买行为是针对商品的。当用户发起购买行为时，系统只需要生成订单并对用户要购买的商品减库存即可。但是，12306就不是那么简单了，具体复杂在哪里，且听我慢慢分析：

如今的票务系统，核心要解决的问题是网上售票。涉及到2个角色使用该系统：用户、铁道部。用户的核心诉求是查询余票、购票；铁道部的核心诉求是售票。购票和售票其实是一个场景，对用户来说是购票，对铁道部来说是售票。

业务模型也大抵如此：

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

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

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

以北京西到深圳北的G72车次高铁为例，它有17个站（北京西是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员就是在这里栽第一个跟头的。实际上，G71有136*3=408种商品（408个SKU），怎么算来的？如下：

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

细思极恐，所以票务系统远远不是题主想的那么简单。

其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。

一个车次包括了：

1）车次名称，如G72；

2）座位数，实际座位数会分类型，比如商务座20个，一等座200个；二等座500个

3）经过的站点信息（包括站点的ID、站点名称等）

4）出发时间；看过GRASP九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过DDD的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。经过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部自然可以维护所有的原子区间，以及每个原子区间的可用票数（相当于是库存数）。当一个原子区间的可用票数为0的时候，意味着火车针对这个区间的票已经卖完了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。

我觉得12306这样的业务场景，非常适合使用CQRS架构；因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用CQRS架构。

CQRS架构模型如下：

下面来讨论下技术层面：

主要的技术模型推测是这样的：

要解决12306面对“高流量，高并发“的难题是需要从软件平台和应用系统层面出发，要实现“可扩展的应用云平台架构”，灵活和快速热部署的机制，才是真正解决高并发访问的根本。

12306承建单位-铁科院在此方面做很多改进，使用Pivotal Gemfire内存数据管理平台，重新设计和改造核心子系统，从用户登录，余票计算，票价计算，实名身份认证，到订单查询；这些改造后的业务子系统都能支持“按需弹性扩展”， 不再受限于原来关系型数据库无法做分布式扩展的问题。

这些一连串的改造，打通各个环节，实现“质”的大跃进， 也为未来使用混合云服务模式的架构打下良好的基础。

其中混合云设计的特点归纳如下：

1. 业务托管：

从整个购票流程来说，12306只是将部分流程的环节-“余票查询”业务交由云厂商提供服务，并不是“整个系统”按需扩容的托管，这与一般企业的业务托管有最大的差异。如何将“业务子系统“剥离整个系统独立作业， 再将数据结果传回系统，协同作业，这需要从应用系统框架设计着手。

2. 敏感资料的存放和安全性：

12306是公共服务平台，敏感性资料的保护和安全性是首要考虑因素。在混合云设计上，12306将这些资料存放在私有云的数据中心， 确保数据安全无虑。

3. 业务连续性，应用不中断的容灾设计：

双数据中心并行作业，不但可以分担高负载运行，而且可以相互备份， 保证操作不间断。

4. 资源动态扩展：

将“难预测，暂时性”的巨大访问量-余票查询业务放在公有云服务商，可以按需动态调整网络带宽和“虚机“资源，保证12306的服务品质，并解决网络传输瓶颈问题。

5. 关系型数据库（SQL） 和非关系型数据库（NoSQL）混合应用：

12306将热点数据放在NoSQL的Gemfire平台，提供快速查询和计算；将关键数据持久化到关系型数据库。

可以看下知乎大神怎么说的：

12306每次放票按500热门车次算，根据央视直播春运火车票抢票 这篇报道，热门车次峰值抢票速度在每分钟500票左右。很容易算出现在12306的峰值订单量在一分钟10万-30万的级别，与淘宝双11峰值是相同数量级。我在前面提过供求关系是12306面临的核心问题，可能很多没有经济学基础的网友不太明白，我这里再详细解释下。

任何限价商品出现供不应求情况时，最终获得商品的大多数消费者支付的成本都是要超出商品本身的标价的。一个简单的例子，超市限量出售半价鸡蛋，大批顾客去抢购，虽然排队买到的顾客为鸡蛋本身花的钱少了，但是这些顾客付出了在那里排队的时间和人力成本。

排了很久队才买到鸡蛋的顾客，为鸡蛋支付的时间与人力成本甚至可能超过了他买半价鸡蛋省下的金额。

于此同时，限量供应的条件下必然有一些排队者最终没能买到鸡蛋。之所以有人买到鸡蛋有人没买到，大多数情况下是因为前者比后者付出了更多的成本；排队者是在跟其他排队者竞争，那些看到长长的队伍就放弃的潜在消费者就是竞争的失败者。

12306的情况也是如此。在现有的车票限价限量供应体系下，在某些高峰期有乘车需求的旅客数量大大超过了铁路系统在这些时间段的运输能力。在这个前提下，必然会有大量旅客无法在这些时间段买到车票，被迫改变出行计划或者出行方式；而买到票的旅客为车票支付的成本，大多数情况下都是高于甚至远高于车票本身的标价的。

超出的这一部分成本，可以体现为向黄牛买票支付的溢价，可以体现为在车站售票口排队付出的时间精力，而到了12306的时代，就可以体现为为了抢到票而付出的等待成本。因此，12306无论怎么改进，都不可能降低因为供求关系而产生的旅客获得车票的额外成本。

其实上面，所说应该都是现有架构的分析，如何优化，还得看我这篇回答：

首先，要明确下为什么购票系统难做：

12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存。读写冲突，锁非常严重，这是抢票业务难的地方。

其次，是优化方向：

优化方向有两个：

（1）将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）。传统票务系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0。

（2）充分利用缓存，春运买票，这是一个典型的读多些少的应用场景，大部分请求是车次查询，票查询，下单和支付才是写请求。一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。

春运购票架构：

（1）浏览器端，最上层，会执行到一些JS代码

（2）站点层，这一层会访问后端数据，拼html页面返回给浏览器

（3）服务层，向上游屏蔽底层数据细节，提供数据访问

（4）数据层，最终的库存是存在这里的，mysql是一个典型（当然还有会缓存）

这个图虽然简单，但能形象的说明大流量高并发的票务业务架构

第一层，浏览器怎么优化？

问大家一个问题，大家都玩过微信的摇一摇抢红包对吧，每次摇一摇，就会往后端发送请求么？回顾我们下单抢票的场景，点击了“查询”按钮之后，系统那个卡呀，进度条涨的慢呀，作为用户，我会不自觉的再去点击“查询”，对么？

继续点，继续点，点点点。。。有用么？

平白无故的增加了系统负载，一个用户点5次，80%的请求是这么多出来的，怎么整？

（第一点）产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求；

（第二点）JS层面，限制用户在x秒之内只能提交一次请求；

APP层面，可以做类似的事情，虽然你疯狂的在摇微信，其实x秒才向后端发起一次请求。这就是所谓的“将请求尽量拦截在系统上游”，越上游越好，浏览器层，APP层就给拦住，这样就能挡住80%+的请求，这种办法只能拦住普通用户（但99%的用户是普通用户）对于群内的高端程序员是拦不住的。firebug一抓包，http长啥样都知道，js是万万拦不住无良抢票软件写for循环，调用http接口的，这部分请求怎么处理？

第二层，站点层面的请求拦截

怎么拦截？怎么防止程序员写for循环调用，有去重依据么？ip？cookie-id？…想复杂了，这类业务都需要登录，用uid即可。在站点层面，对uid进行请求计数和去重，甚至不需要统一存储计数，直接站点层内存存储（这样计数会不准，但最简单）。一个uid，5秒只准透过1个请求，这样又能拦住99%的for循环请求。

5s只透过一个请求，其余的请求怎么办？缓存，页面缓存，同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面。同一个item的查询，例如车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面。如此限流，既能保证用户有良好的用户体验（没有返回404）又能保证系统的健壮性（利用页面缓存，把请求拦截在站点层了）。

这个方式拦住了写for循环发http请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求，这下怎么办，站点层按照uid限流拦不住了。

第三层 服务层来拦截（反正就是不要让请求落到数据库上去）

服务层怎么拦截？大哥，我是服务层，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？没错，请求队列！

对于写请求，做请求队列，每次只透有限的写请求去数据层（下订单，支付这样的写业务）

3k张火车票，只透3k个下单请求去db

如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”。

对于读请求，怎么优化？cache抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的。如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了。

当然，还有业务规则上的一些优化。回想12306所做的，分时分段售票，原来统一10点卖票，现在8点，8点半，9点，...每隔半个小时放出一批：将流量摊匀。

其次，数据粒度的优化：你去购票，对于余票查询这个业务，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票？流量大的时候，做一个粗粒度的“有票”“无票”缓存即可。

第三，一些业务逻辑的异步：例如下单业务与 支付业务的分离

最后是数据库层

浏览器拦截了80%，站点层拦截了99.9%并做了页面缓存，服务层又做了写请求队列与数据缓存，每次透到数据库层的请求都是可控的。db基本就没什么压力了。

全部透到数据库，100w个下单，0个成功，请求有效率0%。透3k个到数据，全部成功，请求有效率100%。

总结下购票流程的优化大概是这样的：

（1）尽量将请求拦截在系统上游（越上游越好）；

（2）读多写少的常用多使用缓存（缓存抗读压力）；

浏览器和APP：做限速

站点层：按照uid做限速，做页面缓存

服务层：按照业务做写请求队列控制流量，做数据缓存

数据层：坐等吃鸡

结合业务做优化