设置一致性级别

功能介绍

RDS MySQL数据库代理默认采用最终一致性级别，在Binlog复制不中断的情况下，读请求直接发送到只读节点。由于只读节点的数据在Binlog复制下是最终一致的，因此代理上的读请求也是最终一致的。RDS MySQL代理支持设置延迟阈值，限制只读实例的最大延迟时间。一旦只读节点的延迟超过该阈值，读请求将不再被发送到该节点。

设置最终一致性会话后，只读节点读取结果如下图所示：

此外，复制延迟可能导致不同只读节点上的数据存在差异。例如，在一个会话中连续执行如下查询，最终查询结果可能有所不同：

SET AUTOCOMMIT = 1;INSERT INTO t1(id, price) VALUES (111, 96);UPDATE t1 SET price = 100 WHERE id = 111;SELECT price FROM t1;

这些查询的结果可能会因复制延迟而有所变化。

适用场景

一致性需求较弱，更希望尽量减轻主节点压力，使更多读请求路由到只读节点时，您可以选择最终一致性。

功能介绍

为应对最终一致性导致查询结果不准确的问题，业务系统通常会将读请求拆分：高一致性要求的读请求发往主节点，低一致性要求的读请求发往只读节点。然而，这种做法不仅增加了应用复杂度，还会使主节点承担更多的读请求，影响读写分离的效果。

为了解决上述问题，RDS MySQL代理提供了会话一致性。与最终一致性直接将读请求发送到只读节点不同，会话一致性下，代理会记录前一个更新操作在主节点上的数据位点（基于GTID确定）。代理仅将读请求发送到已同步该位点数据的只读节点，确保读请求能查询到当前会话中已更新的数据，从而保证会话内的数据一致性。

设置会话一致性后，只读节点读取结果如下图所示：

适用场景

单个会话内存在一致性依赖，推荐使用会话一致性，该级别对性能影响相对较小而且能满足大多数应用场景。

功能介绍

在某些应用场景中，不仅会话内部存在逻辑上的因果依赖关系，不同会话之间也存在依赖关系，要求各会话读取的数据必须完全一致。此时，会话一致性无法满足需求。RDS MySQL代理通过提供全局一致性来解决这一问题。与会话一致性不同，全局一致性下，代理会在每次读操作前记录当前主节点上的数据位点（基于GTID确定），并仅将读请求发送到已完成相应数据位点同步的只读节点，确保读请求能查询到所有会话已更新的数据，从而保证了全局数据的一致性。

设置全局一致性后，只读节点读取结果如下图所示：

适用场景

会话间存在一致性依赖，并且业务为读多写少的场景，建议使用全局一致性。