Redis深入历险读书笔记第四章扩展篇

stream

1. Stream是Redis5.0引入的一种数据结果，它是一个新的强大的支持多播的可持久化消息队列。借鉴Kafka的设计。
2. 每一个Stream的唯一名称就是他在Redis里key。
3. 每个Stream可以挂多个消费组，每个消费组都有一个Stream内唯一的名称，会有一个有表表示消费组消费到那一条消息。

消息ID

消息ID的形式是timestampInMillis-sequence,时间戳+生成的第几条。

消息内容

键值队，形如hash结构。

独立消费

当在不定义消费组的前提下使用Stream，当Stream没有新消息时，可以阻塞等待。可以讲Stream当成一个普通列表使用。

消息如果忘记ack会怎样

Stream在每个消费者结构中保存了正在处理中的消息ID列表PEL，如果消费者收到了消息，处理完了但是没有回复ACK，就会导致PRL列表不断增长。

PEL如何避秒消息丢失

1. PEL保存了以发送出去的小弟ID。待客户端重新连接上之后，可以再次收到PEL中的消息ID列表。

Stream的高可用

Stream的高可用是建立在主从复制基础上的。

Info指令

info指令的信息块

1. server：服务器运行的环境参数
2. clients：客户端相关信息
3. memory：服务器运行内存统计参数
4. persistence：持久化信息
5. stats：通用统计数据
6. Replication：主从复制相关信息。
7. CPU：CPU使用情况
8. Cluster：集群信息
9. KeySpace：键值队统计数量信息。

Redsi每秒执行多少次指令

在谈分布式锁

Redlock算法

1. Redlock算法使用时要考虑出错重试，时钟飘逸等问题
2. Redlock需要向多个节点进行读写，所以性能会下降。

Redlock使用场景

1. 高可用性能。要注意使用成本，因为需要引入额外的library和多Redis实例。

过期策略

过期的Key的集合

1. Reids会将每个设置了过期时间的key放入一个单独的字典中，以后会有定时遍历这个字典来删除过期的key
2. 它还会使用惰性策略来删除过期的key，也就是在客户端访问这个key的时候，Redis对key的过期时间进行检查，如果过期了就立刻删除，如果说定时器是接种处理，那么多性删除就是零散处理。

定时扫描策略

Redis默认每秒进行10次过期扫描，过期扫描不会遍历过期字典中所有的key而是采用一种贪心策略：

1. 从过期字典中随机获取20个key
2. 删除这20个key中过期的key
3. 如果过期的key的比例超过1/4，那就重复1
4. 为了保证不出现循环过度，导致线程卡死现象，所以会有扫描时间上线一般不会超过25ms。

从节点的过期策略

从节点不会进行过期扫描，从节点对过期的处理是被动的。主节点在key到期时，会在AOF增加一条del指令，同步所有从节点，从节点通过执行del来过期key。

优胜劣汰——LRU

Redis提供的集中可选策略

1. noeviction：不会继续服务写请求（del可以继续），读请求可以继续，这样可以保证不会丢失数据，但是会让线上业务不能持续进行服务，这是默认淘汰策略。
2. volatile-lru：尝试淘汰设置了超时时间的key，最少使用的key会优先被淘汰。没有设置超时时间的key不会被淘汰，这样可以保证需要持久化的数据不会丢失。
3. volatile-ttl：比较key的剩余寿命的ttl值，ttl越小越有限淘汰。
4. volatile-random：淘汰的key时过期key集合中随检的key。
5. allkeys-lru：淘汰对象时所有的的key结合，而不是过期key集合。
6. allkeys-random：淘汰的key时随机的。

LRU算法

实现LRU算法需要除了key/value字典外，增加一个链表，链表头部时刚使用的数据，尾部是使用次数较低的数据，当空间满了之后会优先删除链表末端的数据。

懒惰删除

Redis为什么要使用懒惰删除

1. 删除指令del会直接释放对象的内存，一般情况下这个指令是没有明显延迟的，但是当对象过大时就会导致卡顿，所以引入懒惰删除

flush

主要是把操作丢个后台来异步操作删除。

Jedis

重试

Jedis默认时没有重试机制，，这意味着如果网络出现抖动，就会大范围报错。