Arch Day 40: 金融系统数据库设计 — 从分库分表到NewSQL的演进之路

日期: 2026-05-09 (Day 40) 阶段: 第二阶段 - 金融域深度 标签: #核心银行 #数据库 #分库分表 #OceanBase #TiDB #ACID #审计追踪 #数据归档

---

核心概念

一句话定义

金融系统数据库设计是在ACID强一致性、审计追踪、高可用三大刚性约束下，解决海量数据存储、高并发读写、长期数据保存的架构难题——它不是简单的分库分表，而是一套覆盖数据建模、分片策略、一致性保证、归档策略、合规审计的完整数据架构方案。

为什么资深架构师必须关注

常见误区与反模式

---

知识点详解

知识点1：金融系统对数据库的特殊要求

金融数据库的七大刚性要求
━━━━━━━━━━━━━━━━━━━━━━

1. ACID强一致性
   ├── 原子性(A): 转账要么成功要么失败，不能一边扣钱一边没到账
   ├── 一致性(C): 所有账户余额之和在任何时刻都必须正确(总分核对)
   ├── 隔离性(I): 并发交易不能相互干扰(防止超额透支)
   ├── 持久性(D): 一旦确认成功，断电重启后数据必须存在
   └── 金融要求: 不是"最好有"，而是"必须有"，资金差一分钱都不行

2. 审计追踪(Audit Trail)
   ├── 所有数据变更必须有记录(who/when/what/why)
   ├── 审计日志不可篡改(append-only)
   ├── 支持时间点查询(能查任何历史时刻的数据状态)
   ├── 监管审计时能快速提供完整证据链
   └── 保存期限: 通常15-25年

3. 高可用(HA)
   ├── RTO < 30分钟(核心系统)
   ├── RPO ≈ 0(资金系统零数据丢失)
   ├── 自动故障转移(failover)
   ├── 多副本同步(同步复制，非异步)
   └── 支持两地三中心部署

4. 高性能
   ├── 在线交易: TPS 5000-50000(因银行规模而异)
   ├── 响应时间: P99 < 100ms
   ├── 日终批处理: 数亿条数据在4-6小时内处理完
   └── 不能牺牲一致性换性能

5. 数据安全
   ├── 传输加密(TLS)
   ├── 存储加密(TDE/列级加密)
   ├── 敏感数据脱敏(身份证/手机号/卡号)
   ├── 访问控制(RBAC/最小权限)
   └── 数据库防火墙(SQL注入防护)

6. 合规存储
   ├── 数据分类分级(个人金融信息三级)
   ├── 数据不出境(境内存储/处理)
   ├── 删除权(GDPR相关，但金融数据有保存义务例外)
   └── 数据备份合规(异地备份/加密备份)

7. 可扩展性
   ├── 存储扩展: 从TB到PB级别
   ├── 计算扩展: 支持在线扩缩容
   ├── 平滑扩展: 扩容时不影响在线业务
   └── 成本线性: 容量翻倍成本不应超翻倍

知识点2：分库分表策略

分库分表的三种维度
━━━━━━━━━━━━━━━━━

维度1: 按账户(用户)分片 ★最常用
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

分片规则: shard_id = account_id % N  或  account_id_range / shard_size

  DB_0: 账户 00000001-10000000
  DB_1: 账户 10000001-20000000
  DB_2: 账户 20000001-30000000
  ...
  DB_N: 账户 N0000001-(N+1)0000000

优点:
  - 同一用户的所有数据在同一分片(单分片事务)
  - 转账如果是同分片=本地事务，性能好
  - 查询单用户数据不需要跨片

缺点:
  - 跨用户操作(如A向B转账)可能跨片
  - 账户分布不均(新旧客户)需要定期rebalance
  - 全表扫描需要扫所有分片

适用: 核心账务系统(存款/贷款)


维度2: 按时间分片
━━━━━━━━━━━━━━━

