[不吐不快]大家来说说，12306的技术架构是什么级别的存在？

我是真心觉得国内电商在12306面前都是弟弟，淘宝上一个商品没了就没了，铁路线上一个车次N种组合要被人抢，一旦少了一张，那组合还要重新算。

顶级大神那种，就像赚钱的速度你和马云比一样

知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

用的阿里云啊

用的我们公司的服务器

目前国内最好的那个层次的水平，跟很多别的公司有合作，最近几年越来越好了

懂得很自然懂

12306比淘宝难很多很多，不解释

我觉得是程序员都会觉得这个很叼的水平。

神级存在，懂的都懂

12306的算法是铁总找阿里搞定的。所以你说电商平台技术比不过12306，并不是电商没能力，而是觉得没必要

引用 @泉盛辉煌hu5 发表的:
12306的算法是铁总找阿里搞定的。所以你说电商平台技术比不过12306，并不是电商没能力，而是觉得没必要

是马云求铁总用阿里云服务器的，阿里云只承担了查询的部分

高并发加动态库存 想想就很可怕

引用 @打板二加一 发表的:
是马云求铁总用阿里云服务器的，阿里云只承担了查询的部分

这你就吹大了，还求着铁总用，那是因为当时阿里云有一套成熟的数据承载体系，腾讯云百度云都比不上

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

以前没有遇到过两个人买到同一个座位吗？

好像就是阿里团队做的吧

引用 @泉盛辉煌hu5 发表的:
12306的算法是铁总找阿里搞定的。所以你说电商平台技术比不过12306，并不是电商没能力，而是觉得没必要

一开始是清华做的。。

引用 @阿伯吃的饿佛哥 发表的:
用的阿里云啊

部分

引用 @curtainand 发表的:
好像就是阿里团队做的吧

铁总找过阿里，阿里没接，铁总自己内部的人搞定的。

有兴趣去深入了解一下了

现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在2012年5月12306便曾邀请一组阿里精干技术人员组成的项目组赴京，一起“奋战30多个日日夜夜”，此后还曾派出技术人员赴阿里交流学习。2013年底，12306手机App推出也是一个重大里程碑，同期12306网站支持了支付宝支付。这些举措让整个订票过程方便了不少。或许因为这些是其份内职责，因此并未获得外界关注和用户好评。这一次与阿里云达成合作，同样是其积极思变，努力解决存在的问题的表现。
处理大并发业务：阿里巴巴经验最丰富
不少科技公司甚至个别程序员都认为自己可以解决12306所存在的宕机问题，放出豪言可以帮助12306，但恐怕并非想象的那么容易。国内有能力应对这类业务的公司并不多：首先它是超大并发业务；其次是属于电商类业务；还有它是属于某些时段特别忙某些时段特别闲的峰谷特征明显的业务。打造双十一购物节的阿里相对更加适合。
曾经，阿里技术团队在双十一期间也会受到业务部门的指责，就像大家现在职责12306一样，客观来看双十一推动了阿里技术的成熟。经过4次双十一之后，阿里在应对集中时刻大并发的业务上已经经验丰富，飞天5000集群、跨机房调度技术，阿里云技术已经全球领先，而这些技术和能力正在被积极推进开放。
不过，能够搞定双十一并不意味着能够解决12306.cn的高并发访问需求。因为火车票有着完全不同的商品属性，比如一个用户订票就需要重新计算调整余票库存，再比如订不到票的用户会一直刷刷刷，这些都会给网站带来压力。12306并非从零开始，它的历史可以追踪到80、90年代的网点售票系统，与各地路局系统联通，甚至涉及到核心调度业务，庞大而复杂，现在要互联网化是基于已有系统扩展而不是新建，很容易牵一发而动全身。
为此，阿里云与12306的合作只是小试牛刀：将12306余票查询的75%部署到阿里云。业务特征决定了12306的查询业务占据了90%的流量，其压力正是来自于用户一次次刷票，长达30分钟的支付环节压力反而没那么大；并且余票查询业务与其他业务耦合性最小，最适合迁移到外部云平台。这是云计算最基本的思路之一：核心业务可以自己部署，“粗大笨傻”这类对计算资源需求大但不太核心容易解耦的业务放到第三方平台。
迁移到阿里云之后12306不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

