保证主从节点一致性问题
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，是最终一致性的最优解。
