Vitess 分片路由变化怎样影响应用连接池

应用通过 Vitess 的 VTGate 访问分片数据时，分片路由变化通常不会直接要求应用重建连接池。真正需要拆开判断的是三层连接：应用到 VTGate 的前端连接、VTGate 到 VTTablet 的会话路由，以及 VTTablet 到 MySQL 的后端连接池。只要 VTGate 的入口和协议没有变，路由变化多数发生在中间层；但临时表、锁和长事务这类有状态会话，必须单独处理。

官方地址：https://vitess.io/

下面按一次线上分片调整后的排查顺序，说明连接池应该保持什么、哪些指标需要观察，以及什么时候应该让应用主动缩短会话生命周期。

先把三层连接边界画清楚

Vitess 的 VTGate 是应用侧看到的轻量代理。应用可以使用 MySQL 协议连接 VTGate，VTGate 再根据 VSchema、分片信息、tablet 可用性和延迟条件，把查询发往合适的 VTTablet。应用并不需要知道每一行数据落在哪个物理分片上。

因此，先不要把“查询去了另一个 shard”理解成“应用连接池里的连接已经失效”。在常规无状态查询中，应用连接池仍然可以复用同一个 VTGate 地址；变化的是 VTGate 对后端 tablet 的选择。

应用侧可以把连接池当成稳定的入口资源来配置。例如 Go 的 database/sql 只负责控制到 VTGate 的客户端连接数量，不能代替 VTTablet 的后端容量规划：

package main

import (
	"database/sql"
	"log"
)

func openVitess() *sql.DB {
	// DSN 指向 VTGate；应用不把物理 shard 地址写进连接池。
	db, err := sql.Open("mysql", "app:secret@tcp(vtgate.service:15306)/commerce@primary")
	if err != nil {
		log.Fatal(err)
	}
	// 先限制前端并发，避免发布时把大量新会话同时压到 VTGate。
	db.SetMaxOpenConns(80)
	db.SetMaxIdleConns(20)
	return db
}

这里的数值只是示例，不应照搬。应用连接池的上限要结合 VTGate 实例数、请求并发、连接建立成本和发布策略确定；它不是按 shard 数量简单相乘的参数。

路由变化到底改变了什么

VSchema 保存分片键与路由信息，VTGate 消费部署到拓扑中的统一 VSchema 数据。带有分片键条件的查询可以被送往目标 shard；无法确定目标时，VTGate 可能需要向多个 shard 分发。重分片或拓扑切换时，应用看到的仍是同一个逻辑 keyspace，但后端候选集合会变化。

这会影响三类行为：

• 同一条 SQL 可能被送到新的 tablet，后端连接的使用分布随之变化。
• 副本选择会受本地 cell、复制延迟和可用性影响，单个应用连接不等于固定绑定某一台 MySQL。
• 如果某个 tablet 下线，VTGate 会从健康候选中重新选择；应用通常应该处理短暂的重试、超时和事务回滚，而不是盲目销毁整个连接池。

Vitess 的 tablet balancer 有本地 cell 优先、prefer-cell、random 和 session 等模式。session 模式会尽量让一个会话持续读同一副本，以减少复制延迟导致的“回退读取”；但原 tablet 不再 serving 时，会话仍可能迁移到新的健康 tablet，所以不能把这种黏性当成永久物理连接保证。

普通复用连接与有状态会话要分开看

普通查询可以在 VTGate 的连接池与后端池之间复用。Vitess 会把大量客户端连接复用到较小的 MySQL 连接集合中，应用的客户端连接数因此不等于 MySQL 的实际连接数。

例外是需要连接状态的操作。临时表只存在于某个 MySQL 连接上下文中；使用临时表时，Vitess 会把会话标记为需要 reserved connection。使用 MySQL advisory lock，例如 GET_LOCK()，也需要锁定到同一连接。此时路由变化不是简单的“下一条查询换个 shard”，而是要保证这段会话的状态仍然可用。

服务端可以用类似下面的方式把有状态操作限制在短生命周期事务内，并在结束时显式清理：

