vlambda博客
学习文章列表

首先恭祝大家新年好，各个看文的大佬们恭喜发财、身体健康。没想到这么快过年了。不知道看文的大家过的如何，不管好不好，希望大家能越过越好。

关于本文的吐槽。我是没想到写出来的量这么少，只有4k字。大家凑合下吧。可能就是分布式锁那里我挺纠结要不要讲一下更多的细节。比如他的场景啥的。下一篇我要开始写Nginx还是ES数据库都说不好，或者会先说MQ，最近工作碰到了一个MQ问题，虽然不是我处理。但是也是上了一课，也觉得要好好整理一下。（随缘好了~）

本文概要：

    知识点都是来自各博主文章整理，自己写一遍做一遍笔记比单纯看要理解吸收都更好。所以才会有这样的笔记。

    本文只涉及RedisCluster集群、Redis常见问题、过期策略、淘汰策略、分布式锁的一些知识笔记

---

Redis高可用

Cluster集群

前身

Redis Sharding

非官方的分布式存储Redis的数据

使用方式

采用哈希算法将Redis数据的key进行散列。通过hash函数，特定的key会映射到Redis节点上。

优点

所有逻辑都是可控的，不依赖于第三方分布式中间件，配置简单。服务端Redis之间没有关联

缺点

客户端无法动态增删服务节点，客户端需要自行维护分发逻辑，维护性差。

示例

Client	客户端路由规则	Redis1	存放key1的值
		Redis2	key2
		Redis3	key3

（key值都是通过hash算法得出的）

---

Codis

大概了解下即可

对上层应用来说，连接Codis Proxy和连接原生的Redis Server没有明显区别（不过不支持命令列表）。上层应用可以像使用单机的Redis一样使用，Codis底层会处理请求的转发，不停机的数据迁移工作。

人话来说 就是 Client连接的服务器实际上是一个内存无限大的Redis服务。（不过依赖于第三方中间件）

优点

实现了上层Proxy和底层Redis的高可用，数据分片和自动平衡，提供命令接口和RESTful API，提供监控和管理页面，可以动态添加和删除Redis节点。

缺点

部署架构和配置复杂，并且因为是Redis先升级了这家伙还能开发升级的工具。所以该中间件的官方效率很低。

   

---

Cluster来源版本

Redis 3.0（官方推出的）

大概

实现方案上雷同Sharding分片技术。键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通。共同对外承担一致服务。

PS：但是肯定也有不同点。Redis Cluster引入了槽（类似Codis，但是Cluster划分了16384【2^14】个槽）。将所有的数据对应到槽中，然后每个Redis节点管理一部分槽。

大致的示例

Client	Slot1（分片1）	Redis1
	Slot2	Redis1
	Slot3	Redis2
	Slot4	Redis2
	Slot5	Redis3
	Slot6	Redis3

优点

无中心节点（所有的Redis节点都是对等的节点，同步数据使用的是Gossip协议），数据按照槽存储分布式在多个Redis实例上，可以平滑的进行节点 扩容/缩容，当节点数量改变时，只需要动态更改节点负责的槽就行，这对客户端来说是透明的。不需要依赖中间件。运维成本低。

人话环节，就像是一个Redis 就是一个房子。房子里面放了好多个桶子。桶子才是放数据的地方。要是换房子了，把桶子搬走就行。

缺点

严重依赖Redis-trib工具，缺乏监控管理，Failover节点的检测过慢，Gossip协议传播消息到最终一致性有一定延迟。

（看不懂Gossip协议是什么没关系，下面会说的。）

数据分区规则

常见的分区规则

大意

当整个数据计划分到多个节点上，让每个节点负责一部分的数据，就需要使用数据分区规则。

常见规则

· 哈希分区

特点——离散性好，数据分布与业务无关，但是无法按顺序访问。

· 顺序哈希

特点：离散度易倾斜，数据分布与业务相关，但可以按顺序访问   

常见用的场景：大数据分析的数据库中。

Redis的选择方案

哈希分区

哈希分区

固定哈希区

大概含义

根据特定的字段（Redis中使用键）使用哈希函数计算出Hash值，然后根据节点的数量N取值，来决定将数据映射到哪一个节点上。

优点

规则设置和实现都很简单

缺点

扩容或收缩节点会涉及到很多数据的迁移

示例

keys	hash（key）%3	Redis1
		Redis2
		Redis3

一致哈希区

特点

可以很好地解决稳定性问题

大意

可以将所有的存储节点排列在首尾相接的hash环上（环的大小为2^32），key在计算Hash后会顺时针方向找到最近的存储节点存放数据。

（新增/减少节点时，仅影响该节点在hash环上顺时针方向的下一个节点）

大概的运行示例（如果是添加一个Node的话 就是看key离哪个近就保存哪个，而且可以分散单个Node压力）

虚拟槽哈希分区

操作大概

1、利用分散性良好的哈希算法（Redis使用的CRC16算法）把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。

2、每个节点都会管理一定的槽，hash函数将键映射到槽中，然后将数据存储在该槽所对应的节点。

Slot

