Redis+Caffeine介绍

set user:id:name xiaoming

set user:id:age 20

setxx

设置值

存储： set key value

set [key] [value]

只能修改，必须存在key，才能存在

set key value [expiration EX seconds|PX milliseconds][NX|XX] 

实战使用 set key:{id}:{filed}

get key

get [key]

取值

获取： get key

mset key value [key value ...]

mget key [key ...]

getset key value

getset 先get再set

如果不存在值则返回null，再设置新值；若存在，返回原来的值，并设置新指

获取值之后 修改该K的V

若存在key，则将xxx设置进去

若不存在，则不会设置

setex（set with expire）

该k1对应的v的值++（v必须是Integer类型）

设置每次走的步长

DECRBY

设置每次走的步长

该k1对应的v的值--（v必须是Integer类型）

+1操作

自增

incr view

incr key

INCR 自增

decr view

自减

DECR 自减

-1操作

指定-num操作

incrby view [num]

incrby key increment

incrbyfloat key 3.5

固定长度自增

增加key对应的值3.5

指定+num操作

INCRBY 设置步长，指定增量

decrby view [num]

固定长度自减

strlen [key]

查看长度

返回字符串的长度

取其字符集长度

追加值

APPEND 拼接

将value追加到旧到value

append [key] [value]

SDS

C字符串并不记录自身长度，想获取长度只能遍历

sds直接获取len即可

c字符串每次长度变化都会对数组进行内存重新分配，比较耗时

对sds内容进行修改或者需要扩展时，sds有空间预分配和惰性空间释放

C字符串不记录自身长度，不会自动进行边界检查，所以会增加溢出的风险

sds先检查空间是否满足修改所需的要求，如果不满足就先扩容再进行修改

C字符串是以空字符串（\0）结尾，所以字符串中不能包含空字符串，只能保存文本数据

既能保存文本数据，也能保存二进制数据（通过长度判断结束，不受影响）

扩容时机：元素的个数等于第一维数组的长度; bgsave时不扩容，除非达到dict_force_resize_ratio

扩容：扩容 2 倍

缩容：元素个数低于数组长度10%时

渐进式rehash

hash-max-ziplist-entries

hash-max-ziplist-value

hset myhash key1 value1

hset 单个设置值

hget

hget myhash key

存值

hset key field value

hset [map] [key] [value]

存储： hset key field value

hset k field value

批量存值

hmset [map] [k1] [v1] [k2] [v2] ...

hmset 多个设置值 hmset myhash k1 v1 k2 v2

hmset k field value field value

hmset key field value [field value ...]

取值

hget [map] [key]

hget key field

hget k filed

hget key field: 获取指定的field对应的值

批量取值

hmget [map] [k1] [k2] ...

hmget k field filed

hmget key field [field ...]

hmget myhash key1 key2 获取多个值

hincrby key field increment

对其value值做加减法操作 + 使用场景：评论数、点赞数增加

可重复集合

list：可重复集合

允许存在重复元素

可重复

支持重复元素

有序的字符串

存储有序列表

压缩列表（ziplist）

linkedlist

linkedlist格式 

一个通用的双端链表实现

快速列表（quicklist）

lset [list] [index] [value]

lset key index v

语法：lset key index value

lpush k v

lpush [list] [value]

lpush list-name c b a

lpush key value:

LPUSH list one 

lpush key value [value ...]

将元素加入列表左表

LPUSH 插入到第一个元素

LPUSH 将一个值或者多个值，插入到列表的头部（左-left）

lpush:l的意思是left，从左往右push；
+ lpush key a b c d e f在redis中存储的顺序为f e d c b a

从左边放

左存（头插）

rpush k v

rpush [list] [value]

rpush key value [value ...]

rpush key value

RPUSH list one 

将一个值或者多个值，插入到列表的尾部（右-right）

从右边放

右存（尾插）

将元素加入列表右边

rpush:与lpush正好相反

3. 删除：
： 
： 

rpop k

rpop key

rpop [list]

RPOP list

右取

从右边取第一个

右边的值移除，移除list的最后一个元素

删除列表最右边的元素，并将元素返回

lpop k 

lpop [list]

lpop key

LPOP list

左取

从左边取第一个

LPOP 移除第一个元素

左边的值移除，移除list的第一个元素

关于lpop的用法

语法：lpop key | 表示出栈/出队列中的第一个元素，并从原来的list集合中删除该元素

lpop：接上条lpush的数据；弹出数据为f

删除列表最左边的元素，并将元素返回

rpoplpush list list2

brpop k timeout

brpop key timeout

从右边取，没取到的话阻塞timeout时间

List

blpop

blpop k timeout

blpop key timeout

从左边取，没取到的话阻塞timeout时间

等待元素出现（阻塞），第一个线程弹出

语法： ltrim key start stop

ltrim [list] [start] [end]

ltrim key start end: 修剪

ltrim key start stop

Ltrim list 1 2 

ltrim books 1 0 （这其实是清空了整个列表，因为区间范围长度为负）

lindex [list] [index]

lindex key index

lindex queue 0

语法：lindex key index

Lindex list 1

语法：lrang start stop

lrange key start stop

lrange k 0 -1

lrange key start end: 范围

lrange [list] [start] [end]

lrange queue 0 -1

lrange key start end

0 -1 获取全部
lrange myList 0 -1

-1代表倒数第一个

-2 代表倒数第二个

page size

（page-1）* size

page*size-1

LRANGE list 0 1 通过区间获取具体的值

LRANGE list 0 -1  查看列表中的值

