前十强排名家装公司,抚州网站seo,山东金泰建设有限公司网站,响应式布局的缺点应用场景
假设说有这么一种业务场景#xff0c;读流量显著高于写流量#xff0c;你要怎么优化呢。因为写是要加锁的#xff0c;可能就会阻塞你读请求。而且其实读多写少的场景还很多见#xff0c;比如电商平台#xff0c;用户浏览n多个商品才会买一个。
大部分人的思路可…应用场景
假设说有这么一种业务场景读流量显著高于写流量你要怎么优化呢。因为写是要加锁的可能就会阻塞你读请求。而且其实读多写少的场景还很多见比如电商平台用户浏览n多个商品才会买一个。
大部分人的思路可能是建个缓存来帮助 MySQL 抗住大部分的查询请求。但是这不行因为应用缓存的原则之一是保证缓存命中率足够高不然很多请求会穿透缓存最终打到数据库上。不同用户的请求基本上都不一样。
所以你要考虑优化数据库来抗住高查询请求首先要做的就是区分读写流量区这样才方便针对读流量做单独扩展这个过程就是流量的“读写分离”。这是提升MySQL并发性的首选方案因为当单台 MySQL 无法满足要求时就只能用多个具有相同数据的 MySQL 实例组成的集群来承担大量的读写请求。
模型种类
那如何实现主从复制呢答案如下图所示 在完成主从复制之后你就可以在写数据时只写主库在读数据时只读从库这样即使写请求会锁表或者锁记录也不会影响读请求的执行。但是不是说越多从库越好因为一个从库io线程就需要一个主库log dump线程。所以在实际使用中一个主库一般跟 23 个从库1 套数据库1 主 2 从 1 备主这就是一主多从的 MySQL 集群结构。
同时主从复制有三种模式
主从复制的延迟问题怎么解决呢
比如下面这种情况 最推荐的是使用数据冗余可以在异步调用审核模块时不仅仅发送商品 ID而是发送审核模块需要的所有评论信息借此避免在从库中重新查询数据这个方案简单易实现推荐你选择。但你要注意每次调用的参数大小过大的消息会占用网络带宽和通信时间。 或者加一层缓存读先读缓存然后不行再去从库。但这存在一致性问题。 或者直接查询主库但是要提前明确查询的数据量不大不然会出现主库写请求锁行影响读请求的执行最终对主库造成比较大的压力。
