Redis发布和订阅
Redis 发布订阅(pub/sub)是一种消息通信模式：
发送者(pub)发送消息
订阅者(sub)接收消息
Redis 客户端可以订阅任意数量的频道

subscribe c1 c2 c3 订阅c1 c2 c3

publish c1 “hello redis” 向c1频道发布消息

psubscribe c* “c*” #订阅所有发送则是c开头的消息

发送消息和上面的没有区别

事务实例
Redis中事务的使用其实非常简单，通过MULTI命令即可。

127.0.0.1:6379> multi
OK

在MULTI命令执行之后，我们可以继续发送命令执行，但此时命令不会立即执行，而是保持到一个队列中，如下

127.0.0.1:6379> set k1 bbb
 QUEUED
 127.0.0.1:6379> set k2 ccc
 QUEUED
 127.0.0.1:6379> set k3 ddd
 QUEUED
 127.0.0.1:6379> set k4 eee
 QUEUED
 127.0.0.1:6379> get k1
 QUEUED

当所有的命令都输入完成后，我们可以输入EXEC命令来执行队列中的命令，如下

127.0.0.1:6379> exec
1. OK
2. OK
3. OK
4. OK
5. “bbb”

Watch
watch命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到exec命令（事务中的命令是在exec之后才执行的，所以在multi命令后可以修改watch监控的键值）。假设我们通过watch命令在事务执行之前监控了多个Keys，倘若在watch之后有任何Key的值发生了变化，exec命令执行的事务都将被放弃，同时返回Null multi-bulk应答以通知调用者事务执行失败。

exec后会自动执行unwatch命令，撤销监控

UnWatch
撤销对一个key的监控

Redis持久化
所谓的持久化就是保持我们的数据不丢失，将数据通常保存在我们的硬盘中。在Redis中持久化的方式有两种，一种是快照持久化，一种是AOF持久化，各有各的优缺点，在项目中我们得根据实际的情况来选择具体的持久化方式。本文主要介绍快照持久化，下篇文章介绍AOF持久化。

快照持久化
也叫RDB持久化方式。就是通过拍摄快照的方式来实现持久化，将某个时间的内存数据存储在一个rdb文件中。在redis服务重新启动的时候会加载rdb文件中的数据。

优缺点
优点
RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。
RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。
RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。
比起AOF，在数据量比较大的情况下，RDB的启动速度更快。

缺点
RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。

如何禁用快照持久化
1.在redis.conf配置文件中注释掉所有的save配置
2.在最后一条save配置追加吃命令

save “”

AOF持久化
与快照持久化通过直接保存 Redis 的键值对数据不同，AOF 持久化是通过保存 Redis 执行的写命令来记录 Redis 的内存数据。理论上说，只要我们保存了所有可能修改 Redis 内存数据的命令（也就是写命令），那么根据这些保存的写命令，我们可以重新恢复 Redis 的内存状态。AOF 持久化正是利用这个原理来实现数据的持久化与数据的恢复的

AOF优缺点
AOF 的优点
AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

AOF 的缺点
对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

持久化的一些使用建议
1.如果redis仅仅是用来做为缓存服务器的话，我们可以不使用任何的持久化。
2.一般情况下我们会将两种持久化的方式都开启。redis优先加载AOF文件来回复数据。RDB的好处是快速。
3.在主从节点中，RDB作为我们的备份数据，只在salve(从节点)上启动，同步时间可以设置的长一点，只留(save 900 1)这条规则就可以了。
4.开启AOF的情况下，主从同步是时候必然会带来IO的性能影响，此时我们可以调大auto-aof-rewrite-min-size的值，比如5GB。来减少IO的频率
5.不开启AOF的情况下，可以节省IO的性能影响，这是主从建通过RDB持久化同步，但如果主从都挂掉，影响较大