PolarDB MySQL版推出了全局一致性（高性能模式）服务。PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络，在内核层面提供全局一致性（高性能模式）服务，保证发往集群任意副本的读请求都可以获得强一致性的结果。本文档介绍了全局一致性（高性能模式）服务的使用限制、技术原理、开启方式以及性能数据。
版本要求
若要开启全局一致性（高性能模式），PolarDB MySQL版集群版本需为以下版本之一：
8.0.2版本且内核小版本需为8.0.2.2.19及以上。
8.0.1版本且内核小版本需为8.0.1.1.29及以上。
5.7版本且内核小版本需为5.7.1.0.26及以上。
如何确认集群版本，详情请参见查询版本号。
注意事项
Serverless集群的所有只读节点默认开启全局一致性（高性能模式）。
全球数据库网络GDN中的从集群的只读节点不支持开启全局一致性（高性能模式）。
只读列存节点不支持开启全局一致性（高性能模式）。
全局一致性（高性能模式）与Fast Query Cache功能兼容。若此前全局一致性（高性能模式）打开了MTT优化功能，当同时开启Fast Query Cache功能和全局一致性（高性能模式）功能时，全局一致性（高性能模式）的MTT优化功能将失效。Fast Query Cache功能详情请参见Fast Query Cache。
背景信息
在原有的PolarDB一主多备数据库架构中，RO节点默认提供最终一致性读取功能。物理复制和共享存储技术可以有效的降低RO节点延迟，但不能保证发往RO节点的只读请求读取到RW节点上最新写入的数据。在一些对数据延迟比较敏感的金融行业和游戏行业中，RO节点延迟读取会造成业务逻辑的一致性问题。
如上图所示，多个业务之间通过微服务框架进行解耦。服务A写入数据后，产生一条数据写入成功的消息通过MQ通知到服务B。服务B通过消费消息感知到数据写入成功，随后下发读请求进行数据读取，进行下一步的业务流转。在只能提供最终一致性读的情况下，无论是A服务还是B服务，在进行数据读取时，都无法保证读取到步骤1中最新写入的数据，从而给上层业务带来数据一致性问题。此前面对这种使用场景，只能将只读请求转发到RW节点上，以保证写后读的数据一致性。
全局一致性（高性能模式）技术方案
PolarTrans利用CTS技术和RDMA网络，在纯内核层面提供RO节点强一致性读服务，从而保证始终能看到RW和RO节点最新的数据，提供了集群维度的强一致性读能力。
PolarDB在开启PolarTrans功能后，RW节点上每个读写事务提交时，都会赋予一个时间戳，表示事务提交的时间。这个时间可以是逻辑时间戳，也可以是一个和物理时间绑定的混合逻辑时间戳。同时，RW节点会把事务id和提交时间戳CSN记录到Redo Log中，RO节点通过回放Redo Log构建出完整的事务状态。
RO强一致性读SQL执行过程如下：
客户端发起查询；
RO节点通过RDMA one-side remote read获取RW节点当前最大提交时间戳；
RO节点根据RW节点的最大提交时间戳构建强一致性只读视图，并等到RO节点事务状态回放到相应位点；
RO节点根据强一致性读视图判断数据可见性，给客户端返回结果。
在全局一致性（高性能模式）中，RO节点通过RDMA one-side remote read获取RW节点上当前最新的提交时间戳，用于计算当前的事务延迟情况，构建强一致性读视图等。全局一致性（高性能模式）在实现上结合大量的并发优化手段，多线程之间的查询结果可能会进行复用，从而降低remote read次数和开销，使事务状态同步过程的时间消耗控制在2%以内。
细粒度的写入追踪（MTT）
为了在RO节点上实现强一致性读功能，RO节点首先需要获取RW节点上当前的最大时间戳，然后等待RO节点上的日志回放至该时间戳后，才可以处理读请求。然而实际操作中，RO节点在等待日志回放时，可能当前请求的数据已经是最新的，并不需要再等待日志回放。为了避免这些不必要的等待时间，全局一致性（高性能模式）使用了更加细粒度的修改追踪机制。即在RW节点上维护三层修改信息：全局的最新修改的时间戳、表级的时间戳以及页面（Page）级别的时间戳。MTT的核心是从多个层级来追踪RW节点的数据写入状态，并且能够进行Page粒度延迟检测。RO节点在处理请求时，首先获取RW节点上的全局时间戳，如果全局时间戳不满足强一致性读需求，则会进一步获取当前所访问的表的时间戳。如果仍然不满足要求，继续进一步检查需要访问的对应页面的时间戳是否满足要求。只有当页面时间戳仍然比RO节点上日志回放时间戳大时，RO节点才需要等待日志回放。
全局一致性（高性能模式）和全局一致性
PolarDB一共提供了四种一致性级别：最终一致性、会话一致性、全局一致性和全局一致性（高性能模式），可以满足在不同场景下对一致性级别的要求。
其中，全局一致性（高性能模式）是对原有全局一致性级别的升级，具有比全局一致性更严格的强一致性要求。因此，若您的业务追求更强的一致性，更推荐全局一致性（高性能模式），具体如下：
对于PolarDB MySQL版5.7、8.0.1和8.0.2版本，若追求严格强一致性，更推荐全局一致性（高性能模式）。
对于PolarDB MySQL版5.6版本，若追求严格强一致性，由于该版本暂不支持全局一致性（高性能模式），可选择全局一致性。
关于如何开启全局一致性，请参见开启全局一致性。
如何开启全局一致性（高性能模式）
登录PolarDB控制台，在目标集群的基本信息页面的数据库节点区域，选中需要开启全局一致性（高性能模式）功能的只读节点，单击开启全局一致性。
开通只对新连接生效。
为只读节点开启全局一致性（高性能模式）后，其余和此只读节点在同一个集群地址下的没有开启全局一致性（高性能模式）的其他节点，其一致性级别将自动切换为会话一致性，具体请参见会话一致性。
性能对比
测试环境
一个规格为8核32 GB的PolarDB MySQL版8.0版本集群版。
测试工具
Sysbench
测试数据量
25张表，每张表250000行数据。
测试结果及说明
RDMA性能损耗
在RO节点无延迟的情况下，通过对比开启/关闭全局一致性（高性能模式）功能，可以计算出通过RDMA获取RW节点当前最大事务版本号过程中的性能损耗。如下图所示，全局一致性（高性能模式）开启后，RDMA的性能损耗可以控制在2%以内。
全局一致性（高性能模式）只读性能对比
在常规的写入压力下，RO节点存在一定的延迟。由于强一致性读需要进行事务状态获取以及校验，所以对RO节点峰值只读性能存在一定的影响。但经过优化后的全局一致性（高性能模式）技术方案，可以将这一影响范围控制在20%以内，同时RO节点可以提供无异于RW节点的强一致性读体验。
全局一致性（高性能模式）集群混合读写性能对比
全局一致性（高性能模式）提供的严格强一致性读能力，在读写混合场景中，全局一致性（高性能模式）对RW节点的写入性能完全没有影响，并且可以通过集群地址将更多的只读请求分发到RO节点进行处理，从而提升集群整体的混合读写吞吐能力。下图展示了不同模式下Sysbench oltp_read_write的性能，其中RW表示将所有的请求都发往RW节点。全局一致性（高性能模式）在高并发场景下，性能是RW模式的1.7倍左右。
全局一致性（高性能模式）RO读扩展性能
在读写比例较高的场景中，比如Sysbench标准的oltp_read_write，通过扩展RO节点可以进一步提升集群的性能。更重要的是，扩展RO节点相对于现阶段的升配操作来说更加友好，无需进行集群切换，也不会产生访问中断。
全局一致性（高性能模式）高规格集群性能
通过MTT技术对全局一致性（高性能模式）进行优化后，即便在高并发写入压力下，全局一致性（高性能模式）依然可以在很大程度上提升集群的性能。如下图所示，在包含1个RW节点和1个RO节点的集群中，通过Sysbench 512并发对集群进行oltp_read_write压力测试，开启全局一致性（高性能模式）后的集群性能为RW模式的1.7倍。如果写入压力继续增大，通过扩展RO节点（1RW+2RO）可以将集群性能提升到百万级QPS。
- 本页导读 （0）