MySQL读写分离及主从同步延时问题解决思路深入剖析-综合组件环境实战

1,510 阅读3分钟

本套技术专栏是作者(秦凯新)平时工作的总结和升华,并深度整理大量网上资源和专业书籍。通过从真实商业环境抽取案例进行总结和分享,并给出商业应用的调优建议和集群环境容量规划等内容,请持续关注本套博客。QQ邮箱地址:1120746959@qq.com,如有任何学术交流,可随时联系。

1 MySQL 读写分离机制

  • 单库最高承受的读写能力一般上限为2000/s

  • mysql的读写分离就是根据业务场景设计一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库,这样将一个主库拆分为4个主库,每个主库的写并发就500/s,此时主从延迟可以忽略不计。

1.1 MySQL内核主从同步原理

  • 主库将变更写binlog日志,然后从库连接到主库之后,从库有一个IO线程,将主库的binlog日志拷贝到自己本地,写入一个中继日志(RelayLog)中。接着从库中有一个SQL线程会从中继日志(RelayLog)读取binlog,然后执行binlog日志中的内容,也就是在自己本地再次执行一遍SQL,这样就可以保证自己跟主库的数据是一样的。

1.2 主从复制可能存在的问题

  • 用了mysql主从架构之后,可能会发现,因为延时问题刚写入库的数据结果没查到。

  • 从库同步主库数据的过程是串行化的,也就是说主库上并行的操作,在从库上会串行执行。所以这就是一个非常重要的点了,由于从库从主库拷贝日志以及串行执行SQL的特点,在高并发场景下,从库的数据一定会比主库慢一些,是有延时的。所以经常出现,刚写入主库的数据可能是读不到的,要过几十毫秒,甚至几百毫秒才能读取到。

  • 如果主库突然宕机,然后恰好数据还没同步到从库,那么有些数据可能在从库上是没有的,有些数据可能就丢失了。

1.3 MySQL 主从同步机制

  • 半同步复制(semi-sync复制) --> 用来解决主库数据丢失问题,主库写入binlog日志之后,就会将强制此时立即将数据同步到从库,从库将日志写入自己本地的relay log之后,接着会返回一个ack给主库,主库接收到至少一个从库的ack之后才会认为写操作完成了。
  • 并行复制 --> 指的是从库开启多个线程,并行读取relay log中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。

1.4 使用场景

  • 一般在读远远多于写,而且读的时候一般对数据时效性要求没那么高的时候,用mysql主从同步。

2 主从延迟严重时处理思路

  • 分库,将一个主库拆分为成多个主库,此时主从延迟可以忽略不计
  • 打开mysql支持的并行复制,多个库并行复制,如果说某个库的写入并发就是特别高,单库写并发达到了2000/s,并行复制没意义。
  • 重写代码,写代码要慎重,,插入数据之后,直接就更新,不要查询
  • 如果确实是存在必须先插入,立马要求就查询到,然后立马就要反过来执行一些操作,对这个查询设置直连主库。不推荐这种方法,你这么搞导致读写分离的意义就丧失了。

3 总结

结合大数据在我们工业大数据平台的实践,总结成一篇实践指南,方便以后查阅反思,后续我会根据本篇博客进行代码技术实践实现。

凯新云技术社区