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   #帮助信息

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

按一定模式批量订阅

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

服务发布

客户订阅都能监听得到

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

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次做的事情：

  1. 测试随机的20个keys进行相关过期检测。
  2. 删除所有已经过期的keys。
  3. 如果有多于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

 

redis高级特性-持久化快照及aof技术

Redis 提供了不同级别的持久化方式:

Ÿ   RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.

Ÿ   AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

Ÿ   如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

Ÿ   你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

Ÿ   最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始:

RDB的优点

Ÿ   RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.

Ÿ   RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.

Ÿ   RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.

Ÿ   与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

Ÿ   如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.

Ÿ   RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

AOF 优点

  • 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
  • AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
  • Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
  • AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
  • 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  • 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

AOF 缺点

如何选择使用哪种持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

Note: 因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是一个长期计划。） 接下来的几个小节将介绍 RDB 和 AOF 的更多细节。

快照

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。你也可以通过调用 SAVE或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。

比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集:

Save 60 1000

这种持久化方式被称为快照 snapshotting.

127.0.0.1:6379> keys *  #查看数据
1) "name"
2) "name1"
127.0.0.1:6379> flushall #将数据全部清空
OK
127.0.0.1:6379> set k100 v100 #创建数据
OK
[root@redis ~]# cd /application/data/ #进入到rdb文件的目录
[root@redis data]# ls
dump.rdb
[root@redis data]# ll --full-time #查看时间
总用量 4
-rw-r--r--. 1 root root 18 2016-08-26 21:36:20.868781060 +0800 dump.rdb


127.0.0.1:6379> keys * 
1) "k100"
127.0.0.1:6379> set k101 v100
OK

再查看时间信息

[root@redis data]# ll --full-time
总用量 4
-rw-r--r--. 1 root root 18 2016-08-26 21:36:20.868781060 +0800 dump.rdb

上面两种写入对dump.rdb文件都没有写入

127.0.0.1:6379> save #save保存
OK

保存以后，时间发生了变化，说明已经被写入了

[root@redis data]# ll --full-time
总用量 4
-rw-r--r--. 1 root root 42 2016-08-26 21:39:54.305778763 +0800 dump.rdb

bgsave测试

127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> bgsave
Background saving started

时间也发生了变化

[root@redis data]# ll --full-time
总用量 4
-rw-r--r--. 1 root root 42 2016-08-26 21:39:54.305778763 +0800 dump.rdb
[root@redis data]# ll --full-time
总用量 4
-rw-r--r--. 1 root root 49 2016-08-26 21:40:55.341940425 +0800 dump.rdb

Shutdown操作也会保存数据，触发save

127.0.0.1:6379> set k3 v3
OK

重新启动

[root@redis ~]# redis-cli shutdown #shutdown
[root@redis ~]#  redis-server /application/redis/conf/redis.conf & #启动
[root@redis ~]# redis-cli
127.0.0.1:6379> auth zsq #密码
OK
127.0.0.1:6379> keys *  #数据存在
1) "k100"
2) "k3"
3) "k101"
4) "k2"

工作方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:

  • Redis 调用forks. 同时拥有父进程和子进程。
  • 子进程将数据集写入到一个临时 RDB 文件中。
  • 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

只追加操作的文件（Append-only file，AOF）

快照功能并不是非常耐久（dura ble）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

你可以在配置文件中打开AOF方式:

appendonly yes

从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

[root@redis ~]# grep "^append.*" /application/redis/conf/redis.conf 
appendonly yes
appendfilename "appendonly.aof"

重启

redis-cli -a zsq shutdown
redis-server /application/redis/conf/redis.conf &

重启过后生成了文件，不过是0字节内容文件

[root@redis ~]# ll /application/data/
总用量 4
-rw-r--r--. 1 root root  0 12月 26 22:38 appendonly.aof
-rw-r--r--. 1 root root 18 12月 26 22:38 dump.rdb

写数据

[root@redis ~]# redis-cli -a zsq
127.0.0.1:6379> set name zsq
OK
127.0.0.1:6379> get name
"zsq"
127.0.0.1:6379> quit
[root@redis ~]# ll /application/data/
总用量 8
-rw-r--r--. 1 root root 55 12月 26 22:39 appendonly.aof  #文件大小发生了变化
-rw-r--r--. 1 root root 18 12月 26 22:38 dump.rdb

[root@redis ~]# cat /application/data/appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
$3
zsq
View Code

删除恢复操作

[root@redis ~]# redis-cli -a zsq
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> del name
(integer) 1

记录了删除的操作

