南飞雁1999

只是用支付宝和12306比较，其实是不恰当的。12306的逻辑复杂程度远远高于支付宝，所以我们先换一个思维吧，用双11的天猫和12306做比较吧。

2017年的双11，天猫交易量达到了1682亿元，并且也没有出现问题。但是，12306没到春运，就连接不通畅，是什么原因呢？

这就需要从两个系统卖的东西开始说起了。

我们都知道，天猫卖的是实体的商品，这些商品（SKU）都是有库存量的，也就是下图所示的这个内容。

用户每买一个商品，这个库存就相应的减少1，到减少到0的时候，库存就没了，后面的人也就买不到了。

这个是一个非常简单的逻辑，其中的核心，就是SKU（最小库存单元），对于天猫来说，SKU也就是一件商品。

天猫2016年的时候，统计自己拥有940万商家，超10亿件商品，数量是非常庞大的。但是每一件这样的商品的库存都是可以统计出来的，而且任何一个商品销售的时候，并不会影响到其他的商品。

商品量大，我就多增加硬件来存储这些商品就行了，所以技术上的难度并不是特别大。

但是12306不一样，我去查了一下中国的铁路运行情况。

根据2017年初的数据，中国列车车次一共有3500余对，铁路站点2000多个。

也就是说，每天，会有7000余次的列车在中国的铁路上行为，途经这2000多个点。

对于任何电商网站来说，SKU都是核心，那12306也算是电商网站，他的商品是什么呢？就是火车票，火车票对应的是什么呢？火车上的座位或者站位。

那SKU就是座位了。

对于天猫来说，商品卖一个少一个。

对12306来说，一列火车上的座位，卖一个他不一定少一个。因为我一列火车可能途经20个站点，一个人可能始发站上车，第三站下车，那这个SKU在1-3站之间被卖掉了，但是第4站的时候，它又回来了。我还可以继续卖。

但是也可能一个人直接买了始发站到终点站，我这个SKU就完全卖掉了，回不来了。

用户买的行为，决定着我SKU的剩余情况，而用户买的行为是一个不可控的行为。

如果在没有控制策略的情况下，就意味着，SKU是随时发生着变化的。

我们来简单算一笔账。

一列火车途经20个点，车上有5000个座位，那他理论最小库存就是5000（一个座位1张票，始发—终点），最大库存是95000（所有人都只坐1站）

但是对于用户来说，他只是关心他那一站作为起点的时候，剩余的票的数量，这样的话，我们就必须计算，火车行进到他所在站的时候，车票的剩余情况（包括未购买的和要下车的），这样，每有一张火车票销售出去，计算机就需要执行复杂的运算，来重新的定义SKU和库存量。

中国有超过10亿人在春运的时候会去12306抢票，7000余次的列车，这个运算的复杂程度是非比寻常的。

可以说，现在中国的互联网中，暂时还没有能够比12306还复杂的运算场景了。

我们假设，买一张票需要运算1秒钟，有100台服务器同时工作，也就是1秒可以买100张票。一天可以处理多少张票呢？8,640,000（864万张票），我相信，春运开始的第一天，中国至少有1亿人回去12306抢票吧，如果我们真的使用这种算法，那就意味着有9000多万人，可能连抢票页面张什么都看不到。

但实际上是这样么？

并不是的，12306是设置了放票的节点，每个节点进行放票，也就是说，12306会按照以往的数据经验，对车票进行预演算，在不同的线路之间按照一定比例，先将票的库存计算出来。然后进行贩卖。

在下一个节点的时候，会再次按照这个规则，对车票的余量进行统计和计算，保证在每个节点时，各个站点的票都是有的，而且票与票之间的销售不会相互干扰，这样就可以减少在销售期间的运算次数的减少，提高效率。

如此说来，在节点的间隔时间内，12306的下单复杂度和天猫是一样的了，为什么春运时候，它还是要会打不开页面，没有响应呢？

我们就可以看到12306和天猫另一个不同的地方了。

12306是实名制的，一人一票，但是天猫可以随便买，所以，12306在下单前后有比较多的身份验证，但是天猫并不需要，所以，12306的单个订单的处理复杂度还是高于天猫的。

而且，全世界没有任何一个系统，在一个时间节点的时候，会涌进来好几亿人。12306能安安全全的票卖出去，我觉得已经很强大了。

会技术的葛大爷

因为12306的商品库存和品类是不断动态调整的，而淘宝天猫上的SKU是相对固定的。

对于支付宝来说，只要是固定品类，其实都容易处理，不过是数据库里面一行或几行代码。唯一要处理的就是商品的库存和价格。