分片规则: shard_id = year_month  或  year_quarter

  DB_202601: 2026年1月的交易
  DB_202602: 2026年2月的交易
  DB_202603: 2026年3月的交易
  ...

优点:
  - 天然支持数据归档(旧分片直接冷存储)
  - 日期范围查询性能好
  - 数据增长可预测

缺点:
  - 当前月份的分片是热点(写入集中)
  - 跨月份查询需要跨片
  - 不适合需要查历史余额的场景

适用: 交易流水表、操作日志、审计记录


维度3: 按业务线分片(垂直分库)
━━━━━━━━━━━━━━━━━━━━━━━━━━━

  DB_存款: 活期/定期/通知存款
  DB_贷款: 个人贷款/房贷/经营贷
  DB_支付: 转账/汇款/代收代付
  DB_理财: 理财产品/基金代销
  DB_信用卡: 信用卡账户/账单

优点:
  - 不同业务线独立扩展
  - 故障隔离(贷款系统出问题不影响存款)
  - 与组织结构匹配(不同团队维护不同库)

缺点:
  - 跨业务操作(如贷款还款从存款扣款)需要分布式事务
  - 综合查询(如客户所有产品)需要跨库join

适用: 大型银行(业务线复杂)

复合分片策略(推荐)：

推荐: 两级分片
━━━━━━━━━━━━━

第一级: 按业务线垂直分库
    DB_存款  DB_贷款  DB_支付  DB_信用卡

第二级: 每个业务库内按账户水平分表
    DB_存款
    ├── account_0000 (账户 00000001-01000000)
    ├── account_0001 (账户 01000001-02000000)
    ├── ...
    └── transaction_202603 (2026年3月流水)

路由规则:
    function route(account_id, business_type, query_date):
        // 第一级: 确定业务库
        db = get_business_db(business_type)
        // 第二级: 确定分表
        if is_account_table:
            table = "account_" + (account_id / 1000000)
        elif is_transaction_table:
            table = "transaction_" + format_date(query_date, "YYYYMM")
        return db + "." + table

知识点3：路由规则设计

/**
 * 金融系统分库分表路由器
 * 核心设计原则:
 * 1. 同一账户的所有操作路由到同一分片(避免分布式事务)
 * 2. 路由规则不可变(一旦确定不能改，否则数据找不到)
 * 3. 支持扩容时的数据迁移(一致性hash或range rebalance)
 */
public class FinancialShardRouter {

    // 分片策略配置
    private static final int TOTAL_SHARDS = 64;        // 总分片数
    private static final int TABLES_PER_SHARD = 16;    // 每个分片内的表数

    /**
     * 账户分片路由
     * 使用一致性Hash避免扩容时大规模数据迁移
     */
    public ShardInfo routeByAccount(String accountId) {
        // 计算hash(使用MurmurHash3，分布均匀)
        long hash = MurmurHash3.hash(accountId);

        // 确定分片(数据库实例)
        int shardId = (int)(Math.abs(hash) % TOTAL_SHARDS);

        // 确定表(分片内的表)
        int tableId = (int)(Math.abs(hash / TOTAL_SHARDS) % TABLES_PER_SHARD);

        return new ShardInfo(
            "db_" + String.format("%04d", shardId),
            "account_" + String.format("%04d", tableId)
        );
    }

    /**
     * 交易流水分片路由
     * 按时间分片 + 账户二级分表
     */
    public ShardInfo routeTransaction(String accountId, LocalDate txDate) {
        // 第一级: 按月确定数据库
        String dbName = "tx_" + txDate.format(DateTimeFormatter.ofPattern("yyyyMM"));

        // 第二级: 按账户确定表
        long hash = MurmurHash3.hash(accountId);
        int tableId = (int)(Math.abs(hash) % TABLES_PER_SHARD);

        return new ShardInfo(dbName, "transaction_" + String.format("%04d", tableId));
    }