[root@redis ~]# cat /application/data/appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$3
zsq
*2
$3
del
$4
name
View Code

把记录删除的操作删除

重新启动，数据又恢复回来了

redis-cli -a zsq shutdown
redis-server /application/redis/conf/redis.conf &

[root@redis ~]# redis-cli -a zsq 
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379>

日志重写

因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。举个例子， 如果你对一个计数器调用了 100 次 INCR ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。然而在实际上， 只使用一条 SET 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写， 具体信息请查看 2.4 的示例配置文件。

# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #重写的条件是64M，达到百分百才重写

测试

[root@redis ~]# redis-cli -a zsq
127.0.0.1:6379> set test 1
OK
127.0.0.1:6379> incr test
(integer) 2
127.0.0.1:6379> 
127.0.0.1:6379> incr test
(integer) 3
127.0.0.1:6379> incr test
(integer) 4
127.0.0.1:6379> incr test
(integer) 5
127.0.0.1:6379> incr test
(integer) 6
127.0.0.1:6379> incr test
(integer) 7

查看aof文件之后再用BGREWRITEAOF

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

再查看aof文件的变化，会发现重复的数据会清除

AOF有多耐用?

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三种方式：

  • 每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全
  • 每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
  • 从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
  • 推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

如果AOF文件损坏了怎么办？

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

  • 为现有的 AOF 文件创建一个备份。
  • 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复:

$ redis-check-aof –fix

  • （可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
  • 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

内存优化

一、特殊编码：
    自从Redis 2.2之后，很多数据类型都可以通过特殊编码的方式来进行存储空间的优化。其中，Hash、List和由Integer组成的Sets都可以通过该方式来优化存储结构，以便占用更少的空间，在有些情况下，可以省去9/10的空间。
    这些特殊编码对于Redis的使用而言是完全透明的，事实上，它只是CPU和内存之间的一个交易而言。如果内存使用率方面高一些，那么在操作数据时消耗的CPU自然要多一些，反之亦然。在Redis中提供了一组配置参数用于设置与特殊编码相关的各种阈值，如：
    #如果Hash中字段的数量小于参数值，Redis将对该Key的Hash Value采用特殊编码。
    hash-max-zipmap-entries 64
    #如果Hash中各个字段的最大长度不超过512字节，Redis也将对该Key的Hash Value采用特殊编码方式。
    hash-max-zipmap-value 512
    #下面两个参数的含义基本等同于上面两个和Hash相关的参数，只是作用的对象类型为List。
    list-max-ziplist-entries 512
    list-max-ziplist-value 64
    #如果set中整型元素的数量不超过512时，Redis将会采用该特殊编码。
    set-max-intset-entries 512
    倘若某个已经被编码的值再经过修改之后超过了配置信息中的最大限制，那么Redis会自动将其转换为正常编码格式，这一操作是非常快速的，但是如果反过来操作，将一个正常编码的较大值转换为特殊编码，Redis的建议是，在正式做之前最好先简单测试一下转换效率，因为这样的转换往往是非常低效的。
二、BIT和Byte级别的操作：

    从Redis 2.2开始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四个用于字符串类型Key/Value的命令。通过这些命令，我们便可以像操作数组那样来访问String类型的值数据了。比如唯一标识用户身份的ID，可能仅仅是String值的其中一段子字符串。这样就可以通过GETRANGE/SETRANGE命令来方便的提取。再有就是可以使用BITMAP来表示用户的性别信息，如1表示male，0表示female。用这种方式来表示100,000,000个用户的性别信息时，也仅仅占用12MB的存储空间，与此同时，在通过SETBIT/GETBIT命令进行数据遍历也是非常高效的。
    
三、尽可能使用Hash：

    由于小的Hash类型数据占用的空间相对较少，因此我们在实际应用时应该尽可能的考虑使用Hash类型，比如用户的注册信息，这其中包括姓名、性别、email、年龄和口令等字段。我们当然可以将这些信息以Key的形式进行存储，而用户填写的信息则以String Value的形式存储。然而Redis则更为推荐以Hash的形式存储，以上信息则以Field/Value的形式表示。
    现在我们就通过学习Redis的存储机制来进一步证明这一说法。在该篇博客的开始处已经提到了特殊编码机制，其中有两个和Hash类型相关的配置参数：hash-max-zipmap-entries和hash-max-zipmap-value。至于它们的作用范围前面已经给出，这里就不再过多的赘述了。现在我们先假设存储在Hash Value中的字段数量小于hash-max-zipmap-entries，而每个元素的长度又同时小于hash-max-zipmap-value。这样每当有新的Hash类型的Key/Value存储时，Redis都会为Hash Value创建定长的空间，最大可预分配的字节数为:
    total_bytes = hash-max-zipmap-entries * hash-max-zipmap-value
    这样一来，Hash中所有字段的位置已经预留，并且可以像访问数组那样随机的访问Field/Value，他们之间的步长间隔为hash-max-zipmap-value。只有当Hash Value中的字段数量或某一新元素的长度分别超过以上两个参数值时，Redis才会考虑将他们以Hash Table的方式进行重新存储，否则将始终保持这种高效的存储和访问方式。不仅如此，由于每个Key都要存储一些关联的系统信息，如过期时间、LRU等，因此和String类型的Key/Value相比，Hash类型极大的减少了Key的数量(大部分的Key都以Hash字段的形式表示并存储了)，从而进一步优化了存储空间的使用效率。

