Redis

一、五种数据结构

String、List、Map、Set、ZSet

常用命令：set get setnx setex lpush rpush lpop sadd spop zadd zrange kyes......

二、持久化机制

RDB、AOF、RDB&AOF同时开启

1、RDB:

redis默认持久化方式，持久化文件存储的是一个二进制的文件，速度比较快，传输也很方便

• save 900 1 表示在900秒内，有1个key改变了，就执行RDB持久化。
• save 300 10 表示在300秒内，有10个key改变了，就执行RDB持久化。
• save 60 10000 表示在60秒内，有10000个key改变了，就执行RDB持久化。

由此可以看出，RDB 是在一个时间范围内触发事件才进行持久化，如果在未触发事件的情况下， Redis 宕机或者断电了，将会造成数据丢失。因此无法保证数据的绝对安全

2、ROF:

AOF持久化文件存储的是一个文本文件，速度相对 RDB 较慢，到了后期文件会比较大，传输较为困难。开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件

• appendfsync always 表示每执行一个写操作，立即持久化到AOF文件中，性能比较低。 
• appendfsync everysec 表示每秒执行一次持久化，在开发时，综合考虑使用这种方案

AOF 保存文件时，如果执行相同的命令，AOF文件会记录多次，并没有优化，如果需要优化，则需要手动使用bgrewriteaof命令来优化。但手动重写很显然不能满足生产环境的需要，因此，redis提供了如下配置来实现：

• auto-aof-rewrite-percentage 100 # 触发的条件：下面设置的文件大小增加100%，也就是1倍，才会重写
• auto-aof-rewrite-min-size 64mb # aof文件大小达到64M才可能重写记录的命令

3、AOF&RDB（混合持久化） 

混合持久化实际上就是每一次aof被优化的时候，都会将原来的 aof 变成 rdb，再向aof中写内容的时候 依然是 aof，这样在同一个持久化文件中 既有 aof，又有 rdb，这就是混合持久化

三、集群模式

1、主从复制

一个主节点多个从节点，数据从主节点复制到从节点

• Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂

2、哨兵模式

哨兵模式是建立在主从复制的基础上，当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，在低版本中，这个过程需要人工手动来操作。 在Redis 2.8及以后的版本中，提供了哨兵工具来实现自动化的系统监控和故障恢复功能。哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个：

• 监控主服务器和从服务器是否正常运行
• 主服务器出现故障时自动将从服务器转换为主服务器

3、Redis Cluster（集群）模式

n个主从架构组合在一起就是Redis Cluster。Redis Cluster要求至少需要3个master才能组成一个集群，同时每个master至少需要有一个slave节点。

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16383 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个节点， 其中：

节点 A 负责处理 0 号至 5500 号哈希槽。

节点 B 负责处理 5501 号至 11000 号哈希槽。

节点 C 负责处理 11001 号至 16384 号哈希槽。

move重定向

1. 每个节点通过通信都会共享Redis Cluster中槽和集群中对应节点的关系
2. 客户端向Redis Cluster的任意节点发送命令，接收命令的节点会根据CRC16规则进行hash运算与16383取余，计算自己的槽和对应节点
3. 如果保存数据的槽被分配给当前节点，则去槽中执行命令，并把命令执行结果返回给客户端
4. 如果保存数据的槽不在当前节点的管理范围内，则向客户端返回moved重定向异常
5. 客户端接收到节点返回的结果，如果是moved异常，则从moved异常中获取目标节点的信息
6. 客户端向目标节点发送命令，获取命令执行结果

需要注意的是：客户端不会自动找到目标节点执行命令

ask重定向

1. 客户端向目标节点发送命令，目标节点中的槽已经迁移支别的节点上了，此时目标节点会返回ask转向给客户端

2. 客户端向新的节点发送Asking命令给新的节点，然后再次向新节点发送命令

3. 新节点执行命令，把命令执行结果返回给客户端

四、分布式锁

1、加锁：redisTemplate.opsForValue().setIfAbsent(key, value, timeout, unit);

redis中设置key value,设置成功则表明加锁成功，并设置过期时间，避免死锁

2、解锁：先判断key是否存在，存在则删除（即解锁），利用redis 的lua脚本保证判断是否存在和删除key操作的原子性

3、根据线程id，实现可重入锁，redis map数据结构 ->ThreadId为key  num数字为value， 每次同一个线程加锁（重入）则num+1‘

4、redisson分布式锁，看门狗锁续约，创建一个守护线程每10s钟就检查一下线程是否还持有该锁，如果还持有该锁，那就重置锁过期时间为30s