范围——一般远远大于节点数

作用——数据管理和迁移的基本单位（也可以说是容器）

好处 

容易对集群进行扩容和收缩——因为数据是跟槽有关联，并非和节点关联。实现了一定的解耦。

Gossip协议

了解前提

分部署存储中需要维护节点元数据的机制。——元数据指节点负责的数据以及节点的状态。

常见的维护方式：

·  集中式

·  P2P——RedisCluster使用

通信过程

集群中的每个节点会单独开通一个TCP通道，用于节点之间彼此的通信（端口号为节点端加上10000）。

当节点出现变化，该节点会随机向周围几个节点传播消息，收到消息的节点会重复这个过程，最终集群中的所有节点都会收到该消息，达到集群状态最终一致的目的。

优势

·  可拓展性

    网络可以允许节点的任意增加和减少，新增加节点的状态最终会与其他节点一致。

·  容错

    网络中任何节点的宕机和重启都不会影响到Gossip消息的传播，Gossip协议具有天然的分布式容错特性。

·  去中心化

    Gossip协议不要求任何中心节点，所有节点都可以是对等的，任何一个节点无需知道整个网络状况，只要网络是连通的，任意一个节点就可以把消息散播到全网。

·  最终一致性

    Gossip协议实现信息指数级(logN)的快速传播，因此在有新信息需要传播时，消息可以快速地发送到全局节点，在有限的时间内能够做到所有节点都拥有最新的数据。

缺陷

消息的延迟

    由于Gossip协议中，节点只会随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网的，因此使用Gossip协议会造成不可避免的消息延迟，不适合用在对实时性要求较高的场景下。

消息冗余

    Gossip协议规定，节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，因此就不可避免的存在消息重复发送给同一个节点的情况，造成消息的冗余，同时增加了收到消息的节点处理压力。而且由于是定期发送，因此收到了消息的节点还会反复收到重复信息，加重了消息的冗余。

---

常见问题

（以下缓存雪崩、缓存穿透、缓存击穿都是Redis+关系型数据库一起使用的背景下解释）

缓存雪崩

大意

    大量key同一时间失效，这时候如果有访问量大的访问，Redis这时候没有key会导致数据走到数据库，可能会导致程序崩溃

解决方案

·  给key添加上随机值来失效

·  集群部署：

    这种方式通过数据都是热点数据均匀分布在不同Redis库中，保证不会出现一个Redis大面积失效数据。

    PS：如果是用分片（现在大部分都是分片）存储数据，还是加上随机失效才是好方案。

缓存穿透

大意

指缓存数据库和数据库都没有的数据，而用户不断访问，导致数据库压力过大。导致程序崩溃。

解决方案

·  对方法进行参数校验，保证请求的数据都是合法且存在的

（如果有需要的场景会用到一些数据但是无法有值的，就把对应的key的value设置null。保险的可以加上失效时间。）

·  高级点的做法——使用布隆过滤器（Bloom Filter）

缓存击穿

大意

    跟雪崩雷同，都和失效时间有关；主要是热点key长时间被高访问，导致key失效了之后，高访问就会变成直接访问数据库，容易造成程序崩溃

解决方案

·  互斥锁——也就是如果没有值就设置一个有超时时间的K-V

·  热点数据容不失效

双写一致性

大意

    当更新了mysql中的数据后也可以同时保证redis中的数据同步更新

解决方案

延迟双删

流程：

1、在修改MySQL前先清空Redis的数据

2、更新MySQL数据库，延时（2~3s）再删除一次缓存

3、延迟之前的操作读取数据有可能查的是旧数据，但是延时删除后再读就会是Redis的就是新数据

牺牲性能的解决方法

分布式锁

以MySQL作为主库，其他数据库作为副本

（现在的大众方案）

    也就是MySQL的数据会用别的传输工具来把修改的数据传给 Redis/ES去自己修改。都是用中间件的方式。

并发竞争

大意

多个线程或客户端对同一个key进行操作。

解决方案

分布式锁

大Key

大意

指存储的值较大。

这个我举些例子

1、微博大V粉丝数量

2、热门下的评论

3、或者使用的数据类型和场景不匹配，用错类型存储数据

弊端

1、容易出现Redis内存占用过高

2、QPS的突降或者突升，极端的可能会主从复制异常，Redis服务器阻塞无法响应请求。

解决方案

4.0之前的解决

1、redis-rdb-tools工具——使用后可在Redis执行bgsave，然后对rdb文件进行分析找出大key。

2、redis-cli --bigkeys命令——可以找到某个实例5种数据类型（String、hash、list、set、zset）的最大key。

3、自定义扫描脚本——网上都是Python的脚本居多。

4、debug object key命令——可以查看key系列化后的长度，每次只能查找单个key的信息，所以不太好用。

4.0之后的处理方法

Redis 4.0 引入了 memory usage命令 和 lazyfree机制，不管是对大key的发现还是解决大key的删除或者过期造成的阻塞问题都可以解决。

分析

memory usage——通过计算objectComputeSize来计算key的大小。

