后端存储设计
关于后端存储的设计
最后更新于
这有帮助吗？
常用的存储系统有很多，有单机的也有分布式的，有数据库也有文件系统，有基于日志型的，也有基于其他数据结构的...而往往后端存储架构的设计非常依赖于特定的业务场景，根据业务的特点分析出数据的增长趋势、数据的规模、数据的特点等来决定使用何种存储架构、存储技术和存储介质等
常见的后端存储有：
MySQL、Redis、ElasticSearch、HBase、Hive、MongoDB、RocksDB、CockroachDB、HDFS、Cassandra 等, 具体可参考
一般情况下，后端存储应对的复杂度是随着业务发展和业务量的提升而提升的：初期重点在快速构建一个可用的存储，一般单机就能解决，最多加个主备；在成长期，重点在快速变化上，可能要应对单机存储到分布式存储的演进，支持在线平滑扩容等；积累到一定阶段后，就需要关注海量数据处理的复杂度，重点在高并发，海量数据的存储架构设计等问题
先来汇总一下，存储架构在不同阶段可能会面临的各种问题：
怎么保证数据的正确性，在业务处理过程中，涉及到非常多的数据操作，我们需要保证入库的数据是准确的，既不能丢一部分数据，也不能多一些数据，又要保证数据的一致性
在业务发展过程中，可能会存在某些数据是热点数据，相较于其他的数据，在读或者写的压力上会更大一些，这个时候该怎么解决热点数据问题
在多表操作时，会遇到同时插入和更新多个表的情况，比如账户余额和交易流水等，如何使用事务
对于一些查询搜索的场景，需要多维度更智能的搜索，响应时间更快等，怎么办？
数据存储方案怎么做到高可用，数据是很重要的公司资产，高可用一定要考虑，即使做不到高可用，也要保证数据的高可靠，不能因为某种原因造成数据丢失
后端存储如何应对访问超时
后端存储出现操作变慢，如慢sql等，怎么办
后端存储如何应对高并发
后端存储如何应对越来越多的数据增长，海量数据如何存储、查询、写入等
在什么情况下适合引入缓存，缓存如何与DB保持数据一致性
数据迁移方案怎么做，可能是同一种数据库的扩容，还有可能是切换数据存储方案
有哪些典型的场景，后端存储该怎么应对
除去存储架构问题，关于存储还涉及到具体的存储引擎是如何设计、如何使用和如何实现的，这些和实际工作是非常紧密相关的，可以分析多种数据存储系统和存储引擎：
MySQL
Redis
ES
从哪些方面分析：
基本功能，适用的场景
基础架构和常见应用案例
高可用方案
高并发方案（读写）
数据一致性怎么解决
水平扩展如何做，垂直扩展如何做
常见的预估指标，比如 MySQL 在特定的配置下大概能支持多少TPS/QPS、单表的数据量等
如何做优化来提升整体性能
系统设计常见延迟比较表（做设计时可以参考）
文章目录
