修改TaurusDB代理的一致性级别

开启数据库代理后，同一会话内，连续多次SELECT请求会根据权重配比，路由到不同的数据库节点，由于主节点与读节点之前存在复制时延，并且各个读节点的复制时延大小不一定完全相同，可能会导致每次SELECT请求得到的结果存在差异，因此默认情况下，数据库代理只能保证数据的最终一致。

需要减轻主节点压力，让尽量多的读请求路由到只读节点，或您的业务读写比例为写多读少，您可以选择最终一致性。

由于最终一致性可能会导致多次SELECT请求的结果存在差异，数据库代理进一步提供了会话级别的数据一致性，保证了在同一会话内，每次SELECT请求都可以获取到上一次写入操作后的最新数据。

数据库代理会记录每个数据节点的日志序号（Log Sequence Number，简称LSN），同时针对每一个会话也会维护对应的LSN，即Session LSN。当某个会话有数据更新操作执行完成时，数据库代理会根据当时主节点的LSN来更新对应的Session LSN，后续有读请求进来时，数据库代理会比较Session LSN以及各个数据节点的LSN，将请求发往LSN大于或等于Session LSN的数据节点，从而保证当前会话内，SELECT请求总能获取到上一次更新操作后的最新数据。

开启会话一致性后，如果主节点与读节点复制时延较大，各个读节点LSN均小于Session LSN，会导致SELECT请求发送到主节点，从而增大主节点的压力，整个数据库集群的读写性能会有一定的降低。

图1 会话一致性实现原理

TaurusDB的一致性级别越高，对主库的压力越大，集群性能也越低。若您的业务中存在同一会话内即写即查场景，您可以选择会话一致性。

会话一致性保证了同一个会话内，一定能够查询到读请求执行前已更新的数据，例如图2中读请求R(x1)依赖写请求W(x1, 4)的更新场景。但是在部分场景中，会话间也有依赖关系。例如图3中，Conn_2连接的R(x1)依赖Conn_1连接W(x1, 4)的更新数据，此时会话一致性无法保证查询结果的一致性，因此TaurusDB提供了全局一致性功能来解决该问题，保证在不同会话内，数据一致，即写入数据后，立即执行查询类操作，能够准确查到修改后的数据。

图2 会话内依赖关系

图3 会话间依赖关系

全局一致性的工作原理如下：

TaurusDB利用很短的复制延时和共享式分布式日志存储技术，在纯内核层面提供了RO节点强一致性读服务。在全局一致性功能开启之后，当某一个会话数据更新操作执行完成后，此时主节点的LSN会被更新为最新的LSN，后续读请求进来时，数据库代理会按照代理的路由模式直接路由到预期的节点上。由于存在主从复制延迟间隙，只读节点上当前LSN可能仍滞后于主节点。内核层面此时会立即加快只读节点的LSN推进，在毫秒级内完成只读节点和主节点的LSN同步。同步完成后，再对该读请求进行响应，保证读请求能够读到至请求发起时刻为止，任意一条已经完成更新的数据。

图4 全局一致性原理图

如上图，当UPDATE语句下发到主机后，主机的LSN会从6推进到10，那么当下发到只读节点的第一个SELECT语句查询结果时，需要等备机的LSN从2推进到10后再返回最新结果；当下发到只读节点的第二个SELECT语句查询结果时，需要等备机的LSN从5推进到10后再返回最新结果。

当主从延迟较高时，使用全局一致性可能会导致更多的请求被路由到主节点，造成主节点压力增大，业务延迟也可能增加。因此建议您在读多写少的场景下选择全局一致性。

全局一致性提供以下两个配置参数：

• 全局一致性开通只对新连接生效、仅支持通过Proxy连接的场景。
• 全局一致性开关跟数据库代理实例绑定，在多个数据库代理实例场景下，可以根据不同业务的需要，按需提供全局一致性服务。
• 只读的数据库代理在开启全局一致性功能后，无法修改consistTimeoutPolicy参数，只会返回错误报文到客户端。
• 打开只读节点的查询缓存功能，将不支持全局一致性。
• 开启全局一致性，并选择默认consistTimeoutPolicy参数，如果主节点与读节点复制时延较大，会导致SELECT请求发送到主节点，从而增大主节点的压力，整个数据库集群的读写性能会有一定的降低。
• 开启全局一致性，读节点存在复制延迟，当读节点并发读压力大时，对应读节点上活跃连接数会升高、数据库实例读性能下降，建议客户将代理的路由模式配置为负载均衡，通过活跃连接数情况进行读请求分发，来充分发挥数据库实例的读性能。
• 开启全局一致性，若业务压力较大导致CPU满载，服务可能出现闪断的情况。