但是对于12306来说不一样啊。我们就以京九线、京广线来说，每个乘车区间都能卖票，如果卖掉了天津到蚌埠的一张票，那么北京到广州的票、天津到广州的票、北京到蚌埠的票都少了一张。那数据库就接着算吧。

那么如果同时出现10万笔交易，数据库的处理数量绝不是十万这个量级，保守估算乘以二十（诚意每条线路的站点数量）也不过分吧？

如果加上退票、改签、同一人跨区间买票、同一时段重复购票、防止黄牛炒票等问题……难度能跟淘宝上那种商品卖一件少一件的东西一样么？

系统压力

根据来自官方的数据，12306网站PV(页面浏览量)目前每天都超过400亿次。

我们这些做企业管理系统的，如果使用的人多了，比如为一家大公司部署OA系统，按一个省公司1000人计算，全公司30万人估算，已经需要考虑十几台负载均衡、分布式缓存、数据库优化、工作流优化等技术，因为要避免工作流的死循环或者写入数据出错，某个状态位错误。

这种压力下，我们的OA系统的PV也不会超过2000万每天，跟12306每天400亿次，还相差了99.95%。我反正是没有勇气去批评12306。

容错程度

我们做企业管理系统，就算偶尔因为系统架构调整、数据库升级、黑客入侵、版本更新乃至软件错误导致某一个公文、某一笔报销弄错了，在当事人提出问题后，我们改回来也就算了。

在12306上，你好容易抢到一张春节回家乡的票，然后过20分钟有个工程师打电话给你说抱歉先生，因为我们数据库故障，您购买的票无效，请您重新购票的时候，你会不会用尽所有力气问候12306的服务人员、工程师、铁总？肯定会啊。

所以12306的容错程度是零。不允许犯错。

防止刷票

现在有多少软件是在云端每隔6秒跑着轮询？目前的测算是每秒查询数据库40万次-50万次；而对数据库的每次查询过程中，数据库还必须给出实时数据，以便于我们买票。

这个难度，你就看小米每次在抢购的时候，一开始是实时显示所有余量，后来压力实在扛不住，只有在最后1000台的时候才显示余量。小米是认怂了。

我们早就认怂了，我一般都是专门提供一台查询服务器，提供非实时的数据，供查询的数据每天更新两次。

每秒50万次查询，还要返回真实数据，反正让我做，我就认怂。

问我多少钱能做，我觉得20个亿以下，我想都不敢想。

跟支付宝的难度差得太多了，不是一个数量级。

任易

因为确实不是一个量级的。

专业技术层面，前面有很多朋友已经讲得比较透彻了。

但是一些不懂技术的同学，读起来或许会有点费劲。

我来用通俗一点的方法解释一下。

支付宝的运算，相当于加减法，数额有大有小，频次极高，但是终究是加减法，计算机运算能力跟得上的话，不易出错。

至于12306么……

大家在高中时候，大概都学过概率论吧？对！就是那个一个盒子里9个红球8个白球，问连续五次摸到白球的概率是多少？要是给球加上标签，算摸到特定球的概率会更难点。

12306就是结合了加减法与概率算法的运算级别。这个运算量可以说是几何级提升的。

除了算法层面，还有服务器层面。

不是说，12306的服务器压力一定就比支付宝的要大，而是不稳定。

在一些出行高峰期时候，人民都会做一件事：抢票。

大家没事就不停的刷票，出票一瞬间十秒钟之内，票就没了（真实经历，切肤之痛，就没怎么抢到过票）。除了乘客在抢票，还有黄牛，这两年还有机器！各种五花八门的抢票软件，对于漂泊在外的同学们应该不陌生吧？反正我春节回家，全靠这些软件。

可以看看双十一时候，各大电商通宵达旦，全副武装的样子。我的一些京东淘宝的朋友说，双十一时候，大家吃住都是在公司，随时准备战斗。

12306能做到这个份上，真的也是不容易了。

姑婆那些事儿

看到很多答案都在强调12306的购票系统是多么复杂和高难度，似乎12306的网站建设让人不满意的关键是问题本身太复杂导致的。

其次，支付宝的网络和系统也是会出问题，只不过得益于阿里巴巴的技术能力，解决问题的速度会比较快，给大家带来的困扰会比较小。毕竟大家的要求不是完美，而是体验不能太差罢了。阿里巴巴的技术难度不仅仅在支付宝这个系统，而在于淘宝等网站的海量数据处理，阿里巴巴不仅要保证支付环节不能崩溃或者出错，在购物环节也不能崩溃，而且在双十一等流量峰值时段，会有各种抵扣券，满减活动导致系统负担增加。短暂崩溃的情况也是时有出现的。

