CN111723156A - 数据的容灾方法与系统 - Google Patents

数据的容灾方法与系统 Download PDF

Info

Publication number
CN111723156A
CN111723156A CN202010606753.2A CN202010606753A CN111723156A CN 111723156 A CN111723156 A CN 111723156A CN 202010606753 A CN202010606753 A CN 202010606753A CN 111723156 A CN111723156 A CN 111723156A
Authority
CN
China
Prior art keywords
library
data
message
transactional
master
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.)
Pending
Application number
CN202010606753.2A
Other languages
English (en)
Inventor
杨哲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OneConnect Smart Technology Co Ltd
OneConnect Financial Technology Co Ltd Shanghai
Original Assignee
OneConnect Financial Technology Co Ltd Shanghai
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by OneConnect Financial Technology Co Ltd Shanghai filed Critical OneConnect Financial Technology Co Ltd Shanghai
Priority to CN202010606753.2A priority Critical patent/CN111723156A/zh
Publication of CN111723156A publication Critical patent/CN111723156A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/214—Database migration support

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种数据的容灾方法，包括：接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用；若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中；将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中；若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。本发明公开了一种数据的容灾系统、计算机设备和计算机可读存储介质。本发明的有益效果在于：在数据库故障的情况下，提高了数据安全性。

Description

