图解Redis，Redis更新策略、缓存一致性问题

一、为什么Redis集群的最大槽数是16384个？

2^14^=16384、2^16^=65536。

如果槽位是65536个，发送心跳信息的消息头是65536/8/1024 = 8k。

如果槽位是16384个，发送心跳信息的消息头是16384/8/1024 = 2k。

因为Redis每秒都会发送一定数量的心跳包，如果消息头是8k，未免有些太大了，浪费网络资源。

上面提过，Redis的集群主节点数量一般不会超过1000个。集群中节点越多，心跳包的消息体内的数据就越多，如果节点过多，也会造成网络拥堵。因此Redis的作者Salvatore Sanfilippo不建议Redis Cluster的节点超过1000个，对于节点数在1000个以内的Redis Cluster，16384个槽位完全够用。

Redis主节点的哈希槽信息是通过bitmap存储的，在传输过程中，会对bitmap进行压缩，bitmap的填充率越低，压缩率越高。

bitmap 填充率 = slots / N (N表示节点数)。

也就是说slots越小，填充率就会越小，压缩率就会越高，传输效率就会越高。

二、Redis集群是什么？

由于数据量过大，单个master复制集难以承担，因此需要多个master进行承担工作，每个master存储部分数据，这就是Redis集群。

Redis集群包含多个master，一个master对应多个slave，由于集群自带故障转移机制，因此Redis集群不用再使用哨兵sentinel功能。

Redis Cluster是Redis3.0引入的一种无中心化的集群，客户端可以向任何一个节点通信，不同节点间的数据不互通，Redis Cluster将数据的key通过将CRC16算法的结果取模16383后，分给16384个slot槽，集群的每个节点负责一部分hash槽，节点只负责管理映射到这个槽的KV数据，对于不是当前槽的KV数据，会向客户端发送一个MOVED，表示需要客户端重新重定向到其它节点。

使用Redis集群时，我们将需要存储的数据分配到多台Redis服务器上，称为分片。

数据如何分片？

对key进行CRC16(key)算法处理并通过对总分片数量取模，然后使用确定性哈希函数，将指定的key多次映射到同一个分片上。这种模式下，在进行服务器扩容的时候，不会影响集群的使用状态。

Redis集群不保证强一致性，在特定条件下，Redis集群可能会丢掉一些命令。

三、slot槽位映射的方式

1、哈希取余分区

哈希取余分区的优点是分配均匀，使用hash(key)/3的形式让固定的一部分请求存入指定的master，每台master处理一部分数据，起到了负载均衡的效果。

哈希取余分区最大的缺点就是不方便扩容，当需要扩容时，映射关系需要进行重新计算。

2、一致性哈希算法

（1）一致性哈希算法是什么？

一致性哈希算法在1997年由麻省理工学院提出，是一种特殊的哈希算法，目的是解决分布式缓存的问题。在移除或者添加一个服务器时，能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table，DHT) 中存在的动态伸缩等问题。

一致性哈希算法将整个哈希值空间映射成一个虚拟的圆环，整个哈希空间的取值范围为0~2^32^-1，整个空间按顺时针方向组织，0~2^32^-1在零点中方向重合。

接下来使用如下算法对服务请求进行映射，将服务请求使用哈希算法算出对应的hash值，然后根据hash值的位置沿圆环顺时针查找，第一台遇到的服务器就是所对应的处理请求服务器。

当增加一台新的服务器，受影响的数据仅仅是新添加的服务器到其环空间中前一台的服务器（也就是顺着逆时针方向遇到的第一台服务器）之间的数据，其他都不会受到影响。

综上所述，一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。

（2）一致性哈希算法的优点

可扩展性。
更好的适应数据的快速增长，当某个分片存储数据过多时，可以将其一分为二，不需要对全部的数据进行重新hash计算和划分。

（3）一致性哈希算法的缺点

当服务节点太少时，容易造成数据倾斜，分配不均。

大量的缓存数据集中到了一台或者几台服务节点上，称为数据倾斜。

四、Redis更新策略

1、如果Redis中有数据，需要和数据库中的值相同。

2、如果Redis中无数据，数据库中的最新值要对Redis进行同步更新。

五、Redis读写缓存

1、同步直写策略

写入数据库也同步写Redis缓存，缓存和数据库中的数据一致；对于读写缓存来说，要保证缓存和数据库中的数据一致，就要保证同步直写策略。

2、异步缓写策略

某些业务运行中，MySQL数据更新之后，允许在一定时间后再进行Redis数据同步，比如物流系统。

