【02】Redis for OPS:消息订阅和事务管理

写在前面的话

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

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

猜你喜欢

转载自www.cnblogs.com/Dy1an/p/11805098.html