count = 0 ,移除队列里面所有与value 值相同的value

count > 0 , 从表头开始搜索，删除数据value的值，删除的个数为count个

count< 0 ,从表尾开始搜索，删除数据为value的值，删除的个数为 count的绝对值个

count = 0: 删除所有v

count > 0: 从左到右删除count个

count < 0: 从右到左删除count个

分支主题

分支主题

srandmember: 随机取元素

srandmember 随机抽选出set集合中元素

srandmember myset 随机抽选出set中一个元素

随机获取一个元素

随机获取num个元素

从集合中随机挑num个元素

srandmember myset 2 随机抽选出指定个数的元素

SDIFF key1 key2

sdiff k1 k2 (k1-k2)

sdiff [set1] [set2]

减集

sinter

sinterstore

sunion

sunionstore

zadd k 分数 成员

zadd myzset 10

zadd myset k1 v1

zadd key score e

存储：zadd key score value

zadd [set] [score][member]

添加 可批量添加

zadd k1 8 apple 2 banana 3 orange 8、2、3代表分值score

zadd key [NX|XX] [CH] [INCR] score member [score member ...]

zadd [set] [score1] [member1] [score2] [member2] ...

排行 （从低到高）

zrevrange myset max min

m 表示单位为米。
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。

GeoHash

geohash

zrange [key] 0 -1

存储整形值

元数据，int

字符串小于等于44字节

元数据，ptr，SDS 连续存储 避免内存碎片

字符串大于44字节

元数据，ptr，SDS独立空间

每处理一个请求，按序从哈希表1 rehash一个桶到哈希表2

没有新请求时定时执行rehash

//商品服务类 
@Service
@CacheConfig(cacheNames = "GoodsCache")
public class GoodsService {

 private Logger logger = LoggerFactory.getLogger(this.getClass());

 //按id获取商品信息 
 @Cacheable
 public GoodsDo getById(Long id) {
  logger.info("getById({})", id);
  GoodsDo goods = new GoodsDo();
  goods.setId(id);
  goods.setName("goods-" + id);
  return goods;
 }

 //删除商品 
 @CacheEvict(key = "#id")
 public void remove(Long id) {
  logger.info("remove({})", id);
 }

 //编辑商品信息 
 @CachePut(key = "#goods.id")
 public GoodsDo edit(GoodsDo goods) {
  logger.info("edit id:{}", goods.getId());
  return goods;
 }
}

用于指定本类中方法使用的缓存名称

该类使用的缓存名称为 GoodsCache 

与其他缓存区域是隔离的。

开启方法缓存，缓存的键是方法的参数，缓存的值是方法的返回值。

如果多次调用该方法时参数 id 值相同，则第一次会执行方法体，并将返回值放入缓存；

后续方法不会再执行方法体，直接将缓存的值返回。

 可以更新缓存，key = "#id" 表示采用参数中的 id 属性作为键。

当缓存中该键的值不存在时，则将返回值放入缓存；当缓存中该键的值已存在时，会更新缓存的内容。

可以移除缓存，当调用该方法时，会移除 goods 中 id 属性对应的缓存内容。

@SpringBootTest
class SpringBootCacheApplicationTests {
 private Logger logger = LoggerFactory.getLogger(this.getClass());
 @Autowired
 private CacheManager cacheManager;

 @Autowired
 private GoodsService goodsService;

 // 显示当前使用的缓存管理器类型
 @Test
 void showCacheManager() {
  // 输出：org.springframework.cache.concurrent.ConcurrentMapCacheManager
  logger.info(cacheManager.getClass().toString());
 }

 // 缓存测试
 @Test
 void cacheTest() {
  // 第一次执行，没有缓存，执行方法体
  goodsService.getById(1L);
  // 再次执行，直接取出缓存，不执行方法体
  goodsService.getById(1L);
  // 移除缓存
  goodsService.remove(1L);
  // 再次执行，已经没有对应缓存，所以执行方法体
  GoodsDo oldGoods = goodsService.getById(1L);
  // 打印缓存内容
  logger.info("old goods id:{} name:{}", oldGoods.getId(), oldGoods.getName());
  // 更新缓存
  GoodsDo temp = new GoodsDo();
  temp.setId(1L);
  temp.setName("新的商品");
  goodsService.edit(temp);
  // 查询并打印已更新的缓存内容
  GoodsDo newGoods = goodsService.getById(1L);
  logger.info("new goods id:{} name:{}", newGoods.getId(), newGoods.getName());
 }
}

使用 Spring Boot 默认缓存时控制台输出内容

华为云提供的缓存服务

空连接异常

Redis-Cell

寄存器的存储内容

程序计数器存储的指令内容

定时扫描

定时过期（主动淘汰）

内存友好，占用cpu资源去处理

消耗内存

每个过期时间都需要一个定时器，过期清理

定时删除的原理：

缺点：当过期的key特别多时，创建的线程也会非常多，特别消耗cpu资源

每秒运行 10 次，采样删除

每隔默认100s随机检查设置了过期时间的key,若已过期则删除

慢模式：随机检查 20 个key

Redis每秒10次做的事情

问题：

解决方案：

每隔一定时间去扫描库中expires字典一定数量的key，清除

定期删除原理：专门有一个线程监视所有设置了过期时间的key的时间，
如果过期，将该key删除

redis默认每隔100ms就随机抽取一些设置了过期时间的key，检查是否过期，过期则删除。
定期删除是随机抽取一部分并不是全部，所以可能会导致很多过期key到了时间没有被删除掉。

