左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

60 | 性能设计篇之“数据库扩展”

陈皓 2018-04-26

读写分离 CQRS

读写分离是数据库扩展最简单实用的玩法了,这种方法针对读多写少的业务场景还是很管用的,而且还可以有效地把业务做相应的隔离。
如下图所示,数据库只有一个写库,有两个读库,所有的服务都写一个数据库。对于读操作来说,服务 A 和服务 B 走从库 A,服务 D 和服务 E 走从库 B,服务 C 在从库 A 和从库 B 间做轮询。
这样的方法好处是:
比较容易实现。数据库的 master-slave 的配置和服务框架里的读写分离都比较成熟,应用起来也很快。
可以很好地把各个业务隔离开来。不会因为一个业务把数据库拖死而导致所有的业务都死掉。
可以很好地分担数据库的读负载,毕竟读操作是最耗数据库 CPU 的操作。
这样的方法不好的地方是:
写库有单点故障问题。如果是写库出了性能问题,那么所有的业务一样不可用。对于交易型的业务,要得到高的写操作速度,这样的方式不行。
数据库同步不实时,需要强一致性的读写操作还是需要落在写库上。
综上所述,一般来说,这样的玩法主要是为了减少读操作的压力。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • ^o^
    一致性哈希
    2018-06-13
    3
  • 吞枣
    感觉分库分表是分布式数据库到来之前的临时方案,另外感觉老外们好像并不怎么会采用分库分表,是这样吗?
    2018-05-22
    3
  • Geek_22d08b
    请问如果采用阿里云华为云的话,那么多技术要实现是不是只要购买阿里云他们相应的产品,然后配置下就可以了,就没程序员什么事了?
    2018-05-19
    3
  • 唐稳
    CQRS应该用在没有事务强一致性要求的场合,才能充分发挥其作用。不过微服务架构似乎更倾向于设计出最终一致性的程序。

    作者回复: 嗯。另外,仔细想想,强一致性这种场景真的不多。

    2018-05-17
    2
  • W_T
    按照哈希散列分片,实现方案最简单,只需要在操作数据库的时候特殊处理就可以了。
    按照业务分片,为了减少跨分片操作,在请求的前端就需要明确业务字段的值,所以并不是所有场景都适用,这些方案各有利弊。
    不过有一点我还是赞同的,不到万不得已,不要用哈希散列分片,不然等到以后要重新分片的时候代价巨大。

    作者回复: 业务分片,其实直接就数据分库,服务拆分,走向微服务得了。

    2018-05-17
    2
  • chaoqiang
    请只考虑业务分片。请不要走哈希散列的分片方式
    对这句话不太理解,走哈希分片虽然是有跨表查询隐患,后续数据量再次暴涨也需要重新哈希,比较恶心,但也可以解决热点问题,而且互联网公司的用户数据大部分场景下都是有热点的吧,为什么皓叔这么反对呢?实际场景中会遇到什么更痛的点嘛?能否更详细地讲讲呢
    2018-05-17
    2
  • _CountingStars
    索引表也越来越多大 需要分片怎么办呢

    作者回复: 索引表没有业务属性,就是kv,没有join,没有group,所以非常容易用哈希分片

    2018-05-17
    2
  • edisonhuang
    为了提高性能,有两种拆分数据库的方式,一种是读写分离CQRS,另一种是分库分表。
    读写分离Command and Query Responsibility Separation,保证读服务是无副作用,写操作又可以改进为事件回溯的方式,从而提高系统性能。
    在拆分数据库前应该先做服务拆分,并保证每个服务都有对应的数据库,不同服务间的库通过服务访问的方式来交换数据。
    2019-07-24
  • jacy
    先是读写分离,再扩展到按租户、地域等维度分库,再按时间维度进行分表,按数据进行水平或垂直分片。最后在讲到微服务的数据库设计模式,如当服务对单库,在之上应用之前提到的设计方法,拉近业务。
    2018-10-16
  • 王磊
    新公司用到Postgres的Citus,感觉比较小众,老师怎么看这个技术选型。我们是大数据中心。
    2018-07-27
  • 楼下的小黑
    一致性哈希的问题,个人认为很难绕开。实现通用型nosql数据库,不能根据业务分片。就如文章所说,一致性哈希在扩容时,需要重新整合,需要移动大量数据,成本太大。目前优化,也只是在数据移动时的优化,治标不治本。不知道,有没有其他解决方案
    2018-06-23
  • sipom
    谢谢耗子老师。 我涉及的业务是金融交易的清算(批处理系统),需要保证主从库的数据强一致性,但mysql复制不能保证强一致性,这种情况怎么做为好呢?是在应用层写双库,做两阶段提交?还是有什么产品可用呢?

    作者回复: 业务层上,只有两阶段提交,数据层上,只有Paxos

    2018-06-14
收起评论
12
返回
顶部