01.15 Day 31 - 性能设计篇之“数据库扩展”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 31 天，也是我第 31 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《性能设计篇之“数据库扩展”》的文章。

关键词总结：读写分离 CQRS（优点、缺点、CQRS / 命令与查询职责分离（语义区分、语义区分好处））、分库分表 Sharding（影响数据库性能的两个大问题（数据库操作、数据库数据量）、两个关注点（分库策略、数据访问层）、分片策略、分片模式注意点）、数据库扩展设计重点（水平分片注意事项）。

 

所学总结：

 

读写分离 CQRS

适用于读多写少的场景。

优点

• 实现容易。主从配置和服务框架的读写分离比较成熟；
• 把业务隔离。一个服务对数据库造成的影响不会波及其他服务；
• 均分读压力，读操作消耗 CPU。

缺点

• 主库出问题的话，所有服务都没办法进行写操作；
• 库间数据非实时同步，强一致读操作需要访问主库。

CQRS / 命令与查询职责分离

CQRS 是 Command and Query Responsibility Segregation。用户的操作分成两种：

• Command：写操作，增、删以及改；
• Query：读操作，查。

语义区分

• Command 会改变数据但不返回结果数据，而只返回执行状态；
• Query 不会改变数据，只返回结果数据。

语义区分好处

• 分工明确；
• 提高系统性能、可扩展性以及安全性；
• 逻辑清晰；
• 从数据驱动（Data-Driven）转变成任务驱动（Task-Driven）以及事件驱动（Event-Driven）。
  将 Command 变成事件溯源（Event Sourcing）就只需要记录不可变更事件并借助回溯事件获取数据的状态。
   

分库分表 Sharding

影响数据库性能的两个大问题

数据库操作

借助 ElasticSearch 做关联查询，用 Hadoop 或其他数据分析应用来做报表分析。

数据库数据量

将数据库拆分成分布式存储。借助分库分表来实现。

两个关注点

分库策略

按规则数据库拆分成 N 个库：

• 按地理位置；
• 按日期；
• 按范围；
• 按哈希散列算法。

数据访问层

访问层中间件要能够解析 SQL 语句的能力，根据解析完毕的 SQL 来做路由操作。

分片策略

• 多租户：借助租户 ID 将他们隔开，按商家的 ID 划分；
• 数据种类：按商品库存分类划分，或按商家地域划分；
• 范围：按订单月份分表，可以快速检索和统计连续的数据；
• 哈希散列算法：按主键 % N 来划分，会遇到跨库跨表查询和事务以及哈希扩容问题。

分片模式注意点

• 要站在业务的角度而不是技术的角度去考虑如何做分片；
• 只考虑业务分片，不要用哈希散列，除非被迫。
   

数据库扩展设计重点

水平分片注意事项

• 需要定期重新平衡分片，保证均匀分布以及降低热点的可能性。需要开发用于快速重新平衡分片的工具和脚本；
• 借助索引表来进行分片。将数据的索引动态地记录在索引表中。在数据调度时更改索引表里该数据的位置；
• 通过并行方式从各个分片上提取数据并聚合成一个结果后返回。会增加数据访问逻辑的复杂性；
• 很难保证引用的完整性以及一致性，也即跨分片事务，尽量减少多个分片会受影响的操作。在必须跨分片改动数据时需要评估一致性以及是否采用两阶段提交方式；
• 做变更时，根据从生产环境拉的数据做好新的片分方式以及测试工作。

 

末了

重新总结了一下文中提到的内容：单主多从读写分离、CQRS、语义区分、命令和查询、事件溯源方式、分库分表策略、数据访问层抽象、数据库扩展设计重点。