检查 删除 但是是随机的

缺点：实时性差一点

可能存在大量key

访问该key，才会判断是否过期，节省cpu，耗内存

极端下会出现大量过期的key，而不会被清除，占用内存

当你去get一个key的时候，redis会检查一下这个key是否过期了，如果
过期了，那么就删除，这就是惰性删除。

惰性删除原理：当用户访问该key 时，会判断该key 是否过期了
如果过期了就删除该key，给用户返回null，如果没有过期就返回value

缺点：如果用户一直不访问该key，它就一直不会删除，
会一直占用内存

访问key

expired dict

del key

惰性过期（被动淘汰）

在客户端访问key时再进行检查如果过期了就立即删除 unlink指令针对于del的key是一个非常大的对象，延迟删除，将其交给后台异步线程操作。

访问key时才检查是否过期，过期则删除更新

del -> unlink

flushdb -> flushdb async

如下因为删除是定期删除+惰性删除

定期删除+惰性删除

走内存淘汰机制

描述：Redis是基于内存结构进行数据缓存的，当内存资源消耗完毕，想要有新的数据缓存进来，要从现有的Redis内存结构中释放一些数据

最近没有使用算法

不需要额外的存储空间，使用一个双向连表就能实现

如果一个数据在最近一段时间没有被访问到，那么可以认为在将来它被访问的可能性也很小。
因此，当空间满时，最久没有访问的数据最先被置换（淘汰）

最近使用频率最少的key

需要一个能记录key 使用次数的空间，使用ZSet 这样的结构就能实现

如果一个数据在最近一段时间很少被访问到，那么可以认为在将来它被访问的可能
性也很小。因此，当空间满时，最小频率访问的数据最先被淘汰

最少使用

LRU

（驱逐）

默认策略，拒绝写入操作

noeviction（Redis默认）

这是默认的淘汰策略！！！

noeviction（默认）

【这种一般没有人用】

noeviction 报错

禁止驱逐数据

不做删除操作，新写入操作报错

当超过最大容量，不会删除任何key，返回一个错误

当内存不足以容纳新数据，新写入数据报错

# noeviction -> 不淘汰任何数据，当内存不够时直接抛出异常.

不会继续服务写请求 (DEL 请求可以继续服务)，读请求可以继续进行。

这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。

【最常用】

allkeys-lru

在所有key中LRU

LRU算法删除所有key

通过lru算法，删除最近没有使用的key

 从所有数据中淘汰最久未使⽤的数据.

LRU算法

移除最近最少使用的key

从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

当内存不足以容纳新的数据，移除最近最少使用的key

区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不只是过期的 key 集合。

这意味着没有设置过期时间的 key 也会被淘汰。

使用场景、使用策略规则

条件

内存不足。随机溢出某个key

随机删除所有key

在所有key的集合中随机删除一个key

# allkeys-random -> 从所有数据中随机淘汰⼀批数据.

从数据集（server.db[i].dict）中任意选择数据淘汰

跟上面一样，不过淘汰的策略是随机的 key

allkeys-random

allkeys-random 随机移除某个key

allkeys-random使用场景、使用策略规则

volatile-LRU

volatile-lru 移除最近最少使用的key

LRU算法删除 有expire的key

volatile-lru LRU算法

Least Recently used 在设置过期时间的key中，删除最近最少使用

当内存不足，在设置了过期时间的key中移除，最近最少使用的key

# volatile-lru -> 从设置了过期时间的数据中淘汰最久未使⽤的数据.

从设置了过期时间的key集合中删除最近没有使用的key

从设置了过期时间的数据中淘汰最久未使⽤的数据.

从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

尝试淘汰设置了过期时间的 key，最少使用的 key 优先被淘汰。没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。 两个条件： + 设置了过期时间 + 使用了LRU算法淘汰最少使用

内存不足，在设置了过期时间的key中随机移除一个key

volatile-random 随机移除某个key

随机删除过期key

在设置了过期时间的key的集合中随机删除一个key

从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

# volatile-random -> 从设置了过期时间的数据中随机淘汰⼀批数据.

volatile-random

跟上面一样，不过淘汰的 key 是过期 key 集合中随机的 key + 设置了过期时间 + 随机淘汰

volatile-TTL

volatile-ttl

删除最近将要过期key

Time To Live 在设置过期时间的key中，删除剩余存活时间最短的key

volatile-ttl  有更早过期时间的key优先移除

在设置了过期时间的key集合中删除即将过期的key

内存不足，在设置过期时间的key中，有更早过期时间的key被移除

# volatile-ttl -> 淘汰过期时间最短的数据.

从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

跟上面一样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。 根据剩余过期时间来淘汰

LFU: Least Frequently Used

volatile-lfu

# volatile-lfu -> 从设置了过期时间的数据中淘汰使⽤最少的数据.

从设置了过期时间的key集合中删除最近使用频率最少的key

从设置了过期时间的数据中淘汰使⽤最少的数据.

allkeys-lfu

# allkeys-lfu -> 从所有数据中淘汰使⽤最少的数据.

在所有key的集合中 删除最近使用频率最少的key

在所有key中TTL

key: 不要过长

value: ziplist / intset 等优化方式

输出缓冲区

输入缓冲区

repl_back_buffer

默认1M，建议调大 例如100M

防止网络抖动时出现slave全量复制

无限制

默认方式，不需要进行配置，默认就使用这种机制
   * 在一定的间隔时间中，检测key的变化情况，然后持久化数据

