3. 数据库高可用设计：主从复制、读写分离、分库分表、数据库连接池的高可用策略
数据库这块，说实在的，是整个库存系统的命门。库存数据要是丢了，或者查不出来了，那整个系统就瘫了。我这些年踩过的坑，有一半都跟数据库有关。今天咱们就聊聊数据库高可用的四个核心维度。
3.1 主从复制：别让单点成为你的噩梦
主从复制，说白了就是让数据多存几份。一台主库挂了，从库能顶上。我见过太多项目，一开始图省事只搞单库，结果半夜磁盘坏了，全员起来恢复数据。
核心要点：主库负责写，从库负责同步。同步方式有三种：
- 异步复制：主库写完就返回，不管从库。性能最好，但可能丢数据。
- 半同步复制：主库等至少一个从库确认再返回。性能稍差，但数据安全。
- 全同步复制：所有从库都确认才返回。数据最安全，但性能最差。
我个人习惯，核心业务用半同步。库存这种数据，丢一条可能就是几十万的损失。你想想看，异步复制虽然快，但主库挂了，从库还没同步完，那数据就丢了。我曾经在一个电商项目中，就因为用了异步复制，大促期间主库宕机，丢了近千条订单数据。从那以后，我再也不敢在核心链路上用异步复制了。
3.2 读写分离：把压力分散开
读写分离，就是把查询请求打到从库上，写请求走主库。这样主库的压力就小多了。库存系统里，查询操作占了80%以上，读写分离能显著提升吞吐量。
嗯，这里要注意：读写分离会带来数据延迟的问题。从库同步主库的数据需要时间，如果刚写入就查询，可能查不到。怎么办？
- 强制读主：对实时性要求高的查询，直接走主库。
- 延迟容忍：库存查询可以接受秒级延迟，那就无所谓。
- 缓存兜底：用Redis缓存热点数据，减少对从库的依赖。
我的经验：库存查询的读写分离，建议把「库存余量」这种高频查询走缓存，把「库存流水」这种低频查询走从库。这样既保证了实时性，又减轻了数据库压力。
3.3 分库分表：数据量大了怎么办？
库存数据量大了，单库单表扛不住。分库分表是必然选择。分库分表有两种策略：
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 垂直分库 | 业务模块独立 | 解耦、隔离性好 | 跨库查询复杂 |
| 水平分表 | 单表数据量过大 | 扩展性好 | 分片键选择关键 |
我建议库存系统采用「垂直分库 + 水平分表」的组合策略。先把库存服务独立成一个库，再按商品ID做水平分表。分片键选商品ID，因为库存查询基本都是按商品ID来的。
避坑指南：我曾经在一个项目中，分片键选了时间戳，结果导致热点数据全在一个分片上，其他分片空闲。分片键一定要选业务上分布均匀的字段，比如商品ID、用户ID。
3.4 数据库连接池：别让连接成为瓶颈
数据库连接池，很多人觉得简单，不就是配个最大连接数嘛。其实不然。连接池的高可用，涉及到连接的健康检查、超时处理、动态扩容等。
我常用的连接池配置（以HikariCP为例）：
# 核心配置
spring.datasource.hikari.maximum-pool-size=50
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.max-lifetime=1800000
# 健康检查
spring.datasource.hikari.connection-test-query=SELECT 1
spring.datasource.hikari.validation-timeout=5000
这里有几个关键点：
- 最大连接数：不是越大越好。连接数太多，数据库CPU会飙升。一般建议50-100。
- 连接超时：30秒是合理的。太短容易误判，太长会阻塞请求。
- 健康检查：定期用SELECT 1检查连接是否有效。我遇到过数据库重启后，连接池里的连接全失效了，但应用不知道，结果所有请求都报错。
高可用策略总结：
- 主从复制：半同步复制，保证数据不丢
- 读写分离：缓存兜底，延迟容忍
- 分库分表：垂直+水平组合，分片键选业务均匀字段
- 连接池：合理配置最大连接数，定期健康检查
下面这张图，是我自己总结的数据库高可用架构图，你看一眼就明白了：
这张图把整个架构串起来了。应用服务通过连接池访问数据库，写请求走主库，读请求走从库。主库和从库之间通过半同步复制保证数据一致性。数据量大了，再按商品ID分片，每个分片都有主从结构。
最后说一句，数据库高可用不是一蹴而就的。我建议你从主从复制开始，逐步加上读写分离、分库分表。连接池的配置，也要根据实际压测结果来调整。别一上来就搞大而全的方案，容易翻车。