数据库最容易成为一个系统的性能瓶颈,出现瓶颈时如何应对呢?数据库有哪些扩展方式?

打卡Day31:今天学习了《60|性能设计篇之“数据库扩展”》,我的收获如下:

读写分离

适用于读多写少的业务场景。缺点是:写库有单点故障问题;对于交易型的业务,要得到高的写操作速度,这样的方式不行;需要强一致性的读写操作还是需要落在写库上。

CQRS

Command and Query Responsibility Segregation,也就是命令与查询职责分离。

如果把Command操作变成事件溯源Event Sourcing,那么只需要记录不可修改的事件,并通过回溯事件得到数据的状态。于是,我们可以把写操作给完全简化掉,也变成无状态的,这样可以大幅度降低整个系统的副作用,并可以得到更大的并发和性能。

分库分表 Sharding

分片策略

  • 按多租户的方式(商家ID)
  • 按数据的种类来分(商品库类目)
  • 通过范围来分(按月份)
  • 通过哈希散列算法来分(主键ID % 3)

分片关键

  • 分片必须考虑业务,不是从技术的角度入手。
  • 只考虑业务分片,不要走哈希散列的分片方式。

数据库扩展的设计重点

把数据库和应用服务一同拆开。一个服务一个库,服务之间只能通过服务接口通讯,不能通过访问对方的数据库。

在一个单体的库上做读写分离或是做分片都是一件治标不治本的事,真正治本的方法就是要和服务一起拆解。

先做服务化拆分,再做分片。

水平分片,拆分数据行;垂直分片,拆分数据列(商品描述和库存价格分成两张表,提高描述查询性能)。

水平分片注意事项

  • 定期重新平衡分片
  • 使用一个索引表记录数据位置
  • 使用并行任务从多个分片上提取数据然后聚合
  • 尽量减少跨分片事务,仔细评估一致性和两阶段提交
  • 谨慎对待数据分片变更测试,这个事出问题就是灾难性问题

左耳朵耗子带你重学《左耳听风》

https://time.geekbang.org/column/article/7045