金融实时交易系统中的负载均衡模块的制作方法

专利名称：金融实时交易系统中的负载均衡模块的制作方法
CN 102932444 A书明说1/11 页金融实时交易系统中的负载均衡模块技术领域
本申请涉及一种金融实时交易系统，特别是涉及位于终端与后台服务器之间的通讯模块。
背景技术：
人们在使用银行卡、预付费卡等金融卡片进行消费交易时，就用到了金融实时交易系统。请参阅图1，这是金融实时交易系统的简单原理示意图，包括
——多个终端10 :用于读取金融卡片信息，并将包含有金融卡片信息和交易信息的交易请求发送给后台服务器50，还接收后台服务器50返回的交易结果。所述终端10包括刷卡机(也称POS机)、集成有刷卡功能的收银机等，
——一个后台服务器50 :用于接收来自各个终端10的交易请求，根据金融卡片信息(例如金融卡片的卡号、密码等)对交易信息(例如交易金额等)进行处理后，将交易结果返回给各个终端10。
在金融实时交易系统中，交易请求、交易结果均为符合IS08583协议的报文形式。
图I所示的金融实时交易系统中，终端10的数量众多，因而同时发出的交易请求可能有成千上万条，这将对后台服务器50的并行处理能力带来极大的压力。为此，实际应用的金融实时交易系统在后台服务器50的前端设置了通讯模块20，如图2所示。新增加的通讯模块20用于实时接收来自多个终端10的短连接方式传输的交易请求，并将其以长连接方式异步发送给后台服务器50 ;还接收后台服务器50以长连接方式异步传输的交易结果，并将其以短连接方式同时发送回各个终端10。所述通讯模块20与终端10之间采用短连接的通讯方式，即每进行一次报文收发时才进行连接，收发完毕后立即断开连接。所述通讯模块20与后台服务器50之间采用长连接的通讯方式，即先建立连接再进行报文收发，在没有报文收发时连接也不断开。
显然，由通讯模块20同步、并行地接收各个终端10的交易请求，将其缓存起来后串行、异步地发送给后台服务器50，这大大提高了对前台(终端10)的响应能力，又极大地减轻了对后台(后台服务器50)的压力。同时，通讯模块20还串行接收后台服务器50返回的交易结果，并将其并行地返回至各个终端10。
目前，所述的通讯模块20主要是由一种专门的硬件设备“网控器”(Network Access Controller)来实现的。网控器包括被称为上联卡和下联卡的两块网卡、总线、诸如网线接口、串行接口、modem接口等的各种接口。其中，下联卡与终端10通过拨号网、专线、 局域网等物理连接方式进行报文通讯，上联卡与后台服务器50通过串行接口、modem、局域网等物理连接方式进行报文通讯，下联卡与上联卡之间通过内部总线交换数据并受内部路由表的控制。
所述通讯模块20可以是一台网控器，也可以是级联的多台网控器。例如如图3所示，终端IOa位于北京市，后台服务器50位于上海市，终端IOa连接作为北京市节点的第一网控器21a，该第一网控器21a再连接作为华北区域节点的第二网控器21b，该第二网控器421b再连接作为上海市根节点的第三网控器21c，该第三网控器21c直接连接后台服务器 50。此时，第一网控器21a与终端IOa之间采用短连接通讯，各网控器之间的级联、以及第三网控器21c与后台服务器50之间均采用长连接通讯。
由网控器21实现的通讯模块20具有以下缺陷
其一，后台服务器50是金融机构用于交易结算的，每个金融机构在全球范围内通常只部署一处。随着金融交易的迅猛发展，后台服务器50已逐渐发展为基于分布式系统的计算机集群。而每台网控器21都只能连接到一台后台服务器50，不支持计算机集群，自然也不具备负载均衡功能。
针对后台服务器集群，目前只能为每一台后台服务器50设置各自独立的通讯模块20，并根据报文的流量和并发数为每一通讯模块20分配终端10。实际应用中，由于报文流量和并发数随时变化，这种人工干预的处理方式不灵活、难以调整。
其二，网控器21不支持热机备份功能，只能采用冷机备份的方式。一旦某一台网控器21出现故障，只能采用人工恢复的方式，成本高，风险大。
其三，每台网控器21能够支持的前台连接数量是有限的。随着金融交易的迅猛发展，高峰时段内的同时交易数量不断上升，这就需要不断购置新的网控器21部署到通讯模块20中，增加了运营和维护成本。发明内容
本申请所要解决的技术问题是提供一种金融实时交易系统中的负载均衡模块，用于替代现有的金融实时交易系统中处于相同位置的通讯模块。所述负载均衡模块可以用于后台服务器集群环境，并且支持热机备份，还便于扩展处理能力，并具有较高的处理性能和较强的稳定性。
为解决上述技术问题，本申请金融实时交易系统中的负载均衡模块位于终端与后台服务器集群之间；
所述负载均衡模块包括至少两台服务器，每台负载均衡服务器均具有一块前台网卡和一块后台网卡，并均采用VRRP协议(虚拟路由器冗余协议)；
所述VRRP协议将所有前台网卡构成一组，并选出一块主控前台网卡，其余的作为备份前台网卡；还将所有后台网卡也构成一组，并选出一块主控后台网卡，其余的作为备份后台网卡；
每台负载均衡服务器均运行有负载均衡程序,该负载均衡程序包括负载均衡进程、多机热备进程和监控进程；所述监控进程用于在负载均衡进程和/或多机热备进程退出时将其重新启动；所述多机热备进程监控虚拟路由器冗余协议所选定的主控前台网卡和主控后台网卡，并要求两者必须在同一台负载均衡服务器上；所述负载均衡进程和多机热备进程之间还相互同步主控前台网卡和主控后台网卡在哪一台负载均衡服务器上的信息。
进一步地，各台负载均衡服务器之间为多机热备关系或多机互备关系；在多机热备关系下，一组前台网卡对外仅具有唯一 IP地址和MAC地址，一组后台网卡对外也仅有唯一 IP地址和MAC地址；在多机互备关系下，一组前台网卡对外具有X个IP地址和MAC地址，一组后台网卡对外也有X个IP和MAC地址，X为互备的负载均衡服务器的个数。
进一步地，所述负载均衡进程以报文作为调度单位，根据后台服务器集群的各个后台服务器的负荷进行任务调度；所述负载均衡进程与各个终端之间为短连接通讯方式， 与各个后台服务器之间为长连接通讯方式。
进一步地，所述负载均衡进程间隔性地向与每一个后台服务器的长连接发送用于获取该条长连接的状态的命令，并获取该条命令所返回的结果，由此判断每一条长连接是否中断；
所述命令包括带有S0_ERR0R选项的getsockopt函数、带有TCP_INF0选项的 getsockopt 函数；
所述结果包括所述S0_ERR0R选项、所述TCP_INF0选项中的RETRANSMIT域；这两个结果任何一个显示某一条长连接异常，则所述负载均衡进程判断该条长连接中断，并停止向对应的后台服务器进行任务调度；否则所述负载均衡进程判断该条长连接正常。
进一步地，所述负载均衡进程为每一台后台服务器仅设置发送缓冲区，用于缓存发给该后台服务器的报文；(不设置接收缓冲区)当所述负载均衡进程判断某一条长连接中断，则将负载均衡服务器中的为相应的后台服务器设置的发送缓冲区中的数据丢弃。
进一步地，所述负载均衡服务器采用基于EPOLL的事件驱动算法，EPOLL是Linux 内核提供的可扩展I/o事件通知机制；
所述基于EPOLL的事件驱动算法将事件分为三种大类，按优先级由高到低排序为实时事件、就绪事件、同步信号调用事件；
所述就绪事件又分为三种小类，按优先级由高到低排序为子进程退出事件、IO 读写事件、超时事件；
所述就绪事件在其生存周期从前到后具有注册、就绪、执行、回收四种状态。
进一步地，所述超时事件从注册状态经过预先设置的时间就转为就绪状态；计算时间时采用CPU时间。
进一步地，所述IO读写事件在任意进程需要从某一个IO端口读取或写入数据时注册；当EPOLL机制发出该IO端口有数据可供读取、或可供写入数据时，该IO读写事件转为就绪状态。
进一步地，在就绪事件处于回收状态时，不释放该就绪事件所占用的内存空间，以便于新的就绪事件注册时可直接利用该内存空间；只有当内存资源不足时，回收状态的就绪事件所占用的内存空间才会被释放。
本申请金融实时交易系统中的负载均衡模块具有多机热备(或多机互备)、负载均衡、事件驱动等多种功能，不仅可以完美取代现有的金融实时交易系统中的通讯模块，而且在功能、性能、扩展性等诸多方面都有了较大提升。