    /**
     * 跨分片转账路由
     * 确定发起方和接收方是否同分片
     */
    public TransferRoute routeTransfer(String fromAccount, String toAccount) {
        ShardInfo fromShard = routeByAccount(fromAccount);
        ShardInfo toShard = routeByAccount(toAccount);

        if (fromShard.getDbName().equals(toShard.getDbName())) {
            // 同分片: 本地事务即可
            return TransferRoute.sameShardLocal(fromShard);
        } else {
            // 跨分片: 需要分布式事务(TCC/Saga)
            return TransferRoute.crossShardDistributed(fromShard, toShard);
        }
    }
}

知识点4：读写分离在金融场景的挑战

读写分离架构
━━━━━━━━━━━━

  写请求 → Master DB ──(同步/异步复制)──→ Slave DB ← 读请求
                │                            │
                │                            │
           强一致性要求                    延迟问题
           (转账/扣款)                    (余额查询)

核心挑战: 一致性延迟(Replication Lag)

场景分析:
━━━━━━━━

场景1: 转账后查余额
  T0: 用户发起转账(写Master) → 成功
  T1: 用户查询余额(读Slave) → 余额未更新!
  原因: 主从同步延迟通常50-500ms
  用户感知: "钱扣了但余额没变" → 恐慌

场景2: 连续两笔交易
  T0: 第一笔交易写入Master → 成功
  T1: 第二笔交易读Slave检查余额 → 读到旧余额 → 可能超额透支
  风险: 资金安全问题!

解决策略:
━━━━━━━━

策略1: 写后读走主库(Read-your-writes consistency)
  ├── 实现: 写操作后N秒内的读请求路由到Master
  ├── 优点: 简单有效，解决"转账后查余额"问题
  ├── 缺点: 写频繁时Master读压力增大
  └── 适用: 大多数场景

策略2: 半同步复制(Semi-sync Replication)
  ├── 实现: Master写入后等待至少1个Slave确认收到
  ├── 优点: 保证Slave的数据不落后太多
  ├── 缺点: 写入延迟增加(+5-20ms)
  └── 适用: 金融场景推荐

策略3: 同步复制(Synchronous Replication)
  ├── 实现: Master写入后等待所有Slave确认
  ├── 优点: 读任何副本都是最新数据
  ├── 缺点: 写入延迟大幅增加，可用性降低
  └── 适用: 强一致性要求的核心账务

策略4: 分布式数据库(OceanBase/TiDB)
  ├── 实现: Raft/Paxos共识协议保证多副本强一致
  ├── 优点: 自动处理一致性问题
  ├── 缺点: 架构复杂度和运维成本高
  └── 适用: 下一代金融系统

知识点5：分布式数据库选型

金融级分布式数据库对比
━━━━━━━━━━━━━━━━━━━━━

知识点6：金融数据归档策略

热温冷数据分级
━━━━━━━━━━━━━━

Hot (热数据) — 近3-6个月
├── 存储: 高性能SSD，主数据库
├── 访问: 在线交易+即时查询
├── 数据量: ~10%
├── 成本: ★★★★★
└── 例子: 近期交易、当前余额、活跃账户

Warm (温数据) — 6个月-3年
├── 存储: 普通SSD/HDD，归档数据库
├── 访问: 报表查询、审计查询(秒级响应)
├── 数据量: ~30%
├── 成本: ★★★
└── 例子: 历史交易流水、已结清贷款

Cold (冷数据) — 3年-25年
├── 存储: 对象存储(S3/OSS)/磁带
├── 访问: 监管审计(分钟级响应可接受)
├── 数据量: ~60%
├── 成本: ★
└── 例子: 超过3年的交易记录、已销户账户

