Redis for OPS 02：消息订阅和事务管理

写在前面的话

上一节谈了 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

""

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) ""

2) ""

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"

到此，简单的命令我们就学的差不多的，真正会用的其实没几个，接下来的内容才是我们运维更加在意的东西！那就是调优和架构方面的设计。

巴特西

Redis for OPS 02：消息订阅和事务管理

最新文章

热门文章