因此，首先要排除的一个情况就是，支付宝系统容易做，12306难度大，因此支付宝不崩溃，12306崩溃这个说法。虽然火车票订票系统跟支付宝和淘宝的技术难度不一样，但是，真正导致12306使用不顺畅的原因还是在于两个方面：钱和技术。

大家需要搞清楚的一点是，买不到票不能怪12306，因为网站不可能让车票变多，买不到票是因为座位不够。12306的职责是要正常运行，不崩溃。查询，购票，退票等服务能够尽可能高效。在早些年，12306的网站很容易崩溃，正是大家说12306系统不行的原因。淘宝网跟支付宝虽然也会有崩溃的情况发生，但是修复速度快，影响面小，给大家的印象就好很多。为什么会这样呢？因为阿里巴巴的网站技术，实力是世界级的，不是铁路局可以比的。与此同时，阿里巴巴投入网站建设的资金也比铁道部多很多。

铁路系统虽然也很强大，但是订票网站不是其核心竞争力，铁道部不可能把太多的资源投入到网站建设。铁道部的钱主要是用来建设铁路系统的，网站只是附加的一个项目而已。阿里巴巴的网站是安身立命的根本，重视程度不可同日而语。阿里巴巴最大的技术挑战就包括如何解决数据爆炸带来的系统负担，他们不断砸钱去解决这个问题，才有能力应对今天这种规模的交易量。而铁道部的网站建设，是在互联网时代为了满足市场需求做出的适应性行为。因此，阿里巴巴不管是在技术积累，人力投入还是资金投入方面，比起12306都有碾压性的优势。网站更好用一些也是理所应当的。

事实上，在12306订票系统难用备受指责之后，铁道部找了国内外的技术团队帮忙建设，其中就包含了阿里巴巴的团队。在重新梳理系统结构，完善网站建设之后，12306网站比以前已经有了很大的进步，整体的稳定性和可靠性还是可以接受的。由此也可以看出，当初的12306那么难用，主要的原因不在于技术难度，而在于投入程度。

镁客网

因为12306的商品库存和品类是不断动态调整的，而淘宝天猫上的SKU是相对固定的，但是对于12306来说不一样啊。我们就以京九线、京广线来说，每个乘车区间都能卖票，如果卖掉了天津到蚌埠的一张票，那么北京到广州的票、天津到广州的票、北京到蚌埠的票都少了一张。如果加上退票、改签、同一人跨区间买票、同一时段重复购票、防止黄牛炒票等问题

只要是固定品类，不过是数据库里面一行或几行代码。唯一要处理的就是商品的库存和价格。 支付宝体系是非常分散的，而12306却是集中的。不管你在网上买什么商品还是在线下付款，实际上它们都是分散支付的，即便是双十一这样的大型活动时期它还是分散购买。简单点说，无论你购买吃的还是穿的不可以所有的人一起购买一个品类的产品，他们选择的范围太广，

所以12306的容错程度是零。不允许犯错。

12306是实名制的，一人一票，但是天猫可以随便买，所以，12306在下单前后有比较多的身份验证，但是天猫并不需要，所以，12306的单个订单的处理复杂度还是高于天猫的。 而且，全世界没有任何一个系统，在一个时间节点的时候，会涌进来好几亿人。12306能安安全全的票卖出去，我觉得已经很强大了。

所以，一个是面对千万并发顺畅运行的淘宝，一个是可能需要时时刻刻去面对亿级并发保证数据一致性并不保证性能的12306，各有上下，因为业务不一样，量级也不一样。

牛科技

简单来说一下：

你在淘宝相中一件衣服，S码，比如库存10000件，这10000件S码的衣服是一摸一样的，我作为消费者下了订单买了这款S码的衣服，数据库里对这件商品的库存量减1，这就结束了。

你想在12306买一张票，比如说你想买K590这趟车的坐票，起始地北京西，终点站重庆，但是你只是想买北京西到邯郸这部分段的票。这个能仅仅是对数据库的一条操作就可以完成了嘛？

不是。

你需要查询K590这趟车有没有票，而且还需要查询在北京西到邯郸这个区间里是不是有票，如果有票，那么我让你买了数据库里又该怎么去操作，每一张票都是这样的问题，每一行票都有自己独立的一个票号，都有很多个区间，在数据库层面，这就不是一张表可以实现的，在CRUD上，根本不可能想淘宝买衣服那样对数据库操作那么简单，所以他是多张表的关联操作。

