閱讀本文約花費: 6 (分鐘)

其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。

本来我在 weibo 上闲扯两句，这么简单的方案，本以为大家一看就明白的。没想到还是许多人有疑问。好吧，写篇 blog 来解释一下。

简单说，我们设置几个网关服务器，用动态 DNS 的方式，把并发的订票请求分摊开。类比现实的话，就是把人分流到不同的购票大厅去。每个购票大厅都可以买到所有车次的票。OK ，这一步的负载均衡怎么做我就不详细说了。

每个网关其实最重要的作用就是让订票的用户排队。其实整个系统也只用做排队，关于实际订票怎么操作，就算每个网关后坐一排售票员，在屏幕上看到有人来买票，输入到内部订票系统中出票，然后再把票号敲回去，这个系统都能无压力的正常工作。否则，以前春运是怎么把票卖出去的？

我们来说说排队系统是怎么做的：

其实就类似我们去热门馆子吃饭拿号。只不过要防止别人伪造号插队而已。

如果你来一个人（一次 HTTP 请求），我就随机产生一个我做过一些签名处理的号码返回给你。暂时称为 ticket id 。这个 ticked id 是很难伪造的。

系统在内存里开一个大数组（32G 内存够排上亿人了吧），就是一循环队列。把这个 ticket id 放在队列尾。

用户现在拿着 ticket id 向网关发起请求。网关利用一次 hash 查询，在内存中的数组队列里查到它的位置，立刻返回给用户。用户的前端就可以看到，他在这个网关（售票大厅）前面还有多少人等着。

这里的关键是，整个队列都在本机的内存中，查询返回队列中的位置，可以实现的比一个处理静态文件的 web server 还要高效。静态文件至少还要去调用文件 IO 呢。静态文件 web server 可以处理多少并发量，不用我介绍了。

同时，前端会控制用户拿着 ticket id 查询队列位置的频率。高负载时可以 1s 一次，甚至更长时间。为了防止用户自己写脚本刷这个请求（虽然没有太大意义，因为刷的多也不会排到前面去），如果见到同一个 ticket id 过于频繁的查询。比如 10s 内查询了 20 次以上。就直接把这个 ticket id 作废。持有这个 ticket 的人就需要重新排队了。

对于最后排到的人，系统会生成一个唯一的不可伪造的 session id ，用户下面就可以通过这个 session id 去做实际的购票流程了。可以连去真正的购票服务器，也可以通过网关中转。非法的 session id 会立刻断掉，用户一旦知道伪造 session id 几乎不可能，只有通过 ticket id 排队拿到，除非是恶意攻击系统，不然不会有人乱拿 session id 去试。

我们再给每个 session id 设置一个最长有效时间，比如半小时。如果超过半小时还没有完整购票流程，那么就重新去排队。

至于同时开放多少个 session id ，也就是相当于开放多少个购票窗口，就取决于购票系统能承受的负载了。不过简单计算一下，就知道有排队系统保证了良好的次序，再以计算机的吞吐能力，解决不过几亿人的购票请求，即使这些人都同来排队，也就是一组机器几小时的处理量而已。

这票 blog 也就是随便写写，可能不太严谨，但意思达到了。中间有很多数据需要估算，也不是太难的事情。

为什么现在的购票系统这么滥？关键在于大量的网络带宽，计算力浪费在了“维持次序”上。系统不稳定时，大量的只做了一半的无效的购票流程浪费掉了这些。要响应高并发的 HTTP 请求，关键就在于迅速反应，不要什么都想着从数据库绕一圈。排队的队伍维持就完全不需要使用数据库。如果所有 HTTP 请求都立刻返回，在短时间内可以处理的 HTTP 请求量也会非常大。而如果你一下处理不了这个请求，又把 TCP 连接保持在那里，就莫怪系统支持不住了。

另外，用户看到了不断在减少的队列前面的人数，他们也会安心等待。只要网站页面刷新流畅（只处理队列信息很容易保证），用户体验会很好。

---

最后补充几句废话：因为铁路购票系统很多年前就实现了内部网络化，有成熟系统支撑，运作多年。这次做互联网版本，一定不能放弃原有系统新来一套。不然实体购票点也在网页上刷不出票就崩溃了。

所以要做的仅仅是怎么做一个系统和原有系统对接。这样风险最小。两套系统可以分别优化处理能力。基于这个设计起点，所以我才不看好所有企图取代原有系统的方案。

via： 链接