GaussDB关键技术原理_高可用：DCF技术

本篇将分享GaussDB高可用方面的相关知识，详细介绍GaussDB的DCF技术。

1 DCF

DCF是Distributed Consensus Framework的简称，它是自研分布式一致性共识框架，基于Paxos协议开发，实现多数派节点自选主自仲裁、日志复制、一致性控制等高可用功能。

1.1 DCF（Distributed Consensus Framework）分布式一致性共识框架

DCF部署于gaussdb进程，以动态库形式提供给DN调用，实现DN节点间自选主自仲裁、XLOG日志复制、回放控制等。DCF主要设计特点如下：独立API数据复制与内核逻辑隔离；基于Paxos一致性协议实现日志多副本复制，实现跨AZ极致高可用；支持多种节点角色：leader、follower、candidate、passive、logger；支持多日志流通道，支持DN粒度和分区粒度日志分组复制能力；DCF内部实现通过多处的pipeline、batching、compress等手段提升整体性能。

1.2 DCF功能架构

DCF通过上层API提供给DB kernel调用，在DCF内部主要功能模块如下：接口：对外提供写入、查询、注册回调等

接口选举：负责主节点的选举、心跳维持、状态通知复制：负责日志的复制、提交、达成一致控制元数据：负责管理集群配置信息存储：负责日志数据的缓存管理和持久化通信：提供节点间的数据通信功能，并支持压缩解压和SSL能力基础库：提供线程、日志、锁、队列、定时器等基础能力

1.3 DCF选举流程及优化

选举流程介绍：除了配置为不可当主的角色（logger、passive）外，启动时各节点一般默认是备机follower角色。节点启动后如果没有收到主节点的心跳，则达到选举超时时间后节点就会发起选主请求，如果节点收集到超过半数节点的应答则可升主。节点升主后会定期给其他节点发送心跳维持权威，其他节点收到心跳后作为备机工作。每次选出新主都会产生一个新的任期term，这个term是单调递增的。当后续重新选主，term会跟着变大。如果主节点故障，无法继续发送心跳，其他节点达到选举超时时间后会发起新一轮选举，集群选出新主，继续对外提供服务。预选举优化：为防止网络断连导致节点频繁发起选主请求造成term持续增加，采用了优化方案：在Follower变为Candidate前加入pre-candidate状态，发起term不变的预选举流程，成功后才将term增加发起正式选主流程，避免无效的term增加。租约优化：Leader与多数派断连主动降备，防止出现事实双主。在lease时间内不再响应新的选主消息，保证选主可靠性。

1.4 DCF日志复制流程

         复制流程介绍：在集群有主的情况下，上层可以调用DCF写接口将日志写给DCF主节点，DCF主节点将日志复制给各个备机，日志并行在主机和各备机落盘，主机收集自身和各备机日志落盘的位置，从而计算得到达成多数派一致性的日志落盘位置，即一致性点。主机会将一致性点同步给备机，整个过程异步、并行、流水线处理。各个节点都有了实时一致性点，主机可以利用一致性点控制业务提交、脏页刷盘、checkpoint等流程，备机可以利用一致性点控制XLOG日志回放，保证业务一致性、各节点不分叉。

1.5 DCF优先级选主和策略化多数派

优先级选主：

（1）根据用户指定的AZ和节点优先级顺序，通过节点间信息交互及日志索取机制实现了确定性优先级选主。

（2）高优先级节点异常时，其他节点秒级感知，保证选主RTO。

（3）策略化多数派。

（4）支持灵活动态的策略化多数派，可通过参数配置。

（5）在发生AZ级或城市级故障时，能够在其他AZ选出新主，不丢失数据。

1.6 DCF性能设计

          异步流水线：日志采用全异步pipeline方式进行发送，不采用一问一答同步方式，且支持报文合并发送，提高系统整体吞吐量；Leader发送完一批log之后，记录发送位置，下次发送从这个位置持续发送，不用等follower响应回来；Follower落盘线程写完一批log之后，将最新的落盘点发送给leader，持续反馈最新的落盘点；Leader通过各节点的最新落盘点，推进一致性点。   
          
           数据合并与压缩：报文收发和工作线程采用异步pipeline；基于端到端共识流控算法自适应调整batch size、 pipeline并发数，提升系统最大吞吐量；支持将报文按不同压缩算法进行压缩发送，减少网络带宽。批量并行落盘：应用端调用write接口，写入内存buffer就返回，不阻塞应用流程处理；批量写盘和批量发送，日志到buffer之后，并行的将日志落入本地磁盘和发送到follower节点。   

1.7 DCF日志与XLOG日志合一设计

为了减少磁盘空间和IO带宽占用、优化性能，我们进行了DCF日志与XLOG日志合一设计，实现XLOG日志只写一份。
DCF日志头和配置日志放在DCF侧（称为控制日志ctrllog）以方便DCF内部处理，XLOG日志格式和之前保持兼容。ctrllog和XLOG建立内部索引关系，相比XLOG其日志量可以忽略不计。使用XLOG刷盘点计算多数派一致性点，控制业务提交；XLOG刷盘点也是选主的依据。DCF控制日志刷盘以方便业务处理和故障恢复逻辑，限制DCF控制日志刷盘频率避免对XLOG刷盘影响，保证整体性能。

1.8 DCF异常场景处理，高可靠

Leader故障 如图，三节点集群，红色节点表示主机、蓝色表示备机，各节点旁边数字第一行表示日志index，第二行表示任期term，每一列表示一条日志。

leader节点宕机，导致Leader心跳发送停止，日志复制停止。

Follower检测到心跳超时，转换为candidate，发起新任期选举。Follower若接收到其他节点发起的选举，则判断任期和日志长度，确定是否投票给它。

candidate若得到超过半数的选票，则成为leader，拥有新的任期term。新leader开始将自己的日志发送给其他follower。

Follower接收新leader来的日志信息，判断日志是否跟自己连续匹配，连续匹配则接受。若不连续则返回，leader重新发送前段日志；若term不匹配，则将新leader的日志覆盖到原来的位置，并将后面的日志truncate掉。最终所有节点的日志都是一致的。 网络分区五节点集群，分裂为3+2，如图所示：集群脑裂，分裂出两个小集群。2节点小集群存在一个原leader，3节点新集群选举一个新leader，任期增1。原leader无法达成大多数一致，日志无法提交,一定时间内会降备。

新leader能接受写请求进行写入操作，能够达成一致，进行日志提交。脑裂消失之后，新leader的日志复制给旧leader，将旧leader未提交日志覆盖，集群正常。