共计 1098 个字符，预计需要花费 3 分钟才能阅读完成。
按楼主的教训和常识，本文总结了利用开发中的各种存储架构，从易到难，从起步到腾飞。如有不对之处，欢送留言。
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
最终架构图
从单库，逐渐演化成各种存储紧密配合，满足不同的需要和场景。切勿为了架构而架构，抉择适宜本人的、能解决理论问题的架构，才最重要。
正文完