当出现异常情况时，不得不将失败的动作重新修补，需要借助rabbitmq或kafka进行重写。

六、双检加锁策略

多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它。

其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。

后面的线程进来发现已经有缓存了，就直接走缓存。

publicStringget(Stringkey){
// 从Redis缓存中读取
Stringvalue=redisTemplate.get(key);

if(value!=null){
returnvalue;
    }

synchronized (RedisTest.class){
// 重新尝试从Redis缓存中读取
value=redisTemplate.get(key);
if(value!=null){
returnvalue;
        }

// 从MySQL数据库中查询
value=studentDao.get(key);
// 写入Redis缓存
redisTemplate.setnx(key,value,time);
returnvalue;
    }
}

七、数据库和缓存一致性的更新策略

1、先更新数据库，再更新Redis

按照常理出牌的话，应该都是如此吧？那么，这种情况下，会有啥问题呢？

如果更新数据库成功后，更新Redis之前异常了，会出现什么情况呢？

数据库与Redis内缓存数据不一致。

2、先更新缓存，再更新数据库

多线程情况下，会有问题。

比如

线程1更新redis = 200；
线程2更新redis = 100；
线程2更新MySQL = 100；
线程1更新MySQL = 200；

结果呢，Redis=100、MySQL=200；我擦！

3、先删除缓存，再更新数据库

线程1删除了Redis的缓存数据，然后去更新MySQL数据库。
还没等MySQL更新完毕，线程2杀来，读取缓存数据。
但是，此时MySQL数据库还没更新，线程2读取了MySQL中的旧值，然后线程2，还会将旧值写入Redis作为数据缓存。
线程1更新完MySQL数据后，发现Redis中已经有数据了，之前都删过了，那我就不更新了。

完蛋了。。

延时双删

延时双删可以解决上面的问题，只要sleep的时间大于线程2读取数据再写入缓存的时间就可以了，也就是线程1的二次清缓存操作要在线程2写入缓存之后，这样才能保证Redis缓存中的数据是最新的。

/**
* 延时双删
* @autor 哪吒编程
*/
publicvoiddeleteRedisData(Studentstu){
// 删除Redis中的缓存数据
jedis.del(stu);

// 更新MySQL数据库数据
studentDao.update(stu);

// 休息两秒
try {
TimeUnit.SECONDS.sleep(2);
    } catch (InterruptedExceptione) {
e.printStackTrace();
    }

// 删除Redis中的缓存数据
jedis.del(stu);
}

延迟双删最大的问题就是sleep，在效率为王的今天，sleep能不用还是不用为好。

你不睡我都嫌你慢，你还睡上了…

4、先更新数据库，再删除缓存

线程1先更新数据库，再删除Redis缓存。
线程2在线程1删除Redis缓存之前发起请求，得到了未删除的Redis缓存。
线程1此时才删除Redis缓存数据。

问题还是有，这翻来覆去的，没完没了了。

这种情况如何解决呢？

引入消息中间件解决战斗，再一次详细的复盘一下。

更新数据库。
数据库将操作信息写入binlog日志。
订阅程序提取出key和数据。
尝试删除缓存操作，发现删除失败。
将这些数据信息发送到消息中间件中。
从消息中间件中获取该数据，重新操作。

5、总结

哪吒推荐使用第四种方式，先更新数据库，再删除缓存。

方式①和方式②缺点太过明显，不考虑；方式③中的sleep，总是让人头疼；方式④是一个比较全面的方案，但是增加了学习成本、维护成本，因为增加了消息中间件。

八、MySQL主从复制工作原理

1、当 master 主服务器上的数据发生改变时，则将其改变写入二进制事件日志文件中。

2、salve 从服务器会在一定时间间隔内对 master 主服务器上的二进制日志进行探测，探测其是否发生过改变。

如果探测到 master 主服务器的二进制事件日志发生了改变，则开始一个 I/O Thread 请求 master 二进制事件日志。

3、同时 master 主服务器为每个 I/O Thread 启动一个dump Thread，用于向其发送二进制事件日志。

4、slave 从服务器将接收到的二进制事件日志保存至自己本地的中继日志文件中。

5、salve 从服务器将启动 SQL Thread 从中继日志中读取二进制日志，在本地重放，使得其数据和主服务器保持一致。

6、最后 I/O Thread 和 SQL Thread 将进入睡眠状态，等待下一次被唤醒。

本文转载自微信公众号「哪吒编程」，可以通过以下二维码关注。转载本文请联系哪吒编程公众号。

文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/286115.html<