写在前面的话
上一节谈了 Redis 的安装以及五种基本数据类型的一些简单的操作，本章节主要看看 Redis 的另外一些特征，虽然可能不常用，但是还是需要了解的。对于我们运维人员来讲，这些东西更像拓展的知识，可能我们工作很多年都不会用到，但是当你慢慢的需要往运维开发方向发展以后，这些东西就会成为你解决问题的又一方案。另外一种思路。
发布订阅
Redis 发布消息一般有两种方式，消息队列和发布订阅。
对于消息队列，其角色包含：生产者 --> 消息队列 --> 消费者
生产者讲需要处理的任务放到队列中，消费者再不断的从队列中读取任务然后执行。其好处在于解耦合，易于横向扩展。
对于发布订阅，我们可以看成广播FM，我们只有在一个频道，就能收听到广播，调到这个频道的过程就是订阅。
和广播的原理类似，订阅者需要先将频道打开到指定频道，然后另外一个窗口开始发布消息：
SUBSCRIBE fm110
结果如图：
此时另外一个窗口开始往 fm110 的频道发布消息：
PUBLISH fm110 "hello"
结果如图：
此时查看订阅者窗口：
这就有点像QQ群聊天，只允许群主发言，其它可以多个人接收。
# 取消订阅指定的频道, 如果不指定频道，则会取消订阅所有频道 UNSUBSCRIBE [channel ...] # 订阅一个或多个符合给定模式的频道，以 * 作匹配符，如 it* 匹配以 it 开头的频道(it.news 、 it.blog等等) PSUBSCRIBE pattern [pattern ...] # 退订指定的规则, 如果没有参数则会退订所有规则 PUNSUBSCRIBE [pattern [pattern ...]] # 查看订阅与发布系统状态 PUBSUB subcommand [argument [argument ...]]
当然，Redis 的消息队列发布订阅其实是很粗糙的，如果真需要这样的内容，可以选择 RabbitMQ，Kafka 等。
事务处理
在 MySQL 中知道开启一个事务后，如果不 commit 的话是不会将修改刷写到磁盘的，在 Redis 中也存在这样的操作。
在 MySQL 中使用 start transaction 或者 begin 开启一个事务，在 Redis 则使用 multi。
在 MySQL 中取消回滚可以使用 rollback，Redis 则使用 discard 取消，不叫回滚，运维 Redis 并未执行。
在 MySQL 中提交采用 commit，在 Redis 中则使用 exec。
在 Redis 中采用的是乐观锁，可以通过模拟网上买票来测试：
在窗口1执行：
127.0.0.1:6379> set ticket 1 OK 127.0.0.1:6379> watch ticket OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> set ticket 0 QUEUED
暂时不执行它，然后取窗口2执行：
127.0.0.1:6379> get ticket "1" 127.0.0.1:6379> multi OK 127.0.0.1:6379> set ticket 0 QUEUED 127.0.0.1:6379> exec 1) OK
此时再去窗口1执行：
127.0.0.1:6379> exec (nil)
发现票以及被别人买走了！其中 watch 的作用在于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
其它全局操作
常用的命令如下：
# 显示连接的客户端 CLIENT LIST # 杀掉客户端 CLIENT KILL id 10 # 获取所有系统配置 CONFIG GET * # 获取匹配的配置 CONFIG GET log* # 在线修改配置 CONFIG SET requirepass helloworld # 登录 AUTH helloworld # 将修改的配置写入 redis.conf CONFIG REWRITE # 显示当前库中key数量 DBSIZE # 打印redis收到的命令 MONITOR # 删除当前库所有key FLUSHDB # 删除所有库的key FLUSHALL # 当前时间 TIME # 手动持久化 SAVE # 异步执行一个 AOF（AppendOnly File） 文件重写操作 BGREWRITEAOF # 在后台异步保存当前数据库的数据到磁盘 BGSAVE
结果如下：
127.0.0.1:6379> CLIENT LIST id=5 addr=127.0.0.1:48567 fd=8 name= age=15091 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client id=8 addr=127.0.0.1:48573 fd=9 name= age=660 idle=600 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=exec id=10 addr=127.0.0.1:48577 fd=10 name= age=14 idle=14 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=keys 127.0.0.1:6379> CLIENT KILL id 10 (integer) 1 127.0.0.1:6379> CONFIG GET log* 1) "logfile" 2) "/data/services/redis/logs/redis-6379.log" 3) "loglevel" 4) "notice" 127.0.0.1:6379> CONFIG SET requirepass helloworld OK 127.0.0.1:6379> keys * (error) NOAUTH Authentication required. 127.0.0.1:6379> AUTH helloworld OK 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) "helloworld" 127.0.0.1:6379> CONFIG REWRITE OK 127.0.0.1:6379> DBSIZE (integer) 1 127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> TIME 1) "1573022355" 2) "256540" 127.0.0.1:6379> MONITOR OK 1573022218.974627 [0 127.0.0.1:48573] "AUTH" "helloworld" 1573022226.451991 [0 127.0.0.1:48573] "keys" "*" 1573022268.293698 [0 127.0.0.1:48573] "FLUSHDB" 1573022292.090727 [0 127.0.0.1:48573] "FLUSHALL" 1573022355.256531 [0 127.0.0.1:48573] "TIME"
到此，简单的命令我们就学的差不多的，真正会用的其实没几个，接下来的内容才是我们运维更加在意的东西！那就是调优和架构方面的设计。