某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-容灾建设方案篇

字数 7294阅读 3909评论 7赞 6

内容摘要：

银行采用集中式存储+PostgreSQL实现容灾需求，选择磁盘阵列作为存储载体，使用华为OceanStorDorado18000系列全闪存存储设备实现数据同步复制，采用SOCC技术缩短数据库读写时延，采用微服务+多PostgreSQL数据库集群的方式实现数据均衡，但容灾方案需根据业务特性和RTO/RPO要求选择合适策略。

当前摘要为AI生成

> 摘要：在数字化转型的背景下，该银行面临着提高系统性能、降低成本和增强数据安全性的挑战，交易类系统原先使用I OE 架构面临着诸如成本高昂、技术闭源、不适应云服务化趋势等问题，亟需寻找一种替换方案。本文将详细介绍技术路线的选择依据、实施过程、容灾方案设计以及最终取得的成果。通过这一实践，银行成功地提高了系统的性能、降低了成本，并增强了系统的可靠性和可扩展性，为未来的业务发展奠定了坚实的基础。核心通过对交易类系统从Oracle数据库替换技术路线的选择和容灾方案设计的实践经验的介绍和分享，详细阐述这一替换和容灾方案背后的思考和决策过程，以及实施过程中的解决方案。本文分为技术路线选择篇和容灾建设方案篇。
篇一：[某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-技术路线选择篇](https://www.talkwithtrend.com/Article/269203 "某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-技术路线选择篇")
篇二：[某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-容灾建设方案篇](https://www.talkwithtrend.com/Article/269209 "某大型银行手机银行等重要交易系统不做大幅改造整体去IOE最佳实践-容灾建设方案篇")

# 一 、选择集中式存储+PostgreSQL实现容灾需求的决策逻辑和方案
##  1.容灾需求分析
 在设计交易类系统的容灾方案时，我们主要考虑以下几个方面的需求：
 （1） 数据的持久性
 交易类系统处理的交易数据的持久性至关重要。任何数据丢失或损坏都可能导致严重后果，因此不论选择哪种容灾方案，数据持久化是一个硬性的指标。很多时候在系统设计时候，全部以内存缓存形式存放数据，并不持久化，保证系统的运行效率的方案，在交易类系统是不能够采取的。持久化包括两个意义，数据能够持久保存并及时恢复。
 （2）系统的可用性
 交易类系统对于业务的连续性要求非常高，不能因为单点故障而导致系统不可用。因此，容灾方案需要提供高可用性的架构和机制。系统的可用性，也是系统连续性的一种体现。在不同的在灾备机房能够快速地从灾难中恢复，减少了系统中断对业务造成的影响。也就是我们常说的较短的RTO指标。
 （3）数据的一致性
 交易类系统通常需要确保数据的一致性，即对于同一笔交易，在主数据库和备份数据库中的数据应该是一致的。因此，容灾方案需要提供数据同步和一致性保证的机制。说到数据一致性，就不得不提RPO指标，它指的是在发生灾难事件后，系统可以接受的数据损失范围。较好的容灾设计，能够保障主备之间数据一致性时差较小，从而能够保障系统恢复后数据丢失的范围更小，业务数据的完整性更高。
 （4）故障恢复时间
 有的容灾设计方案，满足了以上三点，但是故障恢复时间太长，动辄数天到数周。虽然设计上没有太多的毛病，但是业务上可能就无法接受了。所以当系统遭遇故障时，尽快恢复系统的运行是非常重要的。因此，容灾方案需要提供快速的故障切换和恢复时间。
##  2. 架构选择
 为什么容灾会提及存储，说到底，还是容灾设计的第一原则，数据持久化。存储作为数据持久化的载体，存储性能和存储能力的强大与否，直接关系着容灾设计的好与坏。 集中式存储天然较本地盘在容灾、扩展、IO、性能需求上有优势。数据库所需要的集中式存储主要还是磁盘阵列。磁盘阵列相比本地存储盘具有更高的性能、可靠性和灵活性，适用于需要大数据存储和处理能力的场景。
 一般来说磁盘阵列有以下几个方面的优点。
 性能：多个磁盘驱动器通过RAID组的方式组成一个存储逻辑单元，实现了数据的分布式存储和并行处理，从而提高了存储和读写性能。在对大容量数据的读写和处理上，可以显著减少读写操作的时间，提高处理效率。
 可靠性：通过在多个硬盘驱动器之间分配数据，实现了数据冗余和容错功能。当一个硬盘驱动器发生故障时，其他硬盘驱动器可以接管其工作，避免了数据丢失和业务中断。此外，还提供了多种容错机制，如数据校验和镜像备份等，进一步提高数据的可靠性和安全性。
 数据备份与恢复：RAID技术实现数据在多个硬盘驱动器之间的冗余备份和恢复。当一个硬盘驱动器发生故障时，备份数据可以快速恢复，保证了数据的完整性和可用性。还可以提供定时备份和增量备份等功能，方便管理员进行数据备份和恢复操作。
 灵活扩展：磁盘阵列的容量可以灵活扩展，只需增加硬盘驱动器即可，相对本地盘减少了频繁的数据迁移和设备更换带来的成本和风险。
 I/O性能：磁盘阵列可以同时读写多个硬盘驱动器，从而减少了I/O瓶颈，提高了数据访问速度,减少了本机操作系统和数据读取的I/O竞争关系或者访问量大早晨的I/O性能问题.
 安全性：磁盘阵列提供了多种安全机制，如加密、访问控制等，保护数据的安全性和完整性。此外，磁盘阵列还提供了快照和克隆等功能，方便管理员进行数据备份和恢复操作，减少了因数据丢失或损坏所带来的风险和损失。
##  3. 容灾建设方案
 容灾分为单机房和多地容灾。
 单机房，一般实现高可用即可。常用的高可用方案包括DRBD、PostgreSQLpool-Ⅱ和pcs+pacemaker+corosync实现PostgreSQL的高可用容灾。
 DRBD，在在服务器之间的块设备（如硬盘、分区、逻辑卷）之间进行镜像，以保证数据的一致性和高可用性。当应用程序完成写操作后，它提交的数据不仅仅会保存在本地块设备上，DRBD还会将这份数据复制一份，通过网络传输到另一个节点的块设备上。这样，两个节点上的块设备上的数据将会保存一致，当本地存储出现故障时，远程主机上还会保留有一份相同的数据，可以继续使用。这个在很多其他数据库生态被广泛使用,例如 高斯 。
 ![](/home/attachment/202401/29/1250271_170650986285825.png)
 PostgreSQLpool-Ⅱ，客户端连接到PostgreSQLpool-Ⅱ上，由PostgreSQLpool-Ⅱ反向代理到各个数据库节点，就于连接到数据库上完全一样。负载均衡只适用于读场景，若客户端发送一个DML语句，将并发地在后端所有数据库上执行，保证所有数据库的一致性。该技术的缺点在于代理后面的节点不能自动切换，且在节点有异常情况，会造成内部各个节点之间的数据不一致。
 ![](/home/attachment/202401/29/1250271_170650987332624.png)
 pcs+pacemaker+corosync，是本行最终选择使用的技术。pacemaker用来维护、配置管理集群，corosync用以心跳维系，pcs是Corosync和Pacemaker配置工具。节点掉线了，pacemaker可以自动启动起来。外系统访问集群，不直接访问数据库，而是访问虚拟出来的读和写的VIP节点，实现读写分离。内部集群之间的数据同步使用PostgreSQL的流复制实现。
 ![](/home/attachment/202401/29/1250271_170650987932870.png)
 多机房的数据同步容灾，主要还是针对同城双数据中心，通过双活进行容灾。按照系统的不同和业务的重要程度，可分为多种双活模式。
 模式一：
 两IDC机房应用各自访问本中心数据库，两机房数据不需交叉同步，单机房具备承接全部业务能力。说白了就是业务上对数据没有同步需求的场景才能使用。
 模式二：
 两机房应用各自访问本机房数据库，两机房数据交叉同步到对方中心备库，单机房具备承接全部业务能力。例如下图中，A机房主库向异地B中心进行异步复制，B中心主机房向异地A中心进行异步复制，复制到对方机房的异步复制备库，通过应用软件定时向对方机房主库追加数据。
 ![](/home/attachment/202401/29/1250271_170650988691962.png)
 模式三：
 两机房主库各保留一半的数据(如:总共4套主库，两机房各有2套主库运行)，如A机房出现异常，将复制到B机房的异步复制库角色转换为主库。
 上面说的是两机房，下面说下较为关心的三机房灾备情况，三机房灾备情况也分为三种。
 模式一：
  同城双机房构建双活，异地机房是冷备数据，当同城灾备中心异常的时候，将异地机房切换为激活机房。并将原来访问同城机房的流量引导到异地机房。
 模式二：
 三个机房都是活跃机房，但是每个机房只承载就近地域或者指定范围的业务。业务系统访问数据库的时候，通过DNS或者其他路由，将地域或者业务上的切分路由到指定的机房数据库操作，然后再由流复制，同步到其他对等机房。
 ![](/home/attachment/202401/29/1250271_170650990190076.png)
 模式三：
 三机房全部全量三活，承载全部的业务，这种目前没有非常完美的解决方案。目前采用的方式是，每个机房的PostgreSQL数据库，通过Debezium采集数据库所有行级的数据变化CDC并包装成数据流，写到KAFKA，再由对等端的应用读取数据消息流，回写数据库。在写数据库的时候，利用REDIS做幂等性校验，避免回写的机房重新采集行变化数据，污染主机房。模式三的最大的难点，在于时间延迟，和回放失败的异常除处理。这种模式下需要做好所有的监控和异常预案，若从机房回写失败，需要立即干预，并在业务空闲时进行数据同步一致性对账。例如采用同一个时钟服务器，用数据的最后修改时间判断，一般通过代码进行判断，同一笔交易内的多次数据库操作，全部落在一个机房进行。
![](/home/attachment/202401/29/1250271_170650991513067.png)
 
# 二、存储助力数据库灾备
 早期异地容灾数据传输使用的PostgreSQL数据库的异步流复制，但是异步流复制只管发起wal日志REDO请求到远端从库，但是并不等待请求是否正确在从库落盘。由于异地机房之间的长距离网络传输环境，环境中的链路抖动、坏块、误码、丢包等等问题，实际上方案缺乏数据高可用的保障能力。为此应用层做了很多不应该由应用层维护的工作，如心跳检测确认链路异常情况；但应用层的心跳检测都有相对较长的间隔，当发现链路异常并切换到冗余的链路上时，对于高频业务系统期间可能已经导致数千笔交易失败。
  为了达到架构稳定运行、容灾能力提升的目标，经过反复的验证，本行最终采用了华为OceanStor Dorado 18000系列高端全闪存存储设备作为数据库的存储设备，并采用华为OceanData存储解决方案，将Redo Log流写入存储，并通过OceanStor存储的同步复制功能，将日志复制到远端容灾数据中心的存储当中；远端数据中心通过日志实时回放，保证了备数据库与主库的数据一致。由于存储实现了对复制能力和结果的保障，主库事务执行不必等待远端备库写入成功，只要日志写入完成就可以提交，使得其性能相比之前的存储大幅提升。此外为解决心跳监控的情况，本行使用了OceanData解决方案中波分设备与存储设备联动感知的SOCC技术，在毫秒级时间内感知到链路劣化，快速完成链路倒换，最大幅度的解决了应用因为心跳检测间隔较长导致数据不一致性的问题，也让数据库的资源可以全力进行数据计算。
 在测试中，采用OceanStor 闪存存储和Ocean Data 解决方案后，数据库“平均读时延”和“最大读时延”缩短约8倍，由原服务器本地盘存储架构的4.8ms和20.5ms缩短至0.6ms和0.8ms；“最大写时延”缩短约6倍，由原存储架构的6.4ms缩短至< 1ms；“平均写时延”缩短约2倍，由原存储架构的0.6ms缩短至0.3ms。整体性能提升效果相当可观。
需要特别提及的时，本方案中同数据中心主从节点数据同步，还是通过数据库之间的网络，由主节点将日志同步到各个从节点；而异地机房之间的数据同/异步复制灾备，则广泛使用前述基于存储同步复制的方案。

# 三、测试和上线效果
 结合实际的业务场景，我们采用了微服务+多PostgreSQL数据库集群的方式，数据使用一致性hash实现各个分库数据均衡。在业务实现上，我们采用数据网格的概念，让同业务场景下的所有数据，都集中于一个数据网格，减少检索范围和跨事务操作。整体性能测试结果显示，相较于Oracle RAC，虽然单集群内的单机QPS有所下降，但由于业务场景数据按照数据的区域进行了切分，整体上QPS有明显提升。此外由于采用的是开源软件，虽然在应用上和架构上实现较Oracle有所复杂，但是整体成本有明显下降，且未来的扩展性获得较大的提升。
 下表是使用Oracle12c和PostgreSQL  10.5对比测试的情况。用的是单机性能测试数据，采用TPC-C基准测试数据集，包含10个仓库，每个仓库包含300万条数据记录。查询性能测试结果，可看到相同资源环境下的PostgreSQL的查询响应时间普遍高于Oracle；但是在特定场景的OLTP的查询性能测试中，PostgreSQL的查询响应时间优于Oracle。

|   |   |   |   |
| ------------ | ------------ | ------------ | ------------ |
| 操作 | Oracle平均响应时间 | PostgreSQL平均响应时间 | 性能差异 |
| OLTP查询 | 15 | 13 | -13% |
| OLAP查询 | 50 | 80 | 30% |
| 插入 | 40 | 60 | 20% |
| 更新 | 50 | 90 | 30% |
| 删除 | 60 | 70 | 20% |
 虽然PostgreSQL性能较Oracle有所差距，但在可接受的范围内；最重要的是PostgreSQL本身的成本低廉，以及在集群模式下，数据分散程度高，整体性能是高于Oracle的。
 以下是一个部署的示意图。
![](/home/attachment/202401/29/1250271_170651005652766.png)

#  四、 进一步提升容灾能力的思考
 现在使用的容灾方案，还是基于业务场景进行区分。不论是业务上分机房处理还是在单个机房可以承载全部业务，都是根据业务场景和技术能力作出的最优妥协解决方案。但要实现真正意义上的三中心三活，当前技术依旧存在隐患，尤其是数据在总线上传输过程中是否有数据丢失，以及如何消除传输过程带来的延迟，都是未来完善此方案需要重点攻关的。即使通过额外软件已经可以实现补偿措施，但风险还是较数据库原生高。
 是采用分布式还是数据库集群的部署方式上，更多还是取决于单位内部的技术栈情况，以及业务更重视数据的一致性和可靠性，还是更关注吞吐量。此外数据规模不同，数据库部署方式选择也不尽相同。对于高并发高交易量业务，采用集群模式，可能导致容灾时候，无法切换到从库，导致RPO、RTO指标不达标；但采用分布式部署模式，若促销多节点故障，又可能导致一份数据的超2/3的副本数据不可用，导致整体上数据的不可用。
 对于业务上怎么迁移的问题，应当考虑系统的重要程度和业务的连续性。对于R PO 要求极 低 甚至 近乎0 、R T O要求秒级、业务连续性要求很高的系统，就没有办法停机数日或数小时进行一次性的迁移。这时就要考虑分步迁移。此外，在完成迁移后，应在在应用上进行流量切分，验证迁移后的业务是否正常；在业务正常情况下，开启同步模块，将迁移前后的业务系统的流量，反引流到反向系统，再分别进行交易，对比数据是否一致，来保障业务是否不受影响。
 例如客户的资产变动，客户的资产可能会有很多查询和交易作为强依赖使用，这种情况，使用的是数据三写的方式，保障在3个机房的数据都一致。写的时候，以客户所在的分片机房为主机房写入点，且以主机房成功与否，代表交易是否成功。若在三写同步的过程中，有机房发生异常，则将未能成功同步的记录的写入主机房的登记薄中。 用一个轮询代码去轮询登记薄，发现有待处理的登记薄信息，则读取出来后，将主机房的数据锁定，然后将最新的状态更新到备机房，实现数据的强一致性。
 例如客户资产余额查询，资产余额的数值，可能是很多交易是否能够进行下去的根本。我们采用了如下的方案：先判断被查询方的业务所在的路由分片，到对应的路由分片的机房进行查询，以此结果作为最终结果。
 例如客户的头像信息更新，这种属于非强一致性的，我们采用的方式是，在路由分片的主机房，写入数据，然后以消息队列+CDC的方式同步到其他机房。这样即使同步失败了，在维护一次即可，对业务影响并不大。查询这种非强一致性的也是一样，在交易的发起方所在的分片机房，进行查询，若查询的结果并不一致，让业务在做一次交易，然后同步到其他的机房，实现最终的一致性。
 以下是一个示例图
 ![](/home/attachment/202401/29/1250271_170651002084319.png)
 总之根据业务的特性和RTO\\RPO的要求，选择合适的容灾和迁移策略，不要过度自信拔高指标，或者选择与 业务要求 不符的架构方案。这点不止是针对某款数据库而言，而是所有设计师、架构师、DBA 在应对 各种数据库 时 都需要考虑到的内容。

协作专家：
赵志勇 某城商行系统分析师
陈曦  某大型银行 数据库主管
孙慧天 某城商行 系统架构师
许维豹 某城商行 数据库架构师
杨梦伦  某大型银行 系统架构师

顾问专家：
陈明福 某城商行 技术经理

Postgresql容灾方案设计银行交易系统 OceanStor Dorado PostgreSQL 容灾方案设计

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！