Redis持久化存储（三）

redis高级特性-发布订阅消息服务功能

Pub/Sub

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

127.0.0.1:6379> help subscribe

  SUBSCRIBE channel [channel ...]  #指定一个频道channel
  summary: Listen for messages published to the given channels #监听消息发布
  since: 2.0.0
  group: pubsub #pubsub组

127.0.0.1:6379> help @pubsub   #帮助信息

Redis持久化存储（三）

127.0.0.1:6379> subscribe channel01  #订阅01的频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel01"
3) (integer) 1

开另一个窗口

发布，在同一个频道

127.0.0.1:6379> publish channel01 hello
(integer) 1
127.0.0.1:6379> publish channel01 word
(integer) 1

Redis持久化存储（三）

按一定模式批量订阅

127.0.0.1:6379> PSUBSCRIBE channel* #这个名字可以随便起
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "channel*"

服务发布

Redis持久化存储（三）

客户订阅都能监听得到

Redis持久化存储（三）

普通队列，发布订阅都属于消息队列的一种

redis数据过期实战及redis服务数据过期原理

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

超时后只有对key执行DEL命令或者SET命令或者GETSET时才会清除。这意味着，从概念上讲所有改变key的值的操作都会使他清除。例如，INCR递增key的值，执行LPUSH操作，或者用HSET改变hash的field所有这些操作都会触发删除动作。

使用PERSIST命令可以清除超时，使其变成一个永久的key。

如果key被RENAME命令修改，相关的超时时间会转移到新key上面。

如果key被RENAME命令修改，比如原来就存在Key_A,然后调用RENAME Key_B Key_A命令，这时不管原来Key_A是永久的还是设置为超时的，都会由Key_B的有效期状态覆盖。

刷新过期时间

对已经有过期时间的key执行EXPIRE操作，将会更新它的过期时间。有很多应用有这种业务场景，例如记录会话的session。

返回值

integer-reply, 具体的:

Integers

这种回复类型只是用CRLF结尾字符串来表示整型，用一个字节的“：”作为前缀。例如：“：0\r\n”，或者“:1000\r\n”是整型回复。

像INCR或者LASTAVE命令用整型回复作为实际回复值，此时对于返回的整型没有特殊的意思。它仅仅是为INCR、LASTSAVE的UNIX时间等增加数值。

一些命令像EXISTS将为true返回1，为false返回0。

其它命令像SADD、SREM和SETNX如果操作实际完成了的话将返回1，否则返回0。

接下来的命令将回复一个整型回复：SETNX、DEL、EXISTS、INCR、INCRBY、DECR、DECRBY、DBSIZE、LASTSAVE、RENAMENX、MOVE、LLEN、SADD、SREM、SISMEMBER、SCARD。

1 如果成功设置过期时间。
0 如果key不存在或者不能设置过期时间
[root@redis ~]# redis-cli -p 6379 -a zsq
127.0.0.1:6379> flushdb  #删除当前库
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set name zsq 
OK
127.0.0.1:6379> ttl name  # -1为不过期
(integer) -1

检查key存在不存在

127.0.0.1:6379> exists name  #存在就是1
(integer) 1
127.0.0.1:6379> 
127.0.0.1:6379> del name  #先删除
(integer) 1
127.0.0.1:6379> exists name  #再查看，不存在就是0
(integer) 0

过期expire设置

127.0.0.1:6379> help expire

  EXPIRE key seconds
  summary: Set a key's time to live in seconds
  since: 1.0.0
  group: generic

127.0.0.1:6379> expire name 5 #过期5秒
(integer) 0
127.0.0.1:6379> ttl name
(integer) -2
127.0.0.1:6379> get name  #数据过期了
(nil)

设置时间戳过期

[root@redis ~]# date +%s -d "2016-08-26 20:32:23"  #设置时间格式
1482755543
[root@redis ~]# date #查看当前时间
2016年 08月 26日 星期一 20:30:12 CST
[root@redis ~]# redis-cli -p 6379 -a zsq
127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> set name a
OK
127.0.0.1:6379> expireat name 1482755543 #设置时间
(integer) 1
127.0.0.1:6379> ttl name  #查看过期时间正在倒数
(integer) 89
127.0.0.1:6379> ttl name
(integer) 88

Keys的过期时间

通常Redis keys创建时没有设置相关过期时间。他们会一直存在，除非使用显示的命令移除，例如，使用DEL命令。

EXPIRE一类命令能关联到一个有额外内存开销的key。当key执行过期操作时，Redis会确保按照规定时间删除他们。

key的过期时间和永久有效性可以通过EXPIRE和PERSIST命令（或者其他相关命令）来进行更新或者删除过期时间。

过期精度

在 Redis 2.4 及以前版本，过期期时间可能不是十分准确，有0-1秒的误差。

从 Redis 2.6 起，过期时间误差缩小到0-1毫秒。

过期和持久

Keys的过期时间使用Unix时间戳存储(从Redis 2.6开始以毫秒为单位)。这意味着即使Redis实例不可用，时间也是一直在流逝的。

要想过期的工作处理好，计算机必须采用稳定的时间。如果你将RDB文件在两台时钟不同步的电脑间同步，有趣的事会发生（所有的 keys装载时就会过期）。

即使正在运行的实例也会检查计算机的时钟，例如如果你设置了一个key的有效期是1000秒，然后设置你的计算机时间为未来2000秒，这时key会立即失效，而不是等1000秒之后。

Redis如何淘汰过期的keys

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

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

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

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

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

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

在复制AOF文件时如何处理过期

为了获得正确的行为而不牺牲一致性，当一个key过期，DEL将会随着AOF文字一起合成到所有附加的slaves。在master实例中，这种方法是集中的，并且不存在一致性错误的机会。

然而，当slaves连接到master时，不会独立过期keys（会等到master执行DEL命令），他们任然会在数据集里面存在，所以当slave当选为master时淘汰keys会独立执行，然后成为master。

redis高级特性-简单事务

事务

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

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

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

EXEC 命令负责触发并执行事务中的所有命令：

如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。

另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中。

然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。

如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。

使用redis-check-aof程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

从 2.2 版本开始，Redis 还可以通过乐观锁（optimistic lock）实现 CAS （check-and-set）操作，具体信息请参考文档的链接。

http://www.redis.cn/topics/transactions.html

127.0.0.1:6379> get name
"zsq"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name a  
QUEUED  #放在队列里边
127.0.0.1:6379> set name b
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get name
"b"

事务也有一个组

127.0.0.1:6379> help multi

  MULTI -
  summary: Mark the start of a transaction block
  since: 1.2.0
  group: transactions #组

127.0.0.1:6379> help @transactions

  DISCARD -
  summary: Discard all commands issued after MULTI
  since: 2.0.0

  EXEC -  #执行事务中的所有命令
  summary: Execute all commands issued after MULTI
  since: 1.2.0

  MULTI -  #执行MULTI就是开始一个事务
  summary: Mark the start of a transaction block
  since: 1.2.0

  UNWATCH -
  summary: Forget about all watched keys
  since: 2.2.0

  WATCH key [key ...]
  summary: Watch the given keys to determine execution of the MULTI/EXEC block
  since: 2.2.0

View Code