一种具有状态一致性的市场数据实时广播系统及方法
【专利摘要】本发明涉及网络数据实时广播领域，具体是一种具有状态一致性的市场数据实时广播系统及方法，所述的实时广播系统同时被部署在主机和备机上或部署在一主多备机上，主机工作页面内存中日志区存放了所有的业务处理原始数据，广播模块负责实时扫描工作页面内存数据区的市场数据，建立索引、对数据流定序，状态机根据当前服务器是主机还是备机，处于恢复状态还是活跃状态等信息，跟踪服务状态，并控制广播数据是否可以向市场发布，让广播模块能够更高效的处理内存数据。本发明同现有技术相比，其优点在于：在服务器端建立能够快速定位数据及其状态的缓存结构，在保障较高的吞吐量的同时保证较低的响应延时，避免单点网络瓶颈，提高市场稳定性。
【专利说明】一种具有状态一致性的市场数据实时广播系统及方法
[【技术领域】]
[0001]本发明涉及网络数据实时广播领域，尤其涉及高并发访问与低延时响应之间的均衡技术以及数据发布状态一致性相关技术，具体是一种具有状态一致性的市场数据实时广播系统及方法。
[【背景技术】]
[0002]实时的数据广播系统处理请求时不仅要能够承受高并发访问量，还要能低延时地进行响应，广播系统发布的数据对象有公共消息和私有消息两种，公共消息发布到全市场，私有消息只会发送给相关的几个客户端，因此，当产生一条广播数据时，它需要被发送的对象包括了全市场客户端都需要的公共消息和业务直接参与方的私有消息。当一条广播消息被生成时，其需要以较低的延时发布到市场，在发布的瞬间，网络发送所有公共消息和私有消息的时间需求，在发布的时点趋近于O。因此，当市场规模逐步增大的时候，服务器待发布的数据压力在瞬间被无限放大，当突破网络的承受能力时，便会导致拥塞，甚至使得服务器不能对外提供服务，这属于常见的单点网络瓶颈，其所引起的问题是像金融这样具有高稳定性要求的市场中所不允许发生的。
[0003]现有技术中是使用多点网络发送技术解决单点网络瓶颈的问题，采用多个发布服务器之间互相协作的方式来分散数据发布的压力到多个发布点，对于每一个发布服务器来说，随着负荷的增加，仍然存在潜在的单点网络瞬间产生的瓶颈问题，但是可以扩展服务器的规模来缓解压力。当发布点变得越来越多的时候，服务器之间同步与协作的管理会变得越来越复杂，管理与维护的难度、成本会大幅增加。
[0004]在某些领域，比如金融市场，数据广播系统还需要保证所发布的数据具有状态一致性，即数据必须是完整连续的，而且还不能重复乃至发生回溯现象。由于业务服务系统是实时连续对外服务的，这就要求广播系统也要能将市场业务数据实时发布，即广播系统必须提供连续服务能力。常见的热备方式可以保证服务器的连续服务能力，在这种方式下，持久化的消息或者实时网络同步可以保证主备机之间的数据一致性。对于广播系统来说，除此之外，它还需具备状态一致性，即在故障恢复后保证特定的敏感数据不会在客户端出现乱序的状态。
[0005]为了使广播系统具备状态一致性，一种常见的做法是在服务器端建立状态数据库保存每条数据对应于每个客户端的发布状态，在发布数据时，根据数据库中的状态来控制发送的数据和客户端，该数据库的规模是数据量与客户端数目的笛卡尔积，但这种数据库在业务量大的系统中会是一个海量数据，频繁的查询会大大增加服务器的响应延时。
[
【发明内容】
]
[0006]本发明的目的就是为了解决当市场规模逐步增大时，服务器遭遇单点网络瓶颈，从而导致有高稳定性要求的市场拥塞，使服务器不能对外服务的技术问题，实现实时数据广播系统处理请求时不仅能承受高并发访问量还能低延时地进行响应，并保证广播数据在客户端所发布的数据具有状态一致性，数据完整连续，不会出现乱序的状态。
[0007]为了实现上述目的，提供一种具有状态一致性的市场数据实时广播系统，所述的实时广播系统同时被部署在主机和备机上或部署在一主多备机上，主机工作页面内存中日志区存放了所有的业务处理原始数据，这些数据由一定的同步机制在备机上产生，工作页面内存的数据区则是业务处理产生的数据，广播系统需要发布的数据也处于其中，主备机上的广播数据由状态机进行管理，对于备机上产生的广播数据由其控制不对外发布，对于广播模块而言，它负责实时扫描工作页面内存数据区的市场数据，并建立索引、对数据流定序，状态机根据当前服务器是主机还是备机，当前处于恢复状态还是活跃状态等信息，跟踪服务状态，并控制广播数据是否可以向市场发布，每个主机上都有一个发送模块将广播数据发布到市场，它将耗费性能的网络数据发送工作独立开来，从而让广播模块能够更高效的处理内存数据。
[0008]所述的实时广播系统包括数据索引模块、请求处理模块和数据推送模块，所述的数据索引模块对业务系统产生的待发布数据建立索引，快速地根据条件获取到待发布的数据，业务系统产生的待发布数据存放于一片共享内存中，称之为工作页面内存，数据索引模块作为一个后台异步进程存在，它的工作由一个定时器驱动，在每一个定时唤醒的周期点开始扫描工作页面内存数据区，数据索引模块并不对原始的数据进行任何修改，它的主要职责是对这些数据建立可用于查询的索引，并对其定序，同时，它按照数据类型将数据分为多个数据流，并相应地建立多个索引区，索引区建立在系统共享内存中，从而当数据索引模块发生故障重启时，索引区并不会丢失，它可以继续上次的处理结果往下工作，在建立索引的同时，同一数据流会被按自然数递增顺序编号，形成一个连续的序列，以保证数据可以被顺序发布，或者客户端可以自查并发现自己所丢失的数据，在扫描的过程中，数据索引模块以业务处理的事务为单位，处理完一个事务的数据才会处理下一个，保证市场所接收的数据是完整的，而非某个业务过程的其中一个片段；所述的请求处理模块处理来自客户端的主动获取数据请求，根据数据流定位到索引区中的内容，对于公共消息来说，它们由客户端主动获取，为避免产生不必要的流量及保证数据完整连续，客户端都会维护一个自身的状态，即记录自身已经获取到的每一种数据流中的广播数据，客户端可以查询最大值以决定是否需要向服务器获取数据；所述的数据推送模块用于服务器主动推送具有高优先级的消息，数据索引模块在处理待发布数据时，当遇到这类消息时会实时触发推送模块，为避免干扰对客户端主动请求处理的效率，这类消息在不同模块间采用专用的路由线路，考虑到对于广播数据的下发高并发的压力，推送数据也是经由缓冲池，再由独立的数据发送进程进行对外发布。
[0009]所述的实时广播系统还包括状态机模块，状态机模块是数据发布的一致性的重要保证，它被同时部署在主备机上，主要解决当主机发生故障切换时获取市场数据状态及一致性相关控制，状态机包括了初始化、恢复、活跃三种状态，且只有在活跃状态下，广播模块才可以对外发布数据，主机上状态机的状态流转是由业务处理的状态决定的，当业务模块处于恢复阶段时，广播状态机同样处于恢复状态，当业务模块结束重演开始对外服务时，会产生特定的消息，广播模块处理该消息时使状态机进入活跃状态，无论是进程故障还是服务器故障，状态机都按照这样的规则切换状态，因此，在恢复期产生的高优先级消息并不会被推送到客户端，保证数据发布状态一致。[0010]所述的数据索引模块由一个定时器驱动，数据索引模块以业务处理的事务为单位处理数据，从而保证自身数据处理的事务性，每个处理周期主要包括以下步骤:
[0011]a.数据索引模块从状态机读取上一个处理周期的进度情况，如当前数据流已处理到哪个事务；
[0012]b.扫描工作页面内存数据区读取下一个业务处理事务的数据；
[0013]c.将读取到的数据按照消息类型分类到相应的广播流，为每条新数据分配编号，及在共享内存索引区维护一个编号到数据本身的索引关系；
[0014]d.如果所处理的记录不是一个推送消息，跳至f步，否则继续；
[0015]e.判断状态机是否处于活跃状态，是则将消息推送到主机对外接口的待发布队列，否则不发送；
[0016]f.更新状态机，记录本次处理的进度，即已处理到的事务号，如果状态机中的最大事务号较低，则更新为当前值；
[0017]g.当广播处于恢复阶段时，如果当前处理的事务号已经不落后于状态机所维护的事务号，说明已完成历史数据的恢复，将状态机切换到活跃状态，即允许后续的数据发布；
[0018]h.一个处理周期结束，进程进入休眠状态，等待下一次定时器唤醒。
[0019]所述的客户端主动获取数据时根据下列方法请求广播系统下发市场数据:
[0020]a.客户端初始启动，此时客户端并没有任何数据,获取数据的过程如下:
[0021](I)客户端发起请求向广播系统查询并获得当前某广播流的最大编号，记为N ；
[0022](2)客户端发起请求向广播系统拉取该广播流序号区间为〈1，N〉之间的所有广播数据；
[0023](3)广播系统拉模块收到请求并验证合理性，将所请求的数据打包，放入待发队列回复一个请求成功的响应；
[0024](4)广播系统拉模块以异步方式触发主机接口进程下发广播数据；
[0025]b.客户端在实时交易阶段连续获取广播数据
[0026]该场景下主要流程与初始启动相同，所不同的是所请求的范围为客户端所获取的当前最大编号M和广播系统可用数据的最大编号N之间的数据，即〈M，N〉；
[0027]c.异常情况，客户端部分广播数据丢失
[0028]此时，客户端的广播数据因为被误删或其它的意外而变得不连续，从而对后续交易决策产生了影响，此时客户端需要发送重传请求拉取该段数据。
[0029]所述的数据索引模块在处理工作页面内存中数据记录时，对于一些可以定向发送的数据，则会进行主动下推，虽然一条下推的数据只会发送给有限的市场参与者，但是由于广播系统服务于千万个客户端，在交易高峰期可能会产生一定规模的数据风暴，因此要采取缓冲式发送机制，与客户端主动获取时一样，数据推送同样是在状态机标示活跃状态时才被执行，具体流程如下:
[0030](I)数据索引模块通过异步进程通信机制发送消息到广播推送模块；
[0031](2)广播推送模块接到消息用非阻塞的方式将消息加入待发送队列；
[0032](3)推送模块的执行主线逐条处理队列中的消息，将消息加入发送消息体；
[0033](4)如果发送数据量比较大超出消息体的容量时则拆成多个发送数据消息；
[0034](5)将待发送数据消息加入的主机接口待发送队列；[0035](6)待发送队列作为广播系统与主机接口模块的中介，由主机接口模块以一定的定时频率处理并推送数据到市场。
[0036]所述的广播系统故障处理方法如下:
[0037]( I)故障场景一:业务处理进程发生故障重启:
[0038]当业务处理进程发生故障并重启时，所有共享内存数据都不会丢失，由于广播数据的产生是基于事务的，所以业务进程恢复后不需要重新产生，与此同时，不会有新的业务数据被处理，也就不会产生新的广播数据，广播模块会停止下发数据，直到业务进程切换到正常工作模式；
[0039](2)故障场景二:广播系统发生重启；
[0040]当广播系统发生了重启时，因为广播模块索引区和状态机内存都是无事务保证的，数据索引模块重启后会首先清除索引区并重置状态机，然后数据索引模块重新对工作页面内存数据建立索引，状态机则重新经历初始化、恢复、活跃的状态，从而保证数据一致；
[0041](3)故障场景三:主机发生故障，备机接管:
[0042]由于备机处理的速度小于主处理，因此在切换瞬间，备处理机仍有一部分数据需要处理且不需要发送，备处理机上的数据索引模块在处理完这部分数据后，才能将状态机切到活跃状态，才能通知推送模块发送数据，有效保证了广播数据不回流；
[0043](4)故障场景四:主机失败后进行主备切换，之后仅存的主机发生重启:
[0044]主机重启之后状态机进入恢复状态，在此阶段生成的所有广播数据皆不发送，直到切到活跃状态，从而保证数据不回流，达到一致性。
[0045]一种采用具有状态一致性的市场数据实时广播系统的广播方法，将公共消息和私有消息的发布方式加以区分，公共消息由客户端采用定时拉取的方式，私有消息则实时推送，此时，公共消息发送给客户端的时间点被随机分布在客户端的定时周期tf内，而私有数据的发送时间为tg，对于一条广播消息，单位时间的待发布数据数目V’满足以下条件:
[0046]V，= (n+g)/Max (tg, tf)
[0047]在一个确定的系统中，tf与g均为常数，且g的值非常小，在证券交易系统中g —般为交易双方，即2，此时，tg的值几乎为O,远小于tf,因此有:
[0048]V，=(n+g)/tf
[0049]在每一个系统中tf是一个可以根据系统压力进行配置的常数，取值越大，广播系统发布数据的压力越小，系统性能的伸缩性更强。
[0050]本发明同现有技术相比，其优点在于:
[0051]1.在服务器端建立能够快速定位数据及其状态的缓存结构，在客户端维护其自身的状态来提高快速响应的能力，在保障较高的吞吐量的同时，还可以保证较低的响应延时；
[0052]2.通过弱化服务器端的数据推送能力，加强客户端的主动获取能力，从而在服务器与客户端之间合理地均衡分散数据发布与获取的压力，以避免单点网络瓶颈，提高市场的稳定性；
[0053]3.在服务器端建立广播状态机和在客户端维护自身数据状态，由一个广播状态机控制数据产生、恢复、发布的时序，从而保证在故障恢复后数据发布的状态一致性；[0054]4.可用于一主一备的环境,还可以扩展到基于横向切分的具有多台主机的分布式环境中。
[【专利附图】
【附图说明】]
[0055]图1为实时广播系统部署环境示意图；
[0056]图2为实时广播系统功能模块示意图；
[0057]图3为Indexer索引模块建立索引流程图；
[0058]图4为客户端数据拉取流程图；
[0059]图5为广播系统主动推送数据流程图；
[0060]图6为广播系统业务处理进程发生故障重启场景示意图；
[0061]图7为广播系统主备机切换场景示意图；
[0062]指定图1作为本发明的摘要附图。
[【具体实施方式】]
[0063]下面结合附图对本发明作进一步说明，这种系统的结构和原理对本专业的人来说是非常清楚的。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0064]本发明所述的实时广播系统不仅可以提供较高的吞吐量，还可以保证较低的响应延时，其中状态机模块是数据发布的一致性的重要保证，它被同时部署在主备机上，主要解决当主机发生故障切换时获取市场数据状态及一致性相关控制。
[0065]实施例1
[0066]如图1所示，图1是本发明中实时广播系统的部署环境，该广播系统同时部署在主机和备机上，在可靠性要求特别高的环境中，甚至可以部署在一主多备上。图中的主机工作页面内存中日志区存放了所有的业务处理原始数据，这些数据由一定的同步机制在备机上产生，工作页面内存的数据区则是业务处理产生的数据，广播系统需要发布的数据也处于其中。主备机上的广播数据由状态机进行管理，对于备机上产生的广播数据由其空制不对外发布，对于广播模块而言，它负责实时扫描工作页面内存数据区的市场数据，并建立索弓丨、对数据流定序。状态机根据当前服务器是主机还是备机，当前处于恢复状态还是活跃状态等信息，跟踪服务状态，并控制广播数据是否可以向市场发布等。每个主机上都有一个发送模块将广播数据发布到市场，它将耗费性能的网络数据发送工作独立开来，从而让广播模块能够更高效的处理内存数据。
[0067]实施例2
[0068]图2是本发明所提出的实时广播系统各功能模块，Indexer (数据索引模块)是广播数据发布的源头，它定期处理工作页面内存所产生的新数据，并将这些数据分类到不同的数据流，并进行定序编号，在处理的过程中，如果遇到需要推送的数据，它还要将数据的索引以进程间通信的方式告知数据推送模块，以便加入其任务队列。为了避免进程间通信阻塞工作进程，进程间通信采用了任务队列加异步通知的方式。数据推送模块以非阻塞的方式处理来自Indexer (数据索引模块)的消息,并将它们放入任务队列，以便后续处理,原本的数据推送任务并不会因为处理Indexer (数据索引模块)的消息而被打断。主机对外接口是广播模块与交易平台外的一个接口层，它接收客户端的各类请求并产生相应的任务放到拉模块的队列中，因此，请求处理模块就被从网络连接中解放出来，只需负责处理队列中的任务。
[0069]状态机一方面维护着一份Indexer (数据索引模块)每次处理的最新事务编号，该编号将用于故障重演时判断是否重演结束的标志之一；另一方面它反应了整个广播系统的状态，其状态作为广播模块判断数据是否可以发送的依据。
[0070]无论是数据推送模块还是请求模块，它们的数据发送都是经过主机对外接口统一发布，通过将数据处理与数据发送相互独立开来，各司其职，大大提高了发布的能力。
[0071]实施例3
[0072]图3是本发明中的Indexer模块(数据索引模块)的主要工作流程，Indexer (数据索引模块)由一个定时器驱动，Indexer (数据索引模块)以业务处理的事务为单位处理数据，从而保证自身数据处理的事务性，每个处理周期主要包括以下步骤:
[0073](I) Indexer (数据索引模块)从状态机读取上一个处理周期的进度情况，如当前数据流已处理到哪个事务；
[0074](2)扫描工作页面内存数据区读取下一个业务处理事务的数据；
[0075](3)将读取到的数据按照消息类型分类到相应的广播流，为每条新数据分配编号，及在共享内存索引区维护一个编号到数据本身的索引关系；
[0076](4)如果所处理的记录不是一个推送消息，跳到第6)步，否则继续；
[0077](5)判断状态机是否处于活跃状态，是则将消息推送到主机对外接口的待发布队列，否则不发送；
[0078](6)更新状态机，记录本次处理的进度，即已处理到的事务号。如果状态机中的最大事务号较低，则更新为当前值；
[0079](7)当广播处于恢复阶段时，如果当前处理的事务号已经不落后于状态机所维护的事务号，说明已完成历史数据的恢复，将状态机切换到活跃状态，即允许后续的数据发布；
[0080](8) 一个处理周期结束，进程进入休眠状态，等待下一次定时器唤醒。
[0081]实施例4
[0082]图4是客户端拉取广播数据的一次完整的交互序列的流程图，为抽象出核心模块之间的数据流转逻辑，主机接口及响应路由模块均略去。客户端主动获取数据时可根据自身需要请求广播系统下发市场数据，主要有以下几个场景:
[0083]a.客户端初始启动，此时客户端并没有任何数据,获取数据的过程如下:
[0084](I)客户端发起请求向广播系统查询并获得当前某广播流的最大编号，记为N ；
[0085](2)客户端发起请求向广播系统拉取该广播流序号区间为〈1，N〉之间的所有广播数据；
[0086](3)广播系统拉模块收到请求并验证合理性，将所请求的数据打包，放入待发队列回复一个请求成功的响应；
[0087](4)广播系统拉模块以异步方式触发主机接口进程下发广播数据；
[0088]b.客户端在实时交易阶段连续获取广播数据
[0089]该场景下主要流程与初始启动相同，所不同的是所请求的范围为客户端所获取的当前最大编号M和广播系统可用数据的最大编号N之间的数据，即〈M，N〉；
[0090]c.异常情况，客户端部分广播数据丢失
[0091]此时，客户端的广播数据因为被误删或其它的意外而变得不连续，从而对后续交易决策产生了影响。
[0092]如表1所示，客户端的广播序列〈8，10>已经丢失，此时客户端需要发送重传请求拉取该段数据。
[0093]表1客户端广播数据序列编号示意表
[0094]
【权利要求】
1.一种具有状态一致性的市场数据实时广播系统，其特征在于所述的实时广播系统同时被部署在主机和备机上或部署在一主多备机上，主机工作页面内存中日志区存放了所有的业务处理原始数据，这些数据由一定的同步机制在备机上产生，工作页面内存的数据区则是业务处理产生的数据，广播系统需要发布的数据也处于其中，主备机上的广播数据由状态机进行管理，对于备机上产生的广播数据由其控制不对外发布，对于广播模块而言，它负责实时扫描工作页面内存数据区的市场数据，并建立索引、对数据流定序，状态机根据当前服务器是主机还是备机，当前处于恢复状态还是活跃状态等信息，跟踪服务状态，并控制广播数据是否可以向市场发布，每个主机上都有一个发送模块将广播数据发布到市场，它将耗费性能的网络数据发送工作独立开来，从而让广播模块能够更高效的处理内存数据。
2.如权利要求1所述的一种具有状态一致性的市场数据实时广播系统，其特征在于所述的实时广播系统包括数据索引模块、请求处理模块和数据推送模块，所述的数据索引模块对业务系统产生的待发布数据建立索引，快速地根据条件获取到待发布的数据，业务系统产生的待发布数据存放于一片共享内存中，称之为工作页面内存，数据索引模块作为一个后台异步进程存在，它的工作由一个定时器驱动，在每一个定时唤醒的周期点开始扫描工作页面内存数据区，数据索引模块并不对原始的数据进行任何修改，它的主要职责是对这些数据建立可用于查询的索引，并对其定序，同时，它按照数据类型将数据分为多个数据流，并相应地建立多个索引区，索引区建立在系统共享内存中，从而当数据索引模块发生故障重启时，索引区并不会丢失，它可以继续上次的处理结果往下工作，在建立索引的同时，同一数据流会被按自然数递增顺序编号，形成一个连续的序列，以保证数据可以被顺序发布，或者客户端可以自查并发现自己所丢失的数据，在扫描的过程中，数据索引模块以业务处理的事务为单位，处理完一个事务的数据才会处理下一个，保证市场所接收的数据是完整的，而非某个业务过程的其中一个片段；所述的请求处理模块处理来自客户端的主动获取数据请求，根据数据流定位到索引区中的内容，对于公共消息来说，它们由客户端主动获取，为避免产生不必要的流量及保证数据完整连续，客户端都会维护一个自身的状态，即记录自身已经获取到的每一种数据流中的广播数据，客户端可以查询最大值以决定是否需要向服务器获取数据；所述的数据推送模块用于服务器主动推送具有高优先级的消息，数据索引模块在处理待发布数据时，当遇到这类消息时会实时触发推送模块，为避免干扰对客户端主动请求处理的效率，这类消息在不同模块间采用专用的路由线路，考虑到对于广播数据的下发高并发的压力，推送数据也是经由缓冲池，再由独立的数据发送进程进行对外发布。
3.如权利要求1所述的一种具有状态一致性的市场数据实时广播系统，其特征在于所述的实时广播系统还包括状态机模块，状态机模块是数据发布的一致性的重要保证，它被同时部署在主备机上，主要解决当主机发生故障切换时获取市场数据状态及一致性相关控制，状态机包括了初始化、恢复、活跃三种状态，且只有在活跃状态下，广播模块才可以对外发布数据，主机上状态机的状态流转是由业务处理的状态决定的，当业务模块处于恢复阶段时，广播状态机同样处于恢复状态，当业务模块结束重演开始对外服务时，会产生特定的消息，广播模块处理该消息时使状态机进入活跃状态，无论是进程故障还是服务器故障，状态机都按照这样的规则切换状态，因此，在恢复期产生的高优先级消息并不会被推送到客户端，保证数据发布状态一致。
4.如权利要求2所述的一种具有状态一致性的市场数据实时广播系统，其特征在于所述的数据索引模块由一个定时器驱动，数据索引模块以业务处理的事务为单位处理数据，从而保证自身数据处理的事务性，每个处理周期主要包括以下步骤: a.数据索引模块从状态机读取上一个处理周期的进度情况，如当前数据流已处理到哪个事务； b.扫描工作页面内存数据区读取下一个业务处理事务的数据； c.将读取到的数据按照消息类型分类到相应的广播流，为每条新数据分配编号，及在共享内存索引区维护一个编号到数据本身的索引关系； d.如果所处理的记录不是一个推送消息，跳至f步，否则继续； e.判断状态机是否处于活跃状态，是则将消息推送到主机对外接口的待发布队列，否则不发送； f.更新状态机，记录本次处理的进度，即已处理到的事务号，如果状态机中的最大事务号较低，则更新为当前值； g.当广播处于恢复阶段时，如果当前处理的事务号已经不落后于状态机所维护的事务号，说明已完成历史数据的恢复，将状态机切换到活跃状态，即允许后续的数据发布； h.—个处理周期结束，进程进入休眠状态，等待下一次定时器唤醒。
5.如权利要求2所述的一种具有状态一致性的市场数据实时广播系统，其特征在于所述的客户端主动获取数据时根据下列方法请求广播系统下发市场数据: a.客户端初始启动,此时客户端并没有任何数据,获取数据的过程如下: (O客户端发起请求向广播系统查询并获得当前某广播流的最大编号，记为N ； (2)客户端发起请求向广播系统拉取该广播流序号区间为<1，N>之间的所有广播数据； (3)广播系统拉模块收到请求并验证合理性，将所请求的数据打包，放入待发队列回复一个请求成功的响应； (4)广播系统拉模块以异步方式触发主机接口进程下发广播数据； b.客户端在实时交易阶段连续获取广播数据 该场景下主要流程与初始启动相同，所不同的是所请求的范围为客户端所获取的当前最大编号M和广播系统可用数据的最大编号N之间的数据，即〈M，N〉； c.异常情况，客户端部分广播数据丢失 此时，客户端的广播数据因为被误删或其它的意外而变得不连续，从而对后续交易决策产生了影响，此时客户端需要发送重传请求拉取该段数据。
6.如权利要求2所述的一种具有状态一致性的市场数据实时广播系统，其特征在于所述的数据索引模块在处理工作页面内存中数据记录时，对于一些可以定向发送的数据，则会进行主动下推，虽然一条下推的数据只会发送给有限的市场参与者，但是由于广播系统服务于千万个客户端，在交易高峰期可能会产生一定规模的数据风暴，因此要采取缓冲式发送机制，与客户端主动获取时一样，数据推送同样是在状态机标示活跃状态时才被执行，具体流程如下: (I)数据索引模块通过异步进程通信机制发送消息到广播推送模块；(2)广播推送模块接到消息用非阻塞的方式将消息加入待发送队列； (3)推送模块的执行主线逐条处理队列中的消息，将消息加入发送消息体； (4)如果发送数据量比较大超出消息体的容量时则拆成多个发送数据消息； (5)将待发送数据消息加入的主机接口待发送队列； (6)待发送队列作为广播系统与主机接口模块的中介，由主机接口模块以一定的定时频率处理并推送数据到市场。
7.如权利要求1或2所述的一种具有状态一致性的市场数据实时广播系统，其特征在于所述的广播系统故障处理方法如下: (1)故障场景一:业务处理进程发生故障重启: 当业务处理进程发生故障并重启时，所有共享内存数据都不会丢失，由于广播数据的产生是基于事务的，所以业务进程恢复后不需要重新产生，与此同时，不会有新的业务数据被处理，也就不会产生新的广播数据，广播模块会停止下发数据，直到业务进程切换到正常工作模式； (2)故障场景二:广播系统发生重启； 当广播系统发生了重启时，因为广播模块索引区和状态机内存都是无事务保证的，数据索引模块重启后会首先清除索引区并重置状态机，然后数据索引模块重新对工作页面内存数据建立索引，状态机则重新经历初始化、恢复、活跃的状态，从而保证数据一致； (3)故障场景三:主机发生故障，备机接管: 由于备机处理的速度小于主处理，因此`在切换瞬间，备处理机仍有一部分数据需要处理且不需要发送，备处理机上的数据索引模块在处理完这部分数据后，才能将状态机切到活跃状态，才能通知推送模块发送数据，有效保证了广播数据不回流； (4)故障场景四:主机失败后进行主备切换，之后仅存的主机发生重启: 主机重启之后状态机进入恢复状态，在此阶段生成的所有广播数据皆不发送，直到切到活跃状态，从而保证数据不回流，达到一致性。
8.—种如权利要求1所述的具有状态一致性的市场数据实时广播系统的广播方法，其特征在于将公共消息和私有消息的发布方式加以区分，公共消息由客户端采用定时拉取的方式，私有消息则实时推送，此时，公共消息发送给客户端的时间点被随机分布在客户端的定时周期tf内，而私有数据的发送时间为tg，对于一条广播消息，单位时间的待发布数据数目V’满足以下条件:
V，= (n+g) /Max (tg, tf) 在一个确定的系统中，tf与g均为常数，且g的值非常小，在证券交易系统中g —般为交易双方，即2，此时，tg的值几乎为O，远小于tf，因此有:
V’ =(n+g)/tf 在每一个系统中tf是一个可以根据系统压力进行配置的常数，取值越大，广播系统发布数据的压力越小，系统性能的伸缩性更强。
【文档编号】H04L29/08GK103634411SQ201310689144
【公开日】2014年3月12日 申请日期:2013年12月16日 优先权日:2013年12月16日
【发明者】黄成 , 武剑锋, 王泊, 蒋卫, 何希圣, 黄寅飞, 白硕 申请人:上海证券交易所