（1）redis主进程调用fork()方法创建一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（2）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

Redis DataBase

redis database

RDB（Redis DataBase）

保存策略

Save the DB on disk:保存数据库到磁盘

生成dump.rdb 通过配置文件save参数来定义快照周期

save m n 时间策略

save ""

dbfilename  dump.rdb

dbfilename dump-${port}.rdb

dbfilename：RDB快照文件名

#rdb持久化存储数据库文件名，默认为dump.rdb

导出数据库的文件名称

图解

dir "/etc/redis"

dir /bigdiskpath

dir ./

dir：指定RDB快照保存的目录

#数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限

导出的数据库会被写入这个目录，文件名就是上面'dbfilename'配置项指定的文件名。

只增的文件也会在这个目录创建

注意你一定要在这个配置一个工作目录，而不是文件名称。

stop-write-on-bgsave-error yes 

备份出错时，是否继续接受写操作，默认会停止

    #在默认情况下，如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。    
    #这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。    
    #    
    #如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。    
    #    
    #然而，如果已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。    
    #如此一来即使后台保存操作出错，redis也仍然可以继续像平常一样工作。    

rdbcompression yes

rdbcompression：是否压缩存储快照，若压缩则会采用LZF算法进行压缩

#是否开启RDB文件压缩，该功能可以节约磁盘空间、

    #是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象？    
    #默认情况下总是设置成‘yes’， 他看起来是一把双刃剑。    
    #如果你想在存储的子进程中节省一些CPU就设置成'no'，    
    #但是这样如果你的kye/value是可压缩的，你的到处数据接就会很大。

rdbchecksum yes

rdbchecksum：是否进行数据校验

若校验，则会采用CRC64算法来校验，会增加10%的性能消耗

#在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

    #从版本RDB版本5开始，一个CRC64的校验就被放在了文件末尾。    
    #这会让格式更加耐攻击，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降，    
    #所以，为了达到性能的最大化，你可以关掉这个配置项。

没有校验的RDB文件会有一个0校验位，来告诉加载代码跳过校验检查

图解RDB的原理

时点性

当条件满足，redis需要执行RDB的时候，服务器会执行以下操作

步骤1：创建（fork）子进程来进行持久化，将数据写入到一个临时文件中

步骤2：当父进程发生修改时，Copy On Write复制一份数据并发生修改

步骤3：临时文件替换上次持久化好的dump.rdb文件

步骤4：子进程退出，整个过程中，主进程是不进行任何 IO 操作的

步骤5：恢复时将快照文件直接读到内存中，恢复dump.rdb文件

最后一次持久化的数据可能丢失

从节点发送命令主节点做bgsave，同时开启buffer

备份就会自动生成一个dump.rdb文件

全量复制

debug reload

SAVE

BGSAVE

配置文件: save seconds changes

shutdown

flushall

对数据的完整性要求不高

因为rdb这边有一个配置save 900 10类型的配置，有一个最低要求，如果再这期间宕机，就不会生成文件，导致文件丢失

适合大规模的数据恢复

恢复大的数据集时，RDB方式会更快一些

恢复时比较快，适合大规模的数据恢复

相对于数据集大时，比AOF的启动效率更高

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

父进程无须执行任何磁盘的IO操作，因此恢复数据比AOF快

生成RDB文件时，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

相对于AOF持久化机制来说，基于RDB数据文件来重启和恢复redis进程，更加快速。

RDB 在恢复大数据集时的速度，比 AOF 的恢复速度要快

同样的数据文件比AOF文件小，数据恢复时比AOF要快

RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

RDB文件是经过压缩的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

性能最大化，子线程处理IO持久化

子进程负责所有的RDB操作，父进程不影响IO，最大化redis的性能。

redis主进程调用fork()方法，创建一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

RDB对Redis的性能影响非常小，是因为在同步数据的时候fork了一个子进程去进行持久化

RDB对redis提供对外读写服务，影响非常小，可以让redis保持高性能，

因为redis只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。

每个数据文件都代表了某一时刻中redis的数据，这种多数据文件的方式

可以通过shell脚本将备份文件发送到一些远程的安全存储上去，以预定好的备份策略来定期备份redis中的数据。

fork子进程占用一定空间

需要一定的时间间隔操作

需要一定的时间间隔进程操作

fork大量数据时，有可能会影响性能

如果生成的快照文件比较大会影响redis的性能

在数据集比较庞大时， fork() 可能会非常耗时

RDB在生成数据文件时，如果文件很大，客户端会暂停几毫秒甚至几秒

创建fork子进程时，也会占用一定的内容空间（只要是进程都会占用空间）

RDB每次在fork子进程来执行RDB快照数据文件生成时，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒甚至数秒。

一定不要让RDB间隔时间太长，否则每次生成RDB文件太大，对redis本身性能可能会有影响

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。

根据数据量大小与结构和服务器性能不同，这个时间也不同。

通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20～30秒钟。

不可控、会丢失数据

会丢失fork后一段时间内的文件

如遇突然宕机，丢失的数据比较多

如果期间redis宕机，最后一次数据无法保存

数据安全低，持久化的间隔期间宕机，导致数据丢失

快照持久化期间修改的数据不会被保存，可能丢失数据。

如果redis意外宕机了，这个最后一次修改的数据就没有了

如果你需要尽量避免在服务器故障时丢失数据，那么RDB 不适合你。

快照文件默认五分钟才生成一次（根据时间策略），这意味着这五分钟的数据都有可能丢失

如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。

一般来说RDB快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候一旦redis宕机，可能丢失这段时间的数据。

