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

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

感觉你不是程序员。不允许错误发生的实现办法有很多。最简单的就是，如果拿不准，这单不成立。我只有在100%确定这张票存在的情况下在同意客户的购买请求。除此之外，只需要让前端显示，购买中，抢票的时候卡，需要反复点也可能就是这种情况。对于数据库，事务操作原子性本身就可以很大程度保证数据的一致性。而且，12306并不是100%不出错，也会出错。这么解释完了你还觉得 12306的系统很高大上么。

引用 @背刺小黑屋 发表的:
这明显是阿里拿下项目后发的通稿……说实话12306这种体量的客户全世界厂商都抢着去做的，而且纯技术方面我不觉得阿里比亚马逊谷歌有什么优势，特别是当年。

战略级的东西，交给外国公司？
虽然谷歌技术很强，但是这方面也没有经验

引用 @Lurito 发表的:
那别说了吧，其实我也觉得你不懂技术呢。

好的好的
我的荣幸

找外包，不限价，外包表示，有心无力。外国人来了也被劝退。。

引用 @xyfor1234 发表的:
说了多少次了，没有什么同步一致性，所有区间票都是预留的，数量固定。同步个啥？非得加戏？

你再想想，你跟他们说的不是一回事

引用 @源中华 发表的:
一个二等，一个一等……

一等座还比二等便宜

就这么说吧
12306招过标，各种问题能解决就行，预算没有上线
然后无人敢应

引用 @俄城一抹蓝 发表的:
内行人觉得很吊，无论是逻辑还是并发。

12306这可是注入了几个亿的架构，承载的并发量和稳定性数一数二的

引用 @Bhenzo92 发表的:
感觉你不是程序员。不允许错误发生的实现办法有很多。最简单的就是，如果拿不准，这单不成立。我只有在100%确定这张票存在的情况下在同意客户的购买请求。除此之外，只需要让前端显示，购买中，抢票的时候卡，需要反复点也可能就是这种情况。对于数据库，事务操作原子性本身就可以很大程度保证数据的一致性。而且，12306并不是100%不出错，也会出错。这么解释完了你还觉得 12306的系统很高大上么。

哈哈，你这一说，我100%肯定你不是程序员，基本风险，影响范围都不评估，张口就来100%确定再卖。这是抢购的思路，抢购点一下等结果，库存是唯一。春运卖票不是，每个列车每个人上下车是不固定的，卖少一张票，余量刷新要及时。你辛苦去了高铁站，排队买票，柜台小姐叫你慢慢等吧，已经帮你点了提交。哈哈

引用 @小心夹头 发表的:
我看的一个一等座一个二等座，我确定我不瞎

建议找个好点的眼科兄弟……一趟高铁有几个15车A2座？

引用 @请检查您的网络 发表的:
我都不知道谁告诉你每个区间的票数是固定的，我想知道什么样的天才能够设计一个涵盖所有买票方案的区间划分算法，就还拿北京到广州举例，我买郑州到武汉你要把这个算进哪个区间？郑州到长沙呢？郑州到韶关呢？北京到韶关呢？区间都是相互重叠的，这个算法有多少意义

能别杠了吗？人家铁路就是这么卖票的好不好。卖之前就定好了北京到广州100张，北京到郑州50张，郑州到武汉50张，武汉到广州50张。这么说你聪明的脑袋能理解了吗？还算法，要啥算法啊。搁你那样没电脑之前铁路别卖票了。

引用 @小心夹头 发表的:
你确定你不瞎？

？

引用 @messiah1986 发表的:
就算是高铁中间也是会停站的哟～

我竟然不知道怎么回答你……

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在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不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

我做了一个阿里云的项目 目前来说，阿里云在国内是第一。 国际上是第二档

引用 @xyfor1234 发表的:
能别杠了吗？人家铁路就是这么卖票的好不好。卖之前就定好了北京到广州100张，北京到郑州50张，郑州到武汉50张，武汉到广州50张。这么说你聪明的脑袋能理解了吗？还算法，要啥算法啊。搁你那样没电脑之前铁路别卖票了。

不过有一个问题，如果北京到郑州50张，系统不应该计算出郑州到武汉要多50张吗？总不能车到郑州后，上面空50个位子啊。还是说提前预留的票里就已经包含了这部分。这个理论上也应该会增加难度吧。

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

当是地铁环城线呐hhhggg

以前觉得很稀烂，后来讲分布并行的老师说了一个关于想超越12306的故事，就服了。

引用 @千与千寻Okuhara 发表的:
哈哈，桂林北到桂林这么近，踩个单车也就十几分钟。坐火车不是很麻烦嘛

要不是我在桂林四年，差点就信了

引用 @我想长到120 发表的:
来你给额舍，面前这六杯酒，哪一杯是茅台，额告诉你，么有一杯是茅台，额要是能喝得起茅台额哈坐啥烂怂火车里嘛