func useTempTable(db *sql.DB) error {
	// 事务让临时表的创建、读取和清理保持在一个明确的会话范围。
	tx, err := db.Begin()
	if err != nil {
		return err
	}
	defer tx.Rollback() // 提交成功后 Rollback 只会返回已完成状态，作为兜底清理。

	if _, err = tx.Exec("CREATE TEMPORARY TABLE tmp_ids (id BIGINT)"); err != nil {
		return err
	}
	// 真实业务应在这里完成必要查询，避免把临时表会话长期放回空闲池。
	if _, err = tx.Exec("DROP TEMPORARY TABLE tmp_ids"); err != nil {
		return err
	}
	return tx.Commit()
}

重点不是这段示例是否覆盖业务逻辑，而是不要让使用 reserved connection 的客户端会话无限期闲置。Vitess 文档明确提醒，reserved connection 会在池中留下额外资源占用；客户端或连接器应及时断开不再使用的空闲会话。

容量观察要看 VTTablet 的真实池指标

分片路由变化后，如果只看应用的 db.Stats()，很容易漏掉真正的后端瓶颈。VTTablet 有 normal conn-pool、stream-conn-pool、transaction-pool、dba-conn-pool、app-conn-pool 等不同池，它们的上限和用途并不相同。

生产检查至少要把下面三组信息放在一起：

官方文档建议把带有 _active 后缀的池指标作为当前使用连接数的主要依据，把 _exhausted 作为池耗尽次数的观察线索。池达到上限并不自动等于故障，它也可能是在有意限制数据库并发；关键是和请求延迟、超时、MySQL容量一起判断。

# 发布前记录各类池的当前值，便于和变更后同一时间窗对比。
curl -s http://vttablet.example:15000/metrics | grep 'conn_pool_\|transaction_pool_'

# 检查 VTGate 是否发现了预期的 tablet；这里只读取本地管理端点。
curl -s http://vtgate.example:15000/debug/status | grep 'Health Check Cache'

命令中的地址是示意地址，实际端口与管理端点应以部署配置为准。文章不把这些示例输出当成当前集群已经运行过的证据。

发布前后怎样决定要不要动连接池

我会把一次路由变更拆成四个检查点，而不是先执行“重启所有应用”：

1. 确认入口没变。核对应用使用的 VTGate DNS、端口、认证方式和 keyspace 名称；只改变 VSchema 或 shard 拓扑时，先保持前端池配置不动。
2. 确认会话类型。把普通查询、事务、临时表和 advisory lock 分开统计。长事务或 reserved connection 应有更短的空闲回收策略。
3. 确认路由收敛。观察 VTGate 的 tablet 健康缓存、复制延迟和错误率；若某 tablet 被标为不健康，优先处理服务状态和回滚路径。
4. 确认后端容量。把各 VTTablet 池的 active/exhausted 指标与 MySQL max_connections 对照。不要把应用池上限、VTTablet 池上限和 shard 数量机械相乘后直接当成真实用量。

如果变更导致连接错误，先区分“连接到 VTGate 失败”“VTGate 找不到健康 tablet”“事务中途失去后端会话”三种情况。前两类可能适合有限重试；事务或 reserved connection 失败后，通常应回滚并重新建立业务会话，不能对原事务无限重放。

最后的判断

Vitess 分片路由变化影响的是请求如何到达后端，以及后端连接池的负载分布；它通常不要求应用立刻重建到 VTGate 的连接池。应用需要特别保护的是连接状态：普通查询可以依赖 VTGate 的路由与池化，有临时表、GET_LOCK 或长事务的会话则要缩短生命周期、观察 reserved connection，并准备在 tablet 变化后重新建立会话。

把“入口连接池”“VTGate 路由”“VTTablet 后端池”“有状态会话”四项分开记录，发布时就能知道该改哪一层，也能避免因为一次分片调整而造成全量连接抖动。

相关问题

应用连接池是不是要按 shard 数量扩大？不应直接按 shard 数量相乘。应用池面向 VTGate，后端池由 VTTablet 按各类用途管理，应该结合实际并发和指标容量估算。

session balancer 能保证永远读同一台副本吗？不能。它会尽量保持会话黏性，但 tablet 下线或不再 serving 时，会话可能迁移到新的健康 tablet。

临时表删掉后就能立刻恢复普通池化吗？不一定。会话仍可能被标记为需要 reserved connection，最稳妥的做法是结束不再需要的客户端会话。