备份机制稳健，丢失数据概率低

可读的日志文本，可以处理误操作

比RDB占用更多的磁盘空间

恢复备份较慢

默认是不开启AOF模式的，需要手动进行配置修改

需手动开启：appendonly yes

redis.conf中把appendonly改成yes

打开AOF配置，在配置文件中打开AOF方式

config set appendonly yes

开启后redis会保留一块内存供缓存使用，默认是1M

aof和rdb同时开启时，只保留save 900 1 减少fork子进程的次数（优化点）

图解AOF工作原理

图解AOF工作原理

步骤1：将所有的写命令，追加到AOF缓冲区中

步骤2：根据写入策略，将每条命令 fsync 到硬盘AOF文件

 步骤3：读取和执行存放的指令日志，进行AOF的故障恢复

appendfsync：保存与同步策略

bgrewriteaof：AOF重写机制

AOF重写机制是什么？

为什么需要重写？重写作用

重写后的文件为什么会变小 ？ 

修改配置文件

根据Redis版本不同有些区别

AOF保存的文件是appendonly.aof

Redis执行的每次命令记录到单独的日志appendonly.aof文件

如果AOF文件中出现了残余命令，会无法重启服务

如果aof文件出现错误，这时候redis时启动不起来的，就需要修复aof文件，

redis提供一个工具：redis-check-aof --fix appendonly.aof

使用redis-check-aof工具来修复：redis-check-aof -fix 文件

是否开启AOF

是否开启AOF，默认关闭（no）

appendonly yes

AOF备份文件的名称

指定 AOF 文件名

appendfilename appendonly.aof

是什么？

Always（安全，低效）

Everysec（推荐、默认配置、兼顾速度和安全）

No（不推荐，高效，不安全）

设置允许重写的最小aof文件大小

当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时，由于文件尺寸较小导致频繁的重写。  

auto-rewrite-min-size 64M

指定重写与否的aof文件大小比例

当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewirte-percentage 100

重写时，是否执行保存策略

#设置为yes，表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no

#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。  

no-appendfsync-on-rewrite no

是否截断

相比于RDB，丢失的数据少

数据安全

每一次修改都同步，文件的完整性更好

备份机制稳健，丢失数据概率低

每隔一秒左右（模式可配置）执行一次fsync操作，最多损失一秒的数据

丢失数据介于always与no中间，在性能和持久化方面做了很好的折中

可以更好保护数据不丢失，每隔1s就执行一次fsync操作，保证os cache数据写入磁盘中，redis挂了，最多丢失1s数据

rewrite操作对性能影响很小

从不同步，效率最高的！

记录日志是追加（append_only）的方式，减少了磁盘寻址的开销

写入性能高，而且文件不容易破损

宕机，可通过redis-check-aof工具解决一致性问题

AOF开启后，支持的写QPS会比RDB支持的写QPS更低，因为AOF一般会配置成每秒fsync一次日志文件。

当然，每秒一次fsync，性能还是很高的。

如果你要保证一条数据都不丢失，也是可以的，设置成每写一条数据，进行一次fsync，会导致redis的QPS性能大降。

AOF日志文件的命令通过非常可读的方式进行记录

这个特性非常适合做灾难性的误删除的紧急恢复

比如

恢复慢

恢复速度慢

修复的速度比rdb慢

做数据恢复时，会比较慢

由于需要一条一条执行操作日志中的指令

AOF运行效率也比RDB慢，因此redis默认的配置是RDB持久化

比RDB占用更多的磁盘空间

体量无限变大

相对于数据文件来说，AOF远远大于RDB

对于同一份文件来说，AOF日志文件通常比RDB数据快照文件更大

做冷备，定期的备份，不太方便

可能要自己手写复杂的脚本去做，做冷备不合适

通过AOF做冷备，没有RDB做冷备恢复的速度快。

因为RDB可以定时对数据库备份，并且恢复数据集的速度快，也可以避免AOF的bug

RDB每次简单粗暴生成快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug

redis在重启时通常是加载AOF文件，但加载速度慢因为RDB数据不完整，所以加载AOF

aof-use-rdb-preamble true开启后，AOF在重写时会直接读取RDB中的内容

通过bgrwriteaof完成，不同的是当开启混合持久化后

1 子进程会把内存中的数据以RDB的方式写入aof中，
2 把重写缓冲区中的增量命令以AOF方式写入到文件
3 将含有RDB个数和AOF格数的AOF数据覆盖旧的AOF文件新的AOF文件中，一部分数据来自RDB文件，一部分来自Redis运行过程时的增量数据

当我们开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况如下：

aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。
aof文件开头不是rdb的格式，直接以aof格式加载整个文件。

（redis并没有使用这种方式）

Master以写为主

主（master）redis以写操作为主

而写只需要分给主机，就能缓减服务器压力

一主多从，主机宕机后，需要手动更改ip确定新的主机

主机负责写

一个主机（master）

读的操作都分给从机上

多个从机（salve）

一个从机只能有一个master

一般从库上不会发生写操作，只会有读操作

Slave以读为主

从（slave）redis以读为主

从机从主机中同步复制数据，只读。

从机负责读

查看本机的复制信息

（常用的Redis命令）

查看当前主从状态信息

查看当前redis的主从策略

可以直到redis对应的一些信息，比如是主库，还是从库

后台进程

默认情况下，每台redis服务器都是主节点

需要配置从机就可以了，主机不用配置

集群命令，通过命令实现