归档流程:
━━━━━━━━

  Hot DB ──(定期迁移)──→ Warm DB ──(定期迁移)──→ Cold Storage
    │                      │                       │
    │ 触发条件:            │ 触发条件:              │
    │ - 超过6个月          │ - 超过3年              │
    │ - 账户已销户         │ - 监管保存期到期       │
    │                      │                       │
    │ 迁移要求:            │ 迁移要求:              │
    │ - 数据完整性验证     │ - 压缩存储             │
    │ - 归档后源数据保留   │ - 加密存储             │
    │   30天再删除         │ - 保持可查询           │
    │ - 全程审计日志       │ - 定期可恢复性验证     │
    └──────────────────────┴───────────────────────┘

金融归档的特殊要求:
├── 不可删除: 在监管保存期内(15-25年)数据不可删除
├── 可查询: 归档数据必须能查询(审计/诉讼/客户投诉)
├── 防篡改: 归档数据必须有完整性校验(Hash/数字签名)
├── 合规销毁: 保存期到期后按规定流程销毁，留销毁记录
└── 跨系统一致: 核心系统/数据仓库/灾备系统的归档策略必须一致

知识点7：数据库审计和合规

金融数据库审计体系
━━━━━━━━━━━━━━━━

层次1: SQL操作审计
├── 记录所有DML操作(INSERT/UPDATE/DELETE)
├── 记录DDL操作(CREATE/ALTER/DROP)
├── 记录DCL操作(GRANT/REVOKE)
├── 记录登录/登出
├── 存储: 独立审计数据库(不在主库)
└── 工具: 数据库自带审计 / 第三方(Imperva/安华)

层次2: 数据变更追踪(CDC)
├── 记录每次数据变更的before/after
├── 支持时间旅行查询(Time Travel)
├── 实现方式:
│   ├── 触发器(Trigger): 简单但影响性能
│   ├── CDC工具(Debezium/Canal): 基于binlog，不影响主库
│   └── Event Sourcing: 只记录事件，不记录状态
└── 金融场景: 必须能回答"某个时刻账户的状态是什么"

层次3: 不可篡改审计日志
├── 审计日志一旦写入不可修改
├── 实现方式:
│   ├── WORM存储(Write Once Read Many)
│   ├── 区块链(审计日志上链)
│   ├── 加密Hash链(每条日志包含前一条的Hash)
│   └── AWS QLDB / Azure Immutable Blob
└── 目的: 防止内部人员篡改审计日志

层次4: 数据访问控制审计
├── 谁在什么时间访问了什么数据
├── 是否有异常访问(如非工作时间/大量导出)
├── 特权账号操作监控(DBA操作全程录像)
└── 敏感数据访问审批流程

---

对比分析

NewSQL vs 传统分库分表

何时用传统方案，何时用NewSQL

决策树
━━━━━

Q1: 团队是否有分库分表经验？
  ├── 是 → Q2
  └── 否 → 推荐NewSQL(避免重复造轮子)

Q2: 跨分片事务频率是否高？
  ├── 高(>10%交易跨片) → 推荐NewSQL
  └── 低(<5%跨片) → Q3

Q3: 是否需要复杂SQL(JOIN/子查询/聚合)？
  ├── 是 → 推荐NewSQL
  └── 否 → Q4

Q4: 预算是否充足？
  ├── 是 → NewSQL(长期运维成本更低)
  └── 否 → 传统分库分表(初始成本低)

Q5: 信创合规要求？
  ├── 必须信创 → OceanBase/TiDB/GaussDB
  └── 无要求 → 根据Q1-Q4决策

---

架构设计实操

设计目标

为一家中型银行(3000万零售账户，200万对公账户，日均交易500万笔)设计核心数据库方案。

要求：

• 在线交易TPS: 10,000+ (峰值)
• 响应时间: P99 < 50ms
• 数据保存: 交易数据保存15年
• 信创合规: 2028年前完成国产化
• 灾备: 两地三中心，RPO ≈ 0

数据库架构方案

