Redis---包管主从节点同等性问题 +与数据库数据保持同等性问题 ...

包管主从节点同等性问题

Redis的同步方式默认是异步的，这种异步的同步方式导致了主从之间的数据存在一定的延迟，因此Redis默认是弱同等性的。
办理：
1.使用Redisson如许的工具，它提供了分布式锁的实现，确保在分布式情况中锁的精确性。
2.在Redis的配置中，我们可以设置必须有多少个客户端毗连可以或许乐成同步，这就是所谓的同步因子。通过合理配置同步因子，我们可以趋向于强同等性，淘汰主从之间的数据延迟。
3.使用命令 wait 2 0。这个命令会导致从节点等候一段时间来举行同步，但如果时间设置得不当，可能会导致数据同步的问题。因此，在使用这个命令时，我们需要谨慎设置等候时间，以免影响主从之间的数据同等性。
上述提到的“同步因子”和“wait命令”在某种程度上违反了Redis的初志。Redis作为一款高性能的缓存和键值存储系统，其异步的同步方式和弱同等性正是为了寻求更高的性能和吞吐量。如果我们需要更强的同等性，可能需要考虑其他的方案大概重新评估我们的架构设计。
与数据库数据保持同等性问题

如何保障redis和mysql的数据同等？
结论：在满足实时性的条件下，不存在两者完全生存同等的方案，只有最终同等性方案。

• 先写 MySQL，再写 Redis：数据不同等
  
  
  
  
• 先写 Redis，再写 MySQL：数据不同等
  
  
  
  
• 先删除 Redis，再写 MySQL：数据不同等
  
  
  
  
• 先删除 Redis，再写 MySQL，再删除 Redis：这个也是大家常说的“缓存双删”。
  
  
  
  对于蓝色的文字，“删除缓存 10”必须在“回写缓存10”后面，那如何才能包管一定是在后面呢？
  让哀求 A 的最后一次删除，等候 500ms。----太 Low 了，风险也不可控
  异步串行化删除，即删除哀求入队列----缓存删除失败，增长重试机制。可以借助消息队列的重试机制，也可以自己整个表，记录重试次数，
  
  
  
  
• 先写 MySQL，再删除 Redis
  
  
  
  
• 先写 MySQL，通过 Binlog，异步更新 Redis
  
  
  
  这个方案，会包管 MySQL 和 Redis 的最终同等性，但是如果中途哀求 B 需要查询数据，如果缓存无数据，就直接查 DB；如果缓存有数据，查询的数据也会存在不同等的情况。
  以是这个方案，是实现最终同等性的终极办理方案，但是不能包管实时性。
  

我们对比上面讨论的 6 种方案：

• 先写 Redis，再写 MySQL：这种方案，我肯定不会用，万一 DB 挂了，你把数据写到缓存，DB 无数据，这个是灾难性的；我之前也见同学这么用过，如果写 DB 失败，对 Redis 举行逆操作，那如果逆操作失败呢，是不是还要搞个重试？
  
• 先写 MySQL，再写 Redis：对于并发量、同等性要求不高的项目，很多就是这么用的，我之前也经常这么搞，但是不建议这么做；当 Redis 瞬间不可用的情况，需要报警出来，然后线下处理。
  
• 先删除 Redis，再写 MySQL：这种方式，我还真没用过，直接忽略吧。
  
• 先删除 Redis，再写 MySQL，再删除 Redis：这种方式虽然可行，但是感觉好复杂，还要搞个消息队列去异步删除 Redis。
  
• 先写 MySQL，再删除 Redis：比力保举这种方式，删除 Redis 如果失败，可以再多重试反复，否则报警出来；这个方案，是实时性中最好的方案，在一些高并发场景中，保举这种。
  
• 先写 MySQL，通过 Binlog，异步更新 Redis：对于异地容灾、数据汇总等，建议会用这种方式，比如 binlog + kafka，数据的同等性也可以到达秒级；纯粹的高并发场景，不建议用这种方案，比如抢购、秒杀等。
  

实时同等性方案：采用“先写 MySQL，再删除 Redis”的策略，这种情况虽然也会存在两者不同等，但是需要满足的条件有点苛刻，以是是满足实时性条件下，能只管满足同等性的最优解。
最终同等性方案：采用“先写 MySQL，通过 Binlog，异步更新 Redis”，可以通过 Binlog，结合消息队列异步更新 Redis，是最终同等性的最优解。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。