应用开发中的存储架构进化史——从起步到起飞

按楼主的经验和知识，本文总结了应用开发中的各种存储架构，从易到难，从起步到起飞。如有不对之处，欢迎留言。

1、单库

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

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

2、分库分表、读写分离

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

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

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

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

• client侧分片：较为常见，以jar包库的方式内嵌在服务中，需要与所有的数据库实例，各自建立和维护连接池，性能好
• proxy侧分片：proxy是一个数据库访问中间层服务，应用与proxy建立少量连接，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

最终架构图

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