Redis笔记03

1、Redis管道

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。

• 客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。
• 服务端处理命令，并将结果返回给客户端

服务端处理命令，并将结果返回给客户端。这个连接可以很快或很慢。无论网络延如何延时，数据包总是能从客户端到达服务器，并从服务器返回数据回复客户端。这个时间被称之为 RTT (Round Trip Time - 往返时间)。

当客户端需要在一个批处理中执行多次请求时很容易看到这是如何影响性能的。例如，如果RTT时间是250毫秒（在一个很慢的连接下），即使服务器每秒能处理10万的请求数，我们每秒最多也只能处理4个请求。

管道技术

一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。这就是管道（pipelining），是一种几十年来广泛使用的技术。

#-e启用以下反斜杠转义的解释
#提前yum install nc -y 安装nc命令
[root@node02 ~]# echo -e "set k2 99\nincr k2\nget k2" | nc localhost 6379
+OK
:100
$3
100

2、Redis 发布/订阅（Pub/Sub）

订阅，取消订阅和发布实现了发布/订阅消息范式(引自wikipedia)，发送者（发布者）不是计划发送消息给特定的接收者（订阅者）。而是发布的消息分到不同的频道，不需要知道什么样的订阅者订阅。订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道什么样的发布者发布的。这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑。

应用场景：直播间聊天室等。

#订阅一个张大仙频道
127.0.0.1:6379> SUBSCRIBE zhangdaxian
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "zhangdaxian"
3) (integer) 1
1) "message"
2) "zhangdaxian"
3) "hello zhangdaxian"
#向张大仙频道中推送消息
127.0.0.1:6379> PUBLISH zhangdaxian "hello zhangdaxian"
(integer) 2

3、Redis 事务

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。事务可以一次执行多个命令， 并且带有以下两个重要的保证：

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

MULTI 命令用于开启一个事务，它总是返回 OK 。 MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC命令被调用时， 所有队列中的命令才会被执行。

1、第一个结点先开启事务，并把所有的命令放到一个队列中，后执行，由于第二个结点先执行事务，所以该结点执行完事务没有获取到k1的值。

2、第二个结点后开启事务，但先执行事务，并把队列中所有的命令执行完，成功删除了k1。

3、WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败

#监视k1
127.0.0.1:6379> watch k1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> keys *
QUEUED
127.0.0.1:6379> get k1
QUEUED
#后执行发现k1被修改，整个事务取消不执行
127.0.0.1:6379> EXEC
(nil)

#第二个客户端开启事务
127.0.0.1:6379> MULTI
OK
#更改k1的值
127.0.0.1:6379> set k1 update
QUEUED
#先执行
127.0.0.1:6379> exec
1) OK

为什么 Redis 不支持回滚（roll back）

如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

• 有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

4、Redis 之布隆过滤器

#获取布隆过滤器包
[root@node02 soft]# wget https://github.com/RedisBloom/RedisBloom/archive/refs/heads/master.zip
#安装unzip
[root@node02 soft]# yum install unzip -y
#解压
[root@node02 soft]# unzip master.zip 
[root@node02 soft]# cd RedisBloom/
#编译
[root@node02 RedisBloom]# make
[root@node02 RedisBloom]# cp redisbloom.so /usr/local/redis4/
[root@node02 redis4]# redis-server --loadmodule /usr/local/redis4/redisbloom.so 
127.0.0.1:6379> BF.ADD ooxx hello
(integer) 1
127.0.0.1:6379> BF.EXISTS ooxx hello
(integer) 1
#布谷鸟过滤器
127.0.0.1:6379> CF.ADD xxoo world
(integer) 1
127.0.0.1:6379> CF.EXISTS xxoo world
(integer) 1

5、Redis 过期

设置key的过期时间，超过时间后，将会自动删除该key。在Redis的术语中一个key的相关超时是不确定的。

只有对key执行DEL命令或者SET命令或者GETSET时才会清除。

• key的过期时间会随着访问延长码？ 不对！！
• 当key的值发生写时，会剔除过期时间。
• 可以定时key的过期 EXPIREAT key timestamp

# EXPIRE key seconds
# 设置k1的过期时间是50s
127.0.0.1:6379> SET k1 ooxx ex 50
OK
127.0.0.1:6379> ttl k1
(integer) 45
127.0.0.1:6379> ttl k1
(integer) 44
#访问k1过期时间不会变
127.0.0.1:6379> get k1
"ooxx"
127.0.0.1:6379> ttl k1
(integer) 39
#修改k1的值时剔除k1的过期时间
127.0.0.1:6379> set k1 xxoo 
OK
127.0.0.1:6379> ttl k1
(integer) -1

Redis如何淘汰过期的keys

Redis keys过期有两种方式：被动和主动方式。

• 当一些客户端尝试访问它时，key会被发现并主动的过期。

• 当然，这样是不够的，因为有些过期的keys，永远不会访问他们。 无论如何，这些keys应该过期，所以定时随机测试设置keys的过期时间。所有这些过期的keys将会从密钥空间删除。

具体就是Redis每秒10次做的事情：

1. 测试随机的20个keys进行相关过期检测。
2. 删除所有已经过期的keys。
3. 如果有多于25%的keys过期，重复步奏1。

这是一个平凡的概率算法，基本上的假设是，我们的样本是这个密钥控件，并且我们不断重复过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时刻，最多会清除1/4的过期keys。