Redis的重点理论知识点

文章目录

Redis的重点理论知识点

一、Redis是单线程吗?

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外
提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其

实是由额外的线程执行的。

二、Redis 单线程为什么还能这么快?

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。

三、Redis 单线程如何处理那么多的并发客户端连接？

Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

四、分布式存储如何存储(三种方法)?

1) 哈希取余分区

优点 : 简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台、8台、10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。

缺点 : 原来规划好的节点，进行扩容或者缩容就比较麻烦了额，不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化：Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。

某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

2) 一致性哈希算法分区

优点:

容错性:

假设Node C宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据，并且这些数据会转移到D进行存储。
扩展性:

数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那收到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，

不会导致hash取余全部数据重新洗牌。

缺点:

数据倾斜:

一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，

例如系统中只有两台服务器：

3) 哈希槽分区

解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。

一个集群只能有16384个槽，编号0-16383（0-2^14-1）。这些槽会分配给集群中的所有主节点。

五、Redis集群原理分析

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每
个节点中。
当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这
样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不
一致的情况，还需要纠正机制来实现槽位信息的校验调整

HASH_SLOT = CRC16(key) mod 16384

六、Redis集群节点间的通信机制

redis cluster节点间采取gossip协议进行通信

集中式:

优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数
据的存储压力。很多中间件都会借助zookeeper集中式存储元数据。
gossip：

gossip协议包含多种消息，包括ping，pong，meet，fail等等。
meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通
信；
ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过
ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)；
pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新；
fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上
去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

七、缓存穿透

缓存穿透就是查询一些根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层。

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。

1）造成缓存穿透的基本原因有两个：

第一，自身业务代码或者数据出现问题。
第二，一些恶意攻击、爬虫等造成大量空命中。

2）缓存穿透问题解决方案：

String get(String key) {
    
    
 	// 从缓存中获取数据
 	String cacheValue = cache.get(key);
 	// 缓存为空
 	if (StringUtils.isBlank(cacheValue)) {
    
    
	 // 从存储中获取
		String storageValue = storage.get(key);
 		cache.set(key, storageValue);
     // 如果存储数据为空， 需要设置一个过期时间(300秒)
	 if (storageValue == null) {
    
    
	 	cache.expire(key, 60 * 5);
	 }
	 return storageValue;
	 } else {
    
    
	 // 缓存非空
	 return cacheValue;
 	}
 }

八、缓存击穿

由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间

1）缓存穿透问题解决方案：

String get(String key) {
    
    
     // 从缓存中获取数据
	 String cacheValue = cache.get(key);
	 // 缓存为空
	 if (StringUtils.isBlank(cacheValue)) {
    
    
 	// 从存储中获取
	 String storageValue = storage.get(key);
	 cache.set(key, storageValue);
	 //设置一个过期时间(300到600之间的一个随机数)
	 int expireTime = new Random().nextInt(300) + 300;
 	if (storageValue == null) {
    
    
 		cache.expire(key, expireTime);
	 }
 	return storageValue;
 	} else {
    
    
 	// 缓存非空
	 return cacheValue;
	 }
 }

九、缓存雪崩

缓存雪崩指的是缓存层支撑不住或宕掉后，流量会像奔逃的野牛一样，打向后端存储层。由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不能提供服务(比如超大并发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降)，于是大量请求都会打到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。

1）预防和解决缓存雪崩问题

保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

十、热点缓存key重建优化

开发人员使用“缓存+过期时间”的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害：

当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

要解决这个问题主要就是要避免大量线程同时重建缓存。

我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

String get(String key) {
    
    
	 // 从Redis中获取数据
	 String value = redis.get(key);
 	// 如果value为空， 则开始重构缓存
 	if (value == null) {
    
    
		 // 只允许一个线程重建缓存， 使用nx， 并设置过期时间ex
		 String mutexKey = "mutext:key:" + key;
 	if (redis.set(mutexKey, "1", "ex 180", "nx")) {
    
    
 		// 从数据源获取数据
 		value = db.get(key);
 		// 回写Redis， 并设置过期时间
 		redis.setex(key, timeout, value);
 		// 删除key_mutex
		 redis.delete(mutexKey);
 	}// 其他线程休息50毫秒后重试
 	else {
    
    
     	Thread.sleep(50);
 		get(key);
 	}
 }
 return value;
}

十一、缓存与数据库双写不一致

在大并发下，同时操作数据库与缓存会存在数据不一致性问题

1）双写不一致情况

2）读写并发不一致

3）解决方案

1、对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
2、就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
3、如果不能容忍缓存数据不一致，可以通过加读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
4、也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。

bigkey的危害：

1）导致redis阻塞

2）网络拥塞

bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问
量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务
器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey
可能会对其他实例也造成影响，其后果不堪设想。

3）过期删除

有个bigkey，它安分守己（只执行简单的命令，例如hget、lpop、zscore等），但它设置了过
期时间，当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-
expire yes)，就会存在阻塞Redis的可能性。

不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注
意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞）