原文地址:铁路订票系统的简单设计
其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。
本来我在 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 连接保持在那里,就莫怪系统支持不住了。
另外,用户看到了不断在减少的队列前面的人数,他们也会安心等待。只要网站页面刷新流畅(只处理队列信息很容易保证),用户体验会很好。
最后补充几句废话:因为铁路购票系统很多年前就实现了内部网络化,有成熟系统支撑,运作多年。这次做互联网版本,一定不能放弃原有系统新来一套。不然实体购票点也在网页上刷不出票就崩溃了。
所以要做的仅仅是怎么做一个系统和原有系统对接。这样风险最小。两套系统可以分别优化处理能力。基于这个设计起点,所以我才不看好所有企图取代原有系统的方案。
对变态的业务逻辑只能用变态的业务模型来满足。票(大学)是稀缺资源,不够是正常的。但是只看到有人报怨自己没考好,没报好,没人有抱怨志愿填报不合理。
当然我们用不着让买票人也去参加考试然后凭分数来排定买票的排队次序。在互联网售票已经可以开始运作(虽然运作的还不完美),我们就把排队的广场放在网络上吧。
春运期间售票如果能改成以下流程我觉得12306将能满足广大票友的需求
售票分为以下几个阶段:
实名注册期 => 需求收集期 => 秒杀抢票期 => 后台卖票期 => 订单确认付款期 => 取票\刷卡上车期
假定某年春运第一天为1月30号,提前10天(20号)可以拿票来看
10号(所购票前20天12306开放购票意向收集与用户注册),类似大学报志愿一样,每身份证限购五张,可提交最多所购票当天6个不同车次购票请求,购票请求按优先级从上到下将会在后台售票时依次尝试满足
18号零点前为购票需求收集截止期。
18号早上9点开始开放抢票,用户保持已登录状态开始抢位置,系统显示当前排队的位置,刷新没用,越刷越往后排,一次点击就够了!!19号零点前抢票结束 --您要是实在不着急买票,可以等到最后一秒再来抢,不过买不到票您可别怨铁道路
19号零点后台运行卖票程序,按照18号抢票排队的顺序卖票依次处理售票,售一张则发一个邮件与短信确认,24小时内需确认,逾期则收回。--当然,如果您请票心切,提前把钱存到12306的个人购票账号里也行,铁道部巴不得您在那能存些余额呢。
20号可拿到纸票,或付款后即可以在铁道部数据库中查到购票记录可届时刷卡上车
比方说某人今天网速不佳,或选的车次都太热门没买到票,那好,今天没买到30号出发的票,我再修改一下我的车次信息,明天早上9点我再换个网速好点的地方再去抢个好位置,说不定明天他就能如愿买到31的票。
这个方案有两个“亮”点:
1)抢票。不抢是不行的,中国人这么多,资源又那么少,铁道运力有限的情况下你能不抢??你不在网上刷网页抢,就得冬天一大早起来排队去抢,或者打电话抢,你选择怎么抢??
2)后台卖票程序。这个比起什么高并发,数据库瓶颈,多台server,数据库一致性等等问题简单到不知道哪里去了。后台卖票程序运行的时候定在晚上0点到早上7点之间,7个小时其它地方不卖票,光这个程序读数据库中收集好的购票意向信息逐个处理,7个小时处理不完接下来一天的购票信息吗?如果真处理不完那么具体细节设计上我们再好好探讨一下
排队系统是从云风那里读到的。事在人为,如果不人为设置障碍或者铁道部自己就没打算好好卖,票绝对没有那么难卖