只配置从库，不用配置主库（配置从机，配从不配主，找老大）

在从机中配置，上面认老大的slaveof是命令式的，一次性的

⭐Redis默认自己就是主库，所以只需要配置从库

在从机上输入命令SLAVEOF 【主机的ip】 【主机的端口号】

slave从机配置

master主机配置

通过配置redis.conf里面配置REPLICATION

修改配置文件、一般修改配置redis.conf

最好使用配置文件配置实现

1、使用命令进行主从配置，不需要重启redis服务器，但是不方便管理

2、使用配置进行主从配置，需要重启redis服务器，但是方便管理

slave-read-only yes

设置从节点只当作读的操作

读写分离，主机读写，从机从主机中同步复制数据，只读。

一主多从，主机宕机后，需要手动更改ip确定新的主机

主要是为了高并发，缺点是难扩容，整个集群的容量受限于某台机器内存容量

扩展读的性能

1、将主机的读操作分摊给从节点

读写分离可能遇到问题

maxmemory配置不一致

数据结构优化参数不一致

1、第一次全量复制不可避免

2、节点运行ID不一致

3、复制积压缓存区不足

1、单主节点复制风暴

2、单机器复制风暴

主节点重启，多个从节点复制

优化：更换复制拓扑

从机是从头开始复制，还是从切入点开始复制

从头复制

主机shutdown后，从机是上位还是原地待命

原定待命，不会变成主机

不能 从机只能读get

可以

从机挂了之后,会丢失之前的主从关系,需要重新设置一次主从关系才行

第一阶段

第二阶段

第三阶段

1.【s -> m】psync runId offset

2.【m -> s】+FULLRESYNC {runId} {offset}

3.【s】save masterInfo

4.【m】bgsave / write repl_back_buffer

5.【m -> s】send RDB

6.【m -> s】send buffer

7.【s】flush old data

8.【s】load RDB

Slave从机第一次启动时

Master重启时

1、【m】bgsave时间开销

2、【m】RDB网络传输开销

3、【s】清空数据时间开销

4、【s】加载RDB时间开销

5、【s】AOF重写时间（可能的）

Master根据Slave发送的同步请求中的offset

slave发送psync和加载RDB文件时，会存在offset偏移量

在backlog中查询部分丢失的数据，发送给Slave

master只会发送增量数据。

投票算法

保证了集群的高可用，但仍有容量上限问题

1、客户端高可用观察

2、服务端日志分析：数据节点和sentinel节点

故障转移流程

如何选择合适的slave节点

每10秒，sentinel对m/s执行info

发现slave节点

发现、确认主从关系

每2秒，sentinel通过master的channel交换信息

master频道：__sentinel__:hello

通过_sentinel_hello；进行频道的交互

交换对节点的看法、以及自身信息

交互对节点的看法和自身的信息

每1秒，sentinel对其他sentinel和redis执行ping

心跳检测，失败判定依据

心跳检查，失败判断依据

Redis-Sentienl通过三个定时任务，实现了Sentienl节点对三类节点的监控

至少需要3个实例，保证健壮性

如果哨兵只部署了两个，且都在redis节点上

经典的3节点哨兵集群

投票算法

1.故障转移时，判断一个master节点是否宕机，需要大部分哨兵都同意才行，涉及到分布式选举的问题。

2.即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

一个哨兵进程对redis服务器进行监控，可能会出现问题

可使用多个哨兵进行监控，各个哨兵间会互相进行监控，这样就形成多哨兵模式

当主机宕机后，从库必须投票选举，过半的数量认为主机宕机，才生效。

1.从成本角度看：3台和4台的可允许失效错误的机器数都是1，还不如用3台；

2.从概率看：4台节点数比3台节点数，更容易发生1台机器生效错误的问题。

每次一个哨兵要做主备切换

quorum最好配置所有哨兵的一半+1

配置quorum 主库客观下线最小同意人数

首先，需要quorum数量的哨兵认为odown，然后选举出来一个哨兵做切换。

然后，这个哨兵还得的到mojority个哨兵的授权，才能正式执行切换。

如果quorum<mojority

但是如果quorum>mojority 

每个 Sentinel 以每秒一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个PING命令

每个 Sentinel 以每秒钟一次的频率向它所知的 Master，Slave 以及其他 Sentinel 实例发送一个 PING 命令

如果一个实例，距离最后一次有效回复 PING 命令的时间，超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线；

实例（instance）

如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。

如果一个 Master 被标记为主观下线，则正在监视这个 Master 的所有 Sentinel ，要以每秒一次的频率，确认Master 的确进入了主观下线状态

如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。

当有足够数量的 Sentinel在指定的时间范围内，确认 Master 的确进入了主观下线状态， 则 Master 会被标记为客观下线

Sentinel 实例/节点需要

挑选出新的master后，sentinel向原master的从服务发送slaveof新master的命令，

当下线的原master上线时，sentinel会发送slaveof命令让其成为新master的slaver

哨兵模式在节点失败时，分为两种下线方式、sdown和odown转换机制

图解什么是主观下线， 什么是客观下线

主观下线

客观下线

原因：只有一个sentinel节点完成故障转移

集群通过投票（获取半数以上选票）选举Leader执行主从切换

选举

对这个slave执行slaveof no one

哨兵从服务器列表中挑选Master 、slave-master选举算法、选新 master 的原则、新master选取策略

筛选与过滤

排序

新Master诞生、Slave配置的自动纠正

configuration epoch

configuration传播

sentinel会保持对其关注

以前的Master如果重连了，那么以前的Master会变成新Master的Slave