图
图
图
图
图
图I是金融实时交易系统的理论结构示意图；2是现有的金融实时交易系统的实际结构示意图；3是现有的金融实时交易系统中由多台网控器级联作为通讯模块的示意图； 4是本申请的金融实时交易系统的结构示意图；5是本申请的健康检查算法的流程图；6是本申请的基于EPOLL机制的事件驱动算法所具有的事件分类图。
图中附图标记说明
10、IOa为终端；20、20a、20b、20c为通讯模块；30为负载均衡模块；31为负载均衡服务器一 ；32为负载均衡服务器二 ；50为后台服务器；500为后台服务器集群。
具体实施方式
请参阅图4，本申请金融实时交易系统包括
——多个终端10 :用于读取金融卡片信息，并将交易请求发送给后台服务器集群 500，还接收后台服务器集群500返回的交易结果。
——负载均衡模块30 :用于实时接收来自多个终端10的短连接方式传输的交易请求，并将其以长连接方式异步发送给后台服务器集群500 ;还接收后台服务器集群500以长连接方式异步传输的交易结果，并将其以短连接方式同时发送回各个终端10。所述负载均衡模块30与终端10之间采用短连接的通讯方式。所述负载均衡模块30与后台服务器集群500之间采用长连接的通讯方式。
——后台服务器集群500 :用于接收来自负载均衡模块30的交易请求，根据金融卡片信息对交易信息进行处理后，将交易结果返回给负载均衡模块30。
所述后台服务器集群500由多个后台服务器50组成。
所述负载均衡模块30由至少两台负载均衡服务器服务器31、32组成。每台负载均衡服务器均具有两块网卡，一块与各终端10进行通讯称为前台网卡，另一块与各后台服务器50进行通讯称为后台网卡。所有负载均衡服务器都采用VRRP协议，以使所有前台网卡(物理意义上)构成一组，并选出一块主控前台网卡，其余的作为备份前台网卡。所述VRRP 协议还将所有后台网卡也构成一组，并选出一块主控后台网卡，其余的作为备份后台网卡。
VRRP协议通常用于虚拟路由，其应用环境中均为单一网卡设备。本申请将其应用于具有两块网卡的计算机环境中，可能会出现这样的情况负载均衡服务器一 31的前台网卡被VRRP协议选定为主控前台网卡，负载均衡服务器二 32的后台网卡被VRRP协议选定为主控后台网卡，而这两块物理网卡之间并不进行数据交换因而产生了错误。
在负载均衡模块30的各台服务器31、32、......中均运行有负载均衡程序,该负载均衡程序主要包括负载均衡进程、多机热备进程和监控进程。其中的多机热备进程特别地监控VRRP协议所选定的主控前台网卡和主控后台网卡，并要求两者必须在同一台负载均衡服务器上。例如可采用如下方法当一台负载均衡服务器上的前台网卡被选为主控前台网卡时，则强制地将该台负载均衡服务器上的后台网卡也选为主控后台网卡。如果无法强制选举，则说明负载均衡模块30或网络环境出错，此时将以邮件等方式报警，转为人工处理。
所述负载均衡进程和多机热备进程之间还进行信息同步，所同步的信息包括主控前台网卡和主控后台网卡在哪一台负载均衡服务器上。
所述多机热备进程可以实现多机热备功能，即正常情况下只有负载均衡服务器一 31进行工作，负载均衡服务器二 32不工作；当负载均衡服务器一 31出现故障，则转由负载均衡服务器二 32进行工作。所述多机热备进程也可以实现多机互备功能，即正常情况下两台负载均衡服务器31、32各自独立地进行工作，并且彼此设为备机；当一台服务器出现故障，其处理的工作转由另一台服务器进行，并且不影响该接手的服务器的原有工作。多机热7备、多机互备均有成熟的算法加以实现，本申请不再予以赘述。
所述负载均衡进程以报文作为调度单位在各个后台服务器50之间进行任务调度，这是与现有的负载均衡算法的显著区别。此外，进行任务调度的依据是尽量使各个后台服务器50的工作负荷维持为大致相同。
现有的负载均衡算法是以会话(session)为调度单位的。会话是指在通讯网络中的两节点之间建立通信连接、维持通信连接的畅通以交换数据、终止通信连接的过程。
这种以会话为调度单位的负载均衡算法无法真正地实现对服务器集群的均衡调度，举例说明如下
如果一个网页服务器集群采用了现有的以会话为调度单位的负载均衡算法，当一个用户的访问请求被分配到服务器A，并且在服务器A登录了。然后在很短的时间内，这个用户(例如以IP地址判断是否为同一用户)又发出了一个访问请求，如果没有会话保持功能的话，这个用户的请求很有可能会被分配到服务器B。这个时候这个用户在服务器B上是没有登录的，所以这个用户要重新登录。从用户的角度来说，他所面对的是“一台”网页服务器，他感觉需要在短时间内重复登陆，因而用户体验很不好。为了提升用户体验，现有的以会话为调度单位的负载均衡算法均包含有会话保持功能，在一段时间内将同一用户的访问请求都分配给同一台服务器。这样实际上并不是完全考虑每台服务器的运行负荷来进行调度分配的，其中掺杂有会话保持的因素。只有针对不同用户的访问请求，现有的以会话为调度单位的负载均衡算法由于无需考虑会话保持，才真正实现了以每台服务器的运行负荷来进行调度分配。
本申请以报文作为负载均衡算法的调度单位。所述报文例如是符合IS08583协议的报文，包括交易请求、交易结果等。由于金融交易之间彼此没有关联，互不影响，因而即便是同一终端10所发出的多个交易请求，也可以分配给后台服务器集群500中的不同服务器 50。因此本申请所采用的负载均衡算法不需要会话保持功能，这使后台服务器集群500中的各台服务器50仅根据运行负荷得到调度分配，从而最为均衡、充分地发挥处理性能。
通常，所述负载均衡进程与后台服务器集群500中的每一台服务器50建立一条且仅建立一条长连接用于报文通讯。所述负载均衡进程采用健康检查算法来获知与各台服务器50之间的连接是否中断，一旦连接中断则停止向其进行调度分配，一旦连接恢复才重新开始向其进行调度分配。所述健康检查算法大致可描述为负载均衡进程间隔性地向与每一台服务器50的长连接发送用于获取该条长连接的状态的命令，并获取该条命令所返回的结果。通过分析所述结果，判断每一条长连接是否中断。
本申请示例性地给出所述健康检查算法的一个实施例，如图5所示,包括如下步骤
第I 步，设置 setsockopt 函数的 S0_KEEPALIVE 选项。setsockopt 函数是 LINUX 系统下(P0SIX标准的)用来设置socket连接参数的函数,是set socket option的缩写。
TCP协议内置有KEEPALIVE内部健康检查机制，大致的做法为每隔一段时间发送一个数据包并接收应答；如果在规定的时间内未收到应答，则按一定的时间间隔重复发送; 如果连续发送了 N个数据包都收不到应答则认为连接断开；只要重复发送的数据包中有一个收到应答就认为连接未断。
S0_KEEPALIVE是setsockopt函数支持的选项，用来设置KEEPALIVE机制的参数，包括重复发送数据包的时间间隔、最大重复发送次数、启动检查的闲置时间等。所述启动检查的闲置时间是指当系统正在通过连接传输数据，则说明该连接未断开，KEEPALIVE机制不发送数据包。当系统停止传输数据后，经过预定的时间后KEEPALIVE机制才发送数据包， 所述预定的时间就是“启动检查的闲置时间”。
第2步，所述负载均衡进程定时地向与每一台服务器50的长连接发送带有S0_ ERROR选项的getsockopt函数，并获取其所返回的S0_ERR0R选项。getsockopt是LINUX 系统下(P0SIX标准的)用来得到socket连接选项的函数,是get socket option的缩写。 S0_ERR0R是getsockopt函数支持的选项,是用来查看socket连接的状态是否异常,具体来说是查看KEEPALIVE机制的检查结果。S0_ERR0R选项通常为一位数字，具有一个表示连接正常的取值(例如为O)和多个表示连接异常的取值(例如为1、2、……，不同取值表示不同的异常状态)。
所述负载均衡进程还定时地向与每一台服务器50的长连接发送用于带有TCP_ INFO选项的getsockopt函数，并获取其所返回的TCP_INF0选项。TCP_INF0是getsockopt 函数支持的另一选项，用来查看TCP连接状态信息。TCP_INF0选项中包含RETRANSMIT域， 其中记载了当前时刻数据包在该条长连接的重新发送次数。TCP数据包在第一次发送失败后，经过第一时间间隔后，将进行第二次发送；在第二次发送失败后，经过第二时间间隔后， 将进行第三次发送；……以此类推，直至到达设定的最大发送次数。并且第二时间间隔为第一时间间隔的两倍，第三时间间隔是第二时间间隔的两倍，……。所述RETRANSMIT域就记载了 TCP数据包当前时刻的重新发送次数，根据各时间间隔即可得到对应的重新发送时间。
第3步，一旦有某条长连接的S0_ERR0R选项显示连接异常，则所述负载均衡进程判定该条长连接中断，停止向该条长连接所对应的后台服务器50分配任务。
针对S0_ERR0R选项显示连接正常的长连接，再看这些长连接的TCP_INF0选项中的 RETRANSMIT 域。
如果这些长连接的TCP_INF0选项中的RETRANSMIT域显示当前时刻数据包在该条长连接的重新发送次数大于预设的阈值(即重新发送时间大于预设的阈值)，则所述负载均衡进程判定该条长连接中断，停止向该条长连接所对应的后台服务器50分配任务。
如果这些长连接的TCP_INF0选项中的RETRANSMIT域显示当前时刻数据包在该条长连接的重新发送次数小于或等于预设的阈值，则所述负载均衡进程判定该条长连接未中断，仍然向该条长连接所对应的后台服务器50分配任务。
所述方法第I步和第2步紧密相关，只有在对KEEPALIVE机制的相关参数进行设置之后，所获取的KEEPALIVE机制的检查结果才是及时、有用的。优选地，本申请限定S0_ KEEPALIVE选项中的各参数的取值范围是
——重复发送数据包的时间间隔为2秒。该参数如果设置得太小会影响网络通讯，因为会有大量的数据包发送；如果设置得太大会影响检查的及时性，可能网线中断许久之后才会被发现。
——最大重复发送次数为7次。该参数如果设置得太小会影响检查的准确性，因为会有误判的情况；如果设置得太大会影响检查的及时性。
——启动检查的闲置时间为I秒。该参数设置得越小，越能尽快开始检查。
以上这组参数能保证在1+2*7=15秒左右发现连接坏掉，并通过了多次试验证实这组参数比较稳定。
所述方法第3步中，如果仅依靠KEEPALIVE机制的检查结果，则其具有一个致命缺陷无法及时发现网线断开(例如从网线接口中脱落、人为拔下等)的故障。当发生此类故障时，系统内核的发送缓冲区中有数据，此时KEEPALIVE机制不会工作(其只在系统内核的发送缓冲区中的数据传输完毕后，经过所设置的“启动检查的闲置时间”才开始工作)，通过 S0_ERR0R选项所得到的结果就是KEEPALIVE机制过时的检查结果。为此本申请同时综合了 TCP_INF0选项。优选地，当RETRANSMIT域显示当前时刻数据包在该条长连接重新发送了 6 次(即总共发送了 7次)或更多次，对应于重新发送时间为15秒左右(第一时间间隔O. 25秒 +第二时间间隔O. 5秒+第三时间间隔I秒+第四时间间隔2秒+第五时间间隔4秒+第六时间间隔8秒=15. 75秒)或更长时间，所述负载均衡模块30就认为出现了网线断开的故障，从而判断该条长连接中断。本申请将S0_ERR0R选项和TCP_INF0选项相综合，才可以完整地覆盖各种故障情况的判定。
所述方法第3步中，除了先判断S0_ERR0R选项，在S0_ERR0R选项显示连接正常时再看TCP_INF0选项之外，还可以同时判断S0_ERR0R选项和TCP_INF0选项，这两个结果中只要有任何一个显示某一条长连接异常，则所述负载均衡进程判断该条长连接中断。
所述方法第3步中，当所述负载均衡进程发现其与后台服务器集群500中的一台或多台服务器50之间所建立的长连接断开，则不再为这些服务器50分配任务。尚未处理完毕的交易请求不会反馈给终端10，终端10在预定时间内未收到交易结果则按照超时交易处理，例如发送冲正交易请求。所述冲正交易请求是指如果之前的交易请求已经被后台服务器集群500所处理，产生了扣款操作；那么该冲正交易请求就将之前的交易请求取消， 将扣款返回原账户。如果之前的交易请求尚未被后台服务器集群500所处理，那么该冲正交易请求就不进行操作。同时，所述负载均衡进程为每一个与其连接的后台服务器50均仅设置有发送缓冲区，不设置接收缓冲区。所述发送缓冲区用于缓存发送给后台服务器50的交易请求等报文。一旦发现某一条长连接断开，本申请就将为相应的后台服务器50设置的发送缓冲区中的数据丢弃掉。这样设置可以避免下述情况的发生一旦这些后台服务器50 与所述负载均衡模块30之间重新建立长连接，如果不丢弃发送缓冲区中的内容，则这些后台服务器50必然会处理发送缓冲区中的报文，这就有可能产生终端10认为已经超时的交易在后台服务器集群500却成功交易的矛盾情形。按照本申请的方法，当这些服务器50与所述负载均衡模块30之间的长连接恢复以后，就可以开始接收新的任务，而不会受到之前任务的影响。
本申请的负载均衡服务器均运行一个负载均衡程序，在运行时该负载均衡程序分为多个进程(process )执行，每个进程在执行时具体又分为多个事件(event)。所述进程之间还具有层级，例如，负载均衡程序包括负载均衡进程、多机热备进程和监控进程，监控进程是其他两个进程的父进程，用于在其他两个进程不论以任何方式退出(例如崩溃)时将它们重新启动。
本申请所述的负载均衡服务器采用基于EPOLL的事件驱动算法。EPOLL是2. 6以上版本的Linux内核提供的可扩展I/O事件通知机制，EPOLL机制对外提供I/O接口的状态，包括每个IO端口是否有数据到达可供读取、是否空闲可供写入数据等。
请参阅图6，本申请所述的基于EPOLL的事件驱动算法将事件分为三种类型
——实时事件，是指由人工操作所引起的事件。人工操作会启动一个或多个进程执行，这些进程所对应的事件就属于实时事件，必须以最高优先级进行处理。
——就绪事件，有且仅有三种，分别是子进程退出事件、IO读写事件、超时事件，它们彼此之间的优先级从高到低排序为子进程退出事件> IO读写事件>超时事件。这些事件按照优先级从高到低的顺序进入就绪事件队列，就绪事件队列为先入先出(FIFO)队列， 先放入就绪事件队列的事件就先执行。
——同步信号调用事件，是指对信号的处理，例如子进程退出是以信号的方式通知的，有一些管理员命令如服务器退出也是以信号的方式处理的。
这三种事件类型按照优先级从高到低排序为实时事件>就绪事件> 同步信号调用事件,优先级高的事件类型永远比优先级低的事件类型先执行。
所述就绪事件在其生存周期从前到后具有如下四种状态
——注册，是指初始化就绪事件，包括设置就绪事件的具体种类、回调函数参数、 IO端口，就绪事件所属进程及状态等信息。
——就绪，是指将就绪事件处于随时可执行的状态。
——执行，是指处理就绪事件。
——回收，是指就绪事件执行完毕后，不释放该事件所占用的内存空间，以便于新的就绪事件注册时可直接利用该内存空间。只有当内存资源不足时，回收状态的就绪事件所占用的内存空间才会被释放。
所述子进程退出事件在所述负载均衡程序启动时注册，更具体地讲是在所述多机热备进程和负载均衡进程启动时注册，多机热备进程和负载均衡进程均以监控进程的子进程的方式被创建。在所述负载均衡程序中，监控进程是其他所有进程的父进程，其他所有进程是监控进程的子进程。当任意子进程退出时，都会向父进程发出一个退出信号，这是一个同步信号调用事件。监控进程收到该退出信号后，就将子进程退出事件转为就绪状态。根据进入就绪事件队列的顺序，子进程退出事件会被处理，即将退出的子进程重新启动，并注册一个新的子进程退出事件。然后该老的子进程退出事件转为回收状态。
所述IO读写事件在任意进程需要从某一个IO端口读取或写入数据时注册。当 EPOLL机制发出该IO端口有数据可供读取、或可供写入数据时，该IO读写事件转为就绪状态。根据进入就绪事件队列的顺序，该IO读写事件会被处理，即从该IO端口读取或写入数据，执行时会将IO端口、参数和状态传给回调函数。然后该IO读写事件转为回收状态。
所述超时事件通常用于那些需要定时处理的事务，例如前述的健康检查算法。超时事件也是在所述负载均衡程序启动时注册。注册后经过预先设置的时间就转为就绪状态。值得注意的是，这里的时间采用CPU时间，CPU时间具有只增不减且不能人为修改的特点。根据进入就绪事件队列的顺序，该超时事件会被处理。如果是一次性即可处理完毕的超时事件，随后就转为回收状态。如果是定时处理的超时事件，在处理过程的最后会将自身重新转为注册状态，而不转为回收状态。
本申请所述的基于EPOLL的事件驱动算法具有如下优点
其一，仅给出了有限的事件类型，并且严格定义了优先级，经过反复验证确保了在 Linux系统中运行的稳定性，避免了事件之间的死锁现象。为了避免出现事件之间的死锁现象，现有的事件驱动算法需要人为避免，而本申请则由预先设置的事件类型和优先级予以保证，使得程序的稳定性大大提高，减少了程序开发的难度。
现有的事件驱动算法有许多，比较有名的有libevent, libev,nginx等。这些事件驱动算法都给出了较多的事件类型，并且允许自定义这些事件类型的优先级。例如Iibev 事件驱动算法给出了错误事件、检查事件、自定义事件、定期处理事件、清理事件、子进程复制事件等事件类型，它们可以在255个优先级之间自行定义。一旦对某些事件类型的优先级定义失误，就可能引起整个程序的死机。例如，把信号的同步信号调用事件的优先级定义得比IO读写事件高，然后某个信号的处理过程中会注册IO读写事件并且要等该IO读写事件处理完成后该同步信号调用事件才算完成。那么就会出现新注册的IO读写事件由于优先级较低而无法处理，优先级较高的同步信号调用事件由于需要等待该IO读写事件而无法继续，形成逻辑上的死锁。
其二，采用单调的时间管理，默认使用CPU时间。如CPU不支持则使用系统时间加以模拟，模拟的方式为记录下管理员每次修改系统时间的差值，在计算系统时间时加上差值，以确保不受人为修改系统时间的影响，进而保证超时事件的计时精确性。
其三，与传统的非事件的IO操作相比，性能明显提高。如果不使用事件方式运行 IO读写即IO的阻塞读/写，会挂起IO读写的进程，直到读取或者写入成功。本申请所述系统显然具有大量的IO读写操作，这势必会大量耗费系统资源。
与现有的事件驱动方法相比，本申请基于EPOLL机制运行。EPOLL是Linux下效率最高的IO事件通知机制，因而使得本申请的事件驱动算法的性能和扩展性大大提高。
其四，现有的事件驱动算法中，事件执行完毕后即释放内存空间，新事件注册再重新分配内存空间。如果大量的事件的初始化(即注册)都重新分配内存空间，将会极大地影响系统性能。
本申请为就绪事件设计了回收状态，只是用来保存所分配的内存空间。如果不同事件实际所需的内存大小不同，那么本申请为所有事件不加区分地分配最大的内存空间， 以便于重复使用该内存空间时可用于任何事件。这样新事件在注册时，首先利用回收状态的事件的已分配的内存空间，只有当回收状态的事件全部使用光了，才由系统重新分配内存空间。所述三种就绪事件在回收状态便不再区分，任何新的就绪事件注册都可以使用。例如，IO读写事件进入回收状态后，其未被释放的内存空间可用于新的超时事件的注册。
本申请所述的负载均衡程序分为两种工作模式，分别为调试模式和生产模式。生产模式用于实际工作，调试模式则用于发现程序运行过程中的内存错误和文件描述符错误。
程序在运行过程中会占用计算机的内存资源，在为程序分配内存的过程中，会出现如下几种错误内存访问越界(buffer overrun)、释放空指针(free null pointer) > 重分配空指针(realIoc null pointer)、释放没有分配的内存(free non-allocated buffer)、多次释放同一内存(double free)、分配的内存在程序结束时没有释放 (non-released buffer) 0这些内存错误可能会导致程序运行错误、程序运行失败、计算机死机等重大问题，并且如果不解决内存错误这些问题将会持续不断地发生。
本申请所述的负载均衡模块在调试模式下采用了一种内存管理算法，来检查负载均衡程序在运行过程中的内存分配、释放及使用中的问题。该内存管理算法是这样的
其一，在调试模式下，负载均衡程序在每一次要求获取内存空间时，都会分配比所要求的内存空间更大的实际内存空间。该实际内存空间分为三段，中间一段就是所要求的内存空间大小，前后各多分配一小段空间均用于记录内存边界的校验和数据。
其二，每次内存分配时还会在内存中以额外的数据结构记录本次内存分配的类型、文件、函数、行号、大小、分配后的内存地址。校验和主要是用于检测内存的越界访问，越界访问的话校验和就会被破坏。
其三，每次内存分配时还会在磁盘中记录日志，包括系统在何时进行了何种操作， 具有何种结果等信息。
在调试模式下，通过分析上述校验和是否完整、额外的数据结构、日志记录等，可发现程序设计是否会出现内存分配问题。
文件描述符(file descriptor)是系统内核用来访问文件的，由于其长度固定，因而文件描述符的数量是有限的。在为程序分配文件描述符的过程中，会出现如下几种错误 打开的文件描述符在程序结束时没有关闭(non-closed fd)、关闭没有打开的文件描述符 (closed non-opened fd)、关闭空描述符(close bad fd)、多次关闭同一描述符(double close)、PIPE打开的描述符关闭了一半(only close one of pipe fd)。这些文件描述符错误可能会导致程序运行错误、程序运行失败、计算机死机等重大问题，并且如果不解决文件描述符错误这些问题将会持续不断地发生。
本申请所述的负载均衡模块在调试模式下采用了一种文件描述符管理算法，来检查负载均衡程序在运行过程中的文件描述符的分配、释放及使用中的问题。该文件描述符管理算法是这样的
其一，在调试模式下，负载均衡程序在每一次要求获取文件描述符时，都会在内存中以额外的数据结构记录本次文件描述符分配的类型、文件、函数、行号、大小、打开后的文件描述符的数值。
其二，每次文件描述符分配时还会在磁盘中记录日志，包括系统在何时进行了何种操作，具有何种结果等信息。
在调试模式下，通过分析上述额外的数据结构、日志记录等，可发现程序设计是否会出现文件描述符的分配问题。
本申请所述的负载均衡模块用于替代现有的金融实时交易系统中的通讯模块，因而必然要支持通讯模块所能实现的全部功能。其中最主要的就是实时接收来自多个终端的短连接方式传输的交易请求，并将其以长连接方式异步发送给后台服务器集群；还接收后台服务器集群以长连接方式异步传输的交易结果，并将其以短连接方式同时发送回各个终端。该过程中传输的就是IS08583协议定义的报文，该报文包括TPDU(Transport Protocol Data Unit，传输协议数据单元)、报文头和应用数据。其中TDPU由三项组成，分别是用于标识报文类型的ID项(I个字节)、目的地址项(2个字节)、源地址项(2个字节)。所述ID项在报文正确时一般为0x60，错误时一般为0x68，Ox表示十六进制数。目的地址项就是报文接收方的标识。源地址项就是报文发送方的标识。
例如，在一个实际的金融实时交易系统中，终端10与后台服务器50之间进行交易通讯，但终端10所连接的实际上是负载均衡模块30。终端10、负载均衡模块30、后台服务器50的标识地址分别为A、B、C，均表示两字节的十六进制数。那么从终端10向负载均衡模块30所发送的报文的TPDU部分就是〈0x60，C，A>。负载均衡模块30在收到该报文后， 将该报文的TPDU部分变为〈0x60，C，B〉，同时记录下新的源地址B (标识负载均衡模块30) 与老的源地址A (标识终端10)的对应关系。所述新的源地址B是在均衡模块30动态分配的，对于不同的报文，会分配不同的新的源地址B来记录该报文与终端10的对应关系，从而确定该报文应该回到哪个终端10。负载均衡模块30将该报文发送给后台服务器50后，后台服务器50将该报文的TPDU部分再次变为〈0x60，B，C〉，即将目的地址和源地址交换。该报文经过后台服务器50处理后，发送回负载均衡模块30，负载均衡模块30第三次将该报文的TPDU部分变为〈0x60，A，C〉，随后将该报文发送回终端10。
对负载均衡模块30而言，其接收的来自终端10的交易请求报文的TDPU部分为 <0x60, C，A>，其向后台服务器50发出的交易请求报文的TDPU部分为〈0x60，C，B〉，其接收的来自后台服务器50的交易结果报文的TPDU部分为〈0x60，B, C〉，其向终端10发送的交易结果报文的TPDU部分为〈0x60，A，C〉。
对后台服务器50而言，其所接收的交易请求报文的TDPU部分为〈0x60，B, C〉，其所发送的交易结果报文的TPDU部分为〈0x60，C，B〉。
对终端10而言，其所发出的交易请求报文的TDPU部分为〈0x60，C，A>，其所接收的交易结果报文的TPDU部分为〈0x60，A，C〉，中间的处理过程对终端10是透明的。
由于本申请是以计算机运行负载均衡程序的方式实现负载均衡模块，因而具有极大的扩展性。例如，可对IS08583协议定义的报文格式进行修改，将TDPU的目的地址项和源地址项均由2个字节扩展为4个字节，这样负载均衡模块所支持的同时处理的报文数量就可以由216扩展为232。这种扩展由于突破了 IS08583协议的限制，因而需要对终端和后台服务器进行程序升级，可用于并发交易数量突破216的将来。
本申请所述的负载均衡模块中的服务器需要配置至少两张网卡，一张网卡用于连接终端的接入，另一张网卡用于连接后台服务器集群。通过两张网卡的隔离设置，可以实现网段的隔离，从而很好地保护后台服务器集群的安全性，同时提高实际网络部署时的灵活性。
以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。1权利要求
1.一种金融实时交易系统中的负载均衡模块，其特征是，所述负载均衡模块位于终端与后台服务器集群之间； 所述负载均衡模块包括至少两台服务器，每台负载均衡服务器均具有一块前台网卡和一块后台网卡，并均采用虚拟路由器冗余协议； 所述虚拟路由器冗余协议将所有前台网卡构成一组，并选出一块主控前台网卡，其余的作为备份前台网卡；还将所有后台网卡也构成一组，并选出一块主控后台网卡，其余的作为备份后台网卡； 每台负载均衡服务器均运行有负载均衡程序，该负载均衡程序包括负载均衡进程、多机热备进程和监控进程；所述监控进程用于在负载均衡进程和/或多机热备进程退出时将其重新启动；所述多机热备进程监控虚拟路由器冗余协议所选定的主控前台网卡和主控后台网卡，并要求两者必须在同一台负载均衡服务器上；所述负载均衡进程与多机热备进程之间还相互同步主控前台网卡和主控后台网卡在哪一台负载均衡服务器上的信息。
2.根据权利要求I所述的金融实时交易系统中的负载均衡模块，其特征是，各台负载均衡服务器之间为多机热备关系或多机互备关系； 在多机热备关系下，一组前台网卡对外仅具有唯一 IP地址和MAC地址，一组后台网卡对外也仅有唯一 IP地址和MAC地址； 在多机互备关系下，一组前台网卡对外具有X个IP地址和MAC地址，一组后台网卡对外也有X个IP和MAC地址，X为互备的负载均衡服务器的个数。
3.根据权利要求I所述的金融实时交易系统中的负载均衡模块，其特征是，所述负载均衡进程以报文作为调度单位，根据后台服务器集群的各个后台服务器的负荷进行任务调度；所述负载均衡进程与各个终端之间为短连接通讯方式，与各个后台服务器之间为长连接通讯方式。
4.根据权利要求I所述的金融实时交易系统中的负载均衡模块，其特征是，所述负载均衡进程间隔性地向与每一个后台服务器的长连接发送用于获取该条长连接的状态的命令，并获取该条命令所返回的结果，由此判断每一条长连接是否中断； 所述命令包括带有SO_ERROR选项的getsockopt函数、带有TCP_INF0选项的getsockopt 函数； 所述结果包括所述S0_ERR0R选项、所述TCP_INF0选项中的RETRANSMIT域；这两个结果任何一个显示某一条长连接异常，则所述负载均衡进程判断该条长连接中断，并停止向对应的后台服务器进行任务调度；否则所述负载均衡进程判断该条长连接正常。
5.根据权利要求4所述的金融实时交易系统中的负载均衡模块，其特征是，所述负载均衡进程为每一台后台服务器仅设置发送缓冲区，用于缓存发送给该后台服务器的报文；当所述负载均衡进程判断某一条长连接中断，则将负载均衡服务器中的为相应的后台服务器设置的发送缓冲区中的数据丢弃。
6.根据权利要求I所述的金融实时交易系统中的负载均衡模块，其特征是，所述负载均衡服务器采用基于EPOLL的事件驱动算法，EPOLL是Linux内核提供的可扩展I/O事件通知机制； 所述基于EPOLL的事件驱动算法将事件分为三种大类，按优先级由高到低排序为实时事件、就绪事件、同步信号调用事件；所述就绪事件又分为三种小类，按优先级由高到低排序为子进程退出事件、IO读写事件、超时事件； 所述就绪事件在其生存周期从前到后具有注册、就绪、执行、回收四种状态。
7.根据权利要求6所述的金融实时交易系统中的负载均衡模块，其特征是，所述超时事件从注册状态经过预先设置的时间就转为就绪状态；计算时间时采用CPU时间。
8.根据权利要求6所述的金融实时交易系统中的负载均衡模块，其特征是，所述IO读写事件在任意进程需要从某一个IO端口读取或写入数据时注册；当EPOLL机制发出该IO端口有数据可供读取、或可供写入数据时，该IO读写事件转为就绪状态。
9.根据权利要求6所述的金融实时交易系统中的负载均衡模块，其特征是，在就绪事件处于回收状态时，不释放该就绪事件所占用的内存空间，以便于新的就绪事件注册时可直接利用该内存空间；只有当内存资源不足时，回收状态的就绪事件所占用的内存空间才会被释放。
全文摘要
本申请公开了一种金融实时交易系统中的负载均衡模块，位于终端与后台服务器集群之间。所述负载均衡模块包括至少两台服务器，每台负载均衡服务器均具有一块前台网卡和一块后台网卡，并均采用VRRP协议。所有前台网卡构成一组，对外具有唯一IP地址和MAC地址，对内则区分为一块主控前台网卡和其余的备份前台网卡。所有后台网卡也构成一组，对外具有唯一IP地址和MAC地址，对内则区分为一块主控后台网卡和其余的备份后台网卡。每台负载均衡服务器均运行有负载均衡程序，该负载均衡程序包括负载均衡进程、多机热备进程和监控进程；其中的多机热备进程监控VRRP协议所选定的主控前台网卡和主控后台网卡，并要求两者必须在同一台负载均衡服务器上。
文档编号G06Q40/04GK102932444SQ201210419239
公开日2013年2月13日 申请日期2012年10月29日 优先权日2012年10月29日
发明者袁立威, 钟开鸳, 张林彦 申请人:上海银商资讯有限公司