CN109710699B - 交易数据的录制方法、交易数据的回放方法 - Google Patents
交易数据的录制方法、交易数据的回放方法 Download PDFInfo
- Publication number
- CN109710699B CN109710699B CN201910002323.7A CN201910002323A CN109710699B CN 109710699 B CN109710699 B CN 109710699B CN 201910002323 A CN201910002323 A CN 201910002323A CN 109710699 B CN109710699 B CN 109710699B
- Authority
- CN
- China
- Prior art keywords
- transaction
- message
- local
- data
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明是有关于一种交易数据的录制方法、交易数据的回放方法。所述录制方法包括:前端系统发送交易请求到ESC云终端,将所述交易请求异步写入本地kafka集群,并通过MirrorMaker镜像将所述交易请求同步至异地数据中心;如果本地交易录制补偿应用成功接收到ACK消息,根据所述ACK消息比对核销交易记录;本地ESC云终端接收到后端业务系统响应后,将响应报文异步写入至本地kafka集群,创建topic‑res消息,将所述topic‑res消息持久化至本地数据库,并通过MirrorMaker镜像将所述topic‑res消息同步至异地数据中心。本发明的交易数据的录制方法、交易数据的回放方法弥补异步数据同步的数据差异,保证在异地故障切换时也能实现数据的最终一致性。
Description
技术领域
本发明涉及云计算技术领域,特别是涉及一种交易数据的录制同步方法、交易数据的回放方法。
背景技术
在过去10多年内,人民银行、银监会下发了多份文件指导和规范数据中心灾备建设,以银监会下发的《商业银行数据中心监管指引》为例,明确要求“商业银行应于取得金融许可证两年内设立生产中心”,“生产中心设立后两年内,设立灾备中心”等。目前,国有控股银行、股份制银行和多数城市商业银行都已经进行了同城双活、异地灾备的两地三中心的数据中心建设。
图1示出了两地三中心数据备份的系统结构。参见图1,在目前的两地三中心灾备体系中,数据中心A和数据中心B在同城作为生产级的机房,当用户访问的时候随机访问到数据中心A或B。之所以随便访问,因为A和 B在联机交易发生时会同步做数据复制,所以两边的数据是完全一样的。在两地三中心的概念里,一定会要求这两个生产级的数据中心是必须在同一个城市,或者在距离很近的另外一个城市也可以,但是距离是有要求的,这样网络传输的时间延迟才是有保障的,确保两数据中心的数据同步复制不会对联机交易带来影响。
但是,异地备份数据中心因为距离较远,网络时延较长,是通过数据库异步复制数据实现,这样一来两地三中心中是异地备份的数据中心是不能实时提供服务的,只是做到冷备的作用。
另外在国内一些大型互联网公司,通过服务梳理、跨地域的服务路由等一系列技术手段,减少了跨地域的数据访问,构建多地域能够同时提供服务访问的异地多活架构。但是在进行不同地域之间灾难备份时仍旧采用通过存储应用进行异步数据备份,因为跨地域的网络时延,在进行灾难恢复时仍旧会有部分数据丢失。
发明内容
本发明要解决的技术问题是提供一种交易数据的录制方法、交易数据的回放方法,通过对改变用户数据的联机交易进行实时的录制,并在跨地域灾难切换时进行一定时间的交易回放,从而弥补异步数据同步的数据差异,保证在异地故障切换时也能实现数据的最终一致性。
为解决上述技术问题,本发明提供了一种交易数据的录制方法,应用于本地数据中心,所述录制方法包括:本地前端系统发送交易请求到本地 ESC云终端,将所述交易请求异步写入本地kafka集群,并通过MirrorMaker 镜像将所述交易请求同步至异地数据中心;如果本地交易录制补偿应用成功接收到ACK消息,根据所述ACK消息比对核销交易记录,并将核销结果定时报送给本地监控中心;以及本地ESC云终端接收到后端业务系统响应后,将响应报文异步写入至本地kafka集群,创建topic-res消息,将所述topic-res消息持久化至本地数据库,并通过MirrorMaker镜像将所述 topic-res消息同步至异地数据中心。
作为本发明技术方案的一种改进,在通过MirrorMaker镜像将所述交易请求同步至异地数据中心之后,还包括:如果交易请求异步写入成功,则创建请求类型的topic-req消息,并将topic-req消息持久化至本地数据库的临时表;以及如果交易请求异步写入失败,通知本地监控中心,将失败的交易数据持久化至本地数据库,并实时探测本地kafka集群的状态。
作为本发明技术方案的一种改进,还包括:如果本地交易录制补偿应用未成功接收到所述ACK消息,向本地监控中心告警。
作为本发明技术方案的一种改进,还包括:如果本地ESC云终端未接收到后端业务系统的响应,直接返回;以及如果响应报文写入失败,向本地监控中心告警,同时将该交易记录为可疑交易。
作为本发明技术方案的一种改进,所述交易请求包括:涉及到账户数据变动的交易请求。
作为本发明技术方案的一种改进,在对实时交易录制时,会形成交易涉及用户的黑名单。
此外,本发明还提供了一种交易数据的录制方法,应用于异地数据中心,所述录制方法包括:通过MirrorMaker镜像接收所述交易请求的同步;异地交易录制补偿应用订阅由所述MirrorMaker镜像同步的topic,并将所述交易请求持久化至异地数据库;如果订阅成功,异地交易录制补偿应用反馈ACK消息至本地交易录制补偿应用;以及通过MirrorMaker镜像接收所述topic-res消息的同步。
作为本发明技术方案的一种改进,在对实时交易录制时,会形成交易涉及用户的黑名单。
此外,本发明还提供了一种交易数据的回放方法,应用于异地数据中心,所述回放方法包括:接收本地数据中心发送的故障处理请求;异地交易录制补偿应用从数据库中读取交易的请求报文及对应的响应报文;根据所述响应报文中的响应码,判断所述交易是否被成功响应;如果所述交易被成功响应,异地交易录制补偿应用将所述交易发送至异地ESC云终端;将后端业务系统响应结果与所述响应报文进行比对;以及如果比对结果一致,执行所述交易的回放。
作为本发明技术方案的一种改进,发生异地切换时,会根据交易回放时间锁定黑名单的范围,所述黑名单的范围根据交易回放的进行同步会缩小。
采用这样的设计后,本发明至少具有以下优点:
弥补异步数据同步的数据差异,保证在异地故障切换时也能实现数据的最终一致性。
附图说明
上述仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,以下结合附图与具体实施方式对本发明作进一步的详细说明。
图1是两地三中心数据备份的示意图;
图2是本发明交易录制补偿原理图;
图3是本发明交易数据的录制方法的流程图;
图4是本发明交易数据的回放方法的流程图;
图5是本发明异地切换后交易处理的流程图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明。
谈异地多活架构下跨地域数据同步机制的时候,需要从以下几个维度来看
时效性:跨地域数据同步的时效性主要是要求在一定的距离和一定的有效带宽内,同等数量的数据,同步的用时越短越好,尽可能能够实现实时同步。
保证度:也就是数据一致性的保证程度,其实不存在绝对100%的一致性,尤其是在不同地域的情况下,所以不同机制的差别主要就体现在是几个9,好的机制比如99.999%,弱一点比如99%。
代价:在上述指标保证的前提下,到底要付出多大的代价,例如:跨地域实现万兆带宽,当然这个代价就太大了。
复杂度:指业务系统使用这套机制会带来多大的影响,是不是会变的特别复杂,不能接受。
下面就从上述几个维度对现有的单纯通过存储软硬件进行异步同步进行分析:
时效性:上面通过存储软硬件进行异步数据同步的方式,由于跨地域 (距离在2000公里,百兆带宽情况下)一般情况下的网络时延在30ms-50ms 之间,数据库通过异步log或者异步sql进行数据同步,对于一笔业务交易通常或涉及到多条sql,那么该笔交易的数据同步到另外一个地域需要时间将会在几秒钟,当存在大并发交易请求时,该模式的数据同步延迟将达到几分钟。
保证度:对保证度而言,上述异步数据同步的方式,不能保证实时交易数据的一致性,但是在未发生地域故障时,可以保证数据的最终一致性,但是当发生地域故障时会有一定时间段的数据丢失,不能保证数据的最终一致性。
代价:该机制在跨地域进行传输时,当地域间的距离固定时,只有通过增加带宽的值才能提高数据同步的时效性,而远距离专线的带宽资源的稀缺和高昂的价格都是值得考量的。
复杂度:这种模式,在进行跨地域灾难切换时,势必会存在联机服务的中断,需要采用“挂公告”、“事后对用户进行补偿”、“补充体验”等手段去弥补数据同步丢失数据的问题。
上面的跨地域多活架构下数据同步的主要思路是通过异步binlog或者异步sql同步来实现数据的同步。本专利是在上述异步数据同步的基础上通过对改变用户数据的联机交易进行实时的录制,并在跨地域灾难切换时进行一定时间的交易回放,从而弥补异步数据同步的数据差异,保证在异地故障切换时也能实现数据的最终一致性。
其主体机制是采用对联机交易进行录制补偿实现的,具体如下:
该方案主要功能包括数据异步写入、kafka消息发布订阅、kafka消息可靠传输以及通知监控做监控告警、补偿交易报文的原始响应报文判断、补偿结果对比、KafkaMirrorMaker镜像同步等。图2是本发明交易录制补偿机制的原理图。参见图2,本发明交易录制补偿机制的主要流程如下:
1、本地地域请求报文通过ESC(神州信息企业级服务总线产品,支持银行全部的服务集成)云终端时,由ESC云终端调用异步流程将请求报文写入到本地kafka集群然后持久化到本地DB集群,并启动MirrorMaker集群镜像同步到目标集群。
2、异地地域则启动kafka消费者监听器(交易录制补偿应用)订阅镜像消息,一旦有消息则订阅相关topic,持久化到异地地域数据中心DB集群。
3、本地地域ESC云终端收到后端业务系统交易成功返回后,则返回交易结果并将交易结果异步写入kafka。同时MirrorMaker会将响应报文对应 topic同步到异地地域。
4、如果报文(包括请求响应)异步写入失败则进入异常处理流程并通知监控告警,该笔交易将被记录为可疑交易并将交易相关数据持久化到监控中心作为目标地域还原备份数据,待kafka集群服务恢复正常调用失败重发指令修复丢失数据。
5、最后检查MirrorMaker消费进度确保准确同步。
6、该机制可以灵活进行配置,仅配置涉及数据变更的交易即可,查询等仅涉及读数据的交易无需录制。相应的,该机制配置的所有交易,均需支持幂等性,一旦出现异地切换时,需在ESC上通过重放一定时间(具体时间需参考DB异步备份的进度)的交易,对数据库异步binlog复制的延迟数据进行补偿。
交易录制策略:
1、交易录制补偿的交易选择为涉及到账户数据变动的交易,通过服务代码规则能够进行区分。
2、交易录制补偿链路节点的选择:为防止进行交易补偿时涉及到多个业务系统的数据有前后时差的问题,故需在数据变更类交易源渠道系统节点进行交易录制与回放。
图3示出了本发明交易数据的录制方法的执行过程。参见图3,交易数据的录制方法包括:
1)前端系统发送请求报文到ESC云终端请求后端业务系统等待响应结果,与此同时将涉及数据操作类交易请求报文异步写入本地kafka集群进入MirrorMaker镜像同步流程,异步写入成功则创建请求类型的消息 topic-req并持久化到本地DB临时表中用于报文核销,写入失败则通知监控中心(Kafka Monitor)监控告警同时失败交易数据持久化到DB,之后监控中心进行可疑交易跟踪流程并实时探测kafka集群状态,一旦恢复正常就从DB中读取失败交易数据调用异步写入失败重发命令,最后Kafka Monitor跟踪重发进度。
2)异地交易录制补偿应用订阅上一步镜像同步过去的相关topic并持久化到DB集群,对应的建立请求报文和响应报文的映射关系,订阅报文消息成功则通过TCP方式准实时发送ACK通知信号(全局流水号+子流水号) 给对端交易录制补偿应用,如果源地域交易录制补偿应用成功收到ACK,就根据ACK信息中附带的全局流水号、子流水号字段与前面临时表中记录实时报文比对核销,并将核销结果定时报送给监控中心。如果200ms内未返回ACK就实时报送给监控告警。
3)ESC云终端收到后端业务系统返回后将响应报文写入kafka发布并创建topic-res并持久化到本地TiDB,同时接入MirrorMaker同步流程,如果未收到后端业务系统的响应,一旦达到预设的超时时间,则直接返回,如果响应报文异步写入失败通知监控告警并调用失败重发,同时,该笔交易将被记录为可疑交易由ESC监控系统继续进行跟踪,处理成功则流程结束。
4)对于前端一个交易对应后端多个交易的场景每个云终端节点通过调用异步报文写入基础服务录制原始请求响应报文。
图4示出了本发明交易数据的回放方法的执行过程。参见图4,交易数据的回放方法包括:
1)当本地发生地域级故障时,手工触发地域故障处理,通过异地ESC 注册中心(ESC-M)调用交易录制补偿应用,从DB中读取存储的同一笔交易的请求报文和对应的响应报文;
2)对该成对报文中的响应报文的响应码进行判断,如果为成功响应则进行交易重放,若为失败响应或响应结果为空,则进行下一对报文的处理;
3)由交易录制补偿应用生成请求报文并根据时间戳+全局流水号对要回放的交易进行排序发往云终端(ESC-T),然后对后端业务系统响应结果与该笔报文的原始响应报文进行对比,如果对比结果不一致,则需要通知监控中心并做监控告警,该笔交易作为可疑交易进行人工处理;
4)对于前端一个交易对应后端多个交易的场景解决方案如下:
请求:
交易回放节点的选择:跨多个节点的交易,交易录制时每个C终端记录请求接入的long型时间戳C_IN_TIME,这种场景下同一个全局流水号对应多个请求报文,交易回放时回放节点选择C_IN_TIME最小值对应的请求报文。
响应:
对于多后端交易每个全局流水号对应多条响应报文,只回放每个P终端节点响应成功且业务成功的交易。
5)在进行异地切换时,回放的处理结果做持久化处理,最后把所有记录补偿结果反馈到注册中心,并用页面方式将补偿结果汇总展示流程结束。
图5是本发明异地切换后交易处理的流程图。参见图5,异地切换后交易处理流程如下:
当发生跨地域数据中心切换以后,ESC-T正常交易进来后先判断地域切换开关是否打开,如果打开就判是不是用户相关的交易,如果是,通过补偿标志位去补偿中心判断是不是有该用户有关的交易待补偿,如果有直接驳回,如果没有交易通过,整体的判断流程是在切换后打开开关来执行。
本发明整体的设计理念在于:传统的在做异地多数据中心建设时,都是通过数据库软件或者存储设备进行数据的异步备份,因现有的设备传输效率的问题,势必会带来数据同步延迟的情况;交易录制补偿机制是在传统的数据同步的基础上,通过对实时交易的录制,在发生地域级灾难,进行异地切换时,对对录制的交易进行一定时间段的回放,最大程度的保障数据的完整性,使得异地灾难恢复的RPO趋近于0。
本发明交易录制过程中的可靠性传输机制如下:对于本地地域,在ESC 云终端异步写入kafka成功时创建请求类型的消息topic-req并持久化到本地DB临时表中用于报文核销;在异地地域,当交易录制补偿应用订阅报文消息成功后,需要通过TCP方式实时发送ACK通知信号(全局流水号+子流水号)给对本地地域交易录制补偿应用,如果本地地域交易录制补偿应用成功收到ACK,就根据ACK信息中附带的全局流水号、子流水号字段与前面临时表中记录实时报文比对核销,并将核销结果定时报送给监控中心,如果200ms内未返回ACK就实时报送给监控告警。
本发明交易回放过程中的黑名单机制:在对实时交易录制时,会形成交易涉及用户的黑名单,发生异地切换时,会根据交易回放时间锁定黑名单的范围,该黑名单的范围根据交易回放的进行同步会缩小。在进行异地数据中心接管时,进行交易回放的同时允许接受正常的业务交易请求,在收到正常的业务交易请求时,会对该笔业务交易进行黑名单校验,当该笔业务交易中的用户在上述锁定的黑名单内,该笔交易被拒回,不在黑名单范围内,该笔交易被正常执行。该机制使得在发生地域级故障,进行异地接管时,能够第一时间开展业务,使得异地灾难恢复的RTO尽可能的小。
与现有技术相比,本专利的优点我们同样从上面提到的几个维度进行分析和对比。
时效性:本专利的机制中,在传统的数据库异步数据同步的基础上,通过对交易的录制补偿机制,使得一定距离(1000km以上)不同的两个地域在固定的带宽的情况下,实际数据备份的时效有原来的5分钟以上缩短到30ms以内。
保证度:由于实时的对交易进行录制,当地域级故障突然发生时,通过对录制交易的回放,最大程度的补偿了数据库异步数据同步带来的数据丢失,最大程度保证了用户的数据的完整性。
代价:在本专利的机制中,两个地域只需要百兆的传输带宽即可实现跨地域数据传输的低延迟及数据恢复的高完整性。
复杂度:使用本专利的机制构建的异地多活的数据中心建设,在进行异地灾备接管时,极大的减少了接管的时间,同时对数据的完整性保障措施,极大的减少了人工的干预,使得异地灾备接管自动化、智能化。
整体而言,本专利提供的机制,重点考虑了异地多数据中心的跨异地数据同步的时效性、数据完成性保证度,以较少的代价极大的降低了异地多数据中心跨地域进行灾备接管的复杂度。相对而言现有的机制,在时效性、数据完整性保证度相对比较弱。如果使用现有的机制去进一步提高时效性和数据完整性保证度,需要付出更大代价和实现复杂度。
以上所述,仅是本发明的较佳实施例而已,并非对本发明作任何形式上的限制,本领域技术人员利用上述揭示的技术内容做出些许简单修改、等同变化或修饰,均落在本发明的保护范围内。
Claims (10)
1.一种交易数据的录制方法,应用于本地数据中心,其特征在于,包括:
本地前端系统发送交易请求到本地ESC云终端,将所述交易请求异步写入本地kafka集群,并通过MirrorMaker镜像将所述交易请求同步至异地数据中心,异步写入成功则创建请求类型的消息topic-req并持久化到本地DB临时表中用于报文核销,写入失败则通知监控中心监控告警同时失败交易数据持久化到DB,之后监控中心进行可疑交易跟踪流程并实时探测kafka集群状态;
异地交易录制补偿应用订阅上一步镜像同步过去的相关topic并持久化到DB集群,对应的建立请求报文和响应报文的映射关系,订阅报文消息成功则通过TCP方式准实时发送ACK通知信号给对端交易录制补偿应用,如果源地域交易录制补偿应用成功收到ACK,就根据ACK信息中附带的全局流水号、子流水号字段与前面临时表中记录实时报文比对核销;以及
本地ESC云终端接收到后端业务系统响应后,将响应报文异步写入至本地kafka集群,创建topic-res消息,将所述topic-res消息持久化至本地数据库,并通过MirrorMaker镜像将所述topic-res消息同步至异地数据中心;
其中,ACK信息中附带全局流水号、子流水号字段;
交易录制补偿应用用于根据ACK信息中附带的全局流水号、子流水号字段与前面临时表中记录实时报文比对核销,并将核销结果定时报送给监控中心,如果200ms内未返回ACK就实时报送给监控告警。
2.根据权利要求1所述的交易数据的录制方法,其特征在于,在通过MirrorMaker镜像将所述交易请求同步至异地数据中心之后,还包括:
如果交易请求异步写入成功,则创建请求类型的topic-req消息,并将topic-req消息持久化至本地数据库的临时表;以及
如果交易请求异步写入失败,通知本地监控中心,将失败的交易数据持久化至本地数据库,并实时探测本地kafka集群的状态。
3.根据权利要求1所述的交易数据的录制方法,其特征在于,还包括:
如果本地交易录制补偿应用未成功接收到所述ACK消息,向本地监控中心告警。
4.根据权利要求1所述的交易数据的录制方法,其特征在于,还包括:
如果本地ESC云终端未接收到后端业务系统的响应,直接返回;以及
如果响应报文写入失败,向本地监控中心告警,同时将该交易记录为可疑交易。
5.根据权利要求1所述的交易数据的录制方法,其特征在于,所述交易请求包括:涉及到账户数据变动的交易请求。
6.根据权利要求1所述的交易数据的录制方法,其特征在于,在对实时交易录制时,会形成交易涉及用户的黑名单。
7.一种交易数据的录制方法,应用于异地数据中心,其特征在于,包括:
通过MirrorMaker镜像接收所述交易请求的同步;
异地交易录制补偿应用订阅由所述MirrorMaker镜像同步的topic,并将所述交易请求持久化至异地数据库;
如果订阅成功,异地交易录制补偿应用反馈ACK消息至本地交易录制补偿应用;以及
通过MirrorMaker镜像接收所述topic-res消息的同步;
其中,前端系统发送请求报文到ESC云终端请求后端业务系统等待响应结果,与此同时将涉及数据操作类交易请求报文异步写入到本地kafka集群进入MirrorMaker镜像同步流程,异步写入成功则创建请求类型的消息topic-req并持久化到本地DB临时表中用于报文核销,如果源地域交易录制补偿应用成功收到ACK,就根据ACK信息中附带的全局流水号、子流水号字段与前面临时表中记录实时报文比对核销,ESC云终端收到后端业务系统返回后将响应报文写入kafka发布并创建topic-res并持久化到本地TiDB,同时接入MirrorMaker同步流程;
其中,ACK信息中附带全局流水号、子流水号字段;
交易录制补偿应用用于根据ACK信息中附带的全局流水号、子流水号字段与前面临时表中记录实时报文比对核销,并将核销结果定时报送给监控中心,如果200ms内未返回ACK就实时报送给监控告警。
8.根据权利要求7所述的交易数据的录制方法,其特征在于,在对实时交易录制时,会形成交易涉及用户的黑名单。
9.一种交易数据的回放方法,应用于异地数据中心,其特征在于,包括:
接收本地数据中心发送的故障处理请求;
异地交易录制补偿应用从数据库中读取交易的请求报文及对应的响应报文;
根据所述响应报文中的响应码,判断所述交易是否被成功响应;
如果所述交易被成功响应,异地交易录制补偿应用将所述交易发送至异地ESC云终端;
将后端业务系统响应结果与所述响应报文进行比对;以及
如果比对结果一致,执行所述交易的回放。
10.根据权利要求9所述的交易数据的回放方法,其特征在于,发生异地切换时,会根据交易回放时间锁定黑名单的范围,所述黑名单的范围根据交易回放的进行同步会缩小。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910002323.7A CN109710699B (zh) | 2019-01-02 | 2019-01-02 | 交易数据的录制方法、交易数据的回放方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910002323.7A CN109710699B (zh) | 2019-01-02 | 2019-01-02 | 交易数据的录制方法、交易数据的回放方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109710699A CN109710699A (zh) | 2019-05-03 |
CN109710699B true CN109710699B (zh) | 2021-01-22 |
Family
ID=66259805
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910002323.7A Active CN109710699B (zh) | 2019-01-02 | 2019-01-02 | 交易数据的录制方法、交易数据的回放方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109710699B (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110276680B (zh) * | 2019-05-24 | 2021-05-07 | 国家计算机网络与信息安全管理中心 | 一种应用于互联网金融的真实数据获取方法 |
CN110597725B (zh) * | 2019-09-19 | 2023-05-05 | 浙江诺诺网络科技有限公司 | 一种Mysql的模拟返回方法、装置及设备 |
CN111400331B (zh) * | 2020-03-17 | 2023-05-30 | 吉林亿联银行股份有限公司 | 一种基于TiDB数据库的处理方法及装置 |
CN112910970B (zh) * | 2021-01-21 | 2023-04-07 | 中国工商银行股份有限公司 | 异地灾备数据同步方法、装置及系统 |
CN113704258B (zh) * | 2021-08-20 | 2023-12-26 | 辽宁振兴银行股份有限公司 | 一种基于MongoDB数据库存储交易报文的方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106603665A (zh) * | 2016-12-16 | 2017-04-26 | 无锡华云数据技术服务有限公司 | 云平台连续数据同步方法及其装置 |
CN107124317A (zh) * | 2017-05-31 | 2017-09-01 | 郑州云海信息技术有限公司 | 一种容灾系统 |
CN108446972A (zh) * | 2018-02-07 | 2018-08-24 | 深圳市雁联计算系统有限公司 | 银行头寸监控方法、装置及资金头寸管理系统 |
CN108833479A (zh) * | 2018-05-18 | 2018-11-16 | 吉林亿联银行股份有限公司 | 一种数据同步方法和装置 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10212120B2 (en) * | 2016-04-21 | 2019-02-19 | Confluent, Inc. | Distributed message queue stream verification |
-
2019
- 2019-01-02 CN CN201910002323.7A patent/CN109710699B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106603665A (zh) * | 2016-12-16 | 2017-04-26 | 无锡华云数据技术服务有限公司 | 云平台连续数据同步方法及其装置 |
CN107124317A (zh) * | 2017-05-31 | 2017-09-01 | 郑州云海信息技术有限公司 | 一种容灾系统 |
CN108446972A (zh) * | 2018-02-07 | 2018-08-24 | 深圳市雁联计算系统有限公司 | 银行头寸监控方法、装置及资金头寸管理系统 |
CN108833479A (zh) * | 2018-05-18 | 2018-11-16 | 吉林亿联银行股份有限公司 | 一种数据同步方法和装置 |
Non-Patent Citations (1)
Title |
---|
FireShot Capture 011 - 使用多数据中心部署来应对Kafka灾难恢复(一);扫帚的影子;《简书https://www.jianshu.com/p/3a8565e57b40》;20181221;第1页 * |
Also Published As
Publication number | Publication date |
---|---|
CN109710699A (zh) | 2019-05-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109710699B (zh) | 交易数据的录制方法、交易数据的回放方法 | |
CN109901949B (zh) | 双活数据中心的应用灾备系统及方法 | |
US11614867B2 (en) | Distributed storage system-based data processing method and storage device | |
US6202067B1 (en) | Method and apparatus for correct and complete transactions in a fault tolerant distributed database system | |
CN107491343B (zh) | 一种基于云计算的跨集群资源调度系统 | |
CN108833479B (zh) | 一种数据同步方法和装置 | |
CA2403294C (en) | Bidirectional database replication scheme for controlling ping-ponging | |
CN102890716B (zh) | 分布式文件系统和分布式文件系统的数据备份方法 | |
CN101079896B (zh) | 一种构建并行存储系统多可用性机制并存架构的方法 | |
CN107241430A (zh) | 一种基于分布式存储的企业级容灾系统及容灾控制方法 | |
CN103226502A (zh) | 一种数据灾备控制系统及数据恢复方法 | |
CN111506649A (zh) | 交易数据容灾切换方法、装置及计算设备、存储介质 | |
CN111506648A (zh) | 交易数据备份方法、装置及计算设备、存储介质 | |
CN110807064A (zh) | Rac分布式数据库集群系统中的数据恢复装置 | |
CN114490173A (zh) | 一种数据备份方法及装置、系统、存储介质 | |
CN114090349A (zh) | 一种基于主备集群服务器跨地区服务容灾方法及装置 | |
CN109165122B (zh) | 一种提升基于区块链技术实现的应用系统同城多园区部署灾备能力的方法 | |
JPH06348628A (ja) | インテリジェントネットワークシステム | |
WO2020133473A1 (zh) | 一种备份数据的方法、装置和系统 | |
CN111404737B (zh) | 一种容灾处理方法以及相关装置 | |
CN113065963A (zh) | 一种期货主席交易系统 | |
CN107291575B (zh) | 一种数据中心故障时的处理方法和设备 | |
CN111737043B (zh) | 数据库容灾方法、设备、服务器和存储介质 | |
CN107404511B (zh) | 集群中服务器的替换方法及设备 | |
CN1316779C (zh) | 一种不会产生连环数据复制的数据容灾方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |