《Redis开发与运维》笔记

《Redis开发与运维》学习笔记

Ch 1 初识Redis

Redis（REmote Dictionary Server）——一种基于键值对的NoSQL数据库。

主要特性

速度快
- 所有数据存放在内存中。
- 基于C语言实现。
- 单线程架构。
- 源代码优化好。
基于键值对的数据结构服务器
- Redis的值主要支持5种数据结构：字符串（string）、哈希（hash）、列表（list）、集合（set）、有序集合（zset）。
- 同时在字符串基础上演变了位图（Bitmaps）、HyperLogLog以及GEO（地理信息定位）等数据结构。
丰富的功能
- 键过期功能，实现缓存。
- 发布订阅功能，实现消息系统。
- 支持LUA脚本功能，用LUA创造出新的Redis命令。
- 简单的事务功能。
- 流水线功能，客户端能将命令一次性传到Redis。
简单稳定
- 源码相对较少。
- 使用单线程模型。
- 不依赖OS中的类库。
- 自己实现了事件处理的相关功能。
客户端语言多
- 提供简单的TCP通信协议
- 支持Java、PHP、Python、C、C++、Nodejs等. http://redis.io/clients
持久化
- RDB和AOF。
主从复制
- 分布式Redis的基础，实现多个相同数据的Redis副本。
高可用和分布式

使用场景

缓存
排行榜系统（列表和有序集合）
计数器应用（播放数、浏览数等）
社交网络（赞踩、粉丝、共同好友等）
消息队列系统
数据规模不宜过大、适用热数据（经常访问）

Redis安装与启动

Redis安装

https://redis.io/download

$ wget https://download.redis.io/releases/redis-6.0.9.tar.gz
$ tar xzf redis-6.0.9.tar.gz
$ ln -s redis-6.0.9 redis   #创建软链接
$ cd redis-6.0.9
$ make
$ make install

若显示 install: 无法创建普通文件'/usr/local/bin/redis-server': 权限不够
则执行su root获取root权限
不记得密码执行sudo passwd root修改密码
安装成功查看版本号

$ redis-cli -v
redis-cli 6.0.9

Redis配置、启动、操作和关闭

三种启动方式
- 默认配置启动redis-server
- 运行启动（加上需修改的参数）redis-server --port 6380
- 配置文件启动redis-sever /opt/redis/redis.conf

Redis命令行客户端

交互式：

redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> set good day
OK
127.0.0.1:6379> get good
"day"

命令方式：

redis-cli -h 127.0.0.1 -p 6379 get good
"day"

停止Redis服务
redis-cli shutdown （可选参数nosave|save是否生成持久化文件）

Ch 2 API的理解和使用

基础知识、操作

全局命令

查看所有键
keys *
keys命令会遍历所有键，时间复杂度为O（n），线上环境禁止使用。
127.0.0.1:6379> keys *
1) "good"
2) "hello"
键总数
dbsize
直接获取Redis内置的键总数变量，时间复杂度为O（1）。
127.0.0.1:6379> dbsize
(integer) 2

检查键是否存在
exists key

127.0.0.1:6379> exists hello
(integer) 1
127.0.0.1:6379> exists no_hello
(integer) 0

删除键
del key1 key2 key3~

127.0.0.1:6379> del good hello
(integer) 2                       #返回成功删除键的个数

键过期
expire key seconds
对键添加过期时间，过期自动删除

127.0.0.1:6379> expire hello 10   #单位：s
(integer) 1
127.0.0.1:6379> ttl hello
(integer) 5                       #剩余过期时间
127.0.0.1:6379> ttl hello
(integer) -2                      #-2表示键不存在，-1表示键没有设置过期时间
127.0.0.1:6379> get hello
(nil)

键的数据结构类型
type key

127.0.0.1:6379> rpush mylist a b c d e
(integer) 6
127.0.0.1:6379> type mylist
list
127.0.0.1:6379> type a
none

数据结构和内部编码

优点：改进内部编码而不影响外部数据结构和命令，适应各种场景更加灵活，如图。

单线程架构

单线程首先不会出现并发问题，可以简化数据结构和算法的实现，并且避免了线程切换和竞态产生的消耗，但不适合某个命令执行时间过长的场景。
纯内存访问，重要基础。
非阻塞I/O，使用epoll作为I/O多路复用技术的实现以及自身事件模型，如图。

字符串

Redis最基础的数据结构，键是字符串类型，字符串类型的值可以是字符串（JSON、XML等）、数字、二进制，值最大不能超过512MB。

命令

常用命令
- 设置值
  set key value [ex seconds] [px milliseconds] [nx|xx]
  ex seconds：为键设置秒级过期时间。
  px milliseconds：为键设置毫秒级过期时间。
  nx：等价于setnx key value，键必须不存在才能设置成功，用于添加（可以用于实现分布式锁）。
  xx：等价于setex key seconds value，键必须存在才能设置成功，用于更新。
- 获取值
  get key
- 批量设置值
  mset key value key value···
  127.0.0.1:6379> mset a 1 b 2 c 3
  OK
- 批量获取值
  mget key key key···
  127.0.0.1:6379> mget a b c d
  1) "1"
  2) "2"
  3) "3"
  4) (nil)
- 计数
  incr key
  用于对值做自增操作。
  值必须是整数.
  键不存在，按值为0自增，返回结果为1。
  还有：
  decr key #自减
  incrby key incerement #自增指定数字
  decrby key decrement #自减指定数字
  incrbyfloat key incerement #自增浮点数
不常用命令
- 追加值
  append key value
  向字符串尾部追加值
- 字符串长度
  strlen key
  返回字节数
- 设置并返回原值
  getset key value
  127.0.0.1:6379> getset nice day
  (nil)
  127.0.0.1:6379> getset nice try
  "day"
- 设置指定位置的字符
  setrange key offset value
  127.0.0.1:6379> set redis pest
  OK
  127.0.0.1:6379> setrange redis 0 b
  (integer) 4
  127.0.0.1:6379> get redis
  "best"
- 获取部分字符串
  getrange key start end
  127.0.0.1:6379> getrange redis 0 1
  "be"

各命令时间复杂度如图。

内部编码

int
8个字节的长整型。

127.0.0.1:6379> set key 8653
OK
127.0.0.1:6379> object encoding key
"int"

embstr
小于等于39个字节的字符串。

127.0.0.1:6379> set key "hello world"
OK
127.0.0.1:6379> object encoding key
"embstr"

raw
大于39个字节的字符串。

127.0.0.1:6379> set key "hello world···"
OK
127.0.0.1:6379> object encoding key
"raw"

使用场景

缓存功能
Redis作为缓存层，MySQL作为存储层，如下图。

例如下面用于获取用户信息的伪代码。

UserInfo getUserInfo(long id){
  userRedisKey = "user:info:" + id
  value = redis.get(userRedisKey);
  UserInfo userInfo;
  if (value != null) {
    userInfo = deserialize(value);    #反序列化
  }
  else {
    userInfo = mysql.get(id);
    if (userInfo != null)
      redis.setex(userRedisKey, 3600, serialize(userInfo));   #一小时过期时间
  }
  return userInfo;
}

计数

long incrVideoCounter(long id) {
  key = "video:playCount:" + id;
  return redis.incr(key);
}

共享Session
分布式Web服务使用Redis将用户的Session进行集中管理。

限速
例如网站限制一个IP地址在一定时间内的访问次数等。
用户获取验证码一分钟不超过5次的伪代码如下。

phoneNum = "138xxxxxxxx";
key = "shortMsg:limit:" + phoneNum;
// SET key value EX 60 NX
isExists = redis.set(key,1,"EX 60","NX");
if(isExists != null || redis.incr(key) <=5){
  // 通过
}else{
  // 限速
}

哈希

键值本身又是一对键值对结构，形如

value = {{filed1,value1},{field2,value2}}

命令

设置值
hset key filed value

127.0.0.1:6379> hset user:1 name tom
(integer) 1

获取值
hget key filed
127.0.0.1:6379> hget user:1 name
"tom"

删除field
hdel key filed1 field2...

127.0.0.1:6379> hdel user:1 name age
(integer) 2

计算field个数
hlen key
127.0.0.1:6379> hlen user:1
(integer) 0

批量设置或获取filed-value
hmset key filed1 value1 filed2 value2
hmget key filed1 field2...

127.0.0.1:6379> hmset user:1 name tom age 18
OK
127.0.0.1:6379> hmget user:1 name age
1) "tom"
2) "18"

判断filed是否存在
hexists key filed

127.0.0.1:6379> hexists user:1 name
(integer) 1

获取所有field
hkeys key

127.0.0.1:6379> hkeys user:1
1) "name"
2) "age"

获取所有value
hvals key

127.0.0.1:6379> hvals user:1
1) "tom"
2) "18"

获取所有的field-value
hgetall key（个数较多会导致阻塞）
127.0.0.1:6379> hgetall user:1
1) "name"
2) "tom"
3) "age"
4) "18"
自增
hincrby key filed
hincrbyfloat key filed
计算value的字符串长度
hstrlen key filed（Redis>3.2）
127.0.0.1:6379> hstrlen user:1 name
(integer) 3

各命令时间复杂度如图。

内部编码

ziplist（压缩列表）
使用更紧凑的结构实现多个元素的连续存储，更加节省内存。
使用场景：
- 哈希元素类型个数小于hash-max-ziplist-entries配置（默认512个——field个数）
- 同时所有的值小于hash-max-ziplist-value配置（默认64字节——value值大小）
hashtable（哈希表）
不满足ziplist时采用，O(1)。

使用场景

哈希类型是稀疏的，而关系型数据库是完全结构化的，且Redis不适合做复杂的关系查询，
以下为获取用户信息的伪代码。

UserInfo getUserInfo(long id){
  // 用户id作为key后缀
  userRedisKey = "user:info:" + id;
  // 使用hgetall获取所有用户信息映射关系
  userInfoMap = redis.hgetAll(userRedisKey);
  UserInfo userInfo;
  if (userInfoMap != null) {
    // 将映射关系转换为UserInfo
    userInfo = transferMapToUserInfo(userInfoMap);
  } else {
    // 从MySQL中获取用户信息
    userInfo = mysql.get(id);
    // 将userInfo变为映射关系使用hmset保存到Redis中
    redis.hmset(userRedisKey, transferUserInfoToMap(userInfo));
    // 添加过期时间
    redis.expire(userRedisKey, 3600);
  }
  return userInfo;
}

三种缓存用户信息方法对比。

原生字符串类型
set user:1 name tom
set user:1 age 18
每个属性一个键，简单直观，但内存占用大，用户信息内聚性差。
序列化字符串类型
set user:1 serialize(userinfo)
简化编程，但序列化和反序列化有一定开销，且每次更新都要进行反序列化和序列化。
哈希类型
hmset user:1 name tom age 18
简单直观，合理使用可减少内存占用，但要注意两种内部编码的转换，hashtable会消耗更多内存。

列表

可以存储多个有序、重复的字符串，每个字符串称为元素（个数不大于2^32-1），可以充当栈和队列。

命令

添加

rpush key value1 value2           #从右侧插入
lpush key value1 value2           #从左侧插入
linsert key before|after me you   #在me之前或之后插入you

查找

lrange key start end              #从左至右为0到N-1，从右至左为-1到-N，end包含自身，0到-1为全部
lindex key index                  #获取指定下标的元素
llen key                          #获取列表长度

删除

rpop key                          #从右侧删除
lpop key                          #从右侧删除
lrem key count value              #删除值等于value的元素
                                  #count>0，从左至右，最多删除count个元素
                                  #count<0，从右至左，最多删除count绝对值个元素
                                  #count=0，删除所有
ltrim key start end               #保留列表中start到end的元素

修改
lset key index newValue

阻塞式弹出

blpop key1 key2 timeout
brpop key1 key2 timeout

列表为空时，timeout=3则客户端等到3s后返回，timeout=0则一直阻塞。

127.0.0.1:6379> brpop list:test 3
(nil)
(3.09s)
127.0.0.1:6379> brpop list:test 0
...阻塞中...

此期间添加了数据element1，客户端立即返回。

127.0.0.1:6379> lpush list:test element1
(integer) 1
127.0.0.1:6379> brpop list:test 0
1) "list:test"
2) "element1"
(90.81s)

列表不为空，客户端立即返回。

127.0.0.1:6379> brpop list:test 0
1) "list:test"
2) "element1"

若多个客户端对同一个键执行brpop，那么最先执行brpop命令的客户端可以获取弹出的值。

各命令时间复杂度如图。

内部编码

ziplist（压缩列表）
使用更紧凑的结构实现多个元素的连续存储，更加节省内存。
使用场景：
- 哈希元素类型个数小于list-max-ziplist-entries配置（默认512个——field个数）
- 同时所有的值小于list-max-ziplist-value配置（默认64字节——value值大小）
linkedlist（链表）
不满足ziplist时采用。

注：Redis 3.2 版本提供了quicklist编码，是以一个ziplist为节点的linkedlist，结合了两者的优势。

使用场景

消息队列
使用lpush和brpop命令组合实现阻塞队列，如图。

文章列表
如分页展示文章列表。

每篇文章使用哈希存储

hmset acticle:1 title xx timestamp 1476536196 content xxxx

向用户文章列表添加文章

lpush user:1:acticles article:1 article:2

分页获取用户文章列表

articles = lrange user:1:articles 0 9
for article in {articles}
  hgetall {article}

主要应用场景：

lpush+lpop=Stack（ 栈）
lpush+rpop=Queue（ 队列）
lpsh+ltrim=Capped Collection（ 有限集合）
lpush+brpop=Message Queue（ 消息队列）

集合

集合（set）用来保存多个无序字符串元素，且不允许有重复的元素，不支持下标索引。
一个集合可以存储2^32-1个元素
Redis支持集合内的增删改查以及集合间取交集、并集和差集。

命令

集合内操作

添加元素
sadd key element1 element2
删除元素
srem key element1 element2

计算元素个数

scard key  #时间复杂度O(1)，直接调用Redis内部变量

判断元素是否在集合中
sismember key element
随机从集合返回指定个数的元素
srandmember key count #count默认为1

从集合随机弹出count个元素

spop key count #Redis>3.2，count默认为1

获取所有元素
smembers key

集合间操作

交集
sinter key1 key2
并集
sunion key1 key2
差集
sdiff key1 key2

将交集、并集和差集的结果保存

#将key1和key2运算的结果保存在destination_key中
sinterstore destination_key key1 key2
sunionstore destination_key key1 key2
sdiffstore destination_key key1 key2

各命令时间复杂度如图。

内部编码

intset（整数集合）
更加节省内存。
使用场景：
- 集合中都是整数且元素个数小于set-max-intset-entries配置（默认512个）
hashtable（哈希表）
不满足intset时采用。

使用场景

集合典型的使用场景是标签（用于提升用户体验和增强用户黏度）。
注：用户和标签的关系维护应在一个事务内执行，防止部分命令失败造成的数据不一致。

给用户添加标签

sadd user:1:tags tag1 tag2

给标签添加用户

sadd tag1:users user:1 user:2

删除用户下的标签

srem user:1:tags tag1 tag2

删除标签下的用户

srem tag1:users user:1 user:2

计算用户共同感兴趣的标签
sinter user:1:tags user:2:tags

主要应用场景：

sadd=Tagging（标签）
spop/srandmember=Random item（生成随机数， 比如抽奖）
sadd+sinter=Social Graph（社交需求）

有序集合

相较于集合，有序集合中的元素依据分数进行排序，且元素不能重复但分数可以重复。

命令

集合内

添加成员

zadd key score1 member1 score2 member2

Redis>3.2，添加了如下参数：
nx：member必须不存在才可以添加成功，用于添加。
xx：member必须存在才可以添加成功，用于更新。
ch：返回此次操作后，元素和分数发生变化的个数。
incr：对score做增加，等于zincrby

计算成员个数
zcard key
计算某个成员的分数
zscore key member

计算成员的排名

zrank key member  #分数从低到高
zrevrank key member  #分数从高到低

增加成员的分数
zincrby key increment member

返回指定排名范围的成员

zrange key start end [withscores]  #从低到高，withscores可选
zrevrange key start end withscores

返回指定分数范围的成员

zrangebyscore key min max [withscores] [limit offset count]  #限制起始的位置和个数
zrevrangebyscore key min max [withscores] [limit offset count]

limit offset count 可选参数，限制起始的位置和个数
min和max支持开区间()和闭区间[]，-inf和+inf代表无穷小和无穷大

返回指定分数范围的成员个数
zcount key min max
删除成员
zrem key member1 member2
删除指定排名内的升序元素
zremrangebyrank key start end
删除指定分数范围的成员
zremrangebyscore key min max

集合间

交集

zinterstore destination numkeys key1 key2 weight1 weight2 [aggregate sum|min|max]

destinatin：保存计算结果的键
numkeys：参与计算键的个数
weight：每个键的权重，每个键的member会将自己的分数乘以这个权重。
aggregate sum|min|max：计算成员交集后，分数可以按照sum、min和max做汇总，默认sum。

并集

zunionstore destination numkeys key1 key2 weight1 weight2 [aggregate sum|min|max]

各命令时间复杂度如图。

内部编码

ziplist（压缩列表）
使用更紧凑的结构实现多个元素的连续存储，更加节省内存。
使用场景：
- 哈希元素类型个数小于zset-max-ziplist-entries配置（默认128个）
- 同时所有的值小于zset-max-ziplist-value配置（默认64字节）
skiplist（跳跃表）
不满足ziplist时采用。

使用场景

有序集合的典型使用场景为排行榜系统。榜单的维度可以是多方面的。
例如视频网站对用户上传到视频做排行榜，使用赞数这个维度。

添加用户赞数

zadd user:ranking:2021_01_05 3 mike  #用户mike上传了一个视频并获得了3个赞
zincrby user:ranking:2021_01_05 1 mike  #之后又获得了一个赞

取消用户赞数
zrem user:ranking:2021_01_05 mike

展示获赞数最多前十用户

zrevrangebyrank user:ranking:2021_01_05 0 9

展示用户信息及分数

hgetall user:info:tom
zscore user:ranking:2021_01_05 mike
zrank user:ranking:2021_01_05 mike

键管理

关于键的一些通用命令介绍。
接2.1.1全局命令的一些其他命令。

单个键管理

键重命名
rename key newkey
（1）若rename的newkey已存在，那么该已存在的newkey的值会变成被rename的key的值。
127.0.0.1:6379> set old a
OK
127.0.0.1:6379> set new b
OK
127.0.0.1:6379> rename old new
OK
127.0.0.1:6379> get old
(nil)
127.0.0.1:6379> get new
"a"
（2）为防止被强行rename，Redis提供了renamenx命令，只有newkey不存在时才能rename成功。
（3）由于重命名键期间会执行del删除旧的键，如果键对应的值较大，可能会导致阻塞。
（4）rename key key在3.2版本前会报错。
随机返回一个键
randomkey

键过期

expire key seconds                      #键在seconds秒后过期
pexpire key millionseconds              #毫秒级
                                        #key不存在返回0
                                        #seconds为负数，键会立即被删除

expireat key timestamp                  #键在秒级时间戳timestamp后过期
pexpireat key millionseconds-timestamp  #毫秒级

ttl key                                 #查询键的剩余过期时间，单位秒。
pttl key                                #毫秒级
                                        #-1表示键没有设置过期时间，-2表示键不存在

persist key                             #消除键的过期时间

（1）无论何种方式，在Redis内部最终使用的是pexpireat。
（2）对于字符串类型的键，执行set命令会消除过期时间，详见源码中set命令的函数setKey。
（3）Redis不支持二级数据结构（哈希、列表等）内部元素的过期功能。
（4）setex作为set+expire的组合，不单是原子执行，且减少了一次网络通讯的时间。

迁移键

move
move key db
Redis内部可以有多个数据库，且彼此相互隔离。move命令用于在Redis内部进行数据迁移。

dump+store

dump key
restore key ttl value  #ttl为过期时间，=0不设置

dump+store可实现不同Redis实例之间的数据迁移,整个迁移过程是非原子性的过程，且需要开启两个客户端连接。分为两步：
（1）在源Redis上执行dump，将键值序列化，为RDB格式。

redis-source> set hello world
OK
redis-source> dump hello
"\x00\x05world\x06\x00\x8f<T\x04%\xfcNQ"

（2）在目标Redis上执行restore，进行复原。

redis-target> get hello
(nil)
redis-target> restore hello 0 "\x00\x05world\x06\x00\x8f<T\x04%\xfcNQ"
OK
redis-target> get hello
"world

对应伪代码为：

Redis sourceRedis = new Redis("sourceMachine", 6379)
Redis targetRedis = new Redis("targetMachine", 6379)
targetRedis.restore("hello", 0, sourceRedis.dump(key))

migrate

migrate host port key|"" destination-db timeout [copy] [replace] [keys key [key...]]

host：              目标Redis的IP地址。
port：              目标Redis的端口。
key|""：            在Redis3.0.6版本之前，migrate只支持迁移一个键，所以此处是要迁移的键，
                    在Redis3.0.6版本之后支持迁移多个键，如果当前需要迁移多个键，此处为空字符串""。
destination-db：    目标Redis的数据库索引，例如要迁移到0号数据库，这里就写0。
timeout：           迁移的超时时间（单位为毫秒）。
[copy]：            如果添加此选项，迁移后并不删除源键。
[replace]：         如果添加此选项，migrate不管目标Redis是否存在该键都会正常迁移进行数据覆盖。
[keys key[key...]]：迁移多个键，例如要迁移key1、key2、key3，此处填写“keys key1 key2 key3”。

（1）migrate命令也是用于在Redis实例间进行数据迁移，实际上migrate命令就是将dump、restore、del三个命令进行组合，从而简化了操作流程，而且从Redis3.0.6版本以后已经支持迁移多个键的功能，有效地提高了迁移效率。
（2）第一，整个过程是原子执行的，不需要在多个Redis实例上开启客户端的，只需要在源Redis上执行migrate命令即可。第二，migrate命令的数据传输直接在源Redis和目标Redis上完成。第三，目标Redis完成restore后会发送OK给源Redis，源Redis接收后会根据migrate对应的选项来决定是否在源Redis上删除对应的键。

示例：

源Redis有键hello，目标Redis没有

127.0.0.1:6379> migrate 127.0.0.1 6380 hello 0 1000
OK

源Redis和目标Redis都有键hello

127.0.0.1:6379> migrate 127.0.0.1 6379 hello 0 1000
(error) ERR Target instance replied with error: BUSYKEY Target key name already exists.

127.0.0.1:6379> migrate 127.0.0.1 6379 hello 0 1000 replace
OK

源Redis没有键hello。如下所示，此种情况会收到nokey的提示
127.0.0.1:6379> migrate 127.0.0.1 6380 hello 0 1000
NOKEY

源Redis执行如下命令完成多个键的迁移

127.0.0.1:6379> migrate 127.0.0.1 6380 "" 0 5000 keys key1 key2 key3
OK

遍历键

全量遍历键
keys pattern #patterm使用glob风格通配符

* 代表匹配所有任意字符
? 代表匹配一个任意字符
[1,3] 代表匹配1和3，[1-3] 代表匹配1到3的任意数字
\x 转义字符
考虑到Redis的单线程架构，keys命令一般只在以下三种情况使用：
- 在一个不对外提供服务的Redis从节点上执行，这样不会阻塞到客户端的请求，但是会影响到主从复制。
- 如果确认键值总数确实比较少，可以执行该命令。
- 使用scan命令渐进式的遍历所有键。

渐进式遍历

scan cursor [match pattern] [count number]

cursor：是一个游标，第一次遍历从0开始，每次scan遍历完都会返回当前游标的值，直到游标值为0，表示遍历结束。
match pattern：可选参数，作用是做模式匹配。
count number：可选参数，作用是表明每次要遍历的键个数，默认值是10，可以适当增大。

Redis存储键值对实际使用hashtable作为内部编码。
示例：

127.0.0.1:6379> scan 0
1) "15"
2)  1) "new"
    2) "c"
    3) "a"
    4) "key"
    5) "nice"
    6) "b"
    7) "mylist"
    8) "d"
    9) "redis"
  10) "user:1"
127.0.0.1:6379> scan 15
1) "0"
2) 1) "hello"

除了scan以外，Redis提供了面向哈希类型、集合类型、有序集合的扫描遍历命令，解决诸如hgetall、smembers、zrange可能产生的阻塞问题，对应的命令分别是hscan、sscan、zscan。
需要注意的是scan过程中如果有键的变化，那么可能会遍历重复的键，而遍历不到新增的键。

数据库管理

切换数据库
select dbIndex
Redis只用数字来标识数据库，默认有16个，各数据库独立。
但是该功能已逐步废弃了，原因如下：
- Redis是单线程的。如果使用多个数据库，那么这些数据库仍然是使用一个CPU，彼此之间还是会受到影响。
- 多数据库的使用方式，会让调试和运维不同业务的数据库变的困难，假如有一个慢查询存在，依然会影响其他数据库，这样会使得别的业务方定位问题非常的困难。
- 部分Redis的客户端根本就不支持这种方式。即使支持，在开发的时候来回切换数字形式的数据库，很容易弄乱。
  所以在需要多个数据库功能的情况下，可以在一台机器上部署多个Redis实例，以端口来区分。
flushdb和flushall
flushdb只清除当前数据库，flushall会清除所有数据库。
带来的问题：
- flushdb/flushall命令会将所有数据清除，一旦误操作后果不堪设想。
- 如果当前数据库键值数量比较多，flushdb/flushall存在阻塞Redis的可能性。

Ch 3 小功能大用处

慢查询分析

发送命令>命令排队>命令执行>返回结果
慢查询只统计命令执行的时间，并不反映客户端的超时问题。

两个配置参数

预设阈值

config set slowlog-log-slower-than 20000
config rewrite  #将配置持久化到本地配置文件

单位：微秒，默认值=10000
等于0会记录所有记录，小于0不记录任何命令

慢查询记录存放位置

config set slowlog-max-len 1000
config rewrite  #将配置持久化到本地配置文件

Redis使用一个列表来存储慢查询日志（类似队列），
slowlog-max-len指定列表最大长度

操作命令

获取慢查询日志

slowlog get [n]  #n可选，指定条数

每个慢查询记录有4个属性，分别为：
标识id、发生时间戳、命令耗时以及执行的命令和参数。

获取慢查询日志列表当前长度
slowlog len
慢查询日志重置
slowlog reset

实践注意事项

slowlog-max-len配置建议：线上建议调大慢查询列表，可设置为1000以上，记录慢查询时Redis会对长命令做截断操作，并不会占用大量内存，增大慢查询列表可以减缓慢查询被剔除的可能。
slowlog-log-slower-than配置建议：默认值超过10毫秒判定为慢查询，需要根据Redis并发量调整该值。由于Redis采用单线程响应命令，对于高流量的场景，如果命令执行时间在1毫秒以上，那么Redis最多可支撑OPS不到1000，因此对于高OPS场景的Redis建议设置为1毫秒。
慢查询只记录命令执行时间，并不包括命令排队和网络传输时间，因此客户端执行命令的时间会大于命令实际执行时间。因为命令执行排队机制，慢查询会导致其他命令级联阻塞，因此当客户端出现请求超时，需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞。
慢查询日志是一个先进先出的队列，如果慢查询比较多的情况下，可能会丢失部分慢查询命令，为了防止这种情况发生，可以定期执行slow get命令将慢查询日志持久化到其他存储中（例如MySQL），然后可以制作可视化界面进行查询，第13章介绍的Redis私有云CacheCloud提供了这样的功能，好的工具可以让问题排查事半功倍。

Redis Shell

redis-cli

-r

redis-cli -r 3 ping

将ping命令执行3次

-i（interval）

redis-cli -r 3 -i 1 ping

每隔几秒执行一次一次命令，单位：秒
-i必须与-r一起用

-x

echo "world" | redis-cli -x set hello
OK

-x选项代表从标准输入（stdin）读取数据作为redis-cli的最后一个参数。

-c（cluster）

连接Redis Cluster节点时需要使用，-c选项可以防止moved和ask异常，有关Redis Cluster将在第10章介绍。

-a（auth）

如果Redis配置了密码，可以用-a（auth）选项，有了这个选项就不需要手动输入auth命令。

–scan和–pattern

--scan选项和--pattern选项用于扫描指定模式的键，相当于使用scan命令。

–slave

--slave选项是把当前客户端模拟成当前Redis节点的从节点，可以用来获取当前Redis节点的更新操作，
有关于Redis复制将在第6章进行详细介绍。
合理的利用这个选项可以记录当前连接Redis节点的一些更新操作，
这些更新操作很可能是实际开发业务时需要的数据。

–rdb

--rdb选项会请求Redis实例生成并发送RDB持久化文件，保存在本地。可使用它做持久化文件的定期备份。
有关Redis持久化将在第5章进行详细介绍。

