聊聊大厂那些redis

Posted 2020-11-22

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了聊聊大厂那些redis相关的知识，希望对你有一定的参考价值。

集群选举

redis cluster节点间采取gossip协议进行通信，也就是说，在每一个节点间，无论主节点还是从节点，他们之间都是存在相互通信的。例如你的redis端口号是6379，那么你的gossip协议端口号就是16379。

gossip协议包含多种消息，包括ping，pong，meet，fail等等。

ping:每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据；

pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新；

fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

meet:某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信，不需要发送形成网络的所需的所有CLUSTER MEET命令。发送CLUSTER MEET消息以便每个节点能够达到其他每个节点只需通过一条已知的节点链就够了。由于在心跳包中会交换gossip信息，将会创建节点间缺失的链接。

当我们的master节点和其slave节点中断，或和其它节点中断时，也就是连接超过了我们设置的cluster‐node‐timeout的值，这时就会认为我们的当前的master是不可用的，需要选举了，这时将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息到所有节点上（包括其他主从的从节点），其它主节点收到FAILOVER_AUTH_REQUEST信息会给与一个FAILOVER_AUTH_ACK反馈，其它从节点不会有任何反应，当我们的slave收到ACK反馈达到半数以上时，会当选当前选举内的master节点，其它slave节点不在进行选举，作为该新master的slave节点。广播Pong消息通知其他集群节点。

流程大概就是这样的，还有可能每个正在选举的slave节点收到的ACK反馈是一样的，这时再次触发一次选举，currentEpoch再加1，流程和上面一样。这里要注意的是，并不是每个slave都在同一时刻向外发送FAILOVER_AUTH_REQUEST信息的，一般数据较新的节点会先发，数据的新旧由SLAVE_RANK来判断，SLAVE_RANK越小，代表数据越新。

Redis的优化与实际场景

缓存穿透

我们在一般大型的互联网项目查询到的数据，都是查询的缓存内的数据，也就是我们的redis内的数据，但是第一次查询或者说根本不存在的数据，会穿过缓存到达我们的数据库去查询，如果大量这样的请求过来，我们的数据库是扛不住的。这就是我们常说的缓存穿透。处理思路很简单，只要是请求过来的，没有结果。存入缓存设置超时时间，再返回。设置时间是为了保证现在没用到，现在没缓存结果，不代表永远没有缓存结果。

@GetMapping(value = "/")public String getIndex(String goods_id){
    //优先从缓存去拿 String goods =stringRedisTemplate.opsForValue().get(goods_id);
    if (goods == null){
        //如果拿不到去数据库拿 goods = goodsService.getGoodsById(goods_id);//存入缓存,设置超时时间stringRedisTemplate.opsForValue().set(goods_id,goods,300); }returngoods;}

如果是***来了，一直拿不同的缓存来请求我们的项目，这样的思路是不可取的，我们可以使用布隆过滤器来实现阻止缓存击穿问题。

缓存预热

双11要来了，每次双11的0点，会有大批的商品进行交易，如果这些商品不是存在缓存内的，超高的并发（都不用双11，平时的秒杀就够受的），大量的线程会涌入数据库，给数据库造成超大的压力，我们这时应该提前将这些要秒杀的商品，提前存入到redis当中去，防止大批量的请求直接冲进数据库。这就是我们提到的缓存预热。

缓存失效

刚才我们的说了预热，但是我还是需要设置超时时间的时间的，不设置超时时间的话，你的数据库更新了，而我们的缓存还是我们的最开始的数据，造成数据的不一致。假设我们在预热的时候将大量的商品设置为300秒超时的时间，开始秒杀....过了300秒了。还是有一定的并发量，这时所有的缓存都失效了，还是会有大量的请求进入到我们的数据库的，所以说我在设置缓存预热时，不要设置同一个时间结束。会造成大量的缓存在同一时间失效，给我们的后台服务造成巨大压力。

缓存雪崩

有很多项目还是在停留在使用redis单机的状态，如果说redis不在对我们的项目服务了，大量的请求会涌入我们的数据访问层，造成我们的数据库压力超大，甚至数据库宕机，从导致整个服务的不可用状态。或者说我们的并发量远远超过我们的redis吞吐量。也会早成redis的拥塞，其它线程请求redis超时，早成redis假死现象，造成我们的redis雪崩。这时我们应该尽力采用高可用的缓存层架构，比如哨兵，比如集群架构，对于并发量超大的情况我们可以使用限流的方式来控制。

如果说，我们的设置了一个缓存，失效时间为300毫秒，但在失效那一刻，还是高并发的状态，我们的服务器压力还是巨大的，这些高并发的请求进入我们的数据库，后果可想而知，所以我们要在这个热点key的重建过程中，避免大量的请求进入我们的数据库。我们可以这样来做，尝试加一把简单的锁。

@GetMapping(value = "/")public String getIndex(String goods_id) throws InterruptedException {
    //优先从缓存去拿 String goods = stringRedisTemplate.opsForValue().get(goods_id);if (goods == null){//如果拿不到去数据库拿//设置只有一个请求可以进入数据库,其余的线程自旋等待Boolean aBoolean = stringRedisTemplate.opsForValue().setIfAbsent("lock" + goods_id, goods_id, Duration.ofMinutes(3));if(aBoolean){ goods = goodsService.getGoodsById(goods_id);//存入缓存,设置超时时间stringRedisTemplate.opsForValue().set(goods_id,goods,300); }else{//自旋等待50毫秒 Thread.sleep(50);//再次调用该方法,尝试获取数据getIndex(goods_id); } }return goods;}

一些Redis的使用建议

1.建议key设置为服务名:表名或者模块名:表名作为key，便于后期的查找和使用。

2.保证能识别语义的前提下，尽力设置key要简洁，不要过长。

3.不要在key中设置特殊字符，比如空格、换行等字符。

4.redis中不要设置过大的值，一个字符串最大限制512M，但建议一般是要超过10kb大小，list，set，hash，zset不建议超过5000个元素，视情况而定。

5.不要使用keys命令，建议使用scan命令进行替换。

6.建议多使用原生命令，管道等操作尽力减少使用，推荐使用mget，mset这样的命令。

这些优化其实都是围绕着我们Redis的特性，单线程来说的，如果说我们存了一个bigKey或者是一次性塞入了超多的命令，很可能阻塞后面的命令，造成我们的redis假死现象，也会造成我们的网络拥塞，占有了更多的带宽。

Redis的清除策略

1.被动删除:当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key

2.主动删除:由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key

3.当前已用内存超过maxmemory限定时，触发主动删除策略。