异地多活数据库分片策略核心是“就近写、本地读、少跨域”，按用户维度以uid为键做一致性哈希或范围分片，辅以地域+业务混合分片、数据分层同步及灰度迁移能力。
异地多活数据库分片策略的核心，是让数据“就近写、本地读、少跨域”，在保障业务连续性的同时，把跨地域延迟和一致性风险压到最低。它不是简单按ID取模或哈希，而是围绕业务单元、用户归属、访问模式做结构化切分。
按用户维度做逻辑单元划分
这是最常用也最稳妥的方式。以用户ID（或手机号、账号UID）为分片键，通过一致性哈希或范围分片，将用户及其全链路数据（订单、地址、偏好、会话等）固定归属到某个地理单元（如“华东单元”“华北单元”）。这样同一用户的注册、登录、下单、支付等操作都在本地闭环完成，避免跨地域写冲突。
- 推荐用64位雪花ID或自定义UID作为分片依据，确保全局唯一且可路由
- 分片数建议设为2的幂次（如1024），便于后续扩缩容和负载均衡
- 需配套设计“单元路由表”，记录每个UID对应的目标单元ID和数据库实例地址
按地域+业务类型做混合分片
适用于用户跨区活跃度高、但核心行为有明显地域倾向的场景（如本地生活、同城配送）。先按省/市划分一级地域单元，再在单元内按业务子域（如“团购”“到店”“闪送”）做二级分片。关键数据（如门店信息、库存）只存于所属地域单元，非核心数据（如评论、浏览日志）可异步同步或只读复制。
- 地域编码建议嵌入ID前缀（如“SH2026090000001”表示上海门店）
- 对跨地域查询需求（如全国热销榜），走聚合服务层，不直接跨库JOIN
- 避免用IP地址实时解析做分片依据——精度低、易被代理干扰、无法支持APP端
冷热分离 + 核心数据强同步、非核心数据终一致
不是所有数据都需要异地多活。应明确分层：账户、余额、订单主表等强一致性要求的数据，必须严格单元封闭；而头像、标签、设备指纹等弱一致性数据，可通过MQ、Canal或定时任务异步同步，允许秒级甚至分钟级延迟。
- 密码、实名信息等敏感字段，建议只存主单元，其他单元回源读取（带缓存兜底）
- 使用消息队列同步时，务必加幂等控制和顺序保障（如按用户ID分区）
- 对“写后立即读”的场景（如改密码后立刻登录），可在应用层加二次读机制：先查本地，未命中则查主单元
预留灰度与迁移能力
分片策略上线后不能一成不变。要支持用户单元动态迁移（如因机房扩容、故障隔离需调整归属）、分片规则平滑升级（如从128分片扩到256）、以及灰度验证通道（新规则只对1%流量生效）。
- 所有SQL访问必须经由分片中间件（如ShardingSphere、MyCat）或自研路由SDK，禁止直连DB
- 路由元数据（如分片映射关系）存于配置中心，支持热更新
- 每次迁移前，先双写旧新分片，比对数据一致性后再切流
