【使用版本】OceanBase 社区版 V4.2.x + OBProxy
【问题描述】
- 七层模式（OBProxy 解析 SQL 做路由）下，事务开启后是否会做「会话绑定」，把后续 SQL 强制固定到同一台 OBServer？还是仍然按分区 Leader 重新路由？
- 如果事务执行到一半，某个分区的 Leader 发生切换（或那台 OBServer 挂掉），事务会被回滚还是自动重试？客户端看到的具体错误是什么？
- 四层（LVS/F5 那种纯 TCP 转发）和七层在「会话保持」上的差异，实际会在什么场景踩坑？比如长事务、临时表、prepared statement 复用？
- 强一致性读和弱一致性读的路由策略差别在哪？弱读会不会读到明显滞后的数据，有没有延迟上限？
论坛小助手
#4
事务内多条 SQL 的路由策略
在 OceanBase 社区版 V4.2.x 和 OBProxy 的七层模式下，事务内的多条 SQL 需要保证路由到同一台 OBServer。以下是针对您问题的具体回答：
会话绑定与分区 Leader 路由
-
事务开启后的路由策略：
- 在七层模式（OBProxy 解析 SQL 做路由）下，当一个事务开启后，为了确保事务的一致性和原子性，OBProxy 会尝试将事务内的所有 SQL 请求路由到同一个 OBServer 节点上执行。这种机制通常被称为“会话绑定”或“事务绑定”。
- 如果事务内的 SQL 语句涉及多个分区，并且这些分区的主副本不在同一个 OBServer 上，则 OBProxy 仍然会按照分区的 Leader 进行路由。但为了保证事务的一致性，OceanBase 会在内部进行协调，以确保所有操作在同一个事务上下文中完成。
中途切主的情况
-
Leader 切换的影响：
- 如果在事务执行过程中，某个分区的 Leader 发生切换（或者 OBServer 挂掉），事务可能会遇到以下情况：
-
事务回滚：如果 Leader 切换导致当前事务无法继续执行，OceanBase 会自动回滚该事务。
-
自动重试：OceanBase 的分布式事务采用两阶段提交（2PC），具有失败重试机制。因此，如果在 Leader 切换后，新的 Leader 可以接替继续处理事务，事务可能会被自动重试。
-
客户端看到的具体错误：
- 客户端可能会看到类似于“连接中断”、“事务失败”或“超时”的错误信息。具体错误信息取决于具体的实现和配置。
四层与七层模式下的会话保持差异
-
四层模式：
- 四层模式（如 LVS/F5）通常是基于 TCP 层的负载均衡，不具备解析 SQL 的能力。因此，在四层模式下，SQL 语句会被直接转发到后端 OBServer，不会进行复杂的路由逻辑。这种方式在长事务、临时表、prepared statement 复用等场景下容易出现问题，因为无法保证事务的一致性和会话的绑定。
-
七层模式：
- 七层模式（如 OBProxy）可以解析 SQL 语句并根据实际情况进行智能路由。这种模式可以更好地支持长事务、临时表、prepared statement 处理，因为它可以在事务内保持会话绑定，确保所有操作在同一 OBServer 上执行。
强一致性读与弱一致性读的路由策略差别
-
强一致性读：
- 强一致性读会路由到指定表或分区的 Leader 节点。如果 SQL 指定了表名，将会直接路由到该表对应分区的 Leader 节点。
-
文档片段 1 提供了详细说明。
-
弱一致性读：
- 弱一致性读可能会路由到备节点（Follower），这样可以提高读取性能，但可能会读到稍微滞后的数据。
-
文档片段 1 和 文档片段 10 提供了详细说明。
- 弱一致性读可能会读到明显滞后的数据，具体延迟上限取决于系统的复制延迟。通常情况下，OceanBase 通过各种优化手段尽量减少复制延迟，但没有明确的延迟上限。
总结
- 在七层模式下，事务开启后，OBProxy 会尽量将后续的 SQL 请求路由到同一台 OBServer 节点。
- 如果事务执行过程中发生 Leader 切换，事务可能会被回滚或自动重试，客户端会看到相应的错误信息。
- 四层模式在处理长事务、临时表、prepared statement 等场景时不如七层模式可靠，因为缺乏智能路由的能力。
- 强一致性读会路由到 Leader 节点，弱一致性读可能会路由到 Follower 节点，存在一定的数据滞后风险。
具体信息可参考以下文档:
- SQL 路由
- 数据路由影响因素
- ODP SQL 路由原理
- 事务相关规范
- SQL 调优常见问题
- 函数分区键路由概述
- 路由策略路由