客服端从哨兵订阅消息，进行主库切换

JedisSentinelPool -> MasterListener --> sub "+switch-master"

sentinel是配置中心，而非代理！

客户端初始化时连接的是sentinel集合，而不是具体的redis节点，但是sentienl只是配置中心而不是代理

上线主节点

下线主节点

上线从节点

下线从节点

上线sentinel

临时下线或者永久下线，需要考虑读写分离和原因

1、当作副本，并且是高可用的基础

2、扩展redis 读操作的能力

+switch-master: 从节点晋升

+convert-to-slave: 切换为从节点

+sdown: 主观下线

支持N个master node

可以在多台机器上，部署多个master（实例）

每个master存储一部分的数据

每个redis实例可以挂Redis从实例

每个master来说，写久写到master

读就从master对应的slave去读

提供内置的高可用支持

部分master不可用时，还是可以继续工作的。

每个master都有slave节点

如果master挂掉，redis cluster这套机制，就会自动将某个slave切换成master

如果redis主实例master挂了，会自动切换到redis从实例顶上来。

所有的节点都要有一个主节点

缺点

特点

让每个主机都拥有转发能力

快照同步

增量同步

无盘复制

wait 指令

安装ruby环境

安装redis gem

配置文件

Rax

cluster keyslot k

如果需要添加节点，只需要各将旧节点的部分槽位移动到新节点上即可；

如果需要删除及诶单，只需要将被删除的节点槽位转移到其余节点即可；

只有一个表

所有的key都放在这个表里

自动生成16384个分区表

插入数据时，会根据如上简单算法来决定key应该存在哪个分区

每个分区里有很多key

当前集群有3个节点 

节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.

假如redis集群里面能存放90个key，那么redis集群把90key平分到3个主机

redis对每个主机里面30个存储位置都编号，当应用连接到主机1上面时，发送一个写的命令

主机使用CRC16，算出槽号

如果再发一个命令set age 22，那么主机2使用CRC16，再算槽号，再转发

高并发场景下时不可接受的。
并发，一台机器挂掉了，原来是对3取模存的数据，现在对2取模取数据，会导致所有请求全部无法拿到有效的缓存。
最大问题，一个master宕机那么大量的数据就需要重新计算写入缓存。

可能集中在某个hash区间内的值特别多，那么会导致大量的数据都涌入同一个master内，造成master的热点问题，性能出现瓶颈

给每个master节点都做了均匀分布的虚拟节点
然后这样的话，在每个区间内，大量的数据，都会均匀的分布到不同的节点内，而不是按照顺时针的顺序去走，全部涌入同一个master内。

redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取对应的hash slot
redis cluster中每个master都会持有一部分的hash slot，比如有3个master，那么可能每个master持有5000多个hash slot
hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去，移动hash slot的成本是非常低的。
客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现。

任何一台机器宕机，不影响其他节点，因为key找的是hash slot，不是机器。

redis发现某台机器宕机，会把这台机器的slot快速的分配到其他的master上

故障的信息

master->slave之间的关系

hash slot->node之间的映射表关系

基于zookeeper集中式元数据的维护和存储

storm

每个节点都会频繁的给其他节点发送ping，

其中包含自己的状态，还有自己维护的集群元数据，互相通过ping交换元数据。

ping消息深入

返回ping和meet

包含自己的状态和其他信息

也可用于信息广播和更新

每个节点通过meet命令交换槽位信息

某个节点发送meet给新加入的节点，让新节点加入到集群中，然后新节点就会开始于其他节点进行通信

其实，内部就是发送了一个gossip meet信息，通知那个节点去加入我们的集群

某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

好处

不好

好处

缺点

每个节点都有一个专门用于节点间通信的端口，就是自己的端口号+10000

每个节点间个一段时间都会往另外几个节点发送ping消息，同时其他节点收到ping之后返回pong

在Redis Cluster集群模式架构下，每个redis要开放两个端口

创建集群时，集群节点直接要相互通信，使用 redis-server的端口+10000 = 新的集群的监听端口

10000端口号

6379

16379

图解Redis Cluster集群模式的端口号

客户端重定向

多键操作

读取数据

常见问题

如果一个节点认为另外一个节点宕机了，那么就是pfail，主观宕机
如果多个节点都认为另外一个节点宕机了，就是fail，客观宕机，跟哨兵几乎一样 sdown，odown

根据cluster-node-timeout内某个节点一直没有返回pong，那么就会被认为pfail

如果一个节点认为某个节点pfail了，那么就会在gossip消息中，ping给其他节点，如果超过半数节点都认为pfail了，那么就会变成fail

对宕机的master node，从其所有slave node中，选择一个切换成master node

检查每个slave node与master node 的断开时间，如果超过了cluster-node-timeout*cluster-slave-validity-factory,那么久没有资格切换成master

每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举

所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（n/2+1）都投票给了某个从节点，那么选举通过，那个从节点可以成为master

从节点执行主备切换，从节点切换为主节点

meet

redis-trib.rb add-node

手工

pipeline migrate

redis-trib.rb reshard

通过ping/pong发现故障

主观下线

客观下线

资格检查

准备选举时间

选举投票

替换主节点

迁移槽

忘记节点

关闭节点

0.先尝试访问源节点

1.源节点返回ASK转向

2.向新节点发送asking命令

3.向新节点发送命令

moved

tips

问题：mget/mset必须在同一个槽

实现

cluster-require-full-coverage=yes

大多数业务无法容忍

来源

优化

