银行系统案例

这是一个为你设计的银行系统综合案例分析，这个案例结合了业务逻辑、数据库设计、系统架构以及常见技术难点，非常适合用于学习、面试准备或项目参考。

案例名称：分布式银行核心账户系统（简化版）

项目背景与目标

某区域性银行计划将原有的集中式单体核心系统，升级为分布式微服务架构，以应对“秒杀”类营销活动（如理财抢购）的高并发冲击,并支持未来业务的多租户扩展。

• 核心痛点：原系统在业务高峰期（如工资发放日）数据库连接池耗尽，交易响应时间从200ms恶化到10s+。
• 建设目标：
  • 支持 5000 TPS（每秒事务数）的账务处理能力。
  • 核心链路可用性 99%。
  • 资金安全零差错（对账一致率100%）。

系统核心架构（分层设计）

[客户端/柜面/APP]
      |
      v
[接入层] -> 负载均衡 (Nginx) -> 网关 (Spring Cloud Gateway，限流/熔断)
      |
      v
[业务服务层] (微服务化，无状态)
   - 客户服务 (Customer Service)
   - 账户服务 (Account Service)
   - 交易服务 (Transaction Service，核心)
   - 信贷服务 (Loan Service)
      |
      v
[核心账务引擎] (高并发处理，无锁化/异步化)
   - 记账引擎 (基于Event Sourcing)
      |
      v
[数据层]
   - 账户数据库 (MySQL 集群，分库分表)
   - 流水数据库 (分布式文件存储 或 ClickHouse，供查询)
   - 缓存 (Redis Cluster，存热点账户余额)

关键业务逻辑与技术难点解析

数据一致性（最核心难点：资金不能错）

• 难点：跨账户转账（A扣款，B加款）不能使用传统数据库本地事务（因为是分布式）。
• 解决方案：采用 TCC（Try-Confirm-Cancel） 或 Saga 事务模型。
  • 以Saga为例：流程为 A账户扣款 -> B账户加款。
  • 若B加款失败，则调用Saga的补偿动作，向A账户执行“加款”回滚操作。
  • 为了保证最终一致性，引入了本地消息表或MQ事务消息（如RocketMQ）,确保扣款动作和发送消息在同一个本地事务中。

高并发下的“热点账户”处理（技术亮点）

• 场景：某头部网红在银行开卡，直播带货瞬间进账千万笔（如1分钱打赏）。
• 痛点：所有收入都更新同一个账户余额,造成数据库行锁竞争激烈。
• 创新解法（账务拆分）：
  • 设计：将物理账户逻辑上分为“影子账户”或“子账户组”。
  • 流程：请求进入时，按 user_id + 日期 哈希到不同的子账户（如1号子账户、2号子账户），并行写入,每一笔都记录到流水表。
  • 汇总：夜间批处理任务将所有子账户余额汇总到主账户。
  • 查询时：实时汇总子账户余额 + 缓存值。

分库分表策略

• 主键：不使用自增ID，采用雪花算法（Snowflake）或发号器,保证全局唯一且趋势递增。
• 路由规则：核心表（账户表、流水表）按 account_id 取模或按范围分片。
  • 用户ID % 16 将数据分布在16个数据库实例中。
• 难点处理：跨分片的分页查询（如查询最近10笔交易），解决方案：不同分片并行查询,结果集在中间件层归并排序。

数据库设计（核心表结构）

