12306ng票池系统架构 v0.1

[Bin Zhang(张斌)]

12306ng票池系统架构 v0.1

 

12306ng票池系统提供负责12306ng系统中的列车车票查询，车票订购，线路规划以及相关服务。

票池系统在12306ng系统中的位置

票池系统属于应用层系统，在当前的12306ng系统架构设计中， 票池系统通过服务网关与其他应用层系统通信，并将数据存储至ngSQL子系统中。

关于应用系统间服务接口规范，请参看《12306ng应用层子系统服务接口规范建议》

基础数据服务

基础数据是12306ng系统中被各个应用层服务共享的公共数据部分。包括车站信息、线路信息、车次信息、列车时刻表、票价等等。由于基础数据不轻易变动， 我们建议基础数据服务作为一个进程内组件开发，每个应用层服务自行加载管理各自的基础数据服务，以减少服务器间通信的成本。

票池系统提供的服务接口

票池系统主要提供四个对外服务接口

乘车线路规划

根据用户指定的出发站， 目的地站，出发日期，座位类别等信息， 帮助用户规划乘车方案。乘车方案包括列车车次，发车时间，中转站， 中转车次， 中转发车时间，到达目的地时间等相关信息。

余票查询

根据用户指定的车次， 出发站，目的地站，座位类别，购票数量等信息， 查询相关车次的余票情况。

车票订购

用户向交易服务订购车票。 当用户请求发送至交易服务后， 交易服务首先向票池服务查询相关车票并请求占票。 如果占票成功， 交易服务继续执行交易流程。用户付款成功后， 交易服务通知票池服务车票已售出。 如果交易未能完成， 票池系统将被占用的车票重新放回票池中。

票额计划接收

业务网关制定列车车票发售计划后，通知票池系统。 票池系统按计划销售车票， 并在销售周期结束后将销售结果返回业务网关。

票池系统的整体架构

12306ng票池系统内部主要分为线路规划服务与列车票池服务两大服务。线路规划服务负责提供乘车路线规划，不提供余票信息。列车票池服务提供具体列车余票查询，车票订购，退票服务。如果用户通过起止车站查询余票， 系统将首先调用路线规划服务查找相关车次， 然后根据车次查询余票。

系统中每个子服务设计时都考虑负载均衡、备份以及水平扩展的需求。

上图中， 红线左侧是列车票池服务群集；右侧是线路规划服务群集。

列车票池服务

列车票池服务按照列车车次与发车日期（运营车次）垂直分割， 主要分为调度服务、路由服务、运营车次票池服务。 这些服务又各自形成群集。

运营车次票池服务与运营车次服务群集

 

运营车次票池服务负责1至n趟运营车次的车票查询订购服务。服务实现读写分离。每个运营车次服务内部有分为：

l  1台master服务器， 负责订购操作并复制信息至slave服务器上。

l  1..n台 backup slave服务器， 负责对系统热备份。 当master故障时， backup slave选举其中一台成为master接管工作。每台服务器都已自己独立的event log系统来记录日志。 日志的形式可以考虑文件系统以采用stream io提高系统速度。 另外还可以实现一个数据交换服务将日志转存至ng SQL或其它应用服务中。

l  0..n 台 query slave 服务器， 负责查询操作， master负责保持将票池数据同步到query slave上。

由于磁盘流访问方式的速度比随机访问的速度快上百倍， 所以占票、订购信息不直接写入到数据库中， 而是首先以流的方式保存在本地磁盘上，然后通过一个数据交换程序将数据同步至数据库中。

系统中会部署多个运营车次服务以形成群集， 群集中的每个服务所管理的运营车次都不相同。

调度服务与服务群集

调度服务负责将运营车次的票池分配到具体的运营车次票池服务上。调度时根据相应的负载均衡算法。对于热门车次，相应的运营车次票池服务器上仅部署少量车次； 对于冷门车次，相应的运营车次票池服务器上将部署相对多的车次。调度结果尽量满足每个运营车次服务所接受的请求数量相等。

调度服务本身由1台主服务和0..n台备份服务器构成。当主服务故障时， 由备份服务器选举其中一台成为主服务并接管工作。

调度服务将运营车次的票池部署至运营车次票池服务上后， 立即将地址通知备份服务器和路由服务群集。

