【Redis】基础

1.概述

Redis的好处

• 基于内存，性能好
• 数据类型多
• 持久化存储

2.常用数据类型

• string 简单的key-value类型，value不仅可以是String，也可以是数字，常用命令set,get,decr,incr,mget
• hash 是一个string类型的field和value的映射表,常用命令hget,hset,hgetall
• list 是按照插入顺序排序的字符串链表,常用命令lpush,rpush,lpop,rpop,lrange
• set 作为没有排序的,不重复字符集合，常用命令sadd,spop,smembers,sunion
• sorted set sorted set 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。分数(score)可以重复。
• stream(5.0出品)，它是一个新的强大的支持多播的可持久化的消息队列

3.回收策略

Redis内存回收机制主要体现在以下两个方面：

• 删除到达时间的键对象
• 内存使用达到maxmemory上限时触发内存溢出控制策略

⑴删除过期键对象

• 惰性删除
  惰性删除用于当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空。这样做回节省CPU，但是单独使用这种方式会导致内存长期不能得到及时释放，因为内存没有访问就得不到释放。
• 定时任务删除
  Redis内部维护一个定时任务，默认每秒运行10次（可配置）。定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例，使用快慢两种速率模式回收键。
  • 定时任务在每个数据库空间随机检查20个键，当发现过期时删除对应的键。
  • 超过检查数25%的键过期，循环执行回收逻辑直到不足25%或运行超时为止，慢模式下超时时间为25ms。
  • 如果之前回收键逻辑超时，则在Redis触发内部事件之前再次以快模式运行回收过期键任务，快模式下超时时间为1ms且2s内只能运行1次。
  • 两种模式内部删除逻辑相同，只是执行的超时时间不同。

⑵内存使用达到maxmemory上限时触发内存溢出控制策略

当内存不足以容纳新写入数据时,Redis支持6种策略来移除key:

• noeviction 默认策略，新写入操作会报错，这个不太好
• allkeys-lru 在键空间中，移除最近最少使用的 Key。推荐使用
• allkeys-random 在键空间中，随机移除某个 Key
• volatile-lru 在设置了过期时间的键空间中，移除最近最少使用的 Key
• volatile-random 在设置了过期时间的键空间中，随机移除某个 Key
• volatile-ttl 在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除

4.持久化

如果redis开启了AOF持久化功能，那么当redis服务重启时会优先使用AOF文件来还原数据库。如果要保证数据安全，最好俩都开启。

⑴RDB持久化

RDB，提供一个某个时间点的数据的Snapshot，保存在RDB文件中。它可以通过SAVE/BGSAVE命令手动执行，把数据Snapshot写到RDB文件，也可以通过配置，定时执行。
手动触发也分为两种:SAVE和BGSAVE

• SAVE是阻塞式的RDB持久化,这段时间内redis将不能处理任何命令请求
• BGSAVE属于非阻塞式的持久化,因为会创建一个子进程，占用内存会大大的翻倍。
  自动触发:
• save 900 1 在900秒内发生1次写操作，就会自动进行一次bgsave
• 还有在执行shutdown命令的时候，如果没有开启AOF持久化功能，那么会自动执行一次bgsave。

⑵AOF持久化

默认不开启，通过保存对redis服务端的写命令（如set、sadd、rpush）来记录，它也存在数据丢失问题。有三种持久化模式:

• appendfsync always 每次有数据修改发生时都会写入AOF文件。
• appendfsync everysec 每秒钟同步一次，该策略为AOF的默认策略。推荐
• appendfsync no 从不同步。高效但是数据不会被持久化。

相比RDB每次持久化都会内存翻倍，AOF持久化除了在第一次启用时会新开一个子进程创建AOF文件会大幅度消耗内存外，之后的每次持久化对内存使用都很小。但AOF也有一个不可忽视的问题：AOF文件过大，因此redis有AOF重写机制，通过配置可以让AOF文件精简。

⑶RDB和AOF的区别

• RDB是一次性生成内存快照，压缩程度高，无法做到实施持久化，用于数据冷备和复制传输。
• RDB的save阻塞主线程不好，bgsave通过fork创建子进程避免阻塞。
• AOF可以控制实时持久化，但需要不断重写来减少文件体积。

5.分布式锁实现

首先我们要知道Redis并不能实现严格意义的分布式锁
Redis分布式锁主要基于两个命令

⑴setnx

将key设置值为value，如果key不存在，这种情况下等同SET命令。 当key存在时，什么也不做。SETNX是”SET if Not exists”的简写,最好加上超时防止死锁，返回值:

• 1 如果key被设置了
• 0 如果key没有被设置

⑵getset

返回原来的值并将原来的值设置成新传入的值

⑶步骤

• setnx(lockkey, 当前时间+过期超时时间) ，如果返回1，则获取锁成功；如果返回0则没有获取到锁，转向2
• get(lockkey)获取值oldExpireTime ，并将这个value值与当前的系统时间进行比较，如果小于当前系统时间，则认为这个锁已经超时，可以允许别的请求重新获取，转向3。
• 计算newExpireTime=当前时间+过期超时时间，然后getset(lockkey, newExpireTime) 会返回当前lockkey的值currentExpireTime。
• 判断currentExpireTime与oldExpireTime 是否相等，如果相等，说明当前getset设置成功，获取到了锁。如果不相等，说明这个锁又被别的请求获取走了，那么当前请求可以直接返回失败，或者继续重试。
• 在获取到锁之后，当前线程可以开始自己的业务处理，当处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行delete释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理。