整体数据架构
━━━━━━━━━━━

                    ┌──────────────────────────┐
                    │       应用服务层          │
                    │  (核心银行/渠道/风控)     │
                    └────┬──────┬──────┬───────┘
                         │      │      │
                    ┌────▼──┐ ┌─▼──┐ ┌─▼────┐
                    │路由层 │ │缓存│ │消息队列│
                    │(ShardingSphere)│ │(Redis)│ │(RocketMQ)│
                    └────┬──┘ └─┬──┘ └─┬────┘
                         │      │      │
         ┌───────────────┼──────┼──────┼──────────────┐
         │               │      │      │              │
    ┌────▼────┐    ┌─────▼────┐ │ ┌────▼─────┐  ┌────▼────┐
    │OceanBase│    │OceanBase │ │ │OceanBase │  │  TiDB   │
    │核心账务 │    │交易流水  │ │ │贷款系统  │  │分析查询 │
    │(强一致) │    │(高吞吐) │ │ │(强一致)  │  │(HTAP)   │
    └────┬────┘    └────┬────┘ │ └────┬─────┘  └────┬────┘
         │              │      │      │              │
         └──────────────┴──────┴──────┴──────────────┘
                              │
                    ┌─────────▼─────────┐
                    │    归档存储        │
                    │ 温数据:OceanBase冷副本│
                    │ 冷数据:MinIO/OSS  │
                    └───────────────────┘

分片键选择

核心表的分片键设计
━━━━━━━━━━━━━━━━━

表: 账户表(account)
├── 分片键: account_id
├── 分片方式: Hash(account_id) % 128
├── 理由: 账户查询最频繁的维度是account_id
│         同一账户的余额/冻结等信息必须在同一分片
└── 注意: 按客户号查询需要维护 customer_id → account_id 的索引表

表: 交易流水表(transaction)
├── 分片键: account_id + tx_date (复合分片)
├── 分片方式: 先按account_id Hash → 再按月分区
├── 理由: 查询交易流水最常见的条件是 account_id + 日期范围
│         按月分区支持高效的数据归档
└── 注意: 全局交易号(tx_id)需要全局唯一索引

表: 客户信息表(customer)
├── 分片键: customer_id
├── 分片方式: Hash(customer_id) % 64
├── 理由: 客户信息相对独立，与账户分片解耦
│         避免客户变更影响账户分片
└── 注意: customer_id和account_id的映射关系需要额外维护

表: 操作审计表(audit_log)
├── 分片键: log_date
├── 分片方式: 按天分区
├── 理由: 审计查询通常按时间范围
│         天级分区支持高效归档
└── 注意: append-only，不允许UPDATE/DELETE

ADR: 数据库选型决策

# ADR-040: 核心银行数据库选型

## 状态
ACCEPTED

## 上下文
中型银行核心系统需要选择数据库方案，要求强一致性、高可用、信创合规。
评估了三个方案:
A) 传统MySQL分库分表(ShardingSphere)
B) OceanBase分布式数据库
C) TiDB分布式数据库

## 决策
核心账务系统选择OceanBase，分析查询系统选择TiDB。

核心账务(OceanBase):
- 强一致性(Paxos协议)满足资金交易要求
- TPC-C世界纪录证明了性能上限
- 蚂蚁金服/工行/建行的金融级验证
- 信创合规(国产)
- 支持Oracle兼容模式(降低迁移成本)

分析查询(TiDB):
- HTAP能力(TiFlash列存)满足分析需求
- MySQL兼容(开发者友好)
- 用于报表、对账、数据分析等非核心场景

不选MySQL分库分表的原因:
- 跨分片事务实现复杂，且正确性难以保证
- 信创替换时仍需替换MySQL
- 长期运维成本高于分布式数据库

## 后果
- 正面: 金融级一致性保证，信创合规，长期运维成本可控
- 负面: OceanBase学习曲线高，需要专项DBA培训
- 负面: 双数据库增加了架构复杂度
- 缓解: 与OceanBase签订技术支持合同，DBA团队提前半年培训

---

AI增强实践