数据的容灾方法与系统
技术领域
本发明实施例涉及数据处理领域，尤其涉及一种数据的容灾方法与系统。
背景技术
计算机具有存储信息量大、使用者获取信息方便快捷等优点，得到广泛的应用。随着社会的进步及经济的发展，使用者对计算机的各项性能的要求都有了很大的提高，其中对计算机中存储数据的保护要求越来越高，并且在达到保护数据目的的前提下，还要能够在设备出现故障时快速恢复业务，存储容灾环境发展起来。
随着消费金融场景遍地开花，在满足消费者生活的方方面面同时，对消费金融产品的后端压力也是与日俱增。统计表明：全球平均每天有约有2％的资损事件发生，而在众多的资损事件中，由于数据库的故障造成的诸如订单、流水、余额等账务数据的丢失更是占了大头。如何提高数据库的可用性，业界也有许多方案可借鉴，但是金融场景下对资金数据的安全性显然要比一般场景要求更高，来不得半点误差，基于此，数据的一致性和可用性是要解决的首要问题。
发明内容
有鉴于此，本发明实施例的目的是提供一种数据的容灾方法与系统，提高了在数据库故障下的数据安全性。
为实现上述目的，本发明实施例提供了一种数据的容灾方法，包括：
接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用；
若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中；
将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中；
若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。
进一步地，所述接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用包括：
接收基于事务性消息的账务变更请求，所述账务变更请求包括用户的账户信息；
基于所述账务变更请求将所述账户信息发送给终端；
根据所述终端基于所述账户信息的响应信息判断所述主库是否可用。
进一步地，所述若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中包括：
若接收到所述响应信息，则判断所述主库可用，将所述事务性消息的变更数据进行落库处理写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中。
进一步地，所述将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中之后，包括：
通过所述消息中心管控平台监控所述事务性消息的消息列队；
若所述消息列队的长度与大小超出预设阈值，获取所述消息列队中超出预设阈值对应的积压事务性消息；
将所述积压事务性消息对应的用户作为黑名单。
进一步地，所述若所述主库不可用，禁止所述主库写入数据，将所述事务性消息写入至故障转移库中之后，包括：
获取所述消息中心管控平台中的积压事务性消息；
将所述积压事务性消息作为黑名单存入所述故障转移库中。
进一步地，所述若所述主库不可用，禁止所述主库写入数据，将所述事务性消息写入至故障转移库中之后，包括：
获取所述读库中的存储事务性消息；
将所述存储事务性消息以及所述存储事务性消息对应的变更数据写入至所述故障转移库中。
进一步地，所述若所述主库不可用，禁止所述主库写入数据，将所述事务性消息写入至故障转移库中之后，包括：
当接收到所述主库基于所述账务变更请求的反馈信息时，将所述故障转移库中的事务性消息以及对应的变更数据写入至所述主库中。
为实现上述目的，本发明实施例还提供了一种数据的容灾系统，包括：
判断模块，用于接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用；
第一写入模块，用于若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中；
分发模块，用于将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中；
第二写入模块，用于若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。
为实现上述目的，本发明实施例还提供了一种计算机设备，所述计算机设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的数据的容灾方法的步骤。
为实现上述目的，本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行如上所述的数据的容灾方法的步骤。
本发明实施例提供的数据的容灾方法与系统，通过对主库是否可用进行判断，故障转移库在主库发生故障时，能够马上接替工作，并且将不一致的数据就行黑名单拦截，虽然会影响到一小部分的数据的可用性，但是确保数据的强一致性。通过消息中心管控平台进行缓存和读库进行副存模式，很好的将全量数据做了热备份，在性能和一致性方面做了最好的折中，既不影响核心系统的正常入库操作，同时提供实时数据热备。
附图说明
图1为本发明数据的容灾方法实施例一的流程图。
图2为本发明数据的容灾方法实施例一中步骤S100的流程图。
图3为本发明数据的容灾方法实施例一中步骤S150的流程图。
图4为本发明数据的容灾方法实施例一中步骤S170的流程图。
图5为本发明数据的容灾方法实施例一中步骤S180的流程图。
图6为本发明数据的容灾系统实施例二的程序模块示意图。
图7为本发明计算机设备实施例三的硬件结构示意图。
图8为本发明数据的容灾方法实施例一的第一模式的流程图。
图9为本发明数据的容灾方法实施例一的第二模式的流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例一
参阅图1，示出了本发明实施例一之数据的容灾方法的步骤流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。下面以计算机设备2为执行主体进行示例性描述。具体如下。
步骤S100、接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用。
具体地，当判断用户的账户信息发生变更了时，发送账务变更请求给服务器，服务器会根据该账务变更请求，将用户的账户信息和变更数据发送给第三方平台，即主库进行处理，再接收第三方平台返回的响应数据。事务性消息是指在购买该商品的过程中，进行扣款的情况，就产生了事务性消息。账户信息是用户的支付密码与账户ID，发生变更后根据账户信息与变更数据生成账务变更请求。
示例性地，参阅图2，所述步骤S100包括：
步骤S101、接收基于事务性消息的账务变更请求，所述账务变更请求包括用户的账户信息。
具体地，账户信息发生了变更是指用户在某平台(例如支付宝)上的账户发生了金额的变化，例如在某某平台(淘宝)的某某商店(可不写入消息变更中)购买了某某商品，花了XX元，这件事的处理过程。账户信息是用户的支付密码与账户ID，发生变更后根据账户信息与变更数据生成账务变更请求。
步骤S102、基于所述账务变更请求将所述账户信息发送给终端。
具体地，将账户信息发送给终端的主库进行记账操作，根据终端的反馈判断主库是否可用。
步骤S103、根据所述终端基于所述账户信息的响应信息判断所述主库是否可用。
具体地，若终端接收到账户信息，会将账户信息在给主库进行相应的信息核实，核实后发送响应数据给服务器，若主库不可用，出现故障则不会发送响应数据。
步骤S120、若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中。
具体地，变更数据是用户在消费时，产生了扣款的金额，且账号与金额相对应，作为变更数据。将变更数据落库之后，建立消息链，得到消息列表，消息列表可以包括账务数据是什么，即消费者购买了什么物品，消耗多少钱；账务数据存储地址，即主库地址；账务数据的变动。且进行主从复制，实时的将主库中的事务性消息读取到读库中。
示例性地，所述步骤S120包括：
若接收到所述响应信息，则判断所述主库可用，将所述事务性消息的变更数据进行落库处理写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中。
具体地，将事务性消息的变更数据进行落库处理写入至主库中，是将该消息写入到mysql的主库中，进行消息存储，接受到帐务应用投递的事务性消息之后，立刻将消息进行落库。落库是因为主机房的应用是无状态的，它也是不稳定的，随时可以宕机，必须以变更数据的落库作为消息投递成功的依据，也是作为主库事务可以最终提交的依据。主库可以使用内存型数据库，因此这样更快，也可以使用mysql数据库，因为这样更稳定。由于mysql的稳定性好，不易丢失，一般选用mysql数据库。
示例性地，主库还可以对事务性消息进行状态标记，当消费完成后，标记该事务性消息为已完成状态，未完成，可标记其属于消费中的哪一个阶段。
步骤S140、将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中。
具体地，参阅图8，当主库可以使用时，采用正常模式进行记账处理。即通过数据分发平台，例如：sdp(Simple Discovery Protocol，数据分发系统，基于异步队列机制，将接受的数据分发至不同的数据源中)，将接收到的事务性消息依次分发到分别部署在不同物理机房的独立redis集群进行处理。接收到事务性消息时，将该事务性消息的消息列表(也可以说是消息内容，以列表的形式进行展示，便于列队存储与查看)快照同步至消息中心管控平台。事务性消息存储快照保证严格时间顺序(锁控制)；快照能够还原账户明细。
示例性地，正常模式包括主机房(Active)与从机房(StandBy)，主机房设置有核心系统(账务系统)、消息中心管控平台(RocketMQ)与mysql写库；从机房设置有sdp(SimpleDiscovery Protocol，数据分发系统)以及mysql读库。当接收到用户的账务变更请求时，从账务系统中获取该用户对应的事务性消息以及变更数据，将事务性消息落库到mysql写库中，并且同步调用到消息中心管控平台中。再从mysql写库中进行主从复制，存入到mysql读库。消息中心管控平台再将事务性消息通过数据分发系统分发给Redis集群。
示例性地，在redis集群接收到分发的消息时，设置事务性消息存储的过期时间，redis集群的过期时间设置远大于主库和读库的延时，就能保证reids集群加上读库提供一份实时完整的账户信息。redis集群的过期时间是指存储在里面的数据有效时间，数据过期后将自动删除。
示例性地，消息中心监控平台不断地捞取消息库中的消息，然后进行消费，存入redis集群，此redis集群只保留最后半小时内的帐务的数据。因为正常情况下主从延迟不会超过30分钟的，而且一般在3秒以下。即redis集群所存的数据一定远大于帐务主备库的数据差。这样，帐务读库+redis集群一定可以还原出主库的实时最终状态。
示例性地，参阅图3，所述步骤S140之后，包括步骤S150：
步骤S151、通过所述消息中心管控平台监控所述事务性消息的消息列队。
具体地，消息中心监控平台实时监控消息列队，消息列队存储有账户信息与变更数据。
步骤S152、若所述消息列队的长度与大小超出预设阈值，获取所述消息列队中超出预设阈值对应的积压事务性消息。
具体地，根据监控实时消息列队的长度和大小，若判断消息列队的长度和大小超出预设阈值，说明存在消息积压情况。
步骤S153、将所述积压事务性消息对应的用户作为黑名单。
具体地，将积压的事务性消息对应的用户作为黑名单，不对黑名单用户进行记账处理。消息积压表示备库处理能力达到瓶颈，如果继续记账将可能产生数据丢失当不存在消息积压情况时，主库的需要进行记账的用户的剩余数量与读库的当前用户的数量一致，剩余用户可以基于读库的当前用户的数量进行记账，且不会有资金安全问题。主库的账户数据变动(变更数据)都通过消息同步到从库，两个库的账户数据是完全一致的，一旦主库发生故障，可以实时切换到从库进行记账。
步骤S160、若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。
具体地，参阅图9，故障转移库，是数据库切换机制基于MySql自带的主从架构的切换中间件，即failover库。failover是一个空库，若主库不可用，可将变更数据写入到此库中。如果针对历史账户进行记账，则可以去读库取数据操作。如果主库不可用，先确保主库不会有新的事务提交，触发应用系统从RocketMQ(消息中心管控平台)中获取积压的消息列表，用于生成不可记账的账号黑名单。在failover模式下如果账户被列入黑名单则不允许记账，否则从读库中把最新的账户信息拷贝到failover库，然后在failover库继续记账处理。
示例性地，Failover模式包括主机房(Active)与从机房(StandBy)，主机房设置有账务系统、消息中心管控平台与Mysql-failover库(写库)；从机房设置有Mysql读库与PDCLoud(云存储系统)。当发现主库不可用时，转入Failover模式。将新发出的账务变更请求对应的事务性消息与变更数据写入到Mysql-failover库中，并且从消息中心管控平台获取积压消息记为黑名单。Mysql读库中的存储的事务性消息通过云存储系统发送给Mysql-failover库，可通过账户快照获取之前的用户的事务性消息。
进一步地，当failover库进行记账时，启动应用发出对主库的静止写入，终止消息投递，不管主库现在是否已经损坏；事务性消息继续消费，能消费多少算多少；当发现读库的最后一条余额纪录的修改在消息中心监控平台(消息还没有消费完)或redis集群(消息已经被消费进入redis集群)时，说明两者之和一定可以还原出主库最后的镜像数据，此时，正式进入failover阶段，无论所有的消息是否已经被消费完成。从消息中心监控平台获取未消费消息列表，用户账号纳入黑名单，即标识为不可记帐，不可使用余额功能。二阶段快照比一阶段旧的纳入黑名单。若记账不在黑名单且Failover库中无记录，则通过redis集群和异地读库进行余额还原，优先取redis集群。真正记账前，先进行账户余额登记。在failover库上插入最新的余额数据，并记账。
示例性地，参阅图4，所述步骤S160之后，包括步骤S170：
步骤S171、获取所述消息中心管控平台中的积压事务性消息。
具体地，从消息中心监控平台获取未处理的消息列表，用户账号纳入黑名单，即标记为不可记帐，不可使用余额功能。
步骤S172、将所述积压事务性消息作为黑名单存入所述故障转移库中。
具体地，若在主库写入进行中，接收到主库不可用的提示，将消息中心管控平台的积压的事务性消息对应的用户记为黑名单，并存入故障转移库中。
示例性地，参阅图5，所述步骤S160之后，包括步骤S180：
步骤S181、获取所述读库中的存储事务性消息。
具体地，存储事务性消息包括剩余用户及其对应的变更数据，从读库中将存储事务性消息取出来。
步骤S182、将所述存储事务性消息以及所述存储事务性消息对应的变更数据写入至所述故障转移库中。
具体地，接收新增用户及其对应的新增变更数据与存储事务性消息写入至failover库中。
示例性地，所述步骤S160之后，包括：
当接收到所述主库基于所述账务变更请求的反馈信息时，将所述故障转移库中的事务性消息以及对应的变更数据写入至所述主库中。
具体地，当原主库恢复正常之后，记录在failover库的数据必须进行回迁。即后台另一个Job，不断地将failover库的数据回迁至原主库，无论是覆盖还是新增。当然在回迁过来中，每一个帐务必须通过幂等算法，判断要不要查询一次异地机房的failover库，如果failover库的数据是最新的，但它还没被回迁至原主库，那即在failover库修改之后，开个小灶，立刻把它迁移回主库。
实施例二
请继续参阅图6，示出了本发明数据的容灾系统实施例二的程序模块示意图。在本实施例中，数据的容灾系统20可以包括或被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本发明，并可实现上述数据的容灾方法。本发明实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，比程序本身更适合于描述数据的容灾系统20在存储介质中的执行过程。以下描述将具体介绍本实施例各程序模块的功能：
判断模块200，用于接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用。
具体地，当判断用户的账户信息发生变更了时，发送账务变更请求给服务器，服务器会根据该账务变更请求，将用户的账户信息和变更数据发送给第三方平台，即主库进行处理，再接收第三方平台返回的响应数据。事务性消息是指在购买该商品的过程中，进行扣款的情况，就产生了事务性消息。
示例性地，所述判断模块200还用于：
接收基于事务性消息的账务变更请求，所述账务变更请求包括用户的账户信息。
具体地，账户信息发生了变更是指用户在某平台(例如支付宝)上的账户发生了金额的变化，例如在某某平台(淘宝)的某某商店(可不写入消息变更中)购买了某某商品，花了XX元，这件事的处理过程。账户信息是用户的支付密码与账户ID，发生变更后根据账户信息与变更数据生成账务变更请求。
基于所述账务变更请求将所述账户信息发送给终端。
具体地，将账户信息发送给终端的主库进行记账操作，根据终端的反馈判断主库是否可用。
根据所述终端基于所述账户信息的响应信息判断所述主库是否可用。
具体地，若终端接收到账户信息，会将账户信息在给主库进行相应的信息核实，核实后发送响应数据给服务器，若主库不可用，出现故障则不会发送响应数据。
第一写入模块202，用于若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中。
具体地，变更数据是用户在消费时，产生了扣款的金额，且账号与金额相对应，作为变更数据。将变更数据落库之后，建立消息链，得到消息列表，消息列表可以包括账务数据是什么，即消费者购买了什么物品，消耗多少钱；账务数据存储地址，即主库地址；账务数据的变动。且进行主从复制，实时的将主库中的事务性消息读取到读库中。
示例性地，所述第一写入模块202还用于：
若接收到所述响应信息，则判断所述主库可用，将所述事务性消息的变更数据进行落库处理写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中。
具体地，将事务性消息的变更数据进行落库处理写入至主库中，是将该消息写入到mysql的主库中，进行消息存储，接受到帐务应用投递的事务性消息之后，立刻将消息进行落库。落库是因为主机房的应用是无状态的，它也是不稳定的，随时可以宕机，必须以变更数据的落库作为消息投递成功的依据，也是作为主库事务可以最终提交的依据。主库可以使用内存型数据库，因此这样更快，也可以使用mysql数据库，因为这样更稳定。由于mysql的稳定性好，不易丢失，一般选用mysql数据库。
分发模块204，用于将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中。
具体地，当主库可以使用时，采用正常模式进行记账处理。即通过数据分发平台，例如：sdp(自研数据分发系统，基于异步队列机制，将接受的数据分发至不同的数据源中)，将接收到的事务性消息依次分发到分别部署在不同物理机房的独立redis集群进行处理。接收到事务性消息时，将该事务性消息的消息列表(也可以说是消息内容，以列表的形式进行展示，便于列队存储与查看)快照同步至消息中心管控平台。事务性消息存储快照保证严格时间顺序(锁控制)；快照能够还原账户明细。
第二写入模块206，用于若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。
具体地，故障转移库，是数据库切换机制基于MySql自带的主从架构的切换中间件，即failover库。failover是一个空库，若主库不可用，可将变更数据写入到此库中。如果针对历史账户进行记账，则可以去读库取数据操作。如果主库不可用，先确保主库不会有新的事务提交，触发应用系统从RocketMQ(消息中心管控平台)中获取积压的消息列表，用于生成不可记账的账号黑名单。在failover模式下如果账户被列入黑名单则不允许记账，否则从读库把最新的账户信息拷贝到failover库，然后在failover库继续记账处理。
实施例三
参阅图7，是本发明实施例三之计算机设备的硬件架构示意图。本实施例中，所述计算机设备2是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。该计算机设备2可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图7所示，所述计算机设备2至少包括，但不限于，可通过系统总线相互通信连接存储器21、处理器22、网络接口23、以及数据的容灾系统20。其中：
本实施例中，存储器21至少包括一种类型的计算机可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器21可以是计算机设备2的内部存储单元，例如该计算机设备2的硬盘或内存。在另一些实施例中，存储器21也可以是计算机设备2的外部存储设备，例如该计算机设备2上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，存储器21还可以既包括计算机设备2的内部存储单元也包括其外部存储设备。本实施例中，存储器21通常用于存储安装于计算机设备2的操作系统和各类应用软件，例如实施例二的数据的容灾系统20的程序代码等。此外，存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。
处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制计算机设备2的总体操作。本实施例中，处理器22用于运行存储器21中存储的程序代码或者处理数据，例如运行数据的容灾系统20，以实现实施例一的数据的容灾方法。
所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述服务器2与其他电子装置之间建立通信连接。例如，所述网络接口23用于通过网络将所述服务器2与外部终端相连，在所述服务器2与外部终端之间的建立数据传输通道和通信连接等。所述网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，GSM)、宽带码分多址(Wideband CodeDivision Multiple Access，WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。需要指出的是，图7仅示出了具有部件20-23的计算机设备2，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。
在本实施例中，存储于存储器21中的所述数据的容灾系统20还可以被分割为一个或者多个程序模块，所述一个或者多个程序模块被存储于存储器21中，并由一个或多个处理器(本实施例为处理器22)所执行，以完成本发明。
例如，图6示出了所述实现数据的容灾系统20实施例二的程序模块示意图，该实施例中，所述数据的容灾系统20可以被划分为判断模块200、第一写入模块202、分发模块204以及第二写入模块206。其中，本发明所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，比程序更适合于描述所述数据的容灾系统20在所述计算机设备2中的执行过程。所述程序模块200-206的具体功能在实施例二中已有详细描述，在此不再赘述。
实施例四
本实施例还提供一种计算机可读存储介质，如闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘、服务器、App应用商城等等，其上存储有计算机程序，程序被处理器执行时实现相应功能。本实施例的计算机可读存储介质用于存储数据的容灾系统20，被处理器执行时实现实施例一的数据的容灾方法。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种数据的容灾方法，其特征在于，包括：
接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用；
若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中；
将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中；
若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。
2.根据权利要求1所述的数据的容灾方法，其特征在于，所述接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用包括：
接收基于事务性消息的账务变更请求，所述账务变更请求包括用户的账户信息；
基于所述账务变更请求将所述账户信息发送给终端；
根据所述终端基于所述账户信息的响应信息判断所述主库是否可用。
3.根据权利要求2所述的数据的容灾方法，其特征在于，所述若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中包括：
若接收到所述响应信息，则判断所述主库可用，将所述事务性消息的变更数据进行落库处理写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中。
4.根据权利要求1所述的数据的容灾方法，其特征在于，所述将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中之后，包括：
通过所述消息中心管控平台监控所述事务性消息的消息列队；
若所述消息列队的长度与大小超出预设阈值，获取所述消息列队中超出预设阈值对应的积压事务性消息；
将所述积压事务性消息对应的用户作为黑名单。
5.根据权利要求1所述的数据的容灾方法，其特征在于，所述若所述主库不可用，禁止所述主库写入数据，将所述事务性消息写入至故障转移库中之后，包括：
获取所述消息中心管控平台中的积压事务性消息；
将所述积压事务性消息作为黑名单存入所述故障转移库中。
6.根据权利要求1所述的数据的容灾方法，其特征在于，所述若所述主库不可用，禁止所述主库写入数据，将所述事务性消息写入至故障转移库中之后，包括：
获取所述读库中的存储事务性消息；
将所述存储事务性消息以及所述存储事务性消息对应的变更数据写入至所述故障转移库中。
7.根据权利要求1所述的数据的容灾方法，其特征在于，所述若所述主库不可用，禁止所述主库写入数据，将所述事务性消息写入至故障转移库中之后，包括：
当接收到所述主库基于所述账务变更请求的反馈信息时，将所述故障转移库中的事务性消息以及对应的变更数据写入至所述主库中。
8.一种数据的容灾系统，其特征在于，包括：
判断模块，用于接收基于事务性消息的账务变更请求，根据所述账务变更请求判断主库是否可用；
第一写入模块，用于若所述主库可用，将所述事务性消息的变更数据写入至主库中，并对所述主库进行主从复制，以将所述主库的所述变更数据读取到读库中；
分发模块，用于将所述事务性消息通过快照同步至消息中心管控平台，以使所述消息中心管控平台通过数据分发平台将所述事务性消息依次分发到redis集群中；
第二写入模块，用于若所述主库不可用，禁止所述主库写入数据，将所述事务性消息以及所述事务性消息的变更数据写入至故障转移库中。
9.一种计算机设备，其特征在于，所述计算机设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1-7中任一项所述的数据的容灾方法的步骤。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行如权利要求1-7中任一项所述的数据的容灾方法的步骤。
CN202010606753.2A 2020-06-29 2020-06-29 数据的容灾方法与系统 Pending CN111723156A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010606753.2A CN111723156A (zh) 2020-06-29 2020-06-29 数据的容灾方法与系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010606753.2A CN111723156A (zh) 2020-06-29 2020-06-29 数据的容灾方法与系统

Publications (1)

Publication Number Publication Date
CN111723156A true CN111723156A (zh) 2020-09-29

Family

ID=72570179

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010606753.2A Pending CN111723156A (zh) 2020-06-29 2020-06-29 数据的容灾方法与系统

Country Status (1)

Country Link
CN (1) CN111723156A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160092534A1 (en) * 2014-09-25 2016-03-31 Oracle International Corporation Database snapshots
CN106919473A (zh) * 2015-12-28 2017-07-04 阿里巴巴集团控股有限公司 一种数据灾备系统及业务处理方法
CN107506378A (zh) * 2017-07-20 2017-12-22 阿里巴巴集团控股有限公司 数据库访问的实现方法和装置
US20170371946A1 (en) * 2016-06-27 2017-12-28 Vmware, Inc. Replication groups for content libraries
CN108600300A (zh) * 2018-03-06 2018-09-28 北京思空科技有限公司 日志数据处理方法及装置
EP3441882A2 (en) * 2017-08-10 2019-02-13 Servicenow, Inc. Data synchronization architecture

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160092534A1 (en) * 2014-09-25 2016-03-31 Oracle International Corporation Database snapshots
CN106919473A (zh) * 2015-12-28 2017-07-04 阿里巴巴集团控股有限公司 一种数据灾备系统及业务处理方法
US20170371946A1 (en) * 2016-06-27 2017-12-28 Vmware, Inc. Replication groups for content libraries
CN107506378A (zh) * 2017-07-20 2017-12-22 阿里巴巴集团控股有限公司 数据库访问的实现方法和装置
EP3441882A2 (en) * 2017-08-10 2019-02-13 Servicenow, Inc. Data synchronization architecture
CN108600300A (zh) * 2018-03-06 2018-09-28 北京思空科技有限公司 日志数据处理方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
赵颖;蒋荟;: "基于数据同步技术的5T系统架构优化方案研究", 铁路计算机应用, no. 06 *
金磐石;: "分布式架构在银行核心业务系统的应用", 计算机系统应用, no. 06 *

Similar Documents

Publication Publication Date Title
JP6353924B2 (ja) ブロックベースストレージに対するデータボリュームの耐久性状態の低減
US20210011817A1 (en) Virtual Machine Recovery Method and Virtual Machine Management Device
CN103197990B (zh) 自动优先恢复及相关的装置和方法
CN103164523A (zh) 数据一致性检查方法、装置及系统
CN104750755A (zh) 一种数据库主备切换后的数据回补方法及系统
CN112084066A (zh) 一种数据处理方法、设备及存储介质
CN112181723A (zh) 一种金融灾备方法、装置、存储介质及电子设备
CN114138549A (zh) 基于kubernetes系统的数据备份和恢复方法
CN111444216A (zh) 一种基于中心化块链式账本的数据块删除方法
CN109614263B (zh) 一种容灾数据处理方法、装置及系统
CN109445909A (zh) 虚拟机数据的备份方法、系统、终端及存储介质
CN111723156A (zh) 数据的容灾方法与系统
CN108762988B (zh) 一种数据处理的方法以及相关设备
US10146644B2 (en) Integrity of transactional memory of card computing devices in case of card tear events
CN115470041A (zh) 一种数据灾备管理方法及装置
CN111984473B (zh) 一种内存快照数据获取方法及相关装置
CN111858175A (zh) 一种基于移动存储装置备份云平台数据的方法与设备
CN111752911A (zh) 一种基于Flume的数据传输方法、系统、终端及存储介质
CN112668998A (zh) 流程实现方法、装置、系统、电子设备和可读存储介质
CN114791901A (zh) 数据处理方法、装置、设备及存储介质
CN116578446B (zh) 虚拟机备份方法、装置、系统、电子设备及存储介质
US11132267B1 (en) Ability to maintain RPO in clustered environment with failed nodes/disks
CN116204502B (zh) 一种高可用性的nas存储服务方法及系统
EP4024254A1 (en) Method and device for updating data
CN117194324A (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