1、单库

最简单的初始架构，适用于千万级以下的数据，并发量低的场景。

• 单库、单表

• 或单库、多个分表：之所以分表是为了给后续分库做预留准备

2、分库分表、读写分离

最常见的存储架构，适用于十亿级别以下的数据（单表控制在千万级别或以下），并发量较大、主备高可用的场景。

• 分库分表：对业务 id（如用户 id、商户 id）取模，散列到各个分库的分表中

• 读写分离：适用于读多写少的场景，利用数据库一主多从的方式，提高并发量，对主库读写，对从库只读

此时还需要分片中间件来实现对分库分表的读写分离访问，有 2 种类型：

• client 侧分片：较为常见，以 jar 包库的方式内嵌在服务中，需要与所有的数据库实例，各自建立和维护连接池，性能好

• proxy 侧分片：proxy 是一个数据库访问中间层服务，应用与 proxy 建立少量连接，proxy 与所有的数据库实例建立连接，优点是对应用开发简单透明，缺点是有性能损耗、需要专门的团队维护

client 侧分片

proxy 侧分片

3、引入缓存

高并发标配，当 QPS 高到只靠 mysql 扛不住流量时引入，适用于高并发、流量尖峰的场景

• 本地缓存（堆内缓存、或堆外缓存）：如 caffeine、ehcache、guava 等

• 分布式缓存：如 Redis 集群

缓存查询：先查本地缓存，如果查不到再查 Redis 并写入本地缓存和 Redis，如果 Redis 也查不到再查数据库并写入本地缓存和 Redis 缓存更新：数据库更新后，触发变更消息，通过消息驱动更新 Redis

4、冷热数据分离

引入多级存储，保证热数据量可控、读写迅速，冷数据全量储存，适用于数据量巨大、增长迅速，且分库分表已经不能解决的场景。

• MySQL 热数据：优先读写 mysql，预期能覆盖绝大部分 QPS

• Hbase 冷数据：从 mysql 查询不到数据时，才查询 hbase，hbase 可支持海量数据的存储和查询，预期只有少量 QPS

• 归档：定期把数据从 mysql 归档至 hbase，mysql 只保留最新的热数据，hbase 存储全量数据

5、引入搜索引擎、离线查询

适用于复杂条件的查询、或对运营类统计有需求的场景，此时 mysql 索引已不能满足高效查询，且会影响在线业务。

• 引入 ElasticSearch：可支持各种条件的灵活查询，再也不用担心 mysql 因为缺少合适索引而造成慢查询的问题了

• 大数据分析：引入 hive 数仓做离线查询，需要把 mysql 的数据同步至 hive

最终架构图

从单库，逐步演化成各种存储紧密配合，满足不同的需求和场景。切勿为了架构而架构，选择适合自己的、能解决实际问题的架构，才最重要。

来源：https://www.toutiao.com/a7012475908627972619/?log_from=fc5815566bf5c_1632724857086