–pipe

--pipe选项用于将命令封装成Redis通信协议定义的数据格式，批量发送给Redis执行，
有关Redis通信协议将在第4章进行详细介绍。

–bigkeys

--bigkeys选项使用scan命令对Redis的键进行采样，从中找到内存占用比较大的键值，这些键可能是系统的瓶颈。

–eval

--eval选项用于执行指定Lua脚本，有关Lua脚本的使用将在3.4节介绍。

–latency
用于检测网络延迟，有三个选项
- –lantency
  该选项可以测试客户端到目标Redis的网络延迟，
  redis-cli -h {server} --latency
- –latency-history
- -latency的执行结果只有一条，如果想以分时段的形式了解延迟信息，可以使用–latency-history选项，可以通过-i参数控制间隔时间。
  redis-cli -h 10.10.xx.xx --latency-history -i 10
- –latency-dist
  该选项会使用统计图表的形式从控制台输出延迟统计信息。

–stat

--stat选项可以实时获取Redis的重要统计信息.

–raw和–no-raw
–no-raw选项要求命令的返回结果必须是原始的格式，–raw返回格式化后的结果。

redis-server

redis-server启动Redis：

默认配置启动`redis-server`
运行启动（加上需修改的参数）`redis-server --port 6380`
配置文件启动`redis-sever /opt/redis/redis.conf`

redis-server除了启动Redis外，还有一个–test-memory选项，可以用来检测当前操作系统能否稳定地分配指定容量的内存给Redis，通过这种检测可以有效避免因为内存问题造成Redis崩溃。
下面的命令检测当前操作系统能否提供1G的内存给Redis：

redis-server --test-memory 1024

redis-benchmark

redis-benchmark可以为Redis做基准性能测试。

-c（clients）
-c选项代表客户端的并发数量（默认是50）。

-n（num）
-n选项代表客户端请求总量（默认是100000）。
示例：

redis-benchmark -c 100 -n 20000

代表测试100个客户端同时请求Redis，共执行20000次时的性能
output：
====== GET ======
20000 requests completed in 0.27 seconds
100 parallel clients
3 bytes payload
keep alive: 1

99.11% <= 1 milliseconds
100.00% <= 1 milliseconds
73529.41 requests per second

-q
-q选项仅仅显示redis-benchmark的requests per second信息。
redis-benchmark -c 100 -n 20000 -q
-r
在一个空的Redis上执行了redis-benchmark会发现只有3个键：counter:__rand_int__、mylist和key:__rand_int__。
如果想向Redis插入更多的键，可以执行使用-r（random）选项，可以向Redis插入更多随机的键。
-r选项会在key、counter键上加一个12位的后缀，-r 10000代表只对后四位做随机处理（-r不是随机数的个数）。
-P
-P选项代表每个请求pipeline的数据量（默认为1）。
-k
-k选项代表客户端是否使用keepalive，1为使用，0为不使用，默认值为1。

-t
-t选项可以对指定命令进行基准测试。
示例：

redis-benchmark -t get,set -q
SET: 98619.32 requests per second
GET: 97560.98 requests per second

–csv
–csv选项会将结果按照csv格式输出，便于后续处理，如导出到Excel等。
redis-benchmark -t get,set --csv
"SET","81300.81"
"GET","79051.38"

Pipeline

概念

Redis客户端从发送命令到接收到返回结果的时间为一次RTT，Redis提供的批量操作命令能减少RTT，但大部分命令并不支持批量操作。
Pipeline（流水线）机制，能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端。
redis-cli的–pipe选项实际上就是使用Pipeline机制，例如下面操作将set hello world和incr counter两条命令组装：
echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\
n$7\r\ncounter\r\n' | redis-cli --pipe

性能测试

Pipeline执行速度一般比逐条执行要快。
客户端和服务端的网络延时越大，Pipeline的效果越明显。

原生批量命令与Pipeline对比

原生批量命令是原子的，Pipeline是非原子的。
原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现。

最佳实践

每次Pipeline组装的命令个数不能没有节制，否则一次组装Pipeline数据量过大，一方面会增加客户端的等待时间，另一方面会造成一定的网络阻塞，可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成。
Pipeline虽然只能操作一个Redis实例，但是即使在分布式Redis场景中，也可以作为批量操作的重要优化手段，具体细节见第11章。

事务与Lua

为了保证多条命令组合的原子性，Redis提供了简单的事务功能以及集成Lua脚本来解决这个问题。

事务

将一组需一起执行的命令放在multi和exec之间，若要停止事务的执行，使用discard命令代替exec。
若事务中出现错误，Redis有不同的处理机制：

命令错误
命令写错造成的语法错误，整个事务无法执行。
运行时错误
命令写错但仍是可执行的命令，Redis不支持回滚操作，只能自行修复。
有些应用场景需要在事务之前，确保事务中的key没有被其他客户端修改过，才执行事务，否则不执行（类似乐观锁，其他客户端的修改会执行）。Redis提供了watch命令来解决这类问题。

Lua用法简述

Lua语言在1993年由巴西一个大学研究小组发明，其设计目标是作为嵌入式程序移植到其他应用程序，由C语言实现，虽然简单小巧但是功能强大，许多应用都选用它作为脚本语言。官网：http://www.lua.org/

数据类型及其逻辑处理
Lua语言提供了如下几种数据类型：booleans（布尔）、numbers（数值）、strings（字符串）、tables（表格）。
Lua的基本数据类型和逻辑处理示例如下：

字符串

local strings val = "test"  --local代表局部变量

数组
使用tables类型，数组下标从1开始。

local tables myArray = {"redis", "jedis", true, 88.0}
print(myArray[3])
--true

for

for i = 1, #myArray  --#获取myArray（tables类型）长度
do
  print(myArray[i])
end

或是

for index,value in ipairs(myArray)
do
  print(index)
  print(value)
end

while

local int sum = 0
local int i = 0
while i <= 100
do
  sum = sum +i
  i = i + 1
end
print(sum)
--输出结果为5050

if else

if 1
then
  do something
else
  do something
end

哈希

local tables user_1 = {age = 28, name = "tome"}
print(user_1["age"])
--28
```    
遍历：
```lua
for key,value in pairs(user_1)
do print(key .. value)  --..用来连接字符串
end

函数定义

function contact(str1, str2)
  return str1 .. str2
end

Redis与Lua

在Redis中使用Lua
在Redis中执行Lua脚本有以下两种方法：
- eval
  eval 脚本内容 key个数 key列表参数列表
  
  127.0.0.1:6379> eval 'return "hello " .. KEYS[1] .. ARGV[1]' 1 redis world
  "hello redisworld"
  此外还可使用redis-cli --eval直接执行Lua文件。
- evalsha
  首先将Lua脚本加载到Redis服务端，得到该脚本的SHA1校验和，evalsha命令使用SHA1作为参数可以直接执行对应Lua脚本，避免每次发送Lua脚本的开销。这样客户端就不需要每次执行脚本内容，而脚本也会常驻在服务端，脚本功能得到了复用。
  - 加载脚本
    script load命令可以将脚本内容加载到Redis内存中，得到SHA1
    redis-cli script load "$(cat lua_get.lua)"
    "7413dc2440db1fea7c0a0bde841fa68eefaf149c"
  - 执行脚本
    evalsha 脚本SHA1值 key个数 key列表参数列表
    
    127.0.0.1:6379> evalsha 7413dc2440db1fea7c0a0bde841fa68eefaf149c 1 redis world
    "hello redisworld"
Lua的RedisAPI
- Lua可以使用redis.call函数实现对Redis的访问，例如下面代码是Lua使用redis.call调用了Redis的set和get操作：
  redis.call("set", "hello", "world")
  redis.call("get", "hello")
  放在Redis中的效果如下：
  127.0.0.1:6379> eval 'return redis.call("get", KEYS[1])' 1 hello
  "world"
- 如果redis.call执行失败，那么脚本执行结束会直接返回错误，而redis.pcall会忽略错误继续执行脚本，所以在实际开发中要根据具体的应用场景进行函数的选择。
- Lua可以使用redis.log函数将Lua脚本的日志输出到Redis的日志文件中，但是一定要控制日志级别。Redis3.2提供了Lua Script Debugger功能用来调试复杂的Lua脚本，具体可以参考：http://redis.io/topics/ldb。

案例

Lua脚本功能为Redis开发和运维人员带来如下三个好处：

Lua脚本在Redis中是原子执行的，执行过程中间不会插入其他命令。
Lua脚本可以帮助开发和运维人员创造出自己定制的命令，并可以将这些命令常驻在Redis内存中，实现复用的效果。
Lua脚本可以将多条命令一次性打包，有效地减少网络开销。

示例：
当前列表记录着热门用户的id，假设这个列表有5个元素，如下所示：

127.0.0.1:6379> lrange hot:user:list 0 -1
1) "user:1:ratio"
2) "user:8:ratio"
3) "user:3:ratio"
4) "user:99:ratio"
5) "user:72:ratio"

user:{id}:ratio代表用户的热度，它本身又是一个字符串类型的键：

127.0.0.1:6379> mget user:1:ratio user:8:ratio user:3:ratio user:99:ratio
user:72:ratio
1) "986"
2) "762"
3) "556"
4) "400"
5) "101"

现要求将列表内所有的键对应热度做加1操作，并且保证是原子执行，此功能可以利用Lua脚本来实现：

local mylist = redis.call("lrange", KEYS[1], 0, -1)  --将列表中所有元素取出， 赋值给mylist
local count = 0 --定义局部变量count=0，这个count就是最后incr的总次数

--遍历mylist中所有元素，每次做完count自增，最后返回count
for index,key in ipairs(mylist)
do
  redis.call("incr",key)
  count = count + 1
end
return count

将上述脚本写入lrange_and_mincr.lua文件中，并执行：

