脚本宝典收集整理的这篇文章主要介绍了应用开发中的存储架构进化史——从起步到起飞，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

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

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

  

最终架构图

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

脚本宝典总结

以上是脚本宝典为你收集整理的应用开发中的存储架构进化史——从起步到起飞全部内容，希望文章能够帮你解决应用开发中的存储架构进化史——从起步到起飞所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。