redis 的管理

此篇包含关于管理 Redis 实例的话题。每个话题均包含在一个常见问题表单中。将来会有新的话题加入。

  • Redis安装提示
  • 我们建议使用linux部署Redis。Redis也在osx，FreeBSD，OpenBSD上经过测试，但Linux经过所有主要的压力测试，并且最多产品部署。 确保设置Linux内核overcommit memory setting为1。向/etc/sysctl.conf添加vm.overcommit_memory = 1然后重启，或者运行命令sysctl vm.overcommit_memory=1以便立即生效。
  • 确保禁用Linux内核特性transparent huge pages，它对内存使用和延迟有非常大的负面影响。通过命令echo never > sys/kernel/mm/transparent_hugepage/enabled来完成。
  • 确保你的系统设置了一些swap（我们建议和内存一样大）。如果linux没有swap并且你的redis实例突然消耗了太多内存，或者Redis由于内存溢出会当掉，或者Linux内核OOM Killer会杀掉Redis进程。
  • 设置一个明确的maxmemory参数来限制你的实例，以便确保实例会报告错误而不是当接近系统内存限制时失败
  • 如果你对一个写频繁的应用使用redis，当向磁盘保存RDB文件或者改写AOF日志时，redis可能会用正常使用内存2倍的内存。额外使用的内存和保存期间写修改的内存页数量成比例，因此经常和这期间改动的键的数量成比例。确保相应的设置内存的大小。
  • 当在daemontools下运行时，使用daemonize no
  • 即使你禁用持久化，如果你使用复制，redis会执行rdb保存，除非你使用新的无磁盘复制特性，这个特性目前还是实验性的。
  • 如果你使用复制，确保要么你的master激活了持久化，要么它不会在当掉后自动重启。slave是master的完整备份，因此如果master通过一个空数据集重启，slave也会被清掉。
  • 使用基于HVM的实例，不是基于PV的实例。
  • 不要使用老的实例家族。例如，使用HVM的m3.medium代替PV的m1.medium。
  • Redis持久化使用EC2 EBS卷需要小心处理，因为有时EBS卷有高延迟特性。
  • 如果当slave和master同步时有问题，你可能想尝试新的无磁盘复制特性。
  • 无需停机升级或重启 Redis 实例。

在EC2上运行redis

Redis 被设计成服务器上的长时间运行进程。针对运行实例，有许多配置选项可以通过 CONFIG SET 命令进行修改，而无需执行任何形式的重启。 从 Redis 2.2 开始，可以从 AOF 切换到 RDB 的快照持久性或其他方式而不需要重启 Redis。检索 ‘CONFIG GET *’ 命令获取更多信息。 但偶尔重新启动是必须的，如为升级 Redis 程序到新的版本，或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候。 下列步骤通常用来避免任何形式的停机。

  • 为你的 Redis 实例配置新的从实例。为此你需要一台额外的服务器，或者你的服务器有足够的内存以便同时运行两个 Redis 实例。
  • 如果你用单一的服务器，需确保从实例用与主实例不同的端口启动，否则从实例根本不会启动成功。
  • 等待复制机制的初始同步完成（检查从实例的日志文件）。
  • 用 INFO 命令确认在主从实例中有同样数量的键值。用 redis-cli 检查从实例工作正常并响应你的命令。 使用config set slave-read-only no，允许写slave。
  • 配置你所有的客户端以便使用新的实例（即从实例）
  • 当你确认主实例不再接收到任何请求（你可以用 MONITOR 命令监视到），使用 SLAVEOF NO ONE 命令切换从实例为主实例，然后关闭原先的主实例。

 

posted @ 2017-04-25 13:25  w787815  阅读(1428)  评论(0)  编辑  收藏  举报