数据库最容易成为一个系统的性能瓶颈,出现瓶颈时如何应对呢?数据库有哪些扩展方式?
打卡Day31:今天学习了《60|性能设计篇之“数据库扩展”》,我的收获如下:
读写分离
适用于读多写少的业务场景。缺点是:写库有单点故障问题;对于交易型的业务,要得到高的写操作速度,这样的方式不行;需要强一致性的读写操作还是需要落在写库上。
CQRS
Command and Query Responsibility Segregation,也就是命令与查询职责分离。
如果把Command操作变成事件溯源Event Sourcing,那么只需要记录不可修改的事件,并通过回溯事件得到数据的状态。于是,我们可以把写操作给完全简化掉,也变成无状态的,这样可以大幅度降低整个系统的副作用,并可以得到更大的并发和性能。
分库分表 Sharding
分片策略
- 按多租户的方式(商家ID)
- 按数据的种类来分(商品库类目)
- 通过范围来分(按月份)
- 通过哈希散列算法来分(主键ID % 3)
分片关键
- 分片必须考虑业务,不是从技术的角度入手。
- 只考虑业务分片,不要走哈希散列的分片方式。
数据库扩展的设计重点
把数据库和应用服务一同拆开。一个服务一个库,服务之间只能通过服务接口通讯,不能通过访问对方的数据库。
在一个单体的库上做读写分离或是做分片都是一件治标不治本的事,真正治本的方法就是要和服务一起拆解。
先做服务化拆分,再做分片。
水平分片,拆分数据行;垂直分片,拆分数据列(商品描述和库存价格分成两张表,提高描述查询性能)。
水平分片注意事项
- 定期重新平衡分片
- 使用一个索引表记录数据位置
- 使用并行任务从多个分片上提取数据然后聚合
- 尽量减少跨分片事务,仔细评估一致性和两阶段提交
- 谨慎对待数据分片变更测试,这个事出问题就是灾难性问题