铁路订票系统12306网站的业务和技术优化概述.pdf

铁路订票系统12306 网站的业务和技术优化概述 此文于2012-09-21 首发在博客园 /afarmer/archive/2012/09/21/2697494.html 一、排队 相对靠谱的 1、云风：铁路订票系统的简单设计 /2012/01/ticket_queue.html 文中提出：取得ticket id 进行排队，排到后获得session id 去完成购票过程。排队过程 中还可以定时获得排队人数等。只要排到了，购票过程就会很顺利。 点评：需考虑黄牛取得一票ticket id 进行排队的情形，毕竟这个排队跟网游魔兽世界 登录排队、zol 下载排队并不太一致。当然，可以借鉴网游中反外挂的处理，对同一个 IP 发出的排队请求，每隔一定时间就弹出要求输入验证码，目的是提高黄牛DDOS 的 成本。 不靠谱的 1、批判下最近关于12306 架构方案的“排队思路” /topic/1119803 文中提出：（1）事先选择车次票次，等排到了，票没了，再重新开始排，用户不认可； （2 ）排到后再选择车次票次，用户不熟练等操作时间过长，排队等待时间长。 点评：完全可以让用户事先选择可接受的车票车次，再排队，等排到后，网站列出用 户事先选择的车票车次，并显示是否有票，用户一个单击操作即可购买，这样会大大 减少用户购票操作时间。 二、预约 相对靠谱的 不靠谱的 1、我认为现阶段最可行的春运售票模式：公平买票，可解决买票难、买票苦，并且可 彻底断绝黄牛后路/s/blog_6a64bd150100zp23.html 文中提出：提前预约，系统分组，根据沪深指数确定哪一组获得购票权 点评：使得暗箱操作变得容易，不应考虑此种方式。 三、订票与支付分离 相对靠谱的 不靠谱的 1、火车票网售又是无反应和扣款没买到票 /sz_haitao/article/details/7174037 文中提出：用户先在银行支付，并指定车次、车票，银行后台再跟12306 交互，有票 出票并扣款，无票退款。 点评：试想一下，如果用户先在支付宝充值，并告诉支付宝买什么，然后支付宝后台 完成交易过程。这样的过程是与用户体验相悖的。这不是炒股。这种做法是把简单业 务复杂化，也是银行等不愿意做的。 四、缓存 相对靠谱的 1、曹政：铁路订票网站个人的设计浅见 /caoz/blog/item/f4f1d7caee09b558f21fe780.html 文中提出：车次、车票等信息查询都可静态缓存。车票可以简化为有票、无票两种状 态。只有状态变化的时候才更新静态缓存。使用Redis 等key-value 数据库。 点评：其实12306 目前每隔10 分钟更新数据，也是完全可以的。只要采用key-value 数据库进行缓存，而不是去查sql，查询速度就会快很多很多。 五、综合 相对靠谱的 1、邓侃：建设一个靠谱的火车票网上订购系统 /s/blog_46d0a3930100yc6x.html 邓侃：建设一个靠谱的火车票网上订购系统 （续） /s/blog_46d0a3930100yiap.html 文中提出：根据业务横向切割，根据流程纵向切割。与用户交互的前端使用云计算， 靠堆机器来实现蓄水池的功能。 点评：跟云风、曹政提出的不谋而合。 2、陈皓：由12306.cn 谈谈网站性能技术/articles/6470.html 文中对系统涉及到的业务细节和技术细节进行了分析，提出抢票的业务设计的变态以 致不能很好解决，各地建分站等措施。 点评：本文中除了几个技术细节方面有待商榷，比如队列一致性等，具有一定的参考 意义。 3、林仕鼎：简单讨论火车票系统后面的架构设计 /2244218960/85c41050330009xm.html 林仕鼎：再谈谈火车票系统/2244218960/85c4105033000a3v.html 林仕鼎：三谈火车票系统/2244218960/85c4105033000ab2.html 林仕鼎是百度的架构师，在为海量用户提供在线服务方面拥有大量的经验，具有很强 的权威性。在这三篇文档中，林仕鼎提出了在解决类似业务场景是需要遵循的原则 （系统稳定，不雪崩），在技术架构上需要采取的措施（业务与锁解耦，请求调度， 多线程同步模式改为事件驱动的异步模式等等）。具有极高的参考价值。 六、12306 现状 1、铁路客票系统建设“复杂”？业内吐槽排队功能 /articles/2012-09-21/683750.html 文中写到：“客票系统采取了集中与分布相结合的方案，即设立一个中央数据库和若 干个地区数据库，在地区数据库中存储本