集群状态下的pub/sub

数据倾斜

请求倾斜

只读连接

读写分离客户端会非常复杂

redis-trib.rb import

在线迁移

redis-server --service-install redis.windows.conf --loglevel verbose命令注册服务

redis-server --service-start开启服务

redis-server.exe --service-uninstall

yum install gcc-c++

gcc -v

将所有需要配置文件进行配置

确认是否所有都安装好

commons-pool2-2.3.jar

jedis-2.7.0.jar

Jedis jedis = new Jedis(ip,port);

jedis就可以使用所有指令方法

基础

package com.xiaoye;

import redis.clients.jedis.Jedis;

/**
 * @author 小也
 * @create 2021/4/28 19:47
 */
public class Test {

    public static void main(String[] args) {
        //万物皆对象，先弄个jedis的对象出来，构造函数为主机地址和端口号
        Jedis jedis = new Jedis("8.140.12.96",6379);
        //给密码，获取权限
        jedis.auth("密码");
        //测试是否成功连接，控制台输出PONG则连接成功
        System.out.println(jedis.ping());

    }
}

Jedis jedis = new Jedis("localhost",6379);

jedis.set("username","zhangsan");

jedis.close();

• 客户端可能会挑选任意一个redis实例去发送命令，每个redis实例接收到命令，都会根据key计算对应的hash slot
• 如果在本地就在本地处理，否则返回moved给客户端，客户端进行重定向
• cluster keyslot mykey，可以查看一个key对应的hash slot是什么
• 用redis-cli的时候，可以加-c参数，支持自动的请求重定向，redis-cli接收到moved之后，会自动重定向到对应的节点执行命令。

就是根据key计算CRC16的值，然后跟苦16384取模，拿到对应的hash slot
用hash tag可以手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，比如set mykey1:{100}和setmykey2:{100}

节点间通过gossip协议进行数据交换，就知道每一个hash slot在哪个节点上。

• 在JedisCluster初始化的时候，就会随机选择一个node，初始化hashslot->node映射表，同时为每个节点创建一个jedisPool连接池
• 每次基于JedisCluster执行操作，首先会在本地计算key的hashslot，然后在本地缓存的映射表找到对应的节点。
• 如果node正好还持有hash slot就ok；如果说进行了reshard这样的操作，hashslot不在那个节点上了，就会返回moved
• 然后JedisCluster发现对应节点返回moved，那么利用该节点的元数据，更新本地的hash slot ->node的映射表缓存
• 重复上面步骤，知道找到对应节点，如果重试超过5次，那么就报错，JedisClusterMaxRedirectionException。

如果hash slot正在迁移，那么会返回ask给jedis

jedis接到ask重定向之后，会重定向到目标节点去执行，但是因为ask发生在hash slot迁移过程中，所以不会更新本地缓存的映射表

1.用户发送一个请求

2.收到请求，先查本地ehcache缓存，如果没有再查redis

3.如果ehcache和redis都没有，就查数据库

4.将数据库中的结果，写入ehcache和redis中

可以设置每秒2000个请求，一秒过来5000个请求，此时只会有2000个请求会通过限流组件，进入数据库
剩下3000个走降级，返回一些友好提示。

好处：

• 1.数据库绝对不会死，限流确保了每秒只会过去2000个请求。
• 2.数据库不死，对用户来说2/5是可以被处理的
• 3.只要有2/5请求可以被处理，就意味着你的系统没死，多点几次可能还能用，用户感觉只是有点故障。

1、如果控制能够被缓存，这就意味着缓存需要更多的空间存储来存储更多的键

2、及时对空值设置了过期时间，还是会存在缓存层和存储层的数据，会出现一段时间窗口不一致，这对保持一致性的业务有影响

1、产生更多的键

2、缓存层和存储层数据短期不一致

slowlog-max-len

slowlog-log-slower-than

slowlog get [n]

slowlog len

slowlog reset

1、客户端发送命令到服务端

2、排灯等待执行

3、执行命令

3、返回结果到客户端

slowlog-max-len

slowlog-log-slower-than

1、slowlog get[n].

2、slowlog len

3、slowlog reset

1、slowlog-max-len不要设置过大，默认10ms，通常设置1ms

2、slowlog-log-slower-than不要设置过小，通常设置为1000

3、理解命令的生命周期

4、定期持久化慢查询

embstr

int

raw

通过 `object encoding k` 验证

string < 10K

hash,list,set元素不超过5000

网络阻塞

redis阻塞

集群节点数据不均衡

频繁序列化

应用异常

redis-cli --bigkeys

scan + debug object k

主动报警：网络流量监控，客户端监控

内核热点key问题优化

阻塞（注意隐性删除，如过期、rename）

unlink命令 （lazy delete, 4.0之后）

big hash渐进删除：hscan + hdel

节省内存、但编程复杂

set

bitmap

hyperLogLog

业务希望的 redis 并发量

客户端执行命令时间

redis 资源：应用个数 * maxTotal < redis最大连接数

计数器先累计，然后批量写入DB

如图

如果同一个数据有很多读请求过来，全都进行数据库的更新是没有意义的，

可以做过滤，如果发现队列中已经有一个更新缓存的请求了，就不用再放个更新请求操作进去了，直接等待前面的更细 操作请求完成即可

如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。

（1）读请求长时阻塞

（2）读请求并发量高

（3）多台机器，要确保对同一个商品的读写请求，全部路由到同一台机器上，否则不在同一台机器上队列也就没用了

（4）热点商品的路由问题，导致请求的倾斜