还少了扇耳光的动作

引用 @Kevin特人 发表的:
来了来了

这也太难了吧。。。我买

引用 @憨憨的灵魂 发表的:
哈哈，你这一说，我100%肯定你不是程序员，基本风险，影响范围都不评估，张口就来100%确定再卖。这是抢购的思路，抢购点一下等结果，库存是唯一。春运卖票不是，每个列车每个人上下车是不固定的，卖少一张票，余量刷新要及时。你辛苦去了高铁站，排队买票，柜台小姐叫你慢慢等吧，已经帮你点了提交。哈哈

不好意思，我就是程序员

引用 @憨憨的灵魂 发表的:
哈哈，你这一说，我100%肯定你不是程序员，基本风险，影响范围都不评估，张口就来100%确定再卖。这是抢购的思路，抢购点一下等结果，库存是唯一。春运卖票不是，每个列车每个人上下车是不固定的，卖少一张票，余量刷新要及时。你辛苦去了高铁站，排队买票，柜台小姐叫你慢慢等吧，已经帮你点了提交。哈哈

我觉得最大的风险就是你卖出去了没有的票。我张口就来，我看你是张口就来。

引用 @请检查您的网络 发表的:
我都不知道谁告诉你每个区间的票数是固定的，我想知道什么样的天才能够设计一个涵盖所有买票方案的区间划分算法，就还拿北京到广州举例，我买郑州到武汉你要把这个算进哪个区间？郑州到长沙呢？郑州到韶关呢？北京到韶关呢？区间都是相互重叠的，这个算法有多少意义

每个区间的票就是固定的。。兄弟。

引用 @莱昂纳徳迪卡普里奥 发表的:
我觉得最主要的可能是各类抢票软件 一分钟好几百次递交申请 服务器禁不住也正常

加起来一分钟几亿次都有可能

引用 @千与千寻Okuhara 发表的:
好吧，我是晚上开车感觉快而已，实际上有8、9公里。不过确实中山路一条直路啊，北极广场走环城西也就是沿着铁路边走吖

动车肯定最方便，踩单车没半个小时应该到不了吧

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

当年刚出的时候被喷的不行，一到春运节假日就瘫痪，当时很多人在网上说淘宝双十一零点都不瘫痪，没想到过了这么多年竟然反过来了

引用 @Bhenzo92 发表的:
我觉得最大的风险就是你卖出去了没有的票。我张口就来，我看你是张口就来。

你开心就好，建议你把这个简单解决方案在你们技术团队分享下，让大伙开开眼

引用 @背刺小黑屋 发表的:
这明显是阿里拿下项目后发的通稿……说实话12306这种体量的客户全世界厂商都抢着去做的，而且纯技术方面我不觉得阿里比亚马逊谷歌有什么优势，特别是当年。

双11的量也很大，阿里很有经验的。处理高并发这方面阿里在世界应该也是不虚的

引用 @ICU996 发表的:
有人吐槽12306一个人做app，一群人做服务器

App也是支付宝架构。。闲鱼去给写的业务

引用 @小心夹头 发表的:
我看的一个一等座一个二等座，我确定我不瞎

没坐过高铁？一等座二等座车厢号码不是从1-10+连着排的？还有分二等座15车和一等座15车？

引用 @倪尧BSU 发表的:
最早高峰期网页都打不开的，那时候还被骂，后面算法改进，服务器更新，才不卡的。那时候我大学买春运回家的车票，记忆犹新。

要说以前，可以对比一下大学抢课的网页，那才是真的卡

逻辑很吊，不知道他们怎么处理这么大的任务量，这么多线程，不出错


我能想到的办法里，在春运这种场景下，可能会有十个人买到同一张票。。。


感觉这可能是除了阿里巴巴的那些东西以外，国内高并发项目的巅峰水平

引用 @Lurito 发表的:
好，就算没有AI能够下棋下赢他（其实是有的，阿尔法狗退役后，其他公司的机器人已经超越他了），但是围棋AI就比谷歌搜索、谷歌翻译更“聪明”吗？

我先帮你否定他，不同的DL模型他们的职能不一样，没有什么好比较的，AlphaGo和google现在的那些BERT没有优劣之分

除非是那些CV比赛里的模型


然后alpha zero很明显比市面上公开的所有AI都强，可能新的AI比如现在的绝艺 星阵比那时候的master强，我不知道他们谁厉害，但是他们不会有那时候的zero强，你多看看星阵对人类围棋的解说和分析就可以得出这个结论

引用 @跳伞塔派出所 发表的:
这是量的牛。
不是质的牛。跟你说无数次了。

什么叫质的牛，就在于其算法是否可以在其他领域复用。
阿法狗、安卓系统敢开源。
阿里敢么。

Google当年处理和惩罚那些在PageRank上造假ranking的算法至今闭源，尽管PageRank被淘汰了