redis-cli --eval lrange_and_mincr.lua hot:user:list
(integer) 5

Redis如何管理Lua脚本

script load
script load script
此命令用于将Lua脚本加载到Redis内存中
script exists
scripts exists sha1 [sha1 …]
此命令用于判断sha1是否已经加载到Redis内存中：
127.0.0.1:6379> script exists a5260dd66ce02462c5b5231c727b3f7772c0bcc5
1) (integer) 1
script flush
script flush
此命令用于清除Redis内存已经加载的所有Lua脚本。
script kill
script kill
此命令用于杀掉正在执行的Lua脚本。
但是有一点需要注意，如果当前Lua脚本正在执行写操作，那么script kill将不会生效。
此时，可以执行shutdown save|nosave停掉Redis服务。

Bitmaps

数据结构模型

Bitmaps本身不是一种数据结构，实际上它就是字符串，但是它可以对字符串的位进行操作。
Bitmaps单独提供了一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太相同。可以把Bitmaps想象成一个以位为单位的数组，数组的每个单元只能存储0和1，数组的下标在Bitmaps中叫做偏移量。

命令

本节将每个独立用户是否访问过网站存放在Bitmaps中，将访问的用户记做1，没有访问的用户记做0，用偏移量作为用户的id。

设置值
设置键的第offset个位的值（从0算起）
setbit key offset value
setbit unique:users:2016-04-05 0 1
很多应用的用户id以一个指定数字（例如10000）开头，直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费，通常的做法是每次做setbit操作时将用户id减去这个指定数字。在第一次初始化Bitmaps时，假如偏移量非常大，那么整个初始化过程执行会比较慢，可能会造成Redis的阻塞。
获取值
getbit key offset
获取Bitmaps指定范围值为1的个数
bitcount key [start end]
start和end代表起始和结束字节数
Bitmaps间的运算
bitop op destinatin_key key [key...]
op：and、or、not、xor（异或）。
结果保存在destinatin_key中。
计算Bitmaps中第一个值为targitBit的偏移量
bitpos key targetBit [start] [end]
计算第0个字节到第1个字节之间，第一个值为0的偏移量:
bitpos unique:users:2016-04-04 0 0 1

BitMaps分析

假设网站有1亿用户，每天独立访问的用户有5千万，如果每天用集合类型和Bitmaps分别存储活跃用户可以得到:

随着时间推移节省的内存是非常可观的:
但Bitmaps并不是万金油，假如该网站每天的独立访问用户很少，例如只有10万（大量的僵尸用户），那么两者的对比如图：

HyperLogLog

HyperLogLog并不是一种新的数据结构（实际类型为字符串类型），而是一种基数算法，通过HyperLogLog可以利用极小的内存空间完成独立总数的统计，数据集可以是IP、Email、ID等。HyperLogLog提供了3个命令：pfadd、pfcount、pfmerge。

添加
pfadd key element [element...]
计算独立用户数
pfcount key [key...]
使用脚本向HyperLogLog插入100万个id，插入前记录一下info memory：
127.0.0.1:6379> info memory
# Memory
used_memory:835144
used_memory_human:815.57K
向2016_05_01:unique:ids插入100万个用户，每次插入1000条：
elements=""
key="2016_05_01:unique:ids"
for i in `seq 1 1000000`
do
elements="${elements} uuid-"${i}
if [[ $((i%1000)) == 0 ]];
then
redis-cli pfadd ${key} ${elements}
elements=""
fi
done
当上述代码执行完成后，可以看到内存只增加了15K左右：
127.0.0.1:6379> info memory
# Memory
used_memory:850616
used_memory_human:830.68K
但同时可以看到pfcount的执行结果并不是100万：
127.0.0.1:6379> pfcount 2016_05_01:unique:ids
(integer) 1009838
可以对100万个uuid使用集合类型进行测试，代码如下：
elements=""
key="2016_05_01:unique:ids:set"
for i in `seq 1 1000000`
do
elements="${elements} "${i}
if [[ $((i%1000)) == 0 ]];
then
redis-cli sadd ${key} ${elements}
elements=""
fi
done
可以看到内存使用了84MB：
127.0.0.1:6379> info memory
# Memory
used_memory:88702680
used_memory_human:84.59M
但独立用户数为100万：
127.0.0.1:6379> scard 2016_05_01:unique:ids:set
(integer) 1000000
HyperLogLog内存占用量小得惊人，但是用如此小空间来估算如此巨大的数据，必然不是100%的正确，其中一定存在误差率。Redis官方给出的数字是0.81%的失误率，因此选用原则主要为：
- 只为了计算独立总数，不需要获取单条数据。
- 可以容忍一定误差率，毕竟HyperLogLog在内存的占用量上有很大的优势。
合并
求并集。
pfmerge destinatin_key sourcekey [sourcekey ...]

发布订阅

Redis提供了基于“发布/订阅”模式的消息机制，此种模式下，消息发布者和订阅者不进行直接通信，发布者客户端向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以收到该消息，如图。

命令

发布消息
publish channel message
订阅消息
subscribe channel [channel ...]
有关订阅命令有两点需要注意：
- 客户端在执行订阅命令之后进入了订阅状态，只能接收subscribe、psubscribe、unsubscribe、punsubscribe的四个命令。
- 新开启的订阅客户端，无法收到该频道之前的消息，因为Redis不会对发布的消息进行持久化。
取消订阅
unsubscribe channel [channel ...]
按照模式订阅和取消订阅
pattern支持glob风格。
psubscribe pattern [pattern ...]
punsubscribe [pattern [pattern ...]]
查询订阅
- 查看活跃的频道
  至少有一个订阅者的频道。
  pubsub channels [pattern]
- 查看频道订阅数
  pubsub numsub [channel ...]
- 查看模式订阅数
  通过模式来订阅的客户端数。
  pubsub numpat

使用场景

聊天室、公告牌、服务之间利用消息解耦都可以使用发布订阅模式。
如图，图中有两套业务，上面为视频管理系统，负责管理视频信息；下面为视频服务面向客户，用户可以通过各种客户端（手机、浏览器、接口）获取到视频信息。

视频服务订阅video:changes频道如下：
subscribe video:changes
视频管理系统发布消息到video:changes频道如下：
publish video:changes "video1,video3,video5"
当视频服务收到消息，对视频信息进行更新，如下所示：
for video in video1,video3,video5
update {video}

GEO

Redis3.2版本提供了GEO（地理信息定位）功能，支持存储地理位置信息用来实现诸如附近位置、摇一摇这类依赖于地理位置信息的功能，
GEO功能是Redis的另一位作者Matt Stancliff借鉴NoSQL数据库Ardb实现的，Ardb的作者来自中国，它提供了优秀的GEO功能。

增加地理位置信息

geoadd key longitude latitude member [longitude latitude member ...]

longitude、latitude、member分别是该地理位置的经度、纬度、成员：

127.0.0.1:6379> geoadd cities:locations 116.28 39.55 beijing
(integer) 1

如果需要更新地理位置信息，仍然可以使用geoadd命令，虽然返回结果为0。

获取地理位置信息

geopos key member [member ...]

127.0.0.1:6379> geopos cities:locations tianjin
1) 1) "117.12000042200088501"
2) "39.0800000535766543"

获取两个地理位置的距离

geodist key member1 member2 [unit]

unit代表返回结果的单位，包含四种：
m（meters）代表米。
km（kilometers）代表公里。
mi（miles）代表英里。
ft（ feet）代表尺。

127.0.0.1:6379> geodist cities:locations tianjin beijing km
"89.2061"

获取指定位置范围内的地理信息位置集合

georadius key longitude latitude radiusm|km|ft|mi [withcoord] [withdist]
  [withhash] [COUNT count] [asc|desc] [store key] [storedist key]
georadiusbymember key member radiusm|km|ft|mi [withcoord] [withdist]
  [withhash] [COUNT count] [asc|desc] [store key] [storedist key]

georadius命令的中心位置给出了具体的经纬度，georadiusbymember只需给出成员即可。其中radiusm|km|ft|mi是必需参数，指定了半径（带单位）。剩下的参数如下：

withcoord：返回结果中包含经纬度。
withdist：返回结果中包含离中心节点位置的距离。
withhash：返回结果中包含geohash，有关geohash后面介绍。
COUNT count：指定返回结果的数量。
asc|desc：返回结果按照离中心节点的距离做升序或者降序。
store key：将返回结果的地理位置信息保存到指定键。
storedist key：将返回结果离中心节点的距离保存到指定键。

下面操作计算五座城市中，距离北京150公里以内的城市：

127.0.0.1:6379> georadiusbymember cities:locations beijing 150 km
1) "beijing"
2) "tianjin"
3) "tangshan"
4) "baoding"

获取geohash
Redis使用geohash将二维经纬度转换为一维字符串
geohash key member [member ...]

127.0.0.1:6379> geohash cities:locations beijing
1) "wx4ww02w070"
geohash有如下特点：
- GEO的数据类型为zset，Redis将所有地理位置信息的geohash存放在zset中。
- 字符串越长，表示的位置更精确。
- 两个字符串越相似，它们之间的距离越近，Redis利用字符串前缀匹配算法实现相关的命令。
- geohash编码和经纬度是可以相互转换的。
删除地理位置信息
GEO没有提供删除成员的命令，但是因为GEO的底层实现是zset，所以可以借用zrem命令实现对地理位置信息的删除。
zrem key member

Ch 4 客户端

几乎所有的主流编程语言都有Redis的客户端http://redis.io/clients，不考虑Redis非常流行的原因，如果站在技术的角度看原因还有两个：

客户端与服务端之间的通信协议是在TCP协议之上构建的。
Redis制定了RESP（REdis Serialization Protocol， Redis序列化协议）实现客户端与服务端的正常交互，这种协议简单高效既能够被机器解析，又容易被人类识别。