淘宝很多时候都做秒杀活动，很多人去买1件或者2件的商品，比如说双十一一开始的时候，很多人去抢一些物品，这时候大量的请求蜂拥而至，你必须保证的是，这几件商品是需要被人买走的，同时其他人没有抢到商品，也就是抢购失败。

也就是说，你必须实现的是，这个系统时时刻刻要和数据库保持同步状态，这样才能保证数据的一致性。

而12306， 他是一个时时刻刻要出于秒杀状态的同步系统，而且，业务层面也是及其复杂。

并且，淘宝这种电商平台，都是维持一个28定则，百分之20的增删改，百分之80的查询。所以在数据库层可以加各种中间件，比如说redis缓存啊，数据库做主从复制，读写分离啊，等等来提高系统的性能。但是12306，他是出于一个高查询高修改的系统，很难去实现一个数据库层面的高可用。电商那一套应对高并发的思想在这里完全不适应。

而且，12306第一个要保证的并不是性能，而是数据的一致性，就是无论这个系统有多慢，性能有多差，也不能出现两个人同时买到一张票这样的重大bug，所以在技术上，他只能去用一些非常成熟非常熟悉的技术，因为必须保证不能出bug，一旦在这样的业务上出了bug，那代价和后果是及其严重的，一旦出现这样的bug，影响的可是成千上万人的出行。

而且，论并发，淘宝双十一那一天的并发量可能是每年里最高的，我认为他也并没有12306在春运时期要高。而淘宝，在平时的并发量，也远远不如12306

所以，12306的系统，无论你说他的ui界面做的有多垃圾，性能有多慢，但是，后台业务层，还是很厉害的！

至于所谓的阿里云免费为12306提供技术支持，好像是阿里云免费为12306提供了服务器和云数据库，最难的还是业务，像12306这样复杂的业务，像12306这样需要面对春运时期那样的并发，整个世界，我觉得都没有。

所以，一个是面对千万并发顺畅运行的淘宝，一个是可能需要时时刻刻去面对亿级并发保证数据一致性并不保证性能的12306，各有上下，因为业务不一样，量级也不一样。

木剑温不胜

做为一名资深的架构师想告诉你淘宝与12306有本质的区间。如果你能设计出他的方案给你100万都值得，前提是你的方案是可行的。

1、世界上最大的同时在线网站：先不要说购票，他能支持上亿人同时登录这个方案都很值钱了。大部分网站可以采用镜像方式在全国不同地点部署多套服务器提供服务，但你能忍受你在12306上查询出车票，但无法定票的结果吗？上亿人在线需要消耗多少内存，多少带宽？

2、世界上最高的并发操作：淘宝不同的商家分布在不同的服务器上，甚至不同的商品可以可以分布在不同的服务器上，所以淘宝在线用户不少，但在每台服务器上并不多。但12306呢？最算将一列火车放在一台服务器上，有多少人要这一列火车的票？票不能多买，在无数用户要购买同一张票状态下，如果锁定只让一个用户购买就很不容易。

3、多种类型的购买方式：淘宝就在淘宝上购买，但火车票呢？窗口、电话、团体、网站多在售出一列火车的，如何分配票都是一个很重要的问题。

4、分段购买方式：你在淘宝上见过分段购买东西的吗？目前只有火车票是这样做的，光你将如果分段做出来，你的工资过万是没有问题的。

总的来讲，12306在全世界都属于最等级的系统，你如果真有能力设计出来，你到任何一个IT公司都能做个技术总监的职位是没有问题的。

至于那些说几个学生做的，那说明他们不是做IT的。

lihhsd

华哥杂谈

简单来说一下：

你想在12306买一张票，比如说你想买K590这趟车的坐票，起始地北京西，终点站重庆，但是你只是想买北京西到邯郸这部分段的票。这个能仅仅是对数据库的一条操作就可以完成了嘛？

不是。

你需要查询K590这趟车有没有票，而且还需要查询在北京西到邯郸这个区间里是不是有票，如果有票，那么我让你买了数据库里又该怎么去操作，每一张票都是这样的问题，每一行票都有自己独立的一个票号，都有很多个区间，在数据库层面，这就不是一张表可以实现的，在CRUD上，根本不可能想淘宝买衣服那样对数据库操作那么简单，所以他是多张表的关联操作。

