本文介绍 OceanBase 数据库的 Location cache 刷新机制。
Location cache 的刷新分为同步刷新和异步刷新两种：
同步刷新：主要给 SQL、存储模块及 Proxy 使用，刷新 Location Cache 时通过加锁，无法使用批量聚合来一次性刷新多个分区的位置信息。
- 当并发的 SQL、PL 同时触发对同一个分区对象的 Location Cache 的刷新请求时，会出现竞争 Location Cache 锁的情形，导致 SQL 工作线程的堵塞。
异步刷新：主要给 CLOG、SQL、事务模块以及定时任务使用，具有批量聚合的能力，其并发数由集群配置项
location_fetch_concurrency和location_refresh_thread_count来控制。- 异步刷新时，不同的并发任务刷新不同对象的 Location Cache，不存在锁竞争的情况。
| 配置项 | 默认值 | 功能描述 |
|---|---|---|
location_fetch_concurrency |
20 | 用于设置单机 location_cache 刷新的最大并发数。 |
location_refresh_thread_count |
4 | 用于设置 OBServer 从 RootService 中获取分区位置信息的线程数量。 |
修改 Primary Zone、添加删除 OBServer 等操作时，如果涉及的分区数较多，可以适当调大异步刷新的并行度参数（location_fetch_concurrency 和 location_refresh_thread_count），来加速 Location Cache 的刷新，避免 SQL、PL 执行时触发同步刷新。
Location Cache 有主动刷新机制，当发生切主、副本迁移时，OceanBase 数据库会主动刷新 Location Cache。在此期间，SQL 的执行过程如下：
OBProxy 根据旧的 Location Cache 信息将 SQL 路由到了旧 Leader 的位置。
OBServer 生成了一个本地执行计划或者分布式执行计划。
对于本地执行计划，OBServer 会在 Open Plan 时检查分区的 Leader 是否有变化，如果 Leader 位置已变化，则会重试并生成远程执行计划。
对于分布式执行计划，OBServer 不在 Open Plan 时检查 Leader 变化，而是依赖 SQL 执行时的重试能力。
OBServer 在 SQL 执行时会检查 Leader 位置的变化，当发现 Leader 变化时，如果还没有开始返回数据，则重试；如果已经开始返回数据（比如 union 的场景），则无法重试，只能将错误抛给客户端。常见的报错有 -4038 和 -4255。
ORA-00600: internal error code, arguments: -4225, Partition entry not exists ERROR 4038 (HY000) : The observer or zone is not the master
适用版本
OceanBase 数据库 V3.x 版本。