-- 1. 账户信息表 (分库分表)
CREATE TABLE `account_info` (
  `account_id` BIGINT NOT NULL COMMENT '雪花算法生成',
  `user_id` BIGINT NOT NULL,
  `account_type` TINYINT NOT NULL COMMENT '1-借记卡, 2-信用卡',
  `balance` DECIMAL(15,2) NOT NULL DEFAULT 0.00 COMMENT '可用余额（缓存热点数据）',
  `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-正常, 0-冻结',
  `version` INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
  `update_time` DATETIME(3) NOT NULL,
  PRIMARY KEY (`account_id`),
  KEY `idx_user_id` (`user_id`)
);
-- 2. 交易流水表（核心账本，只允许插入，不允许修改）
CREATE TABLE `transaction_log` (
  `txn_id` VARCHAR(64) NOT NULL COMMENT '全局唯一流水号',
  `account_id` BIGINT NOT NULL,
  `amount` DECIMAL(15,2) NOT NULL,
  `balance_after` DECIMAL(15,2) NOT NULL COMMENT '交易后余额（快照）',
  `txn_type` TINYINT NOT NULL COMMENT '1-消费, 2-充值, 3-转账, 4-退款',
  `opposite_account` BIGINT DEFAULT NULL COMMENT '对手方账号',
  `status` TINYINT NOT NULL COMMENT '1-成功, 2-冲正, 3-失败',
  `create_time` DATETIME(3) NOT NULL,
  PRIMARY KEY (`txn_id`),
  KEY `idx_account_id_time` (`account_id`, `create_time`)
);
-- 3. 冻结/解冻明细表（用于处理并发锁定的资金）
CREATE TABLE `account_freeze` (
  `id` BIGINT NOT NULL,
  `account_id` BIGINT NOT NULL,
  `amount` DECIMAL(15,2) NOT NULL,
  `status` TINYINT NOT NULL COMMENT '1-冻结中, 2-已解冻, 3-已扣减',
  `create_time` DATETIME(3) NOT NULL,
  PRIMARY KEY (`id`)
);

业务场景模拟：转账操作（伪代码）

为了确保接口幂等性（防止用户双击导致重复扣款）,代码逻辑如下：

// 转账服务（伪代码）
@Service
public class TransferService {
    @Autowired
    AccountMapper accountMapper;
    @Autowired
    TxnLogMapper txnLogMapper;
    @Transactional(rollbackFor = Exception.class)
    public boolean transfer(Long fromAccount, Long toAccount, BigDecimal amount, String requestId) {
        // 1. 幂等检查：确认该requestId是否已处理过（查流水表）
        if (txnLogMapper.existsByRequestId(requestId)) {
            return false; // 重复请求直接返回成功，不处理
        }
        // 2. 加锁（悲观锁，防止并发）
        AccountDO fromAcct = accountMapper.selectByPrimaryKeyForUpdate(fromAccount);
        // 3. 余额校验
        if (fromAcct.getBalance().compareTo(amount) < 0) {
            throw new InsufficientBalanceException("余额不足");
        }
        // 4. 扣减原账户
        int update = accountMapper.deductBalance(fromAccount, amount);
        if (update == 0) {
            throw new RuntimeException("扣款失败");
        }
        // 5. 增加目标账户（此处需考虑跨数据源分布式事务，此处为伪代码示意本地事务）
        int updateTo = accountMapper.addBalance(toAccount, amount);
        // 6. 写入流水（状态：成功）
        txnLogMapper.insert(new TxnLog(requestId, fromAccount, toAccount, amount));
        // 7. 发送MQ消息，通知积分服务增加积分等
        mqProducer.send("points_topic", fromAccount, amount);
        return true;
    }
}

系统稳定性设计（高可用）

1. 限流：网关层基于令牌桶算法，对异常流量（如爬虫试密码）进行拦截。
2. 熔断：当外部服务（如征信接口）响应超时，使用Sentinel/Resilience4j进行熔断，快速失败,防止服务雪崩。
3. 对账机制：
   • T+1：每日凌晨，系统拉取银行清算文件与本地流水进行逐笔勾对。
   • 准实时：通过监听Binlog（Canal）,比对业务数据库与Elasticsearch中的交易状态。
4. 灰度发布：采用金丝雀发布策略，先让少量内部账号体验新机房链路,确认无误后切全量流量。

总结与面试/答辩亮点

• 亮点一（资金安全）：不仅使用数据库事务，还结合了消息队列事务与Saga模式，确保了资本金的最终一致性。核心思想：宁可暂停服务，绝不出现长款/短款。
• 亮点二（性能优化）：通过对热点账户的“拆分”设计，将行锁冲突降低90%以上,支撑了千万级账户的并发访问。
• 亮点三（可观测性）：建立了全链路追踪系统（基于SkyWalking/Zipkin），所有核心操作都有traceId，一旦发生错账,能在分钟内定位到物理机房与代码行。

这个案例涵盖了高并发、分布式事务、数据一致性、分库分表等高频考点，如果你需要针对某个特定环节（具体如何分库分表？或者TCC如何具体落地？）进行深入探讨,随时告诉我。