又到了年关了，马上要回家过年了。一说到过年，对于我们这些在外漂泊的游子来说，买一张回家过年的票，回家陪家人过年就成了最大的期许了。一谈论买票，又不得不说火车票，如何这般难买的问事情了。像我一样的码农看着一张张的票瞬间刷完，不禁又要吐槽12306了。
哎，其实习惯了，这票难买，为买票发愁吧，也不是一年两年的事儿了。只不过以前没出来工作时候，没出过远门儿，也就不知“愁”滋味了。
记得去年同事之间为买火车票难的事情，还吐槽过：诶，这12306呀，花了几个亿呀，怎么就这么烂，动不动就卡死，真TMD坑爹。还有同事紧跟着说了：要是交给阿里团队，绝对能够做的好。我相信，这种埋怨票难买而有情绪的大有人在吧，我就是其中一个。那把12306交给阿里或者其他的互联网大佬来开发情形是不是会好一点呢？我想可能会好一点，但是解决不了根本问题。乐观地估计一下:该抢不到的还是抢不到，该卡死的照样卡死！
有的同志可能会吐槽我了：信口开河，您怎么知道阿里做不好一个12306呢？大概会有“子非鱼，安知鱼之乐？”的意味在里面。那先不看我是怎么想的，为什么会得出这样的结论，让我们一起来看看前淘宝工程师是怎么说的。
在题目以“前淘宝工程师发帖谈12306：曾嗤之以鼻 现在认为几乎是奇迹”的文章中作者写到：当自己还是在一家百强民企做电商副总的时候对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百万半年时间做个好的出来。于是他狂妄地想做一个开源的订票系统给他们。花了一个星期时间思考建立数据模型，思考到库存这一步的时候，才发现，12306的库存复杂性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足12306的需求。他还进一步从技术的角度分析了复杂性的问题：在平时，12306也就是个正常的电商网站。但一到黄金周，12306就是一个全站所有商品都秒杀，所有SKU都是动态库存的变态。这就意味着即使不考虑线下既有的电话、代售点等渠道，要实现一个12306，最少最少也是千万级别的硬件投入（这是当时的估算，没有精算，可能与实际相差较大，总之，我说得不一定对，12306的业务也许没我说的那么复杂，但也绝不是某些人喷的那么简单），软件和人力另算。那些叫嚣只要40台服务器、只要2个架构师4个程序员、大谈分库分表和前端CDN的人们，只是纸上谈兵罢了。所谓初生牛犊不怕虎，做了三年CMS和BBS，就以这个经验来喷12306，未免太天真了。
文章还说了，媒体人喷12306，是他们不懂技术，没有能力和耐心来分析背后的难度。技术人员喷，则是因为大部分的技术人员在短时间思考时，容易陷入过于乐观的误区，经典的例子就是估算工作量，程序员们往往容易估算出一个超短的工期，把写程序的工作乐观地想象成了打字员照稿敲键盘的工作。文章感叹道：事非经过不知难，在网上批判12306的人，大部分还是形成了【国企=垄断+腐败+低效】的思维定势。小部分是真的轻视了它的难度（其实很多人包括我都有这个认为毕竟那是3个多亿做出来的东西）。对于这个复杂级别的项目，花费如此之巨，文章做了一个横向的对比：百度一年的研发费用（不含硬件）是10亿，这个数字来自百度财报。网上能查到。3亿看起来好大一个数字，真用到超大型的电商系统、搜索引擎系统里面，其实也不算什么天文数字了。
我们都知道，12306买票基本上市秒杀。那么秒杀究竟是个什么概念呢？或许一般人包括做技术的没深入不怎么了解。还是上面那篇文章中，作者现身说法，叙述了自己抢天猫魔盒的事情。15000个天猫魔盒，19秒内全部抢完！在这个过程中还出现了服务器错误的页面。反复刷新几次，就告诉秒杀结束了。接着说了淘宝技术团队的配置相关情况，得出了为什么淘宝也会出现12306同样的情况的问题说在：一是要尊重物理原理；二是要考虑经济效益。简单来讲就是技术不能解决所有问题，而且不可能为了某一个点而投入巨大的资源消耗。
当然文章还讲了不少技术层面的问题。其实呢，我觉得这些都是有道理的。当然最关键的还不是技术问题（当然技术也确实存在需要改进的问题），打个不恰当的比方：巧妇难为无米之炊。一事物与周围事物的联系时事物存在和发展的条件。一个国家即使拥有了发达的生产能力，但是人口、资源有限，消费能力不足，能源需要进口，你的经济就严重依赖海外市场。比方说日本。一票难求最根本的原因在于铁路运输运输在交通运输中的主导作用一时无法改变，而随着经济的发展，各个地区之间的相互联系日益紧密，人口流动量也日益加大，铁路运输能力的不足和时间段内巨大的人口流动之间的矛盾一时无法消弭。只有那么的线路、那么多的车次。那么快的速度。你想他又能怎么满足得了一个春节几十亿人次的人口流动呢？这放在任何一个国家都是个难题。
为之奈何？！能有啥办法呢。对于像我一样的码农！我又不能改变什么，说了也是白说了。凑合着能回去就行了。哎，而今识尽愁滋味，欲说还休。欲说还休，却道天寒好个冬。