淘宝很多时候都做秒杀活动，很多人去买1件或者2件的商品，比如说双十一一开始的时候，很多人去抢一些物品，这时候大量的请求蜂拥而至，你必须保证的是，这几件商品是需要被人买走的，同时其他人没有抢到商品，也就是抢购失败。

也就是说，你必须实现的是，这个系统时时刻刻要和数据库保持同步状态，这样才能保证数据的一致性。

而12306， 他是一个时时刻刻要出于秒杀状态的同步系统，而且，业务层面也是及其复杂。

并且，淘宝这种电商平台，都是维持一个28定则，百分之20的增删改，百分之80的查询。所以在数据库层可以加各种中间件，比如说redis缓存啊，数据库做主从复制，读写分离啊，等等来提高系统的性能。但是12306，他是出于一个高查询高修改的系统，很难去实现一个数据库层面的高可用。电商那一套应对高并发的思想在这里完全不适应。

而且，12306第一个要保证的并不是性能，而是数据的一致性，就是无论这个系统有多慢，性能有多差，也不能出现两个人同时买到一张票这样的重大bug，所以在技术上，他只能去用一些非常成熟非常熟悉的技术，因为必须保证不能出bug，一旦在这样的业务上出了bug，那代价和后果是及其严重的，一旦出现这样的bug，影响的可是成千上万人的出行。

而且，论并发，淘宝双十一那一天的并发量可能是每年里最高的，我认为他也并没有12306在春运时期要高。而淘宝，在平时的并发量，也远远不如12306

所以，12306的系统，无论你说他的ui界面做的有多垃圾，性能有多慢，但是，后台业务层，还是很厉害的！

至于所谓的阿里云免费为12306提供技术支持，好像是阿里云免费为12306提供了服务器和云数据库，最难的还是业务，像12306这样复杂的业务，像12306这样需要面对春运时期那样的并发，整个世界，我觉得都没有。

所以，一个是面对千万并发顺畅运行的淘宝，一个是可能需要时时刻刻去面对亿级并发保证数据一致性并不保证性能的12306，各有上下，因为业务不一样，量级也不一样。

欧密切

另一方面，阿里的业务广泛，服务器运算和存储资源调度也很容易。一个小公司出1000万很难，但是10个子公司的集团，每个公司出 100万就可以集齐这么多钱。阿里自己也是这样做。像双十一会需要很多服务器来支撑，双十一一过基本上一大半的资源都用不上了，他这些资源就会被租用给阿里云的用户。等第二年双十一他再从各个单位把一些可以收集起来的空闲西苑拿过来用以支撑淘宝和支付宝等业务。但是资源太庞大，每个被收集资源的地方也不太容易感觉出来。就像集团需要80块，某子公司有80块流动资金，集团就可以把其中的70抽走，而对这个子公司没有什么大影响。

再来说说12306，这个网站刚建起来的时候好像是自己的服务器，那时候资源也不是很足，另一方面网站也不是跟完善。有漏洞，以及资源在高峰时紧缺，所以会出现流量拥堵情况。这几年好像12306也开始用阿里的云资源了，总体来说现在比前几年稳定了不少。像12306这种业务，用云资源是比较好的。可以很灵活的调整资源占用。像平时站点弄一点资源根本不会有什么压力，春节的时候就业务量大，需要大量的资源来处理网络请求。

从网络需求来讲，像淘宝支付宝用阿里云资源，他们的请求大部分都可以在一个区域内完成。而春节订票的时候我们抢到一张票网站会提示你正在排队。这个过程是什么呢？像深圳和北京，两个地方的人不可能买到同一区间和座位的票，因为我们抢到票之后排队的这个时间实际上就是后台服务器在跟全国范围内其他12306数据中心做比对。而这个过程就会是很繁琐的一个程序，工作量也是很大的。你要想，每个座位都要在全部的数据中心比对一次，当然，并不会傻到每次只比对一个座位。但是这个工作量也已经跟庞大。所以我们排队的这个过程要等蛮久。同时，如果12306数据中心设置越多，这个比对过程花费时间就越长。但是数据中心越少，用户访问请求的压力就回越大，所以这个数据中心在数量和位置上也是需要多加考虑权衡的。反正肯定不能做的像阿里那么多。（关于12306数据中心的事可以在一些抢票软件上看到，抢票前会比对每个数据中心的用时，并让你选择一个，实际上就是让你选择一个用户压力小，网络情况好的数据中心，这样有利于更快的抢到票）

但是总体来讲，12306的资源相对于阿里的资源还是有差别的，就像一个小型集团跟跨国大型集团一样，所以对于网络请求变化应对能力还是有所差别。

關鍵字: 天猫 一千亿 科技