架构实战(5)——读写分离的那点事儿

什么是读写分离?

读写分离就是将数据库分为主库和从库,一个主库专用于写入数据,一个或多个从库用于读数据。主库和从库通过某种机制进行数据的同步。


读写分离能解决什么问题?

在互联网应用中,对数据库的操作普遍存在的问题是写少读多,数据的读取是性能瓶颈。通过引入从库,分担数据库读的压力,提升应用的并发访问能力。总结一下,读写分离解决的是数据库的读性能问题

典型的应用场景:

主从库差异化的性能优化

  • 主从库采用不同的数据库引擎。Innodb是支持事务的,适合作为写库;而读库不需要事务,可使用MyISAM。
  • 主从库创建不同的索引。索引对可以提示读的性能,却会降低写的性能。可以在从库上创建差异化的索引,提升读性能。
  • 主从库差异性的参数优化。

线上库和分析库的分离

很多互联网应用,一方面要在线上对客户提高可用的服务,另一方面也要满足线下运营部门的功能需求。线上的特点是查询简单、并发高;线下的特点是查询复杂、并发低。如果运营部门的查询需求,和线上应用一个从库,一些复杂的查询,就可能导致数据库的雪崩效应。针对这样的应用场景,提供两个从库,一个服务于线上,一个服务于线下,并根据不同的应用场景,做相应的优化。

延时备份

一般的做法是,创建一个延时从库,如果某个不小心的程序员,执行了一个删除命令,发现问题后,立即切断延时从库的同步,并且切换成主库,这样就能快速的恢复应用了。延时备份主要解决的是在发生故障的时候,能够快速恢复服务,并且尽量减少客户数据的丢失。

数据同步的原理是什么?

  • step1:主库的数据变动,逐条保存到binlog日志文件中。
  • step2:从库的IO线程,读取主库的binlog日志文件,把binlog写入从库的relaylog日志文件中。
  • step3:从库的SQL线程,读取已经同步过来的relaylog,逐条执行binlog,完成数据的同步。

从这个过程中可以看出,同步是异步的,即使网络的延迟非常小,主从库的同步无法避免延迟。另外,从库不能主动的去修改,只能从主库同步。

如何解决主从延迟?

正常的延迟应保持在100ms以内,20ms左右是比较理想的。但是,程序员用到主从库,心里就要有个意识,延迟随时可能发生,甚至会非常严重,在程序设计与开发的时候,要考虑到这个因素。

场景1:写后立即读。在一个请求中,写入数据后,立即数据库中读取数据。这种读的场景,写入和读取的时间间隔小于1ms,比正常的主从延迟时间更短,解决方案就是强制读主库

场景2:读后写。这种典型场景就是insertOrUpdate,不存在插入,存在就更新。如果两个请求的时间间隔小于主从延迟的时间间隔,第二次的请求因为读不到,就会执行insert。当然可以用强制读主库的方式解决问题,但是这样增加了主库的读压力。正确的解决方案是分布式锁+缓存

  • step1:加分布式锁。防止同时对一条记录操作。
  • step2:缓存中读数据。如果读到数据,执行step4。如果读不到数据,执行step3。
  • step3:从库中读数据。
  • step4:写库。
  • step5:写缓存。设置缓存的有效期,缓存的有效期,即为允许的主从最大延迟时间。

持续分享IT互联网相关的知识点,欢迎关注我。

发表评论
留言与评论(共有 0 条评论)
   
验证码:

相关文章

推荐文章

'); })();