以前网上段子说淘宝双十一一分钟多少个亿的交易都能立马处理，反观12306经常买不到票，就觉得国家真是垃圾找关系户做软件浪费钱……

引用 @当干你们成了习惯 发表的:
以前没有遇到过两个人买到同一个座位吗？

我想到了人在囧途的假票。。。

引用 @当干你们成了习惯 发表的:
以前没有遇到过两个人买到同一个座位吗？

我发生过一起不知道算不算，我当时从桂林北站去桂林站，我上车后找到我座位发现有人了，然后我报了我的车次和座位，发现跟旁边的人的车次都不一样，也就是发生了之前jr说的到站后车次改变了，因为我是最后一节车厢跟乘务员们讨论了之后确实是改变了，但座位有没有重叠我不记得了(当时发生这种事我也有点慌，瞄了一眼她的车票座位，后面我就忘记了，印象中是重叠了），想着也就站十几分算了。

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在2012年5月12306便曾邀请一组阿里精干技术人员组成的项目组赴京，一起“奋战30多个日日夜夜”，此后还曾派出技术人员赴阿里交流学习。2013年底，12306手机App推出也是一个重大里程碑，同期12306网站支持了支付宝支付。这些举措让整个订票过程方便了不少。或许因为这些是其份内职责，因此并未获得外界关注和用户好评。这一次与阿里云达成合作，同样是其积极思变，努力解决存在的问题的表现。
处理大并发业务：阿里巴巴经验最丰富
不少科技公司甚至个别程序员都认为自己可以解决12306所存在的宕机问题，放出豪言可以帮助12306，但恐怕并非想象的那么容易。国内有能力应对这类业务的公司并不多：首先它是超大并发业务；其次是属于电商类业务；还有它是属于某些时段特别忙某些时段特别闲的峰谷特征明显的业务。打造双十一购物节的阿里相对更加适合。
曾经，阿里技术团队在双十一期间也会受到业务部门的指责，就像大家现在职责12306一样，客观来看双十一推动了阿里技术的成熟。经过4次双十一之后，阿里在应对集中时刻大并发的业务上已经经验丰富，飞天5000集群、跨机房调度技术，阿里云技术已经全球领先，而这些技术和能力正在被积极推进开放。
不过，能够搞定双十一并不意味着能够解决12306.cn的高并发访问需求。因为火车票有着完全不同的商品属性，比如一个用户订票就需要重新计算调整余票库存，再比如订不到票的用户会一直刷刷刷，这些都会给网站带来压力。12306并非从零开始，它的历史可以追踪到80、90年代的网点售票系统，与各地路局系统联通，甚至涉及到核心调度业务，庞大而复杂，现在要互联网化是基于已有系统扩展而不是新建，很容易牵一发而动全身。
为此，阿里云与12306的合作只是小试牛刀：将12306余票查询的75%部署到阿里云。业务特征决定了12306的查询业务占据了90%的流量，其压力正是来自于用户一次次刷票，长达30分钟的支付环节压力反而没那么大；并且余票查询业务与其他业务耦合性最小，最适合迁移到外部云平台。这是云计算最基本的思路之一：核心业务可以自己部署，“粗大笨傻”这类对计算资源需求大但不太核心容易解耦的业务放到第三方平台。
迁移到阿里云之后12306不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

厉害了！真·科普

引用 @秋名山顶老司机 发表的:
以前网上段子说淘宝双十一一分钟多少个亿的交易都能立马处理，反观12306经常买不到票，就觉得国家真是垃圾找关系户做软件浪费钱……

买不到票是没票，不是系统有票但是你刷不出来。跟系统没关系，要黑到点子上才行。

引用 @秋名山顶老司机 发表的:
以前网上段子说淘宝双十一一分钟多少个亿的交易都能立马处理，反观12306经常买不到票，就觉得国家真是垃圾找关系户做软件浪费钱……

没票怎么给你买？

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

说到这，我以前就买过一次车票，中间付款环节卡了，支付宝付了一次没出票，第二次付款才出票，然后我看到支付宝上扣了两张的钱，之后找了12306客服，也联系不到，联系了官方邮件，把支付宝两次交易单号发过去，过了几天，才收回了那多发的钱。
所以你说的这些，我是不认同的！

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在2012年5月12306便曾邀请一组阿里精干技术人员组成的项目组赴京，一起“奋战30多个日日夜夜”，此后还曾派出技术人员赴阿里交流学习。2013年底，12306手机App推出也是一个重大里程碑，同期12306网站支持了支付宝支付。这些举措让整个订票过程方便了不少。或许因为这些是其份内职责，因此并未获得外界关注和用户好评。这一次与阿里云达成合作，同样是其积极思变，努力解决存在的问题的表现。
处理大并发业务：阿里巴巴经验最丰富
不少科技公司甚至个别程序员都认为自己可以解决12306所存在的宕机问题，放出豪言可以帮助12306，但恐怕并非想象的那么容易。国内有能力应对这类业务的公司并不多：首先它是超大并发业务；其次是属于电商类业务；还有它是属于某些时段特别忙某些时段特别闲的峰谷特征明显的业务。打造双十一购物节的阿里相对更加适合。
曾经，阿里技术团队在双十一期间也会受到业务部门的指责，就像大家现在职责12306一样，客观来看双十一推动了阿里技术的成熟。经过4次双十一之后，阿里在应对集中时刻大并发的业务上已经经验丰富，飞天5000集群、跨机房调度技术，阿里云技术已经全球领先，而这些技术和能力正在被积极推进开放。
不过，能够搞定双十一并不意味着能够解决12306.cn的高并发访问需求。因为火车票有着完全不同的商品属性，比如一个用户订票就需要重新计算调整余票库存，再比如订不到票的用户会一直刷刷刷，这些都会给网站带来压力。12306并非从零开始，它的历史可以追踪到80、90年代的网点售票系统，与各地路局系统联通，甚至涉及到核心调度业务，庞大而复杂，现在要互联网化是基于已有系统扩展而不是新建，很容易牵一发而动全身。
为此，阿里云与12306的合作只是小试牛刀：将12306余票查询的75%部署到阿里云。业务特征决定了12306的查询业务占据了90%的流量，其压力正是来自于用户一次次刷票，长达30分钟的支付环节压力反而没那么大；并且余票查询业务与其他业务耦合性最小，最适合迁移到外部云平台。这是云计算最基本的思路之一：核心业务可以自己部署，“粗大笨傻”这类对计算资源需求大但不太核心容易解耦的业务放到第三方平台。
迁移到阿里云之后12306不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

你字多跟你混

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

其实12306也有超卖，但是概率不高，我两三年下来碰到过一两次的样子

个人看法，对于12306来说，有两个巨大难点，一个是高并发，除了正常用户的访问，各种抢票软件各种爬虫都在访问，对于服务器造成的压力是巨大的。另一个是不能出错，因为有区间售票，要考虑的情况是很复杂的。至于有人说人在囧途那种情况，那是因为向黄牛买到了假票。

https://b23.tv/av81009627

这个视频清楚明白的讲解了春运时期12306业务处理难度与爆买时期电商平台的难度比较……

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

买了票不让上车都有，没座位才多大点事。不要神话

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

这就有点自以为是了，火车上临时改签换票不要太普遍，而且大部分车次都有部分可操作的座位

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

去年国庆在公司抢票，1点钟放票，大中午的不睡觉好不容易抢到一张，付了钱美滋滋的去睡觉。结果睡醒看到一条短信，说出票失败，瞬间无语，钱都付了还出票失败

引用 @蓝白月光 发表的:
这就有点自以为是了，火车上临时改签换票不要太普遍，而且大部分车次都有部分可操作的座位

高铁改签出来的都是无座，你要不相信可以试一下

引用 @一六年总冠军骑士 发表的:
买了票不让上车都有，没座位才多大点事。不要神话

高铁买票不让上是因为很多人没能买到目的地的票就买了个之前站点的，然后上车补票导致列车超员了，所以才不让上

引用 @未知的181 发表的:
高铁改签出来的都是无座，你要不相信可以试一下

火车上总有空闲位置的，只是不会随便给乘客而已，比如餐车，比如某些空闲卧铺，列车工作人员不难找出来

引用 @蓝白月光 发表的:
火车上总有空闲位置的，只是不会随便给乘客而已，比如餐车，比如某些空闲卧铺，列车工作人员不难找出来

我说的是高铁，高铁没有坐卧混杂的，要么就全是坐票要么全是卧铺，而且高铁的餐车都是开放的，不过哥们你咋还不睡啊，这都几点了？

不久几个循环的事🐶

引用 @映斜阳 发表的:
去年国庆在公司抢票，1点钟放票，大中午的不睡觉好不容易抢到一张，付了钱美滋滋的去睡觉。结果睡醒看到一条短信，说出票失败，瞬间无语，钱都付了还出票失败

你这个描述很明显不是在 12306买的票

引用 @drowing425 发表的:
你这个描述很明显不是在 12306买的票

？？就是12306app，我从来不用第三方

引用 @saem2 发表的:
这你就吹大了，还求着铁总用，那是因为当时阿里云有一套成熟的数据承载体系，腾讯云百度云都比不上

别尬，查询票池存在峰谷性，放在云上是最佳方案，核心的票池还在12306自己的服务器上，政企的业务bat再加一个360挤破头了都想做，你以为是谁想做就能做的？你品吧

引用 @香球王 发表的:
说到这，我以前就买过一次车票，中间付款环节卡了，支付宝付了一次没出票，第二次付款才出票，然后我看到支付宝上扣了两张的钱，之后找了12306客服，也联系不到，联系了官方邮件，把支付宝两次交易单号发过去，过了几天，才收回了那多发的钱。
所以你说的这些，我是不认同的！

概率问题，懂

引用 @当干你们成了习惯 发表的:
以前没有遇到过两个人买到同一个座位吗？

之前坐城际轻轨 就买过 还好就十几分钟路程

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

借楼回复一下，从事过后端算法及大数据相关行业。其实，12306的算法，逻辑和结构并不难，难的是支撑如此大的用户同时使用的算力支撑。个人见解，欢迎讨论。

阿里双十一的优惠券算法也很复杂

引用 @憨憨的灵魂 发表的:
知乎上面讲过，12306难就难在不允许发生错误，每一笔交易都必须精准算好，电商出bug大不了赔个代金券，或者叫别的仓库补发。12306出错了，你去哪里赔张票给人家，座位就那么多。

我觉得最难的还是抢票软件，无数机器人不停的冲击服务器，比淘宝双十一的访问量应该大多了。

引用 @秋名山顶老司机 发表的:
以前网上段子说淘宝双十一一分钟多少个亿的交易都能立马处理，反观12306经常买不到票，就觉得国家真是垃圾找关系户做软件浪费钱……

所以是段子呀，春节12306的访问量比双十一大，买票的人比购物的人多，还要考虑到抢票软件这种流氓，机器人不停的在冲击服务器。

引用 @未知的181 发表的:
高铁买票不让上是因为很多人没能买到目的地的票就买了个之前站点的，然后上车补票导致列车超员了，所以才不让上

你这种怎么可能不让上，都是这趟车。

引用 @你看我这个昵称怎么样 发表的:
买不到票是没票，不是系统有票但是你刷不出来。跟系统没关系，要黑到点子上才行。

他不是说是段子了吗

引用 @煤气佬R698 发表的:
之前坐城际轻轨 就买过 还好就十几分钟路程

哪里到哪里，对方票一模一样？

引用 @香球王 发表的:
说到这，我以前就买过一次车票，中间付款环节卡了，支付宝付了一次没出票，第二次付款才出票，然后我看到支付宝上扣了两张的钱，之后找了12306客服，也联系不到，联系了官方邮件，把支付宝两次交易单号发过去，过了几天，才收回了那多发的钱。
所以你说的这些，我是不认同的！

你和层主说的属于两件事。

引用 @蓝白月光 发表的:
这就有点自以为是了，火车上临时改签换票不要太普遍，而且大部分车次都有部分可操作的座位

你这回答太自以为是了。

引用 @EmricKos 发表的:
其实12306也有超卖，但是概率不高，我两三年下来碰到过一两次的样子

不可能。

引用 @苏美丽颜容 发表的:
我发生过一起不知道算不算，我当时从桂林北站去桂林站，我上车后找到我座位发现有人了，然后我报了我的车次和座位，发现跟旁边的人的车次都不一样，也就是发生了之前jr说的到站后车次改变了，因为我是最后一节车厢跟乘务员们讨论了之后确实是改变了，但座位有没有重叠我不记得了(当时发生这种事我也有点慌，瞄了一眼她的车票座位，后面我就忘记了，印象中是重叠了），想着也就站十几分算了。

全国铁路以北京为中心，离开北京的车辆为下行，对应的车次尾数为单数;开向北京的车辆为上行，对应的车次尾数为双数。当列车行驶到某车站，需要改变行进方向时，车次也需要做相应的变动，这就不难理解同一趟车同一时间车次不同了

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在2012年5月12306便曾邀请一组阿里精干技术人员组成的项目组赴京，一起“奋战30多个日日夜夜”，此后还曾派出技术人员赴阿里交流学习。2013年底，12306手机App推出也是一个重大里程碑，同期12306网站支持了支付宝支付。这些举措让整个订票过程方便了不少。或许因为这些是其份内职责，因此并未获得外界关注和用户好评。这一次与阿里云达成合作，同样是其积极思变，努力解决存在的问题的表现。
处理大并发业务：阿里巴巴经验最丰富
不少科技公司甚至个别程序员都认为自己可以解决12306所存在的宕机问题，放出豪言可以帮助12306，但恐怕并非想象的那么容易。国内有能力应对这类业务的公司并不多：首先它是超大并发业务；其次是属于电商类业务；还有它是属于某些时段特别忙某些时段特别闲的峰谷特征明显的业务。打造双十一购物节的阿里相对更加适合。
曾经，阿里技术团队在双十一期间也会受到业务部门的指责，就像大家现在职责12306一样，客观来看双十一推动了阿里技术的成熟。经过4次双十一之后，阿里在应对集中时刻大并发的业务上已经经验丰富，飞天5000集群、跨机房调度技术，阿里云技术已经全球领先，而这些技术和能力正在被积极推进开放。
不过，能够搞定双十一并不意味着能够解决12306.cn的高并发访问需求。因为火车票有着完全不同的商品属性，比如一个用户订票就需要重新计算调整余票库存，再比如订不到票的用户会一直刷刷刷，这些都会给网站带来压力。12306并非从零开始，它的历史可以追踪到80、90年代的网点售票系统，与各地路局系统联通，甚至涉及到核心调度业务，庞大而复杂，现在要互联网化是基于已有系统扩展而不是新建，很容易牵一发而动全身。
为此，阿里云与12306的合作只是小试牛刀：将12306余票查询的75%部署到阿里云。业务特征决定了12306的查询业务占据了90%的流量，其压力正是来自于用户一次次刷票，长达30分钟的支付环节压力反而没那么大；并且余票查询业务与其他业务耦合性最小，最适合迁移到外部云平台。这是云计算最基本的思路之一：核心业务可以自己部署，“粗大笨傻”这类对计算资源需求大但不太核心容易解耦的业务放到第三方平台。
迁移到阿里云之后12306不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

你字多你说了算，其实是我觉得你说的很对。

引用 @saem2 发表的:
这你就吹大了，还求着铁总用，那是因为当时阿里云有一套成熟的数据承载体系，腾讯云百度云都比不上

服了 铁路这样大客户
bat谁不想搞

引用 @映斜阳 发表的:
？？就是12306app，我从来不用第三方

12306有APP？

引用 @热风唱唱歌 发表的:
12306有APP？

怎么没有

引用 @凶手带带大师兄 发表的:
没票怎么给你买？

没票为什么不多印几张

引用内容被灭过多已被折叠

你咋不说一个座位上坐八个人？或者一段铁轨上开着十趟火车？

引用 @热风唱唱歌 发表的:
12306有APP？

看来是旅游软件受害者

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在2012年5月12306便曾邀请一组阿里精干技术人员组成的项目组赴京，一起“奋战30多个日日夜夜”，此后还曾派出技术人员赴阿里交流学习。2013年底，12306手机App推出也是一个重大里程碑，同期12306网站支持了支付宝支付。这些举措让整个订票过程方便了不少。或许因为这些是其份内职责，因此并未获得外界关注和用户好评。这一次与阿里云达成合作，同样是其积极思变，努力解决存在的问题的表现。
处理大并发业务：阿里巴巴经验最丰富
不少科技公司甚至个别程序员都认为自己可以解决12306所存在的宕机问题，放出豪言可以帮助12306，但恐怕并非想象的那么容易。国内有能力应对这类业务的公司并不多：首先它是超大并发业务；其次是属于电商类业务；还有它是属于某些时段特别忙某些时段特别闲的峰谷特征明显的业务。打造双十一购物节的阿里相对更加适合。
曾经，阿里技术团队在双十一期间也会受到业务部门的指责，就像大家现在职责12306一样，客观来看双十一推动了阿里技术的成熟。经过4次双十一之后，阿里在应对集中时刻大并发的业务上已经经验丰富，飞天5000集群、跨机房调度技术，阿里云技术已经全球领先，而这些技术和能力正在被积极推进开放。
不过，能够搞定双十一并不意味着能够解决12306.cn的高并发访问需求。因为火车票有着完全不同的商品属性，比如一个用户订票就需要重新计算调整余票库存，再比如订不到票的用户会一直刷刷刷，这些都会给网站带来压力。12306并非从零开始，它的历史可以追踪到80、90年代的网点售票系统，与各地路局系统联通，甚至涉及到核心调度业务，庞大而复杂，现在要互联网化是基于已有系统扩展而不是新建，很容易牵一发而动全身。
为此，阿里云与12306的合作只是小试牛刀：将12306余票查询的75%部署到阿里云。业务特征决定了12306的查询业务占据了90%的流量，其压力正是来自于用户一次次刷票，长达30分钟的支付环节压力反而没那么大；并且余票查询业务与其他业务耦合性最小，最适合迁移到外部云平台。这是云计算最基本的思路之一：核心业务可以自己部署，“粗大笨傻”这类对计算资源需求大但不太核心容易解耦的业务放到第三方平台。
迁移到阿里云之后12306不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

其他不知道，反正很早之前的双十一淘宝也跟辣鸡，付不了钱

12306是世界级难题，面向国外招标解决并发问题，没有人敢接

引用 @单身奥特曼 发表的:
你咋不说一个座位上坐八个人？或者一段铁轨上开着十趟火车？

叠罗汉🐶

引用 @NASA宇航局 发表的:
全国铁路以北京为中心，离开北京的车辆为下行，对应的车次尾数为单数;开向北京的车辆为上行，对应的车次尾数为双数。当列车行驶到某车站，需要改变行进方向时，车次也需要做相应的变动，这就不难理解同一趟车同一时间车次不同了

不经过北京的车次算上行还是下行？

引用 @香球王 发表的:
说到这，我以前就买过一次车票，中间付款环节卡了，支付宝付了一次没出票，第二次付款才出票，然后我看到支付宝上扣了两张的钱，之后找了12306客服，也联系不到，联系了官方邮件，把支付宝两次交易单号发过去，过了几天，才收回了那多发的钱。
所以你说的这些，我是不认同的！

那是付款失败，我今年我是，这种情况15个工作日自动退款

引用 @哆啦A梦917 发表的:
不经过北京的车次算上行还是下行？

看方向啊

这么多年了一次错都没遇到过，我们属于比较经常出差的工作

引用 @joungpig 发表的:
我觉得是程序员都会觉得这个很叼的水平。

内行人觉得很吊，无论是逻辑还是并发。

引用 @hycold 发表的:
高并发加动态库存 想想就很可怕

裂变库存，每一次交易都会裂变出多个车次。 12306跟双11主要区别就是难在每次交易的业务复杂度高度耦合。

引用 @NASA宇航局 发表的:
全国铁路以北京为中心，离开北京的车辆为下行，对应的车次尾数为单数;开向北京的车辆为上行，对应的车次尾数为双数。当列车行驶到某车站，需要改变行进方向时，车次也需要做相应的变动，这就不难理解同一趟车同一时间车次不同了

我是今年才发现同一趟车有的站点后车次不一样，然后又一样，原来是这样

引用 @等晴天TvT 发表的:
别尬，查询票池存在峰谷性，放在云上是最佳方案，核心的票池还在12306自己的服务器上，政企的业务bat再加一个360挤破头了都想做，你以为是谁想做就能做的？你品吧

给电信做吧。😄

牛逼到，外国团队，不敢接这个项目的水平……

难度劝退

阿里只是线上，12306线上线下

引用 @Marsmanman9 发表的:
你和层主说的属于两件事。

哈哈，很明显不同的事件，为了杠而杠

引用内容被灭过多已被折叠

不加个狗头？？？

引用 @awakemee 发表的:
你这种怎么可能不让上，都是这趟车。

超员了真不让上

引用 @苏美丽颜容 发表的:
我发生过一起不知道算不算，我当时从桂林北站去桂林站，我上车后找到我座位发现有人了，然后我报了我的车次和座位，发现跟旁边的人的车次都不一样，也就是发生了之前jr说的到站后车次改变了，因为我是最后一节车厢跟乘务员们讨论了之后确实是改变了，但座位有没有重叠我不记得了(当时发生这种事我也有点慌，瞄了一眼她的车票座位，后面我就忘记了，印象中是重叠了），想着也就站十几分算了。

重点不是瞄了一下她吗

引用 @joungpig 发表的:
我觉得是程序员都会觉得这个很叼的水平。

反正我达不到的水平

引用 @让我再想一下 发表的:
他不是说是段子了吗

我没看出来呀🐶

引用 @香球王 发表的:
说到这，我以前就买过一次车票，中间付款环节卡了，支付宝付了一次没出票，第二次付款才出票，然后我看到支付宝上扣了两张的钱，之后找了12306客服，也联系不到，联系了官方邮件，把支付宝两次交易单号发过去，过了几天，才收回了那多发的钱。
所以你说的这些，我是不认同的！

来个记录让我们来学习一下？

引用 @NASA宇航局 发表的:
看方向啊

那个问题来了，如果一趟车次以北京为圆心，做圆周运动，那么它的方向是驶向还是驶离呢。。。狗头狗头

引用 @Marsmanman9 发表的:
你这回答太自以为是了。

鹦鹉学舌，多坐坐火车就知道了

努力建设家乡，不要坐铁路去远方人挤人

引用 @awakemee 发表的:
你这种怎么可能不让上，都是这趟车。

复兴号超员了驾驶室会报警，严重的车就走不了的

引用 @awakemee 发表的:
你这种怎么可能不让上，都是这趟车。

高铁超员就G，不允许超重

引用 @你看我这个昵称怎么样 发表的:
买不到票是没票，不是系统有票但是你刷不出来。跟系统没关系，要黑到点子上才行。

我感觉是有票，刷不出来，就给你没票的提示

国服最难

引用 @秋名山顶老司机 发表的:
以前网上段子说淘宝双十一一分钟多少个亿的交易都能立马处理，反观12306经常买不到票，就觉得国家真是垃圾找关系户做软件浪费钱……

段子看多了吧 好好了解一下12306吧 双十一也就那一个点并发高 你想想春运什么概念 一个月并发都那么高 你以为12306的服务器哪来的 阿里也参与了 宝贝

引用 @秋名山顶老司机 发表的:
以前网上段子说淘宝双十一一分钟多少个亿的交易都能立马处理，反观12306经常买不到票，就觉得国家真是垃圾找关系户做软件浪费钱……

这都有人亮，黑也得黑到点子上啊

12306主要是票务系统太复杂，并发什么不是事

关键是可以多加负载服务器就行了

主要就是各种锁，你买着一段的，其他的人就要更新

引用 @当干你们成了习惯 发表的:
以前没有遇到过两个人买到同一个座位吗？

坐了五六年火车了，反正我没遇到过

引用 @香球王 发表的:
说到这，我以前就买过一次车票，中间付款环节卡了，支付宝付了一次没出票，第二次付款才出票，然后我看到支付宝上扣了两张的钱，之后找了12306客服，也联系不到，联系了官方邮件，把支付宝两次交易单号发过去，过了几天，才收回了那多发的钱。
所以你说的这些，我是不认同的！

你说的这属于支付环节，平常买东西扫码一样可能遇到的。第一次支付完整流程没走完。第二次才走完的，但第一次的支付已经付出去了。

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在2012年5月12306便曾邀请一组阿里精干技术人员组成的项目组赴京，一起“奋战30多个日日夜夜”，此后还曾派出技术人员赴阿里交流学习。2013年底，12306手机App推出也是一个重大里程碑，同期12306网站支持了支付宝支付。这些举措让整个订票过程方便了不少。或许因为这些是其份内职责，因此并未获得外界关注和用户好评。这一次与阿里云达成合作，同样是其积极思变，努力解决存在的问题的表现。
处理大并发业务：阿里巴巴经验最丰富
不少科技公司甚至个别程序员都认为自己可以解决12306所存在的宕机问题，放出豪言可以帮助12306，但恐怕并非想象的那么容易。国内有能力应对这类业务的公司并不多：首先它是超大并发业务；其次是属于电商类业务；还有它是属于某些时段特别忙某些时段特别闲的峰谷特征明显的业务。打造双十一购物节的阿里相对更加适合。
曾经，阿里技术团队在双十一期间也会受到业务部门的指责，就像大家现在职责12306一样，客观来看双十一推动了阿里技术的成熟。经过4次双十一之后，阿里在应对集中时刻大并发的业务上已经经验丰富，飞天5000集群、跨机房调度技术，阿里云技术已经全球领先，而这些技术和能力正在被积极推进开放。
不过，能够搞定双十一并不意味着能够解决12306.cn的高并发访问需求。因为火车票有着完全不同的商品属性，比如一个用户订票就需要重新计算调整余票库存，再比如订不到票的用户会一直刷刷刷，这些都会给网站带来压力。12306并非从零开始，它的历史可以追踪到80、90年代的网点售票系统，与各地路局系统联通，甚至涉及到核心调度业务，庞大而复杂，现在要互联网化是基于已有系统扩展而不是新建，很容易牵一发而动全身。
为此，阿里云与12306的合作只是小试牛刀：将12306余票查询的75%部署到阿里云。业务特征决定了12306的查询业务占据了90%的流量，其压力正是来自于用户一次次刷票，长达30分钟的支付环节压力反而没那么大；并且余票查询业务与其他业务耦合性最小，最适合迁移到外部云平台。这是云计算最基本的思路之一：核心业务可以自己部署，“粗大笨傻”这类对计算资源需求大但不太核心容易解耦的业务放到第三方平台。
迁移到阿里云之后12306不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

很牛逼的，而且做的越来越好

引用 @我爱苹果C 发表的:
那个问题来了，如果一趟车次以北京为圆心，做圆周运动，那么它的方向是驶向还是驶离呢。。。狗头狗头

hhhhhhhh狗头铡伺候