• 1、先删除缓存；
• 2、再写数据库；
• 3、

先说结论：不是普通Hash不行，是分布式场景下它太脆弱！

你以为取模就够了？Redis集群扩容时，数据重分布的噩梦才刚刚开始！

1、实现强一致性

读操作时：

写操作时：

两次删除缓存在更新缓存，是为了预防其他线程查询缓存未命中时再一次写入了缓存。

在第二次删除缓存时，需要延时以下，是由于数据库可能存在主从数据需要同步，但是延时多少时间不好确定，为了解决这个问题，可以用以下读写锁方案实现强一致：

对于读操作：使用redisson的读写锁，获取读锁，读完数据释放锁。其他线程可以共享读操作，对于写是不行的

前言

以存储为例，在整个微服务系统中，我们的存储不可能说只是一个单节点。

一是为了提高稳定，单节点宕机情况下，整个存储就面临服务不可用；

二是数据容错，同样单节点数据物理损毁，而多节点情况下，节点有备份，除非互为备份的节点同时损毁。

1. 写在前面

周末就像太阳，总会到来，也总会离开。

昨晚在B站看了几个长视频，导致2点才睡觉，早上一觉醒来已经10点了。

一致性hash算法是，1097麻省理工提出的分布式hashDHT实现算法，极倔internet的热点问题

平衡性 hash结果尽可能的分布到所有的缓存中去，缓冲空间利用率最高

单调性 保持已有的缓存能映射到对应的位置，新加入的缓存能加入新的位置不会映射到旧的位置

分散性 尽量降低分散性的缓存不一致情况发生

负载 负载被粉丝降低负荷