如活动背景中谈到的需求,该银行系统现需进行高可用设计,要求集群架构无任何服务单点,针对各种国产数据库,可采用的设计方案有哪些,分别有哪些优缺点。
就OceanBase数据库而言,OceanBase数据库集群由多个Zone组成,Zone 由一个或多个 OBServer 组成,每个 OBServer 有若干个 Partition 的Replica。同一分区的多个副本使用 Paxos 一致性协议保证副本的强一致,每个分区和它的副本构成一个独立的 Paxos 组,其中一个分区为主副本(Leader),其它分区为从副本(Follower)。主副本具备强一致性读和写能力,从副本具备弱一致性读能力。
1、单生产中心环境下,一个由三个zone组成的集群中,假设每个zone包含一台OBServer,基于Paxos协议,任意一台OBServer故障,不会对业务连续性造成影响,如果高可用要求较高,可以使用5副本的架构,这样允许故障的OBServer就会达到两台。
2、假设存在双中心环境,此时可选的方案是建设基于主中心集群的备集群,备集群采用OceanBse提供的主备同步技术进行近似实时同步,可以保证跨中心的数据容灾。主中心异常情况下,可以切换至同城中心。在双中心的环境下,存在跨中心集群部署方式,比如主中心2个Zone和备中心1个Zone的三副本架构和主中心3个Zone和备中心2个Zone的五副本架构,但在主中心故障情况下,备中心将无法接管服务,所以该方案一般不选择。
3、假设存在三中心环境,在机房间网络性能较好情况下,就尤其适合OceanBase集群部署方式。比如三中心1-1-1的三副本部署或者2-2-1的五副本部署方式,可以防止任意中心级故障影响业务连续性。
收起分布式自带数据同步的就不说了。
简单的以PG为例子 PG同步加异步流复制加级联复制,可以满足两地三中心的数据同步和高可用
让主中心的数据库 异步流复制到异地中心1; 同步流复制到异地中心2
当有异常后,将异地中心2提升为主,异地中心1提升为同步流复制。
首选分布式,整体架构可以选用目前比较成熟的一些产品,tidb,golden db,等等,当然如果有研发能力,建议自行研发设计,目前可用的底层架构无非就是mysql和postgresql,架构方面建议一主多从,读写分离
收起针对该需求,可以考虑以下几种设计方案:
双主架构是一种常见的高可用设计方案,它通过在两个节点上同时运行主数据库实例,实现了无单点故障的目标。在该架构下,当一个主节点出现故障时,另一个主节点可以立即接管服务,保证了系统的可用性。该方案适用于大多数国产数据库,如神通数据库、南大通用数据库等。
优点:实现了无单点故障,可用性高。
缺点:需要较高的硬件成本和网络带宽,且在主节点切换时可能会出现数据同步延迟的问题。
主备架构是另一种常见的高可用设计方案,它通过在主节点和备节点之间进行数据同步,实现了主备切换的目标。在该架构下,当主节点出现故障时,备节点会自动接管服务,保证了系统的可用性。该方案适用于大多数国产数据库,如神通数据库、南大通用数据库等。
优点:实现了无单点故障,可用性高,数据同步延迟较小。
缺点:备节点的硬件配置需要与主节点相同,且在主备切换时可能会出现数据同步延迟的问题。
分布式架构是一种适用于大规模数据存储和处理的高可用设计方案,它通过将数据分散存储在多个节点上,实现了无单点故障的目标。在该架构下,当一个节点出现故障时,其他节点可以继续提供服务,保证了系统的可用性。该方案适用于大规模数据存储和处理场景,如分布式数据库、分布式文件系统等。
优点:实现了无单点故障,可用性高,可扩展性强。
缺点:需要较高的硬件成本和网络带宽,且数据分散存储可能会导致数据一致性问题。
总体而言,以上三种设计方案均可适用于国产数据库的高可用设计,具体选择哪种方案需要根据实际情况进行综合考虑。同时,需要注意的是,在设计高可用架构时,还需要考虑数据备份、灾备恢复等方面的问题,以保证系统的可靠性和安全性。