致还在喷12306的同行

眼看着要过年了，又到了一家人排队买过车票的时间了。今年的排队不同于以往，这次大家都集中到了12306上面排队了。

要说前些年排队，只要你能吃苦，肯熬夜，总能买到票。可今年这个优势俨然成了会不会用网路、网速、手速的大比拼。加上天天500的网站，大量的人狂喷12306。大致上理由如下（由深至浅）：

1. 无法访问
2. 各种各样的漏洞：退票、延期付账漏洞、身份证/姓名伪造漏洞等。
3. 前端简陋

现在的网络，没有什么可以吐槽的状态才是值得吐槽的，本无可厚非。大家发发牢骚，发泄一下买不到票的情绪没什么问题。可有人自称自己只要数周时间就可以简单的重构12306，修补种种问题。我只能在这里“呵呵”。

先说最让人无法接受的500无法访问问题。之前作为一个 并发量问题的讨论，那时我已经说过150/s的并发，现在我觉得这个数字保守的不可救药了。150只是针对传统的电商来说的，现在的状态是每天90%以上甚至98%以上的访问集中在每天放票的半小时以内——这已经超出了13年“双十一”的峰值水平了！况且TB的购物方式仅仅是货号对唯一ID*数量=价格的简单购物系统。考虑过火车票吗？

A车站：A->B 2张，A->C 2张；B车站：B->A 1张，B->C 3张；C车站：C->A 0张，C->B1张；从A到B必经C。都是个位数一只手都不到，谁能一下子算出一共有多少张票？提示：要考虑到排列组合，只是简单加加的人直接去面壁吧！任何一张票的售出都回直接影响到整个系统中的存票量。这个模型只是在一个最简单不过的状态下的情况，想知道全国有多少火车站吗？每辆列车有多少座位吗？用户有多少种乘车/换乘可能吗？出票的系统从来不是一个“产供销”系统，更加接近于一个“路由系统”。况且每出一张票的同时都需要对几乎所有沿线的车站票务状态都要重新更新的过程。以上种种的纬度再加上时效性，有更好的数据结构和索引算法的话我愿倾听。

如果这个时候你说：只要一台强有力的机器就可以了。好吧，我只能说，你根本不了解什么叫做“原子操作”。你必须保证在同一时间全局只能由唯一一张的车票被售出，就必须在每次操作的同时对全局上锁。短期内强力的机器却是可以提升部分性能，但趋向是“无限接近于0”的双曲线。实现中，为了实现故障转移和负载均衡，这样的场景往往是多台机器铺路，但机器越多，实现原子操作的成本和难度就越大，而且同样是“趋向于正无穷”的抛物线。如果我得到的信息没错的话，当下12306用的是FireGem，中心节点17台Linux，8路Xeon E7,，1T RAM。没错，顶配的X86。

年终的时候曾经有消息称TB介入了12306的开发，甚至大家都对12306有了一点小激动。可事实上没有太大的改观——TB只是参与了12306的队列系统而已。换句话说TB可能都没有touch到核心业务。可能有人会认为有什么幕后交易阻碍了TB。事实上TB现在敢于搞个“双十一”什么的，完全是站在了自己有了10年以上的技术积累之上的，甚至为了技术上的实现重新设计过商业流程。贸然介入一个自己连自己的业务流程，甚至于管理流程都不太了解的项目中，肯定不会有太大的起色。队列系统相对简单，相信TB一开始就觉得“自己现成的解决方案，没有太多的耦合性，也相当容易有起色，绝对是油水活！”

流程上的问题，先是可以用假身份证买票。好吧，如果每个身份证都去到公安系统验证一下的话，第一订票时间至少延长一倍；第二公安身份证系统也会搞垮，这是更加让人不能接受的情况。

退票和延期付账的漏洞。关于退票漏洞，我觉得这是一个被滥用的功能。只能说退票的手续费太低，以至于还不够填补黄牛的加价费。延期付账的漏洞，其实任何一家电商都有类似的设定，只不过电商没有这么强的时效性而已。

说到前端的问题，其实我并不觉得这个有太大的槽点。UI就是一个UI，你可以说它丑，但考虑到很多用户——可能都到了爷爷辈——根本无法接受太多的图片/色彩/动态的堆嵌。大量的文字描述+简单表格反而更有可行性。就好比说每个人回家都不会看着门牌号一家一户地找，但你不能说为此门牌号就没有存在的价值。只是能在网上吐槽UI的人本身已经占据了信息高地而已。

归根结底，作为一个票务系统，我敢说在全世界范围内不会再有哪个系统敢说能出其右。买不到票的原因不见得是因为12306烂，而是根本上车票的稀缺性。如果你自诩为有过硬的技术，充沛的带宽，一系列的工具尚买不到票而牢骚满腹牢骚，我只能说，比你牛的人早就满大街了。如果不了解IT的人吐槽我一笑了之，如果哪位同行还有不懈我只能说：You can you up!