MySQL读写分离原理

  • 业务上的层级拆分:关联查询如何进行跨库的查询?
  • image-20191013154750579

image-20191013155018982

  • 主从复制,数据不一致问题
    • 第三方插件,半同步
  • 一主一从,并不能提高程序的性能,但是能容灾,mater 挂了,slave 顶上。不需要考虑数据一致性问题,因为 slave 只是用来做备份的

作者:Gary Chen

读写分离指的是,通过增加一些节点,扩展读的能力。这些节点可以是主节点的全部内容的副本或者部分内容的副本,也可以是缓存产品。读写分离一般配合负载均衡产品使用。

对于读多写少(非更新查询为主)的负载,特别适合做读写分离。你需要留意的是,保证用户感知到自己所做的变更生效即可,用户很多情况下并不需要知道其他用户的改变。如果用户对于数据的一致性要求在某个时刻高,那么这部分数据,建议不要使用读写分离,MySQL的复制可能出现延时,无法满足业务需要。你可以采取变通的方式,比如,在用户修改了内容后,临时强制用户访问主节点,以获取一致性的数据,在过一段时间后,再让用户访问副本的数据,一般在此时,副本的数据已经同步到最新状态了。

读写分离往往和负载均衡技术配合使用。负载均衡软硬件产品有F5、Haproxy以及一些自己设计的MySQL Proxy代理等,负载均衡可以更高效的利用硬件,你可以设置权重,分配更多的流量给性能更好的机器,负载均衡产品一般还有故障检测、自动冗余切换功能,这可以大大提高你的可用性。

读写分离技术的一个难点在于延时的影响,你需要有一个手段确保你没有读取到太旧的数据,写操作和一些不能容忍延时的查询,需要指向主库。对于数据延时敏感度不高的数据,你需要定义延时的阈值,通过自动或者手工的方式处理延时数据对于用户体体验的影响。

你可以通过监控SHOW SLAVE STATUS里的输出Seconds_behind_master的方式判断是否有延时,但这种方式不太可靠。监控复制滞后(replication lag)的更稳健的方式是通过心跳表的方式。

我们很难确保MySQL的延时,因为网络波动、复制异常、性能问题都可能导致复制中断,而往往需要人工来进行干预,毕竟有能力开发专用的Proxy代理的公司很少,所以,不建议使用读写分离,采用读写分离是基于一个前提,主库已经出现读瓶颈,如果出现读瓶颈,使用缓存一般是更有效、更成熟的解决方案。

由于没有好的读写分离的方案,如果你一定要使用读写分离,推荐应用程序自身实现读写分离,把读的流量指向负载均衡产品或者Proxy代理。

读写分离,又往往和拆分数据有关联。部分数据更适合读写分离,部分数据更适合拆分。对于一致性要求很高的数据,往往很难以去拆分,使用读写分离保证适当的用户体验更可取。 如果一定要拆分,很可能导致架构、运维异常复杂。 在做数据架构的时候,要清楚数据的用户,细分各种数据,针对各种数据,进行各种处理,确保异常情况下的可用、可恢复,而不是简单的考虑 读写分离、水平扩展、垂直扩展这些更简单的分解。

https://zhuanlan.zhihu.com/p/24698266

发布了191 篇原创文章 · 获赞 17 · 访问量 6万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览