产品中心
前言：
我们都知道互联网数据有个特性，大部分场景都是 读多写少，比如：微博、微信、淘宝电商，按照 二八原则，读流量占比甚至能达到 90%。
结合这个特性，我们对底层的数据库架构也会做相应调整。采用 读写分离。
处理过程：
看似非常合理，细想却不是那么回事。
主库 与 从库 是采用异步复制数据，如果这两者之间数据还没有同步怎么办?
主库刚写完数据，从库还没来得及拉取最新数据，读 请求就来了，给用户的感觉，数据丢了?
针对这个问题，今天，我们就来探讨下有什么解决方案?
针对不用的业务诉求，区别性对待。
场景一：
如果是对数据的 实时性 要求不是很高，比如：大V有千万粉丝，发布一条微博，粉丝晚几秒钟收到这条信息，并不会有特别大的影响。这时，可以走 从库。
场景二：
如果对数据的 实时性 要求非常高，比如金融类业务。我们可以在客户端代码标记下，让查询强制走主库。
由于主从库之间数据同步需要一定的时间间隔，那么有一种策略是延迟从从库查询数据。
比如：
高并发系统，缓存作为性能优化利器，应用广泛。我们可以考虑引入缓存作为缓冲介质。
处理过程：
缺点：
K-V 存储，适用一些简单的查询条件场景。如果复杂的查询，还是要查询从库。
参考 Redis Cluster 模式， 集群网络拓扑通常是 3主 3从，主节点既负责写，也负责读。
通过水平分片，支持数据的横向扩展。由于每个节点都是独立的服务器，可以提高整体集群的吞吐量。
常见的解决方式，是分库分表，每次读写都是操作主库的一个分表，从库只用来做数据备份。当主库发生故障时，主从切换，保证集群的高可用性。
到此这篇关于分享MySQL 主从延迟与读写分离的七种解决方案的文章就介绍到这了,更多相关MySQL主从延迟读写分离解决方案内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