（默认抽取5个field来循环累加计算整个key的内存大小，样本的数量决定了key的内存大小的准确性和计算成本，样本越大，循环次数越多，计算结果越精确，不过也费性能。）

lazyfree机制——删除的时候只进行逻辑删除，把key释放操作在bio（background I/O）单独的子线程处理中，减少删除大key对Redis主线程的阻塞。

题外话

    Redis将最主要的网络收发和执行命令等操作都放在了主工作线程，然而除此之外还有几个bio后台线程，比如处理关闭文件和刷盘的后台线程，以及Redis4.0新增加的lazyfree线程。

热点Key

大意

    Redis被使用较多次的key，当key失效会出现影响Redis+MySQL的性能。

防止热点key出问题的方案

1、缓存时间不失效

2、多级缓存——跟MySQL的那种差不多意思，我就不多解释了。大概是开启本地缓存，如果本地缓存有就读缓存，不走Redis 获取数据

3、布隆过滤器

4、读写分离

---

过期策略

（对key设置时效后 Redis如何会什么时候删除）

定时删除

    为key设置定时器，一旦时间到了，自动删除key。

特点

    对内存友好，但是对CPU不友好，定时器占用CPU资源

惰性删除

    不管key有没有过期，都不会自动删除，等每次获取的时候再判断是否过期，如果过期就删除该key，否则返回键对应的值。

特点

    对内存不够友好，因为会存着已经过期的键

定期删除

    系统每个一段时间就定期扫描一次，发现过期了的键就进行删除。这种策略相对来说是上面两种方案的折中版。

特定

    弊端是可能会在在删除的时候有别的线程读到了键，返回了内容给客户端

---

淘汰策略

大意

当Redis内存被占用到满了，客户端set值就会触发淘汰策略来给客户端set值

如何设置用什么策略

静态配置

maxmemory-policy <bytes>

动态配置

config set maxmemory-policy <策略>

<bytes>的可写值

volatile-lru	根据 LRU 算法删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
allkeys-lru	根据 LRU 算法删除所有的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
volatile-lfu	根据 LFU 算法删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
allkeys-lfu	根据 LFU 算法删除所有的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
volatile-random	随机删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
allkeys-random	随机删除所有键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
volatile-ttl	根据键值对象的 ttl 属性， 删除最近将要过期数据。如果没有，则直接报错
noeviction	默认策略，不作任何处理，直接报错

LRU算法

全称：Least Recently Used

大致

    通过抽样的方式进行删除

LFU 算法

全称：Least Frequently Used

大致

    通过最少使用的频率来选择对象。

---

分布式锁

前提

    实现分布式锁之前，外部调用系统一定要有对key这块有【互斥】的能力。比如两个请求设置相同key。只能一个成功，另外一个失败。

大致操作

SETNX lock 1——加锁处理

DEL lock——解锁

弊端

当客户端1拿到锁，如下操作时Redis会出问题（锁被锁死了）

·  程序处理业务逻辑异常，没及时释放锁

·  进程在操作的时候，挂了。这时候就会没机会释放锁

避免死锁的方法如下

1、给锁设置超时时间

    但是即便这样设置也不行，有可能还是会无法保证锁被释放。比如Redis异常了。或者客户端崩溃，网络问题

2、Redis 2.6.12 之后，只需要用一条命令即可（官方拓展了Set命令）

    语法：SET lock 1 EX 10 NX

缺点（2.6.12之后还存在如下弊端）

    1.锁过期——可能会存在操作业务时间过久，导致锁自动被释放了

    2.执行了别人的锁——因为如1步骤的话锁已经自动失效，那时候解锁可能会误解了别人的锁

    

解决2.6.12版本弊端的办法

    客户端加锁时候，设置一个只有自己知道的【唯一标识】进去。

    （唯一标识只求随机且唯一即可）

PS：如上示例需要用lua脚本操作。原理是在lua操作的时候其他该key请求需要等待。

锁的相关步骤

1、加锁——SET lock_key $unique_id EX $expire_time NX

2、操作共享资源

3、释放锁——Lua 脚本，先 GET 判断锁是否归属自己，再 DEL 释放锁

Java技术栈对锁过期时间不好评估如何处理

Java使用工具类：Redisson

    在使用分布式锁时，它就采用了「自动续期」的方案来避免锁过期，这个守护线程我们一般也把它叫做「看门狗」线程。

本文来源：

• https://juejin.cn/post/6844904057048563725

• https://www.jianshu.com/p/50c0894c0a19

• https://mp.weixin.qq.com/s/D4Ik6lTA_ySBOyD3waNj1w

• https://mp.weixin.qq.com/s?__biz=MzAwNDA2OTM1Ng==&mid=2453140871&idx=3&sn=0ad5fc9d0474089a4271b16bf47b7cb0&chksm=8cf2d704bb855e1208ee8fead319c27204a00c64b484a950014527379d022623350e83e9353d&scene=21#wechat_redirect

• https://mp.weixin.qq.com/s/-caMTrOXQu-o0O44e6I9dQ

• https://mp.weixin.qq.com/s/RnSokJxYxYDeenOP_JE3fQ