大道至简

至繁归于至简~~~

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  19 随笔 :: 0 文章 :: 58 评论 :: 0 引用

公告

  难得在博客园上能看到案例设计讨论,而且是关于12306售票系统的。于是我也来发表下的我一些感想,欢迎来吐槽!

  12306系统升级了,但还是被吐槽了。这次国庆我没买火车票,按照去年春节的购票经历,我谈谈我的看法。

  什么才是12306最需解决的问题?

  1、  重大节假日前期,系统登陆难。

  2、  抢票环节的并发处理能力。

  3、  余票查询的响应速度。 

  人们往往有先入为主的观念,导致了解决问题的思维方式收到束缚,难以跳出既定的圈子。谁能说现在的购票系统的业务逻辑和用户体验是最合理的呢?它的设计合理之处又在哪里呢?我想完全不懂技术的人做产品经理,可以比技术出身的人做的更好,因为不懂技术的产品经理提出的需求不会受技术的束缚,更加注重用户体验。12306的余票查询的用户体验太糟糕了,为什么非要有帐号才可以查询-_-

  购票系统的功能架构和技术架构,势必要考虑到峰值的处理能力,尤其是超大规模并发的处理能力。12306虽说是非盈利性的,但是这毕竟关乎到民生,为何不公开技术架构,让更多的人参与改进呢?

  以上内容可以忽略。以下是我的设计思路,主要采用功能适度分离的思想进行设计。

  1、  余票查询的优化方案

  将余票查询系统与抢票系统功能分离,余票查询系统部署到镜像站点CDN上,抢票系统应用单独部署,支付和退票应用单独部署。(这点很关键)

  数据库的读写分离,主数据库只做写操作,写入购票记录和更新实时余票信息,余票查询库可以通过异步更新获取余票信息。余票查询功能可以基于部署到CDN上,建议免登陆,建议向社会开放余票资源和API。解决查票问题)

  余票查询系统的系统架构。我们需要什么级别的实时性?毫秒级?不需要!余票查询的操作远大于抢票,每1秒内信息的变化都难以想象,所以在余票查询上实时性太高意义不大,只能作为抢票前的参考,所以也没必要一定要用关系数据库,NOSQL其实很合适。系统只要保证购票者在信息获取是平等的,抢票环节是公平的(按照先购先得的原则),然后进行适度优化设计。余票查询的系统架构,我有2个设计方案

  1) 内存数据为主、数据库为辅方案。

写一个分布式数据分发系统(主站为SApp,镜像站点为CApp),支持远程调用更新,设计特定的类或数据结构,将所有待出售的车票余票信息存储在特定的类或数据结构中(也可以是数据缓存),常驻内存。余票信息变更后,更新SApp。SApp与CApp的数据同步可以设置为15秒1次(或1min一次甚至更久,没数据变化当然不需要去更新啦,因为查询这块应用没必要做到秒级的同步)。SApp的故障恢复,数据可以通过DB(DB可以是一个数据库群集或NOSQL)获取;而CApp的故障恢复,就直接从SApp进行提取即可。如果余票信息不存在于本CApp中,则直接通过算法,从对应的CApp_x获取,如果对应的CApp_x中数据不存在,则直接从SApp获取,并告诉SApp应该去更新CApp_x数据。

  

                       

 

  2) 纯数据库方案。

基于车票余额信息进行分库,并进行数据库远程同步。考虑到实际应用特点,可以对余票信息按照部署城市或者地区进行分库。如在杭州买票,基本上都是查询涉及包含杭州的车次信息,所以可以根据这点做深入的优化,增加冗余记录,减少跨库查询。所以这些数据的实时性要求会比较高,要直接从CDN的镜像库获取。出现异地代购性质的余票查询时,通过主数据库的读库(或者对应CDN的镜像库)进行查询。

 

  2、  抢票环节的优化方案

  我可以理解在火车站买票需要排队,因为这样可以维持秩序,对先排队的人也是一种。但是无法理解在网络上买票还需要排队,难道排到后一定有票?更无法理解登陆还要排队,因为把购票者堵在外面不是解决问题的办法,提高窗口的并发处理能力才是关键。

消息队列是需要的,但不应该出现在登陆和购票环节。虽说抢票靠的是硬件、软件、网络和人品,但是每个人都应该同享购票的权利。如何做到这点?

  1)  抢票处理服务和身份认证必须分开部署,前端通过负载均衡提高并发处理能力。

  2)  将每个抢票请求提交到对应的消息队列(不同车次的抢票处理服务,可以部署在不同的服务器上),并返回队列位置ID,抢票环节完成。然后就是等待抢票决策系统的处理结果。保证每个请求都会被登记并被处理,这点才能体现抢票环节的公平、公正、公开。

  3)  异步处理抢票消息队列中的每个信息。抢票成功(表示抢票信息被处理后,受理通过),则给予车票支付序列号,按照序列号支付,完成购票环节。

  4)  用户抢票申请的被接收和被处理过程分开。抢票被接收后,如果当前车次的未处理消息队列大于设定的阀值,则堵塞新的抢票申请。如果消息队列数小于阀值,已经没有余票,但是还有未完成支付的余票,则询问用户知否排队等待(如果有人退票或未能完成支付,则享受优先获得该票的资格,在退票和支付过期处理系统中优先考虑这部分申请)。

  5)  单独部署未支付订单审查系统。每分钟检测超时未支付订单,并将失效的购票申请反馈到相应的队列处理服务器。

  6)  用户可以在有效时间内完成支付工作。可以通过在线支付平台,完成对特定车票支付序列号的支付。支付应用最好也单独部署,加入负载均衡。

 

 

posted on 2012-09-21 15:46 By道无名 阅读(...) 评论(...) 编辑 收藏