企业官网建设流程全解析

建设部颁发的证书网站,hao123网址怎么删除,广东的网站备案,马鞍山的网站建设公司哪家好文章目录引言Redis主从架构Redis主从数据同步延迟很大的常见原因复制积压堆积BigKey网络与硬件解决方法关键业务强制读主 (Read from Master)使用 WAIT 命令 (强一致性折衷,不推荐)业务层校验 版本号 或 时间戳杜绝BigKey等总结引言 大家好啊#xff…文章目录引言Redis主从架构Redis主从数据同步延迟很大的常见原因复制积压堆积BigKey网络与硬件解决方法关键业务强制读主 (Read from Master)使用 WAIT 命令 (强一致性折衷,不推荐)业务层校验 版本号 或 时间戳杜绝BigKey等总结引言大家好啊今天给大家带来一个面试常问题redis主从数据同步延迟担心从节点读到脏数据怎么办Redis 主从复制默认是异步的这意味着在 CAP 理论中Redis 默认保证的是AP可用性 分区容错性而不是 CP强一致性。因此主从延迟导致的“读脏数据”Stale Data在理论上无法完全避免只能通过业务策略或技术手段来缓解Redis主从架构要先弄明白为什么redis主从架构会出现脏数据读我们才能想出对应的缓解之策。举一个栗子redis一主二从架构主节点负责变更数据然后同步给从节点。从节点负责读数据。因此从这样的架构来说出现脏数据读从理论上说是不可避免的因为主从节点数据同步无法做到零延迟。Redis主从数据同步延迟很大的常见原因复制积压堆积主节点每秒处理大量写操作如高频 SET、INCR、LPUSH 等产生大量复制流从节点消费速度跟不上主节点生产速度导致复制积压堆积。lave0/slave1的offset与主节点master_repl_offset的差值就是是否复制积压堆积的标准。若差值持续增大说明复制追不上。BigKeyRedis的BigKey传输是导致主从延迟最常见的原因。Master 传输一个几十 MB 的 List 或 Hash 给 Slave网络被占用解析被阻塞导致后续命令瞬间堆积延迟。网络与硬件同局域网:确保主从在同一机房/局域网跨公域网同步延迟极大。机器负载:检查 Slave 节点的 AOF 重写Rewrite或 RDB 生成是否导致 CPU 飙升阻塞了主线程的同步回放解决方法我从业务容忍度、代码逻辑和运维配置三个层面来解决这个问题。关键是不要试图全局解决“0延迟”而是根据数据敏感度拆分策略。关键业务强制读主 (Read from Master)这是最简单且最有效的方案。对于必须准确的数据不要走读写分离的逻辑直接路由到 Master 节点。比如余额库存扣减订单状态等等。在Java中可以类似这样写if(isCriticalData){redisTemplate.opsForValue().get(key);// 配置为主库连接}else{redisReadReplicaTemplate.opsForValue().get(key);// 配置为从库连接}使用WAIT命令 (强一致性折衷,不推荐)Redis 支持WAIT命令它可以阻塞当前写操作的客户端直到写操作被同步到指定数量的从节点。命令:WAIT numreplicas timeout逻辑:只有当至少numreplicas个从节点确认接收到写操作后Master 才会返回成功。代价:严重牺牲写性能。如果从节点故障或网络抖动写操作会阻塞直到超时。适用:极其重要且写频率较低的数据业务层校验 “版本号” 或 “时间戳”如果你必须读从库但又想知道数据是否过期写入时:在 Value 中写入一个时间戳或版本号v1。另外存储:将该 Key 的最新版本号v1存入一个高可用的缓存如 Zookeeper、Etcd 或 Redis Master 的一个专用 Key。读取时:读取从库数据对比其中的版本号与 Master/中心存储的版本号。如果不一致说明延迟了触发回源读主库杜绝BigKey等还有很多策略比如代码层我们要拆分bigkey监控主从复制偏移量等等总结我们要根据业务敏感度来解决这个问题根据数据敏感度来拆分策略场景示例推荐策略强一致性余额、库存扣减、订单状态强制读主库 (Master)最终一致性用户昵称、非实时排行榜、历史记录读从库 监控/重试高敏感度秒杀资格、配置开关使用WAIT命令或分布式锁最高优先级:梳理业务。将必须强一致的读请求如金额在代码层面指定直接读 Master。这是最稳妥的。次优先级:检查是否有BigKey阻塞了同步链路。可选策略:如果必须读从库且要求较高一致性实现一个简单的监控熔断机制通过 Java/Go 定时检查 Offset自动隔离高延迟的从节点