主题：谈谈大型网站架构的一些关键技术 -- 季侯

邓兄好久不见，进来可好？

邓兄的思路当然很技术，很专业。作为一个伪IT人士，我也来提一个伪技术的解决思路。

我的解决思路是要结合支付宝或类似的第三方支付平台来做。我是这样考虑的。

一、需求分析

1、对于着急买票回家的人，最关心的是能否卖到某日某趟车的车票（或某天的某个时段的车票），对于余票什么的是因为不得已才需要查询，如果能不查询就卖到，谁会关心什么余票。

2、对于铁路买票尤其是春运，提前数天，甚至数十天的计划出行是主流。

基于以上两点考虑，我设计一个“全额预付价款、时间优先的预订单处理系统”

二、设计方案

1、允许用户在发售日之前的相当长一段时间（比如20日）内，在网站查询车次，并填写一个完整的订单（包括了身份证号、预定座位类型，铺位类型、以及铺位优选顺序如先选下铺，再选中铺，几人连号等）。然后用户对这个完整的订单按照最多可能价额，全额预付票价。

2、完成了全额预付费用的订单，进入一个FIFO队列，在车票发售的时候，由后台系统直接处理这个队列就可以了，有剩余的车票再进入传统的销售渠道。

3、用户可以在发票前的任何时候取消订单，票款退回。

4、订单的数量以全车的座位数为限，超出后无法预订，避免超额预订。这个预定较为宽松，因为：

a：可以参考航空座位预售，允许少量超售

b：很多人的需求是允许调整的，比如，没有下铺可以接受上铺，没有9点的车次，可以接受10点的车次，因此是一个较为宽泛的范围。不需要在订单处理的时候，做严格的锁定控制。

c：为了避免预订失败的情况，可以考虑设定比例，比如80%的车票被预订以后，就不再接受新的订单。

因此也避免了数据库的瓶颈。

三、小结

一句话总结：要买票，你把详细订单说明和现金都准备好，一个个排好队，到发票时间点我铁老大按订单的先后顺序依次处理，不提前排队的只能自己碰运气了。

这个方案的核心是，所有的车次查询、订单填写、支付等工作，都是分散在发售日之前的数天甚至数十天之内，在时间轴上进行了平滑。另外，所有的预订都是和数据库弱相关的，不需要锁定数据库（因为预订的时候并不实际处理订单，只是保证订单总座位数不超过车次座位数，实际上如果允许多车次预订，那么实际上限制是一个很宽松的数字）。并且也不存在短时间大量队列处理的问题，预订可以在发售前的任何时间进行。

实际的订单处理可以是一个后台程序，在发售时间以时间优先方式处理完所有的全额预付订单以后再按照传统流程把剩余的票额上网发售。相信这个后台程序不会有什么难度和瓶颈，实际上做成单线程的都可以。

这个方式我认为符合大部分中国人的出行需求，并且对黄牛也很有杀伤力。因为黄牛不可能有大量的资金在20日之前全额票款预定车票，但是自己买票出行的就可以。黄牛也不可能长时间的DDOS阻塞网站，因为阻塞其实也是没有意义的，只有全额预付的订单才会进入（可能的）处理队列。