铁路客票系统架构设计

《铁路客票系统架构设计》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、铁路客票系统架构设计38前言什么才是12306最需解决的问题？1、重大节假日前期，系统登陆难。2、抢票环节的并发处理能力。3、余票查询的响应速度。人们往往有先入为主的观念，导致了解决问题的思维方式收到束缚，难以跳出既定的圈子。谁能说现在的购票系统的业务逻辑和用户体验是最合理的呢？它的设计合理之处又在哪里呢？我想完全不懂技术的人做产品经理，可以比技术出身的人做的更好，因为不懂技术的产品经理提出的需求不会受技术的束缚，更加注重用户体验。12306的余票查询的用户体验太糟糕了，为什么非要有帐号才可以查询-_-购票系统的功能架构和技术架构，势必要考虑到峰值的处理能力，尤其是超

2、大规模并发的处理能力。12306虽说是非盈利性的，但是这毕竟关乎到民生，为何不公开技术架构，让更多的人参与改进呢？以上内容可以忽略。以下是我的设计思路，主要采用功能适度分离的思想进行设计。1、余票查询的优化方案将余票查询系统与抢票系统功能分离，余票查询系统部署到镜像站点CDN上，抢票系统应用单独部署，支付和退票应用单独部署。（这点很关键）38数据库的读写分离，主数据库只做写操作，写入购票记录和更新实时余票信息，余票查询库可以通过异步更新获取余票信息。余票查询功能可以基于部署到CDN上，建议免登陆，建议向社会开放余票资源和API。（解决查票问题）余票查询系统的系统架构。

3、我们需要什么级别的实时性？毫秒级？不需要！余票查询的操作远大于抢票，每1秒内信息的变化都难以想象，所以在余票查询上实时性太高意义不大，只能作为抢票前的参考，所以也没必要一定要用关系数据库，NOSQL其实很合适。系统只要保证购票者在信息获取是平等的，抢票环节是公平的（按照先购先得的原则），然后进行适度优化设计。余票查询的系统架构，我有2个设计方案1)内存数据为主、数据库为辅方案。写一个分布式数据分发系统（主站为SApp，镜像站点为CApp），支持远程调用更新，设计特定的类或数据结构，将所有待出售的车票余票信息存储在特定的类或数据结构中（也可以是数据缓存），常驻内存。余票

4、信息变更后，更新SApp。SApp与CApp的数据同步可以设置为15秒1次（或1min一次甚至更久，没数据变化当然不需要去更新啦，因为查询这块应用没必要做到秒级的同步）。SApp的故障恢复，数据可以通过DB（DB可以是一个数据库群集或NOSQL）获取；而CApp的故障恢复，就直接从SApp进行提取即可。如果余票信息不存在于本CApp中，则直接通过算法，从对应的CApp_x获取，如果对应的CApp_x中数据不存在，则直接从SApp获取，并告诉SApp应该去更新CApp_x数据。382)纯数据库方案基于车票余额信息进行分库，并进行数据库远程同步。考虑到实际应用特点，可以对

5、余票信息按照部署城市或者地区进行分库。如在杭州买票，基本上都是查询涉及包含杭州的车次信息，所以可以根据这点做深入的优化，增加冗余记录，减少跨库查询。所以这些数据的实时性要求会比较高，要直接从CDN的镜像库获取。出现异地代购性质的余票查询时，通过主数据库的读库（或者对应CDN的镜像库）进行查询。382、抢票环节的优化方案我可以理解在火车站买票需要排队，因为这样可以维持秩序，对先排队的人也是一种。但是无法理解在网络上买票还需要排队，难道排到后一定有票？更无法理解登陆还要排队，因为把购票者堵在外面不是解决问题的办法，提高窗口的并发处理能力才是关键。38消息队列是需要的，但不

6、应该出现在登陆和购票环节。虽说抢票靠的是硬件、软件、网络和人品，但是每个人都应该同享购票的权利。如何做到这点？1）抢票处理服务和身份认证必须分开部署，前端通过负载均衡提高并发处理能力。2）将每个抢票请求提交到对应的消息队列（不同车次的抢票处理服务，可以部署在不同的服务器上），并返回队列位置ID，抢票环节完成。然后就是等待抢票决策系统的处理结果。保证每个请求都会被登记并被处理，这点才能体现抢票环节的公平、公正、公开。3）异步处理抢票消息队列中的每个信息。抢票成功（表示抢票信息被处理后，受理通过），则给予车票支付序列号，按照序列号支付，完成购票环节。4）用户抢票申请的被接

7、收和被处理过程分开。抢票被接收后，如果当前车次的未处理消息队列大于设定的阀值，则堵塞新的抢票申请。如果消息队列数小于阀值，已经没有余票，但是还有未完成支付的余票，则询问用户知否排队等待（如果有人退票或未能完成支付，则享受优先获得该票的资格，在退票和支付过期处理系统中优先考虑这部分申请）。5）单独部署未支付订单审查系统。每分钟检测超时未支付订单，并将失效的购票申请反馈到相应的队列处理服务器。6）用户可以在有效时间内完成支付工作。可以通过在线支付平台，完成对特定车票支付序列号的支付。支付应用最好也单独部署，加入负载均衡。铁道部新客票系统的设计（一）非功能