客户端通信协议

发送命令格式

RESP规定一条命令的格式如下，CRLF代表”\r\n”。

*<参数数量> CRLF
$<参数1的字节数量> CRLF
<参数1> CRLF
...
$<参数N的字节数量> CRLF
<参数N> CRLF

以set hello world为例：

*3
$3
SET
$5
hello
$5
world

实际传输格式为：*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n

返回结果格式

Redis的返回结果类型分为以下五种:

状态回复
在RESP中第一个字节为”+”。
错误回复
在RESP中第一个字节为”-“。
整数回复
在RESP中第一个字节为”:”。
字符串回复
在RESP中第一个字节为”$”。
多条字符串回复
在RESP中第一个字节为”*”。

redis-cli只能看到最终的执行结果，是因为redis-cli本身就是按照RESP进行结果解析的，所以看不到中间结果，redis-cli.c源码对命令结果的解析结构如下：

static sds cliFormatReplyTTY(redisReply *r, char *prefix) {
sds out = sdsempty();
switch (r->type) {
case REDIS_REPLY_ERROR:
// 处理错误回复
case REDIS_REPLY_STATUS:
// 处理状态回复
case REDIS_REPLY_INTEGER:
// 处理整数回复
case REDIS_REPLY_STRING:
// 处理字符串回复
case REDIS_REPLY_NIL:
// 处理空
case REDIS_REPLY_ARRAY:
// 处理多条字符串回复
return out;
}

例如执行set hello world，返回结果是OK，并不能看到加号+OK。
为了看到Redis服务端返回的“真正”结果，可以使用nc命令、telnet命令、甚至写一个socket程序进行模拟。下面以nc命令进行演示：

从源代码安装netcat
安装包：netcat-0.7.1.tar.gz

wget http://sourceforge.net/projects/netcat/files/netcat/0.7.1/netcat-0.7.1.tar.gz
tar -xzvf netcat-0.7.1.tar.gz
cd netcat-0.7.1
./configure
sudo make
sudo make install

首先使用nc 127.0.0.1 6379连接到Redis：
nc 127.0.0.1 6379
状态回复：set hello world的返回结果为+OK：
set hello world
+OK
错误回复：由于sethx这条命令不存在，那么返回结果就是”-“号加上错误消息：
sethx
-ERR unknown command 'sethx'
整数回复：当命令的执行结果是整数时，返回结果就是整数回复，例如incr、exists、del、dbsize返回结果都是整数，例如执行incr counter返回结果就是“：”加上整数：
incr counter
:1
字符串回复：当命令的执行结果是字符串时，返回结果就是字符串回复。get、hget返回结果都是字符串，例如get hello的结果为“$5\r\nworld\r\n”：
get hello
$5
world
多条字符串回复：当命令的执行结果是多条字符串时，返回结果就是多条字符串回复。mget、hgetall、lrange等命令会返回多个结果，例如下面操作：
mset java jedis python redis-py
+OK

mget java python
*2
$5
jedis
$8
redis-py
注意，无论是字符串回复还是多条字符串回复，如果有nil值，那么会返回$-1。
get not_exist_key
$-1
如果批量操作中包含一条为nil值的结果，那么返回结果如下：
mget hello not_exist_key java
*3
$5
world
$-1
$5
jedis

有了RESP提供的发送命令和返回结果的协议格式，各种编程语言就可以利用其来实现相应的Redis客户端。

Java客户端Jedis

Java有很多优秀的Redis客户端，详见：http://redis.io/clients#java

获取Jedis

Jedis的基本使用

Jedis连接池使用

Jedis中的Pipeline使用

Jedis的Lua脚本使用

Python客户端redis-python

Redis官网提供了很多Python语言的客户端：http://redis.io/clients#python

获取redis-py

使用pip进行安装：
pip install redis
使用easy_install进行安装：
easy_install redis

使用源码安装：

wget https:// github.com/andymccurdy/redis-py/archive/2.10.5.zip
unzip redis-2.10.5.zip
cd redis-2.10.5
#安装redis-py
python setup.py install

redis-py基本使用方法

import redis

client = redis.StrictRedis(host='127.0.0.1', port=6379)
key = "hello"
setResult = client.set(key, "python-redis")
print(setResult)
value = client.get(key)
print("key:" + key + ", value:" + value)

output：
True
key:hello, value:python-redis

下面代码给出redis-py操作Redis五种数据结构的示例:

#1.string
#输出结果： True
client.set("hello","world")
#输出结果： world
client.get("hello")
#输出结果： 1
client.incr("counter")

#2.hash
client.hset("myhash","f1","v1")
client.hset("myhash","f2","v2")
#输出结果： {'f1': 'v1', 'f2': 'v2'}
client.hgetall("myhash")
 
#3.list
client.rpush("mylist","1")
client.rpush("mylist","2")
client.rpush("mylist","3")
#输出结果： ['1', '2', '3']
client.lrange("mylist", 0, -1)

#4.set
client.sadd("myset","a")
client.sadd("myset","b")
client.sadd("myset","a")
#输出结果： set(['a', 'b'])
client.smembers("myset")

#5.zset
client.zadd("myzset","99","tom")
client.zadd("myzset","66","peter")
client.zadd("myzset","33","james")
#输出结果： [('james', 33.0), ('peter', 66.0), ('tom', 99.0)]
client.zrange("myzset", 0, -1, withscores=True)

redis-py的Pipline使用

用redis-py的Pipeline实现mdel功能：

import redis

def mdel(keys):
  client = redis.StrictRedis(host='127.0.0.1', port=6379)
  pipeline = client.pipeline(transaction=False)   #不使用事务
  for key in keys:
    print pipeline.delete(key)
  return pipeline.execute()

redis-py的Lua脚本使用

redis-py提供了三个重要的函数实现Lua脚本的执行：

eval(String script, int keyCount, String... params)

script_load(String script)

evalsha(String sha1, int keyCount, String... params)

eval函数有三个参数，分别是：

script：Lua脚本内容。
keyCount：键的个数。
params：相关参数KEYS和ARGV。

示例：

import redis

client = redis.StrictRedis(host='127.0.0.1', port=6379)
script = "return redis.call('get',KEYS[1])"
#输出结果为world
print client.eval(script,1,"hello")

script_load和evalsha函数要一起使用，首先使用script_load将脚本加载到Redis中，evalsha函数用来执行脚本的哈希值，它需要三个参数：

scriptSha：脚本的SHA1。
keyCount：键的个数。
params：相关参数KEYS和ARGV。

示例：

import redis

client = redis.StrictRedis(host='127.0.0.1', port=6379)
script = "return redis.call('get',KEYS[1])"
scriptSha = client.script_load(script)
print client.evalsha(scriptSha, 1, "hello")

客户端管理

客户端API

client list
client list命令能列出与Redis服务端相连的所有客户端连接信息。

127.0.0.1:6379> client list
id=421 addr=127.0.0.1:54264 fd=8 name= 
age=6 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 
argv-mem=10 obl=0 oll=0 omem=0 tot-mem=61466 events=r cmd=client user=default

标识：addr、id、fd、name
id：客户端连接的唯一标识，这个id是随着Redis的连接自增的，重启Redis后会重置为0。
addr：客户端连接的ip和端口。
fd：socket的文件描述符，与lsof命令结果中的fd是同一个，如果fd=-1代表当前客户端不是外部客户端，而是Redis内部的伪装客户端。
name：客户端的名字。
输入缓冲区：qbuf、qbuf-free
Redis为每个客户端分配了输入缓冲区，作用是将客户端发送的命令临时保存，同时Redis会从输入缓冲区拉取命令并执行。
输出缓冲区：obl、oll、omem
客户端存货状态：age、idle
客户端类型：flag
其他

client setName和client getName
client kill
client pause

客户端相关配置

客户端统计片段

客户端常见异常

无法从连接池获取到连接

客户端读写超时

客户端连接超时

客户端缓冲区异常

Lua脚本正在执行

Redis正在加载持久化文件

Redis使用的内存超过maxmemory配置

客户端连接数过大

客户端案例分析

Redis内存陡增

客户端周期性超时

Ch 5 持久化

RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

触发机制

手动触发
- save命令（已废弃）
  save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
  运行save命令对应的Redis日志为：* DB saved on disk
- bgsave命令
  Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
  运行bgsave命令对应的Redis日志为：
  * Background saving started by pid 3151
  * DB saved on disk
  * RDB: 0 MB of memory used by copy-on-write
  * Background saving terminated with success
自动触发
- 使用save相关配置，如save m n。表示m秒内数据集存在n次修改时，自动触发bgsave。
- 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点，更多细节见Ch6介绍的复制原理。
- 执行debug reload命令重新加载Redis时，也会自动触发save操作。
- 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

流程说明

执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
进程发送信号给父进程表示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。

RDB文件的处理

保存
RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir {newDir}和config set dbfilename {newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。
注：当遇到坏盘或磁盘写满等情况时，可以通过config set dir{newDir}在线修改文件路径到可用的磁盘路径，之后执行bgsave进行磁盘切换，同样适用于AOF持久化文件。
压缩
Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression {yes|no}动态修改。
注：虽然压缩RDB会消耗CPU，但可大幅降低文件的体积，方便保存到硬盘或通过网络发送给从节点，因此线上建议开启。
校验
如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：
# Short read or OOM loading DB. Unrecoverable error, aborting now.
这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告。

RDB的优缺点

RDB的优点：
- RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
- Redis加载RDB恢复数据远远快于AOF的方式。
RDB的缺点：
- RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
- RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

AOF

AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。理解掌握好AOF持久化机制对我们兼顾数据安全性和性能非常有帮助。

使用AOF

开启AOF功能需要设置配置：
- appendonly yes，默认不开启。
- AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。
- 保存路径同RDB持久化方式一致，通过dir配置指定。
AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load），如图所示：
- 所有的写入命令会追加到aof_buf（缓冲区）中。
- AOF缓冲区根据对应的策略向硬盘做同步操作。
- 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
- 当Redis服务器重启时，可以加载AOF文件进行数据恢复。

命令写入

AOF命令写入的内容直接是文本协议格式，Redis协议格式具体说明见4.1客户端协议小节。

AOF为什么直接采用文本协议格式？可能的理由如下：
- 文本协议具有很好的兼容性。
- 开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。
- 文本协议具有可读性，方便直接修改和处理。
AOF为什么把命令追加到aof_buf中？
Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

文件同步

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，不同值的含义如下：

系统调用write和fsync说明：
- write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
- fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。
- 除了write、fsync，Linux还提供了sync、fdatasync操作，具体API说明参见：
  http://linux.die.net/man/2/write
  http://linux.die.net/man/2/fsync
  http://linux.die.net/man/2/fdatasync
配置为always时，每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置。
配置为no，由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。
配置为everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。（严格来说最多丢失1秒数据是不准确的，5.3节会做具体介绍到。）

重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。
AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写后的AOF文件为什么可以变小？有如下原因：
- 进程内已经超时的数据不再写入文件。
- 旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a 111、set a 222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
- 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。
AOF重写过程可以手动触发和自动触发：
- 手动触发：直接调用bgrewriteaof命令。
- 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
  - auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
  - auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（ aof_base_size）的比值。
  - 自动触发时机 = aof_current_size > auto-aof-rewrite-minsize &&
    (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewritepercentage
    其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。
当触发AOF重写时，内部的运行流程如下：
执行AOF重写请求。
如果当前进程正在执行AOF重写，请求不执行并返回如下响应：ERR Background append only file rewriting already in progress
如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行，返回如下响应：Background append only file rewriting scheduled
父进程执行fork创建子进程，开销等同于bgsave过程。
主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令 Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
父进程把AOF重写缓冲区的数据写入到新的AOF文件。
使用新AOF文件替换老文件，完成AOF重写。

重启加载

AOF和RDB文件都可以用于服务器重启时的数据恢复。Redis持久化文件加载流程如图。
流程说明：
- AOF持久化开启且存在AOF文件时，优先加载AOF文件，打印如下日志：
  * DB loaded from append only file: 5.841 seconds
- AOF关闭或者AOF文件不存在时，加载RDB文件，打印如下日志：
  * DB loaded from disk: 5.586 seconds
- 加载AOF/RDB文件成功后，Redis启动成功。
- AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

文件校验

加载损坏的AOF文件时会拒绝启动，并打印如下日志：

# Bad file format reading the append only file: make a backup of your AOF file,
then use ./redis-check-aof --fix <filename>

注：对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof–fix命令进行修复，修复后使用diff -u对比数据的差异，找出丢失的数据，有些可以人工修改补全。
AOF文件可能存在结尾不完整的情况，比如机器突然断电导致AOF尾部文件命令写入不全。Redis为提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动，同时打印如下警告日志：

# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 397856725 !!!
# AOF loaded anyway because aof-load-truncated is enabled

问题定位与优化

fork操作

当Redis做RDB或AOF重写时，一个必不可少的操作就是执行fork操作创建子进程，对于大多数操作系统来说fork是个重量级操作。虽然fork创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。例如对于10GB的Redis进程，需要复制大约20MB的内存页表，因此fork操作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是Xen虚拟机，fork操作会更耗时。
fork耗时问题定位：对于高流量的Redis实例OPS可达5万以上，如果fork操作耗时在秒级别将拖慢Redis几万条命令执行，对线上应用延迟影响非常明显。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统计中查latest_fork_usec指标获取最近一次fork操作耗时，单位微秒。
如何改善fork操作的耗时：
- 优先使用物理机或者高效支持fork操作的虚拟化技术，避免使用Xen。
- 控制Redis实例最大可用内存，fork耗时跟内存量成正比，线上建议每个Redis实例内存控制在10GB以内。
- 合理配置Linux内存分配策略，避免物理内存不足导致fork失败，具体细节见12.1节“Linux配置优化”。
- 降低fork操作的频率，如适度放宽AOF自动触发时机，避免不必要的全量复制等。

子进程开销监控与优化

子进程负责AOF或者RDB文件的重写，它的运行过程主要涉及CPU、内存、硬盘三部分的消耗。

CPU
- CPU开销分析。
  子进程负责把进程内的数据分批写入文件，这个过程属于CPU密集操作，通常子进程对单核CPU利用率接近90%。
- CPU消耗优化。
  Redis是CPU密集型服务，不要做绑定单核CPU操作。由于子进程非常消耗CPU，会和父进程产生单核资源竞争。
- 不要和其他CPU密集型服务部署在一起，造成CPU过度竞争。
- 如果部署多个Redis实例，尽量保证同一时刻只有一个子进程执行重写工作，具体细节见5.4节“多实例部署”。

内存

内存消耗分析。
子进程通过fork操作产生，占用内存大小等同于父进程，理论上需要两倍的内存来完成持久化操作，但Linux有写时复制机制（copy-on-write）。
父子进程会共享相同的物理内存页，当父进程处理写请求时会把要修改的页创建副本，而子进程在fork操作过程中共享整个父进程内存快照。

内存消耗监控。
RDB重写时，Redis日志输出容如下：

* Background saving started by pid 7692
* DB saved on disk
* RDB: 5 MB of memory used by copy-on-write
* Background saving terminated with success

如果重写过程中存在内存修改操作，父进程负责创建所修改内存页的副本，从日志中可以看出这部分内存消耗了5MB，可以等价认为RDB重写消耗了5MB的内存。
AOF重写时，Redis日志输出容如下：

* Background append only file rewriting started by pid 8937
* AOF rewrite child asks to stop sending diffs.
* Parent agreed to stop sending diffs. Finalizing AOF...
* Concatenating 0.00 MB of AOF diff received from parent.
* SYNC append only file rewrite performed
* AOF rewrite: 53 MB of memory used by copy-on-write
* Background AOF rewrite terminated with success
* Residual parent diff successfully flushed to the rewritten AOF (1.49 MB)
* Background AOF rewrite finished successfully

父进程维护页副本消耗同RDB重写过程类似，不同之处在于AOF重写需要AOF重写缓冲区，因此根据以上日志可以预估内存消耗为：53MB+1.49MB，也就是AOF重写时子进程消耗的内存量。
注：编写shell脚本根据Redis日志可快速定位子进程重写期间内存过度消耗情况。

内存消耗优化：
- 同CPU优化一样，如果部署多个Redis实例，尽量保证同一时刻只有一个子进程在工作。
- 避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗。
Linux kernel在2.6.38内核增加了Transparent Huge Pages（THP），支持huge page（2MB）的页分配，默认开启。当开启时可以降低fork创建子进程的速度，但执行fork之后，如果开启THP，复制页单位从原来4KB变为2MB，会大幅增加重写期间父进程内存消耗。建议设置sudo echonever>/sys/kernel/mm/transparent_hugepage/enabled关闭THP。更多THP细节和配置见12.1节Linux配置优化

硬盘
- 硬盘开销分析。
  子进程主要职责是把AOF或者RDB文件写入硬盘持久化。势必造成硬盘写入压力。根据Redis重写AOF/RDB的数据量，结合系统工具如sar、 iostat、 iotop等，可分析出重写期间硬盘负载情况。
- 硬盘开销优化。
  - 不要和其他高硬盘负载的服务部署在一起。如：存储服务、消息队列服务等。
  - AOF重写时会消耗大量硬盘IO，可以开启配置no-appendfsync-onrewrite，默认关闭。表示在AOF重写期间不做fsync操作。
  - 当开启AOF功能的Redis用于高流量写入场景时，如果使用普通机械磁盘，写入吞吐一般在100MB/s左右，这时Redis实例的瓶颈主要在AOF同步硬盘上。
  - 对于单机配置多个Redis实例的情况，可以配置不同实例分盘存储AOF文件，分摊硬盘写入压力。
- 注：配置no-appendfsync-on-rewrite=yes时，在极端情况下可能丢失整个AOF重写期间的数据，需要根据数据安全性决定是否配置。

AOF追加阻塞

当开启AOF持久化时，常用的同步硬盘的策略是everysec，用于平衡性能和数据安全性。对于这种方式，Redis使用另一条线程每秒执行fsync同步硬盘。当系统硬盘资源繁忙时，会造成Redis主线程阻塞，如图所示。
阻塞流程分析：
- 主线程负责写入AOF缓冲区。
- AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间。
- 主线程负责对比上次AOF同步时间：
  - 如果距上次同步成功时间在2秒内，主线程直接返回。
  - 如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完成。
通过对AOF阻塞流程可以发现两个问题：
- everysec配置最多可能丢失2秒数据，不是1秒。
- 如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率。
AOF阻塞问题定位：
- 发生AOF阻塞时，Redis输出如下日志，用于记录AOF fsync阻塞导致拖慢Redis服务的行为：
  Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer
  without waiting for fsync to complete, this may slow down Redis
- 每当发生AOF追加阻塞事件发生时，在info Persistence统计中，aof_delayed_fsync指标会累加，查看这个指标方便定位AOF阻塞问题。
- AOF同步最多允许2秒的延迟，当延迟发生时说明硬盘存在高负载问题，可以通过监控工具如iotop，定位消耗硬盘IO资源的进程。优化AOF追加阻塞问题主要是优化系统硬盘负载，优化方式见上一节。

多实例部署

Redis单线程架构导致无法充分利用CPU多核特性，通常的做法是在一台机器上部署多个Redis实例。当多个实例开启AOF重写后，彼此之间会产生对CPU和IO的竞争。本节主要介绍针对这种场景的分析和优化。

对于单机多Redis部署，如果同一时刻运行多个子进程，对当前系统影响将非常明显，因此需要采用一种措施，把子进程工作进行隔离。Redis在info Persistence中为我们提供了监控子进程运行状况的度量指标，如表所示。

我们基于以上指标，可以通过外部程序轮询控制AOF重写操作的执行，整个过程如图所示。
流程说明：
- 外部程序定时轮询监控机器（machine）上所有Redis实例。
- 对于开启AOF的实例，查看（aof_current_sizeaof_base_size） / aof_base_size确认增长率。
- 当增长率超过特定阈值（如100%），执行bgrewriteaof命令手动触发当前实例的AOF重写。
- 运行期间循环检查aof_rewrite_in_progress和aof_current_rewrite_time_sec指标，直到AOF重写结束。
- 确认实例AOF重写完成后，再检查其他实例并重复第2步到第4步操作。从而保证机器内每个Redis实例AOF重写串行化执行。

Ch 6 复制

配置

拓扑

原理

开发与运维中的问题

Ch 7 阻塞

发现阻塞

内在原因

外在原因

Ch 8 理解内存

内存消耗

内存管理

内存优化

Ch 11 缓存设计

缓存的收益和成本

图左侧为客户端直接调用存储层的架构，右侧为比较典型的缓存层+存储层架构，下面分析一下缓存加入后带来的收益和成本。

收益如下：

加速读写：因为缓存通常都是全内存的（例如Redis、 Memcache），而存储层通常读写性能不够强悍（例如MySQL），通过缓存的使用可以有效
地加速读写，优化用户体验。
降低后端负载：帮助后端减少访问量和复杂计算（例如很复杂的SQL语句），在很大程度降低了后端的负载。

成本如下：

数据不一致性：缓存层和存储层的数据存在着一定时间窗口的不一致性，时间窗口跟更新策略有关。
代码维护成本：加入缓存后，需要同时处理缓存层和存储层的逻辑，增大了开发者维护代码的成本。
运维成本：以Redis Cluster为例，加入后无形中增加了运维成本。

缓存的使用场景基本包含如下两种：

开销大的复杂计算：以MySQL为例子，一些复杂的操作或者计算（例如大量联表操作、一些分组计算），如果不加缓存，不但无法满足高并发
量，同时也会给MySQL带来巨大的负担。
加速请求响应：即使查询单条后端数据足够快（例如select*from table where id=?），那么依然可以使用缓存，以Redis为例子，每秒可以完成数万次读写，并且提供的批量操作可以优化整个IO链的响应时间。

缓存更新策略

缓存中的数据通常都是有生命周期的，需要在指定时间后被删除或更新，这样可以保证缓存空间在一个可控的范围。但是缓存中的数据会和数据源中的真实数据有一段时间窗口的不一致，需要利用某些策略进行更新。

下面将分别从使用场景、一致性、开发人员开发/维护成本三个方面介绍三种缓存的更新策略。

LRU/LFU/FIFO算法剔除

使用场景。剔除算法通常用于缓存使用量超过了预设的最大值时候，如何对现有的数据进行剔除。例如Redis使用maxmemory-policy这个配置作为内存最大值后对于数据的剔除策略。
一致性。要清理哪些数据是由具体算法决定，开发人员只能决定使用哪种算法，所以数据的一致性是最差的。
维护成本。算法不需要开发人员自己来实现，通常只需要配置最大maxmemory和对应的策略即可。开发人员只需要知道每种算法的含义，选择适合自己的算法即可。

超时剔除

使用场景。超时剔除通过给缓存数据设置过期时间，让其在过期时间后自动删除，例如Redis提供的expire命令。如果业务可以容忍一段时间内，缓存层数据和存储层数据不一致，那么可以为其设置过期时间。在数据过期后，再从真实数据源获取数据，重新放到缓存并设置过期间。例如一个视频的描述信息，可以容忍几分钟内数据不一致，但是涉及交易方面的业务，后果可想而知。
一致性。一段时间窗口内（取决于过期时间长短）存在一致性问题，即缓存数据和真实数据源的数据不一致。
维护成本。维护成本不是很高，只需设置expire过期时间即可，当然前提是应用方允许这段时间可能发生的数据不一致。

主动更新

使用场景。应用方对于数据的一致性要求高，需要在真实数据更新后，立即更新缓存数据。例如可以利用消息系统或者其他方式通知缓存更新。
一致性。一致性最高，但如果主动更新发生了问题，那么这条数据很可能很长时间不会更新，所以建议结合超时剔除一起使用效果会更好。
维护成本。维护成本会比较高，开发者需要自己来完成更新，并保证更新操作的正确性。

最佳实践

有两个建议：

低一致性业务建议配置最大内存和淘汰策略的方式使用。
高一致性业务可以结合使用超时剔除和主动更新，这样即使主动更新出了问题，也能保证数据过期时间后删除脏数据。

缓存粒度控制

缓存层选用Redis，存储层选用MySQL，是很多项目关于缓存比较常用的选型，如图：

例如现在需要将MySQL的用户信息使用Redis缓存，可以执行如下操作：
从MySQL获取用户信息：

select * from user where id={id}

将用户信息缓存到Redis中：

set user:{id} 'select * from user where id={id}'

假设用户表有100个列，需要缓存到什么维度呢？

缓存全部列：

set user:{id} 'select * from user where id={id}'

缓存部分重要列：

set user:{id} 'select {importantColumn1}, {important Column2} ... {importantColumnN}
                from user where id={id}'

上述这个问题就是缓存粒度问题，究竟是缓存全部属性还是只缓存部分重要属性呢？下面将从通用性、空间占用、代码维护三个角度进行说明。

通用性。缓存全部数据比部分数据更加通用，但从实际经验看，很长时间内应用只需要几个重要的属性。
空间占用。缓存全部数据要比部分数据占用更多的空间，可能存在以下问题：
- 全部数据会造成内存的浪费。
- 全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在极端情况下会阻塞网络。
- 全部数据的序列化和反序列化的CPU开销更大。
代码维护。全部数据的优势更加明显，而部分数据一旦要加新字段需要修改业务代码，而且修改后通常还需要刷新缓存数据。

缓存粒度问题是一个容易被忽视的问题，如果使用不当，可能会造成很多无用空间的浪费，网络带宽的浪费，代码通用性较差等情况，需要综合数据通用性、空间占用比、代码维护性三点进行取舍。

穿透优化

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层，如图所示整个过程分为如下3步：

缓存层不命中。
存储层不命中，不将空结果写回缓存。
返回空结果。

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。

缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。

造成缓存穿透的基本原因有两个。第一，自身业务代码或者数据出现问题，第二，一些恶意攻击、爬虫等造成大量空命中。

下面我们来看一下如何解决缓存穿透问题。

缓存空对象
如图所示，当第2步存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，这样就保护了后端数据源。
缓存空值应对穿透问题
缓存空对象会有两个问题：

第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间（如果是攻击，问题更严重），比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

这种方法适用于数据命中不高、数据频繁变化、实时性高的应用场景，代码维护较为简单，但是缓存空间占用多，存在数据不一致问题。

下面给出了缓存空对象的实现代码：

String get(String key) {
  // 从缓存中获取数据
  String cacheValue = cache.get(key);
  // 缓存为空
  if (StringUtils.isBlank(cacheValue)) {
    // 从存储中获取
    String storageValue = storage.get(key);
    cache.set(key, storageValue);
    // 如果存储数据为空，需要设置一个过期时间(300秒)
    if (storageValue == null) {
      cache.expire(key, 60 * 5);
    }
    return storageValue;
  } else {
  // 缓存非空
  return cacheValue;
  }
}

布隆过滤器拦截
如图所示，在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截。例如：一个推荐系统有4亿个用户id，每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户id不存在，那么就不会访问存储层，在一定程度保护了存储层。

有关布隆过滤器的相关知识，可以参考：https://en.wikipedia.org/wiki/Bloom_filter
可以利用Redis的Bitmaps实现布隆过滤器，GitHub上已经开源了类似的方案，参考：
https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter
这种方法适用于数据命中不高、数据相对固定、实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。

无底洞优化

2010年， Facebook的Memcache节点已经达到了3000个，承载着TB级别
的缓存数据。但开发和运维人员发现了一个问题，为了满足业务要求添加了
大量新Memcache节点，但是发现性能不但没有好转反而下降了，当时将这
种现象称为缓存的“无底洞”现象。
那么为什么会产生这种现象呢，通常来说添加节点使得Memcache集群
性能应该更强了，但事实并非如此。键值数据库由于通常采用哈希函数将
key映射到各个节点上，造成key的分布与业务无关，但是由于数据量和访问
量的持续增长，造成需要添加大量节点做水平扩容，导致键值分布到更多的
节点上，所以无论是Memcache还是Redis的分布式，批量操作通常需要从不
同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作
会涉及多次网络时间。
图11-6展示了在分布式条件下，一次mget操作需要访问多个Redis节点，
需要多次网络时间。
而图11-7由于所有键值都集中在一个节点上，所以一次批量操作只需要
一次网络时间。
无底洞问题分析：
·客户端一次批量操作会涉及多次网络操作，也就意味着批量操作会随
着节点的增多，耗时会不断增大。
·网络连接数变多，对节点的性能也有一定影响。
710用一句通俗的话总结就是，更多的节点不代表更高的性能，所谓“无底
洞”就是说投入越多不一定产出越多。但是分布式又是不可以避免的，因为
访问量和数据量越来越大，一个节点根本抗不住，所以如何高效地在分布式
缓存中批量操作是一个难点。
下面介绍如何在分布式条件下优化批量操作。在介绍具体的方法之前，
我们来看一下常见的IO优化思路：