Redis高级特性
1. 发布订阅模型
Redis 的 SUBSCRIBE 命令可以让客户端订阅任意数量的频道， 每当有新信息发送到被订阅的频道时， 信息就会被发送给所有订阅指定频道的客户端。下面是SUBSCRIBE命令和PUBLISH命令的用法：
-
SUBSCRIBE channel [channel ...]用于订阅给指定频道的信息。 -
PUBLISH channel message将信息 message 发送到指定的频道 channel。
发布订阅.JPG
Redis发布订阅功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。群聊时所有成员都订阅（SUBSCRIBE ）一个主题，然后成员发送群消息时实际上是向该主题发布（PUBLISH ）一条消息，从而实现通知。
1. Redis发布订阅机制的实现
订阅.JPG
发布.JPG
Redis发布订阅与ActiveMQ的比较
- ActiveMQ支持多种消息协议，包括AMQP，MQTT，Stomp等，并且支持JMS规范，但Redis没有提供对这些协议的支持。
- ActiveMQ提供持久化功能，但Redis无法对消息持久化存储，一旦消息被发送，如果没有订阅者接收，那么消息就会丢失。
- ActiveMQ提供了消息传输保障，当客户端连接超时或事务回滚等情况发生时，消息会被重新发送给客户端，Redis没有提供消息传输保障。
参考文章
- https://redisbook.readthedocs.io/en/latest/feature/pubsub.html
- https://blog.csdn.net/fly910905/article/details/78495971
2. Redis事务
Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
- 批量操作在发送 EXEC 命令前被放入队列缓存。
- 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
- 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。
一个事务从开始到执行会经历以下三个阶段：
- 开始事务。
- 命令入队。
- 执行事务。
下面是一个例子：
redis 127.0.0.1:7000> multi
OK
redis 127.0.0.1:7000> set a aaa
QUEUED
redis 127.0.0.1:7000> set b bbb
QUEUED
redis 127.0.0.1:7000> set c ccc
QUEUED
redis 127.0.0.1:7000> exec
1) OK
2) OK
3) OK
单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。
事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。
3. Redis持久化
Redis持久化的目的是为了灾难恢复。Redis主要支持两种方式进行持久化：RDB和AOF：
- RDB：全量备份。是Redis默认的数据备份方式。它会周期性的生成一个数据快照，包含了某个时间点redis内存中的所有数据，并保存在一个名为dump.rdb的文件中。Redis重启时会将dump.rdb中的数据加载到内存中进行数据恢复。
- AOF：增量备份。将每条写入命令以append-only的方式写入日志。在redis重启时，可以通过回放AOF中所有写入指令来重新构建整个redis集群。
Redis需要执行RDB备份的时候服务器会执行以下操作：
- redis调用系统的fork()函数创建一个子进程。
- 子进程将数据集写入一个临时的RDB文件。
- 当子进程完成对临时的RDB文件的写入时，redis使用原子性的rename系统调用将临时文件重命名为dump.rdb文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。
同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。第一次Slave向Master请求同步的流程是： Slave首次成为Master的从节点后，会向Master发出全量同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。
之后每一个写操作，Master都会同步给Slave。除此以外，Slave会定时向Master发送REPLCONF ACK {offset}命令，其中offset指从节点保存的复制偏移量。REPLCONF ACK命令的作用包括：检测主从服务器的网络连接状态以及Master判断数据丢失（主节点会与自己的offset对比，如果从节点数据缺失，主节点会推送缺失的数据）。
更多关于主从复制原理，请参考：https://www.cnblogs.com/kismetv/p/9236731.html
RDB模式优缺点：
- RDB模式对Redis对外提供的读写服务性能影响很小，因为Redis主进程进行RDB备份时，会fork一个子进程来进行磁盘IO操作。
- 相对与AOF模式，使用rdb文件进行数据恢复的速度更快。
- RDB模式由于是周期性的进行数据快照，因此会存在数据丢失的问题。
在Redis配置文件中，通过配置以下内容开启AOF模式：
- 将
appendonly设置从no修改为yes
appendonly yes
- 指定本地AOF数据文件名，默认值为
appendonly.aof
appendfilename "appendonly.aof"
- 指定更新日志条件
# appendfsync always
appendfsync everysec
# appendfsync no
- always：同步持久化。每次发生数据变化会立刻写入到磁盘中。性能较差但数据不会丢失
- everysec：出厂默认设置，每秒异步记录一次（默认值）
- no：不同步
AOF是存放每条写命令的，所以会不断的增大。当大到一定程度时，AOF会做rewrite操作，rewrite操作就是基于当时redis的数据重新构造一个小的AOF文件，然后将大的AOF文件删除。
AOF模式的优缺点：
- AOF模式能够防止数据丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。
- AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
- AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
- 对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
- AOF 开启后，写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件。当然，每秒一次 fsync，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）
参考文章
4. Redis过期策略
Redis过期策略主要包括两部分：定期删除和惰性删除。
定期删除指的是，Redis默认每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。
由于定期删除策略只是随机挑选一部分key进行检测，因此可能存在大量key过期了仍然没有删除，此时就需要惰性删除机制了。
惰性删除指的是，Redis在返回某个key值时，会检测这个key是否过期，如果过期了就执行删除操作，然后返回空。
此时，仍然可能存在大量key定期删除策略和惰性删除策略都没有覆盖到，此时内存耗尽了，那么Redis就会启用内存淘汰机制。
内存淘汰机制指的是，当内存空间不足时，Redis淘汰key的策略。主要包括以下几种：
- noeviction: 当内存不足以容纳新写入数据时，新的写入操作直接报错。
- allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key。
- allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key。
- volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key。
- volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
- volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。