AI在金融数据库管理中的应用

AI-Enhanced Database Operations
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 智能SQL优化(AI DBA)
   ├── 自动分析慢查询并生成优化建议
   ├── 自动识别缺失的索引
   ├── 基于历史查询模式预测未来的热点数据
   └── 工具: OceanBase内置的SQL优化器 / 阿里云DAS

2. 智能容量规划
   ├── 基于业务增长趋势预测数据库容量需求
   ├── 提前N个月告警扩容需求
   ├── 自动推荐分片Rebalance策略
   └── 避免: "存储空间不足导致系统宕机"

3. 异常检测
   ├── 检测异常的查询模式(如大规模数据导出→内鬼)
   ├── 检测性能异常(响应时间突增→可能被攻击)
   ├── 检测数据异常(余额突变→可能有bug)
   └── 实时告警 + 自动阻断

4. 智能归档
   ├── 基于数据访问频率自动识别冷数据
   ├── 自动触发归档流程
   ├── 智能压缩策略(不同数据类型用不同压缩算法)
   └── 自动验证归档数据的完整性

5. AI辅助合规
   ├── 自动扫描数据库中的敏感数据(PII/金融信息)
   ├── 自动生成数据分类分级报告
   ├── 自动检测合规违规(如敏感数据未加密)
   └── 辅助生成监管审计报告

# AI驱动的数据库异常检测
class AIDBMonitor:
    """金融数据库AI监控"""

    def detect_anomaly(self, metrics: dict) -> list:
        """
        基于多维指标检测数据库异常
        """
        anomalies = []

        # 1. 查询性能异常检测
        if metrics['p99_latency'] > self._get_dynamic_threshold('latency'):
            anomalies.append(Anomaly(
                type='PERFORMANCE',
                severity='HIGH',
                detail=f"P99延迟 {metrics['p99_latency']}ms 超过动态阈值",
                suggested_action='检查慢查询日志，可能存在全表扫描或锁等待'
            ))

        # 2. 数据量异常检测(防内鬼)
        if metrics['select_rows'] > self._get_baseline('select_rows') * 10:
            anomalies.append(Anomaly(
                type='SECURITY',
                severity='CRITICAL',
                detail=f"查询返回行数 {metrics['select_rows']} 远超基线",
                suggested_action='可能存在大规模数据导出，立即审查操作人员'
            ))

        # 3. 余额异常检测
        balance_change = metrics['total_balance_change']
        if abs(balance_change) > self._get_threshold('balance_change'):
            anomalies.append(Anomaly(
                type='BUSINESS',
                severity='CRITICAL',
                detail=f"总余额变动 {balance_change} 超过阈值",
                suggested_action='可能存在计息错误或异常交易，需要紧急对账'
            ))

        return anomalies

---

与Web3/DeFi的关联

传统金融数据库 vs 区块链存储

区块链解决了传统数据库的哪些痛点

区块链作为"金融数据库"的优势
━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 不可篡改审计
   传统: 需要额外建设审计系统，仍可能被DBA篡改
   区块链: 天然不可篡改，任何人都可以验证

2. 跨机构一致性
   传统: 银行间需要对账(T+1/T+2)，因为各方有独立数据库
   区块链: 共享账本，不需要对账

3. 透明度
   传统: 数据对外不可见，需要监管报送
   区块链: 监管机构可以直接查询(Open Finance)

4. 结算终结性
   传统: 清结算需要1-3天(涉及多个中介)
   区块链: 交易即结算(Atomic Settlement)

但区块链无法替代传统数据库的场景:
├── 高性能在线交易(链上TPS仍不够)
├── 隐私数据存储(链上数据公开)
├── 复杂查询(区块链不支持SQL)
├── 数据修正(链上数据不可修改，错误怎么办？)
└── 成本(链上存储极其昂贵)

---

今日思考

深度问题1

"金融系统分库分表的分片键选择，选account_id还是customer_id？"

