Redis缓存热点引发的思考

01—背景

 

一开始并没有打算梳理redis的相关内容，因为在一篇文章中看到关于热点问题的处理，心中有一些疑惑，内容如下：

缓存热点：

对于特别热的数据，如果大部分甚至所有的业务都命中同一份缓存数据，则这份数据所在缓存服务器压力就很大，例如，某明星微博发布“我们”来宣告恋爱了，则短时间内有成千上万的用户都来围观。

缓存热点解决方案：

就是复制多份缓存，将请求分散到多个缓存服务器上，减轻缓存热点导致的单台缓存服务器压力，以新浪微博为例，对于粉丝超过100万的明星，每一条微博都可以生成100分缓存，缓存的数据都是一样的，通过缓存key里面加编号进行分区，每次读缓存都随机读取其中某份缓存。

解决思路是没有问题的，是通过备份相同的数据到多台缓存服务器中，缓解分散单台服务器的压力，我的疑惑是"通过缓存key里面加编号进行分区"这种方式是怎么确保使需要保存的数据都分散到不同的服务器呢？redis集群根据key进行hash散列算法，最终映射的是槽位，不同的缓存服务器分别管理的是一些列表槽位，怎么保证通过key计算出来的槽位值正好不在同一台机器上呢？

带着这个疑问点，开始了redis复制，哨兵，集群内容的整理。

  

 

02—内容梳理

 

复制

在分布式系统中，为了解决单点问题，通常会把数据复制多个副本部署到其他的机器，满足故障恢复和负载均衡的需求。哨兵和集群模式都是在复制的基础上实现的高可用。

 

redis复制拓扑极其应用

拓扑结构分为一主一从，一主多从，树状多从结构。

  

1. 一主一从结构

 

应用场景：主节点出现宕机时，从节点提供故障转移支持。

当写命令并发量较高并且需要持久化时，可以在从节点开启AOF，这样既保证了数据的安全也避免了持久化对于主节点的影响。

注意：

当主节点关闭持久化功能，在从节点实现的时候，如果主节点脱机要避免主节点自动重启，因为主节点没有开启持久化功能，自动重启后数据集为空，这时如果从节点继续复制主节点会导致从节点数据也被清空。

解决方案：

在从节点执行slaveof no one断开与主节点的复制关系，再重启主节点避免这种情况。

 

2.  一主多从结构

 

利用多个节点实现读写分离，适用于读占比大的场景，把读命令发送到从节点来分担主节点压力。

日常开发中，执行一些比较耗时的读命令，可以在其中的一个从节点上进行，防止慢查询对主节点造成阻塞   

 

3. 树状主从结构

 

从节点不但可以复制主节点的数据，同时可以作为其他从节点的主节点继续向下层复制。

有效的降低主节点的负载和需要传送给从节点的数据量，降低主节点压力。

 

 <