路由服务与路由服务群集

路由服务负责向用户提供运营车次的票池服务的地址， 同时缓存售罄信息。售罄信息可以选择不同的策略，包括整个列车， 某个区间，甚至铺位等等。 用户查询/订购车票时， 必须首先查询路由服务器获取相应的运营车次服务地址， 然后再调用运营车次服务查询/订购车票。

系统中将部署多台路由服务器。每台路由服务器都是相等的。路由服务器从调度服务器获取运营车次地址信息。 用户可以随机选择一台路由服务器进行查询。

 

线路规划服务

线路规划服务负责提供乘车路线规划。 乘车线路规划的结果可以是一系列的候选路线。规划的结果将缓存在服务中以便快速检索。 系统中包含多台线路规划服务器， 每台服务器都是相等的，依赖服务网关提供的负载均衡算法实现负载均衡。

票池系统设计的一些原则和设想

计算在内存中执行

由于内存访问的速度是磁盘访问速度的上万倍， 系统中所有的数据都将提前加载到内存中， 计算将完全在内存中执行。只有需要写入时，计算结果才会保存在磁盘中。由于系统业务垂直分割， 每个运营票池服务器所占的内存大小是可以接受的。

服务定义原则

请参看《12306ng应用层子系统服务接口规范建议》

使用Imax Disruptor模式

采用Disruptor模式设计系统

Disruptor模式官方网址 http://lmax-exchange.github.com/disruptor/

 

按IO/业务逻辑水平分割运算流程

结合单项服务调用原则与Disruptor中的Ring Buffer消息队列， 系统中的运算流程将按照IO、业务逻辑进行水平分割。这些操作将分别在自己的线程中执行，之间通过ring buffer通信。采用这种模式可以最大限度地提高CPU以及IO设备的使用效率。

假设一个CPU有8个核，理想状态下， 最高效的运行方式是系统只有8个线程， 这8个线程之间互不干扰，每个线程运算所需的数据都在缓存/内存当中，运算过程中完全没有任何如IO等会导致中断的操作。这种模式就是希望让运算尽量向这种理想状态靠拢。
 
假设一个简单的读，运算， 写的交易运算过程， 传统的方式是为每个交易开启一个线程， 流程大约是这样：
 
{
     var data = Read_Input_Data_From_Disk();
    
     var result = Call_Business_Logic(data);
 
     Write_Result_To_Disk(Result);
}
 
在这个流程中，Read_Data_From_Disk以及Write_Result_To_Disk因为会调用IO操作， 那么必然会导致当前CPU运算中断，然后CPU会进行线程切换或进入idle状态。
 
如果我们将这个操作变化成3个独立的线程执行:
 
1 读线程
{
      do
     {
           var data = Read_Input_Data_From_Disk();
           Write_Input_Data_To_RingBuffer(data);
           
     }while(...)
}
 
2 运算线程
{
     do
    {
         var data = Read_Input_Data_From_RingBuffer();
         var result = CallBusinessLogic(data);
         Write_Result_To_RingBuffer(result);
        
    }while(...)
}
 
3 写入线程
{
      do
     {
           var result = Read_Result_From_RingBuffer();
           Write_Result_To_Disk(result);
     }while(...);
}
 
 
那么在这个模式下，当有队列中消息时，所有的设备（CPU， IO）都不会空闲。运算线程由于直接从内存中访问数据， 它的CPU使用率一定非常高。读取、写入线程可以不断把数据从磁盘读入内存或内存写入磁盘，不需要等待逻辑运算的结果。IMax Disruptor模式贡献了一套非常巧妙的消息队列-RingBuffer。这个数据结构可以使得多个线程共同访问消息队列时几乎没有锁定。

 

 

采用多播协议广播消息

在票池系统中的主服务器或调度服务器向备份服务器、查询服务器或路由服务器发送消息时采用多播协议广播消息以减少网络负载。应答模式根据具体的业务要求决定。对于重要的信息，例如备份消息， 路由消息， 采用正向应答模式。即接受者收到消息后会向发送者发送一条确认消息。如果消息接收失败， 发送者重发消息。对于不重要的消息，则没有应答。例如运营车次票池查询服务器， 由于系统允许车票查询存在一定误差， 所以查询服务器不向主服务器返回任何应答消息。