项目中遇到通过使用路由策略实现主从数据库访问数据不同步的问题

1.问题的关键在于,主从架构是一种用于数据容错的高可用性解决方案,而不是一种处理高并发压力的解决方案。
它的目的是主机宕机以后备机可以马上顶上,而不是让备机来分担并发压力。完全同步机制也只是用于保证主机宕机以后数据不会丢失,
而不是保证从备机读取数据时的一致性。因此,我根本也不主张你使用从备机读取数据以分担并发压力这种方式。

2.主机与备机之间的物理延迟是不可控的,也无法避免。但是这种强一致性可以实现:mysql5.6官方开始支持。
只需要在主机写入时,确认更新已经同步到备机之后,再返回写操作成功即可。主流数据库均支持这种完全的同步模式。
显而易见,如果写操作必须等待更新同步完成,肯定会极大地影响性能,除非你不在乎性能。

技术层面的解决方式是:不要试图在数据库层解决并发的读操作问题,至少不要在主从架构的数据库层解决。
要在数据库层之上架构一个redis这样的分布式缓存来解决,它是专门干这个的。其性能肯定远高于从备机读取数据。
业务层面的解决方法是

     a).有更新数据后的 读取相关数据动作,都从默认到主库(需要读写强一致性的业务,要强行将读语句路由至Master库);
     b).利用缓存;插入新的数据,使用数据库的存储过程返回插入的id,组装成数据,缓存到前端。读取此 id 数据时,先从缓存取(仅限于id字段)。或者这样插入新数据后将新数据加入到缓存,读缓存。

     c).为Slave库增加浮动IP,并通过脚本检测Slave库的延迟,延迟大于指定阈值时,将浮动IP切换至Master库,追平后再切换回Slave

你可能感兴趣的:(项目中遇到通过使用路由策略实现主从数据库访问数据不同步的问题)