1、发布订阅
1.1简介
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道。
1.2 示例
下图展示了频道 channel1，以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1之间的关系
当有新消息通过 PUBLISH 命令发送给频道 channel1 时，这个消息就会被发送给订阅它的三个客户端：
1.3 命令
订阅频道：
SUBSCRIBE channel [channel ...]订阅给定的一个或多个频道的信息
PSUBSCRIBE pattern [pattern ...]订阅一个或多个符合给定模式的频道。
发布频道：
PUBLISH channel message 将信息发送到指定的频道。
退订频道：
UNSUBSCRIBE [channel [channel ...]] 指退订给定的频道。
PUNSUBSCRIBE [pattern [pattern ...]]退订所有给定模式的频道。
例子：
客户端订阅CCTV1频道
新消息通过publish发送给CCTV1
客户端收到推送的消息
1.4 应用场景
这一功能最明显的用法就是构建实时消息系统，比如普通的即时聊天，群聊等功能
1、在一个博客网站中，有100个粉丝订阅了你，当你发布新文章，就可以推送消息给粉丝们。
2、微信公众号模式
2、Redis 多数据库
Redis下，数据库是由一个整数索引标识，而不是由一个数据库名称。默认情况下，一个客户端连接到数据库0。
redis配置文件中下面的参数来控制数据库总数：
database 16 //(从0开始 1 2 3 …15)
2.1 命令
select 数据库//数据库的切换
move
key 名称
数据库 //移动数据（将当前key移动另个库)
flushdb //清除当前数据库的所有key
flushall //清除整个Redis的数据库所有key
3、Redis事务
Redis 事务可以一次执行多个命令，（按顺序地串行化执行，执行中不会被其它命令插入，不许加塞）
3.1 简介
批量操作在发送 EXEC 命令前被放入队列缓存。
收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。
1、Redis会将一个事务中的所有命令序列化，然后按顺序执行
2、执行中不会被其它命令插入，不许出现加赛行为
一个事务从开始到执行会经历以下三个阶段：
开始事务。
命令入队。
执行事务。
事务的错误处理：
队列中的某个命令出现了报告错误，执行时整个的所有队列都会被取消。
事务的错误处理：
如果执行的某个命令报出了错误，则只有报错的命令不会被执行，而其它的命令都会执行，不会回滚。
3.2 命令
Redis 不支持回滚（roll back）
正因为redis不支持回滚功能，才使得redis在事务上可以保持简洁和快速。
3.3 示例
3.3.1 示例1 MULTI EXEC
转帐功能，A向B帐号转帐50元。一个事务的例子，它先以 MULTI 开始一个事务，然后将多个命令入队到事务中，最后由 EXEC 命令触发事务
1输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行
2直到输入Exec后，Redis会将之前的命令队列中的命令依次执行
3.3.2 示例2 DISCARD放弃队列运行
1输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行
2直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
3命令队列的过程中可以通过discard来放弃队列运行
3.3.3 示例3事务的错误处理
事务的错误处理：
如果执行的某个命令报出了错误，则只有报错的命令不会被执行，而其它的命令都会执行，不会回滚。
3.3.4 示例4 事务的错误处理
事务的错误处理：
队列中的某个命令出现了报告错误，执行时整个的所有队列都会被取消。
3.3.5 示例5事务的WATCH
WATCH key [key ...]
监视一个(或多个)
key ，如果在事务执行之前这个(或这些)
key 被其他命令所改动，那么事务将被打断。
需求：某一帐户在一事务内进行操作，在提交事务前，另一个进程对该帐户进行操作。
3.3.6 示例六 UNWATCH
Redis Unwatch 命令用于取消 WATCH 命令对所有 key 的监视。
如果在执行WATCH命令之后，EXEC命令或DISCARD命令先被执行的话，那就不需要再执行UNWATCH了
3.4 应用场景
一组命令必须同时都执行，或者都不执行。
我们想要保证一组命令在执行的过程之中不被其它命令插入。
商品秒杀（活动）。
4、Redis数据淘汰策略 redis.conf
Redis官方给的警告，当内存不足时，Redis会根据配置的缓存策略淘汰部分Keys，以保证写入成功。当无淘汰策略时或没有找到适合淘汰的Key时，Redis直接返回out of memory错误。
最大缓存配置
在 redis 中，允许用户设置最大使用内存大小：maxmemory 512G
redis 提供6种数据淘汰策略：
建议：了解了Redis的淘汰策略之后，在平时使用时应尽量主动设置/更新key的expire时间，主动剔除不活跃的旧数据，有助于提升查询性能
5、持久化
数据存放于：
内存：高效、断电（关机）内存数据会丢失
硬盘：读写速度慢于内存，断电数据不会丢失
6.1 RDB
RDB：是redis的默认持久化机制。 RDB相当于照快照，保存的是一种状态。
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为
dump.rdb。
优点：
快照保存数据极快、还原数据极快
适用于灾难备份
缺点：小内存机器不适合使用,RDB机制符合要求就会照快照
快照条件：
1、服务器正常关闭时 ./bin/redis-cli shutdown
2、key满足一定条件，会进行快照
vim redis.conf 搜索save
:/save
save 900 1 //每900秒（15分钟）至少1个key发生变化，产生快照
save 300 10 //每300秒（5分钟）至少10个key发生变化，产生快照
save 60 10000 //每60秒（1分钟）至少10000个key发生变化，产生快照
5.2 AOF
由于快照方式是在一定间隔时间做一次的，所以如果redis 意外down 掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof 持久化方式。
Append-only file:aof 比快照方式有更好的持久化性，是由于在使用aof 持久化方式时,redis 会将每一个收到的写命令都通过write 函数追加到文件中(默认是appendonly.aof)。当redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
有三种方式如下（默认是：每秒 fsync 一次）
产生的问题：
aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test命令 100 次，文件中必须保存全部的 100 条命令，其实有 99 条都是多余的。
原文：https://www.cnblogs.com/lgh544/p/12905643.html