14 | 高性能数据库集群：读写分离
2018-05-29 李运华
《从 0 开始学架构》
课程介绍
讲述：黄洲君
时长:大小4.31M
“从 0 开始学架构”专栏已经更新了 13 期，从各个方面阐述了架构设计相关的理论和流程，包括架构设计起源、架构设计的目的、常见架构复杂度分析、架构设计原则、架构设计流程等，掌握这些知识是做好架构设计的基础。
在具体的实践过程中，为了更快、更好地设计出优秀的架构，除了掌握这些基础知识外，还需要掌握业界已经成熟的各种架构模式。大部分情况下，我们做架构设计主要都是基于已有的成熟模式，结合业务和团队的具体情况，进行一定的优化或者调整；即使少部分情况我们需要进行较大的创新，前提也是需要对已有的各种架构模式和技术非常熟悉。
接下来，我将逐一介绍最常见的“高性能架构模式”“高可用架构模式”“可扩展架构模式”，这些模式可能你之前大概了解过，但其实每个方案里面都有很多细节，只有深入的理解这些细节才能理解常见的架构模式，进而设计出优秀的架构。
虽然近十年来各种存储技术飞速发展，但关系数据库由于其 ACID 的特性和功能强大的 SQL 查询，目前还是各种业务系统中关键和核心的存储系统，很多场景下高性能的设计最核心的部分就是关系数据库的设计。
不管是为了满足业...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
海。2018-05-30老师，您好
我个人的想法是可以加入缓存，例如注册后登录这种业务，可以在注册后加入数据库，并加入缓存，登录的时候先查缓存再查库表。
例如存入redis中并设置十分钟的过期时间。登录的时候先查redis，再查库表，如果redis中没有，说明就是过期的数据，这时候查从机就肯定存在了，希望能得到老师的点评，谢谢。作者回复: 赞同，并不是说一有性能问题就上读写分离，而是应该先优化，例如优化慢查询，调整不合理的业务逻辑，引入缓存等，只有确定系统没有优化空间后，才考虑读写分离或者集群
共 6 条评论203
tangfengr2018-07-19我认为读写分离适用单机并发无法支撑并且读的请求更多的情形。在单机数据库情况下，表上加索引一般对查询有优化作用却影响写入速度，读写分离后可以单独对读库进行优化，写库上减少索引，对读写的能力都有提升，且读的提升更多一些。
不适用的情况:1如果并发写入特别高，单机写入无法支撑，就不适合这种模式。
2 通过缓存技术或者程序优化能够满足要求作者回复: 赞同👍
共 6 条评论95
LONGER2018-06-05目前还在用单机一直在扛着，目前数据量在百万万，在不停的优化，建立冗余等方式，还在保持着一个较快的查询速度，因为业务查询的关系，多表之间的关联，聚合，很难避免，一直想引用缓存，但是查询的条件太多，很动态，就不知道如何设计缓存，类似于京东筛选物品，多品类，多维度筛选，不知道大牛有何高见作者回复: 按照2-8原则，选出占访问量80%的前20%的请求条件缓存，因为大部分人的查询不会每次都非常多条件，以手机为例，查询苹果加华为的可能占很大一部分
共 2 条评论65
lee2019-01-23SQL优化——缓存——读写分离——分库分表共 1 条评论44- 性能2018-06-03我们做网银系统，用redis存了一些不太重要的数据，比如数据字典信息，作为缓存。但是不太敢把用户权限，交易数据等重要信息存在缓存里，因为redis并不保证事务，我们担心一旦缓存服务器宕机或者失败会影响银行业务。所以缓存的作用也不是很大，还是把大部分读数据的压力放到了数据库上，您说我们这种担心有必要吗？如果单库后续扛不住压力，是否读写分离比加缓存更好一些？
作者回复: 交易型业务缓存应用不多，缓存一般总在查询类业务上，你们的担心有一定必要
共 3 条评论40 
侯海佳2018-05-29我认为读写分离适合类似微博这种业务：读多写少19
narry2018-05-29个人感觉，读写分离适合读压力比写压力大很多的业务类型，最终的瓶颈应该是出现在承担写操作的主机上，最大规模和这台主机的iops等能力相关19
richey2018-06-26TDDL已经长期不更新了，老师怎么不提一下Mycat共 1 条评论17
彡工鸟2018-05-30是否还应该加上一个，当单机写顶不住压力后，就可以做数据库拆分了，例如业务纵向拆分，连同数据库一起，就变成分布式服务，微服务了:)作者回复: 说法没错，但具体实施的时候要注意，不要一有压力就上读者分离，因为很多时候其实是sql语句或者业务逻辑有问题，因此先优化，只有优化后也无法满足要求的时候才考虑读者分离或者集群
16
小喵喵2018-06-03公司现在的系统时采用读写分离的，是中间层程序封装的api，第一套分两类:1读主库,2.读从库.然后客户端程序通过传递SQL或存储过程和参数的值调用。
第二套只提供一个api,通过传递一个布尔值来判断是走主库还是从库，这套是供自动调度工具来调用。这两套api都有一个共同点，就程序猿必须手动指定是走主库还是从库。现在出现的问题是大量的SQL应该走从库，结果很多菜鸟都走了主库，导致现在的主库压力很大。听了你的课程后觉得走主库还是从库不应该由程序猿自己指定，而是由中间层来判断。具体如何做呢，请老师指点一下。客户端有时传递一些复杂的SQL,比如，先做更新然后再查。作者回复: 默认读走从库，写走主库，特殊情况才由程序员制定，可以代码指定，可以配置指定，这样就不会出现大量sql都走主库了
共 2 条评论13
Up2018-05-31读写分离，主从架构，顾名思义，写不变，主要解决高性能读的问题，所以适用场景自然是读多写少的情况。比如类似于博客、中小型朋友圈，这种一般写数据库后基本不变，但是很多人会去访问，频繁的读。我认为如果缓存能支撑的话就没必要上读写分离，相对来说缓存更简单。12
云学2018-05-29相比于前面的几篇高大上文章，这篇更接地气11
rubin2018-05-30读写分离的前提是并发量大，单机已经不能处理该数量的并发请求了，想要解决问题就得做作拆分，于是有了读写分离，主库负责写，从库负责读，降低了同台机器并发请求，当读越来越多时，可扩充从库，写越来越多时，只好拆分业务或分库分表，如：注册功能，单独出来做一个注册的微服务，但还是会到达一个瓶颈，没做过，不知道能支持多少的并发？作者回复: 要具体测试，不同业务复杂度不同
10
刘岚乔月2018-05-29请问 对于主从出现的数据同步延时问题 在实际生产落地 真的只有把重要的查询指向主吗 还有其他真正的落地方案吗作者回复: 当然是真的呀，难道我还会骗你不成？😂
如果不想用这种方式，用缓存是可以规避这个问题的，但其实这时候的方案就不是读写分离了共 2 条评论9
spoofer2019-12-18前段时间，老大在大表上执行了delete操作，然后主从就不同步了。然后线上各种bug，最后我花了5分钟排查到了问题（运维团队比较小，我打杂的）。解决方式，线上业务部分限流，关键业务读写紧急切换到主库，修复主从不同步问题，切换回读写分离配置。最后发现是老大做了骚操作，一问才知道，是个日志表，清理一下。😂我。。。作者回复: 我们要求线上delete每次不能超过1000条，超过就定时循环操作
共 3 条评论8
老邪2018-07-19你好，华仔，请问文章内的架构图用的什么软件，谢谢！作者回复: Libre office的Draw
共 2 条评论8
@漆~心endless2018-05-31并非所有系统都需要进行读写分离，正如之前讲得架构三原则，其中根据“合适原则”的规定，先确认系统的业务量是否出现了数据库的性能问题。如果是，首先通过优化MySQL语句等，如果还是达不到要求的性能指标，则需进行读写分离。毕竟读写分离会引入一系列不可预知的问题，如数据不同步。8
allen.huang
2018-08-14老师您好，
像我们数据库服务器只有一台，并且现在业务量也越来越大，尤其是中午，晚上加起来大概是5，6个小时是业务高峰，订餐的量还挺大。前台读写操作都很频繁，
后来就是要看数据统计啊之类的，客户也是经常在使用。在业务高峰期，他们还要进去看实时交易情况。这样子经常会出现磁盘IO报警。
我也在尝试规划做读写分离，但是像业务前台做了以后，就会出现数据延时的情况，这样子业务处理就有问题。
我现在初步规划是前台都用主，后台读写分离，这样子是否合理，有经验的同学也给予我指导谢谢😜展开作者回复: 面向用户的业务读写都用主，面向客户和运营的业务可以读写分离，大部分场景没必要看实时交易情况的
7
刘志刚2018-05-29读写分离比较适用于类似消息记录，对于写和读业务的强实时性要求不到苛刻的地步的情况，而且做的时候这种跟业务量还是有比较大关系的，比如，业务量的订单量每年都不超过1千万，整天去做分库分表倒不如好好优化下sql写法，如果订单量每天都超过好几百万，那这个必要性就很强了！作者回复: 赞，先优化
共 2 条评论6- null2018-05-29re: 写操作后的读操作指定发给数据库主服务器
后端无法知道本次请求是否为写操作之后的读，因此会依赖前端传递一个参数，如 target_db=master / slave，来决定目标数据库。
所以这种方式，需要在前后端代码实现相关逻辑，代码耦合较大。
这种解决方案是否只提供了一种思路，实际开发时很少使用这方案，不知道理解是否正确，谢谢！展开作者回复: 是的，对代码逻辑有要求，
6