架构师教你 | 如何设计存储架构-极客时间

如何设计存储架构

一. 存储架构设计总的思路
1.估算性能需求：基于具体的业务场景来估算性能需求，包括存储量、读写性能等。【挑战】1.不知道如何估算；2.担心估算不准。
2.选择存储系统：根据技术储备、方案优缺点选择合适的存储系统。 【挑战】1.不知道有哪些存储系统；2.知道但是不知道怎么选。
3.设计存储方案   :基于选择的存储系统，设计其具体的存储方案，如果发现不行，回到步骤2再换一个。 【挑战】1.不知道如何设计存储方案。

二、如何估算业务所需存储性能
1.性能估算步骤：用估算模型应对估算挑战
(1).用户量预估
(2).用户行为建模
(3).性能需求计算

架构师澄清ToB业务：客户、解决方案架构师
架构师决策ToC业务：产品人员、运营人员、老板
为什么ToB是“澄清”，ToC是“决策”？

2.用户量预估
(1).规划: 根据成本、预算、目标等确定。案例：1.某个新业务预算投入2000万拉新；2.年底某业务用户规模达到100万。
(2).推算: 基于已有数据推算。 案例：1.做一个面向广州在校大学生的购物小程序；2.香港地铁扫码乘车业务。
(3).对比: 跟已有标杆进行对比。 案例：1.跟竞争对手比；2.跟自己已有的同类业务比。
注意：用户不一定是人，可以是设备（IoT 平台），可以是公司（云平台）。

3.用户行为建模
(1).行为:用户的典型行为。
(2).数量:采取某种行为的用户数量。
(3).频率:用户某种行为的频率。
案例：1.预计每个月使用钱包付款码的用户有100万，付款笔数达到500万笔；2.每天使用扫码乘车的用户有500万，平均扫码次数4.6次。

4.存储性能需求计算
(1).数据量:需要存储的数据总量(G)。
(2).请求量:对数据的读写请求量(TPS/QPS)。
(3).预留量:预留的增长空间。
说明和技巧：1.并不是所有数据都一定要用同样的存储方式，例如当前数据和历史数据可以分开存储。2.TPS/QPS需要计算出以秒为单位的数值，并且计算“平均值”和“峰值”。3.预留增长空间不能太大也不能太小，如果能做到线性伸缩是最好的。

5.存储性能需求计算案例
【案例】用户行为模型：每天使用扫码乘车的用户有500万，平均扫码次数4.6次。
【部分分析和计算过程示例】1.假设总用户数1000万，则用户数据存储量是1000万；2.每次扫码乘车，都需要访问一次用户数据，则用户数据读取次数：每天500万* 4.6=2300万；3.每次扫码乘车，都会生成一条乘车记录，则单日乘车记录数：500万* 4.6=2300万；4.乘车记录要保存2年，则总数据量为2300万* 800≈200亿；5.每条乘车记录对应一条支付记录，单日支付记录数2300万，总数据量为200亿；6.地铁乘车60%集中在早晚高峰的2个小时内，因此乘车记录写入的峰值TPS平均大约为2300万* 60%/(2*3600)≈2000。
如果这个是香港地铁，你准备预留多少？

三. 如何选择存储架构
1.存储架构选择逻辑：
(1).单机能否存储所有数据(否：是否需要分区部署？分区架构/分片架构)
(2).单机能否支撑写性能(否：是否需要分区部署？分区架构/分片架构)
(3).单机能否支撑读性能（否：是否需要自动切换?主从切换/集群选举/主从复制）
(4).是否需要自动切换(是：主备切换， 否：主备复制)

2.常见存储系统分类：
SQL： 1.OLTP（MySQL， PostgreSQL，Oracle）； 2.OLAP（ClickHouse，Hive，Kylin）
NoSQL：Redis，MongoDB，Elasticsearch，InfluxDB
大数据：HDFS，HBase，Cassandra，Ceph
更多请参考：https://db-engines.com/en/ranking/relational+dbms
NoSQL = Not Only SQL，而不是No SQL！

3. 如何选择合适的存储系统？
(1).技术本质：挑选英语常见和系统本质契合的系统
(2).技术储备：挑选熟悉的。
(3).综合考虑：可维护性，成本，成熟度等。
什么是技术本质？
系统的DNA，有别于其他系统的典型特征，例如：MongoDB是文档数据库，MySQL是关系数据库，Redis是Remote dictionary Server。
Elasticsearch是倒排索引搜素引擎，HBase是“sparse，distributed，multidimensional sorted map”......

技术本质有什么影响？技术本质决定了其核心应用场景和优缺点，例如MongoDB是文档数据库，优点是Schemaless，缺点是事务支持不好，Elasticsearch是搜索引擎而不是存储引擎（虽然可以做存储）。举例：1.游戏服务器用什么存储玩家数据比较好？2.论坛服务器用什么存储帖子数据比较好？
为什么要先理解技术本质，后掌握技术细节？

四. 如何设计存储方案？
以下为存储方案设计案例–Redis存储粉丝列表：
1.设计数据结构：选择或者设计具体的数据结构，例如如何设计具体的表，选择Redis的哪个数据结构。
 方案1选择List是有序的，可以重复；方案2选择Sorted set，有序但不能重复。

2.验证读写场景: 将数据结构放到具体的场景进行验证，设计读写具体如何执行（Rule）。
1.新增关注：需要扫描List判断是否重复，不重复则尾部追加；2.取消关注：需要扫描List找到粉丝ID然后删除；3.拉黑：和取消关注一样。
1.新增关注：使用关注时的timestamp作为score来排序，无需扫描，Redis会判断粉丝ID是否重复；2.取消关注：直接删除；3.拉黑：和取消关注一样。

3.评估读写性能: 评估具体场景下的数据结构设计是否满足性能需求，不满足则重新设计。
1.新增关注和取消关注都需要扫描整个List，性能较低，某些爆红的账户会有性能问题，因此需要再迭代看看是否有其它更合适的方案。
1.无论是性能还是实现复杂度，都比List要更优。

以阿X为例，P5/P6开发/测试/运维负责需求评审，方案设计，测试方案设计，测试用例执行，编码自测，项目上线，线上运维。P7开始即要负责子系统架构设计，方案设计，技术规划，技术演进，并带单个或多个技术团队。

本文出自极客时间架构师华仔，如有涉及版权问题请联系本人，谢谢！