我们都知道Google用BERT，但是他们具体的model也是闭源的


以上内容对google员工应该是开源的

但是GOOGLE X的几乎任何代码对普通员工也是闭源的。。。。。。


google不敢

无脑觉得很厉害🤣

真的吗

引用 @唐僧近女色 发表的:
肯定有啊，哪有100%的事情，我们IT界的有个数字叫99.99%可用性，但是感觉12306这个可用性可能能打到99.99..99%

可用性和超卖是两个概念来的……超卖是逻辑出问题，可用性是出故障，我也是业界的😂

引用 @RossGaller 发表的:
首先并发量不是一个级别的，以前靠人工，满打满算就是全国所有售票窗口的总和，往小了说每个窗口排10个人吧，有app之后可能有5个人就app买了，并发量就上去了。最恐怖的是春运这种时候，并发量估计是以前传统售票系统的几百倍，体量翻了几个数量级，原来的算法就不能适应要重新设计了。以上个人愚见

几百倍，太小看了，春运期间，一趟列车，起码有80%座位都是瞬间被订下来，同时几趟列车下来，然后抢票的人起码得翻倍，而且还有用多个软件抢的，起码是以前人工的万倍以上，加上列车站点的排列。
铁道部一开始被骂后，后来公开投标，结果没一个企业敢去投标的，后来没办法，然后才找的啊里来协助，然后再把一些车次起售时间段分开，现在才差不多解决问题。

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在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不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

你字多，一定对，哈哈哈

引用 @messiah1986 发表的:
我感觉我银行里应该有人转账5亿……查了下幼儿园财务扣了500儿子学费，感觉挺准的，都是账户变动，没什么差别～

例子不恰当，我觉得我卡里有钱，取了一下提示没钱，我认为银行骗我，给我没钱的提示

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

12306平均每天访问860亿次，最高每秒160万次并发访问，就这压力，能勉强扛住不错了

引用 @单身奥特曼 发表的:
看来是旅游软件受害者

我一直都是在12306官网买的，没下APP

没下，一直直接找官网买

引用 @w55520 发表的:
我大清亡了？？

大清亡了上百年了

引用 @你是我V1 发表的:
我们老师说开始就是外包做的，后来请了韩国的团队和其他的团队优化，才做成这样子🐶

有一说一，做这么大流量的并发，整个韩国互联网行业捆绑在一起都不够阿里打的，韩国就那么多人，春运这个级别的流量根本没有处理经验

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在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不再需要配合春运大量扩容基础设施，而是租赁阿里云；高峰期之后不再租赁回收成本。对于阿里云而言，可以不断扩容计算资源，不同时间分配给不同客户，比如双十一扩容的服务器春运就派上了用场，这让整个计算资源得到充分利用。

哦呵呵，我同事被拉去干了几个月苦力，最后就表扬了一下，阿里跪舔大铁总也是没办法的。他也是JRS

引用 @留坝吴彦祖 发表的:
你让我嗦那个是奶糖

哪个是茅台

引用 @米粒儿爹 发表的:
可以自己去搜 这么懒呢 十年前我确实是开发 而且还是我说的那俩老总中的公司

张嘴就来？当时网上很多半桶水程序员自视甚高，拿淘宝的拍卖系统来类比12306，当时不就被真正懂行的架构师有理有据打脸了吗?不说腾讯阿里老大根本没喷过12306，就是后来阿里云也只是帮助12306上云而已，架构设计依然是人家铁科院做的。
在大厂待过就这么目空一切，有意思？

引用 @断水流大师兄0 发表的:
真以为每个软件刚出来都很牛逼？不是在讨论12306现在的技术有多厉害吗，为什么扯到10年前....

它刚出来的时候一样牛逼，只是大部分人不知道它的架构复杂度。

引用 @憨憨的灵魂 发表的:
你开心就好，建议你把这个简单解决方案在你们技术团队分享下，让大伙开开眼

祝你过个好年吧，另外希望你不要外行和内行瞎较劲，不然真是人如其名了。

引用 @Marsmanman9 发表的:
不可能。

我遇到过，我买的四张票和对方买的四张票一样，他是红色票，我是蓝色票，车次座位一样。最后列车长过来给安排了两个卧铺。

引用 @跳伞塔派出所 发表的:
世界上夸张了，全国最难差不多。
全国铁路节点差不多2000个，阿法狗的运算就秒他了。

不是，你是学计算机的吗？

引用 @马超的双龙尖 发表的:
现在的人啊，记性怎么那么差，记性差就算了，百度一下那么难吗？
一则报道现实早在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，给双十一积累了不少经验。毕竟全世界这么大规模的高并发项目，只有国内才有应用场景，才能让他们有机会去尝试

彼此成就，但还是牛逼

本码农反正觉得是屌爆了的存在

引用 @郑州外国语学校 发表的:
很明显，有一张是假票

这位校友你还挺活跃，见你两次了