选account_id。原因：(1)账户是金融系统最核心的查询维度，90%的交易和查询都基于account_id；(2)同一客户可能有多个账户(活期/定期/贷款)，按customer_id分片会导致一个客户的所有账户在同一分片，造成数据倾斜(大客户可能有上百个账户)；(3)跨账户的操作(如A账户转B账户)如果按customer_id分片，同一客户内的转账是本地事务，但这类操作占比不高。代价是按客户维度的综合查询需要跨片，可以通过维护customer_id→account_id映射表解决。

深度问题2

"分布式数据库如何保证金融级一致性？"

以OceanBase为例：(1)使用Paxos共识协议，每次写入需要多数派(majority)确认，保证不丢数据；(2)分布式事务使用两阶段提交(2PC)+Paxos日志，确保跨分片事务的原子性；(3)全局时间戳(类似Spanner的TrueTime)保证事务的可串行化隔离级别。代价是写入延迟比单机MySQL高(约5-15ms)，但对金融交易(P99<50ms)是可以接受的。

深度问题3

"如果区块链能做到不可篡改的审计追踪，银行还需要传统审计数据库吗？"

短期内仍然需要。原因：(1)隐私——银行的审计数据包含大量个人隐私信息，不能放在公链上；联盟链可以解决隐私问题，但增加了部署和运维成本；(2)性能——审计数据量巨大(每天数亿条)，区块链的写入性能不够；(3)查询能力——审计查询需要复杂的SQL(JOIN/聚合/子查询)，区块链不支持。但长期趋势是混合架构——关键审计日志的Hash上链(保证不可篡改性)，详细数据仍存在传统数据库。

---

面试题准备

面试题1：金融系统分库分表的分片键如何选择？

30秒版本： 核心原则是将最频繁访问的维度作为分片键，并尽量让单个业务操作在同一分片内完成。对于核心账务系统，分片键选account_id，因为90%的操作基于账户。对于交易流水，使用复合分片键account_id + 日期。分片键一旦确定不可变更，所以选择时要考虑未来3-5年的查询模式。

2分钟版本： 分片键选择需要考虑四个因素：

第一，查询频率。选择最常用的查询条件作为分片键。核心账务系统90%的查询和交易基于account_id，所以选它。

第二，数据分布均匀性。如果选customer_type(个人/企业)作为分片键，个人客户占99%导致严重倾斜。account_id通常分布均匀。

第三，事务封闭性。同一个业务操作涉及的数据尽量在同一分片。比如查询某账户余额+最近交易，如果都按account_id分片就是本地操作。但跨账户转账无论怎么分片都可能跨片。

第四，扩展性。分片数要预留空间。建议初始设计128或256个逻辑分片，即使物理只有16台服务器，逻辑分片多便于未来扩容。

实际案例中，我建议核心表用account_id做Hash分片，交易流水用account_id+月份做复合分片(支持归档)，操作日志按天分区(支持审计查询)。

可能的追问：

• Q：跨分片转账怎么处理？
• A：用TCC或Saga模式。以TCC为例：Try阶段冻结两个分片的金额，Confirm阶段执行扣款和入账，Cancel阶段解冻。为减少跨片频率，可以按同城/同分行做亲和性路由。

面试题2：分布式数据库如何保证金融级一致性？

30秒版本： 通过三层机制：单分片内用Raft/Paxos共识协议保证多副本强一致(写入需要多数派确认)；跨分片用两阶段提交(2PC)保证分布式事务原子性；全局用统一的时间戳服务保证事务的可串行化隔离。代价是写入延迟比单机数据库高5-15ms，但对金融场景可接受。

---

学习资源

---

明日预告

Day 41: 金融级高可用设计 — 两地三中心架构、异地多活设计、灾备切换流程、CAP理论在金融场景的实际选择、混沌工程在金融系统的应用。高可用是金融系统的生命线，RTO/RPO的要求直接影响架构设计的每一个决策。