Redis

Redis介绍

简介

Remote Dictionary Server 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value内存数据库。

Redis 与其他 key - value 缓存产品有以下三个特点：

1. Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
2. Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
3. Redis支持数据的备份，即master-slave模式的数据备份。

Redis特性

Redis最好是在Linux使用。 其设计的时候就基于Linux的，因为redis 是单线程高性能的，所以redis需要单线程轮询，而操作系统机制的轮询是不太一样的，linxu轮询用epoll，window 用selector，性能上来说 epoll高于selector。

redis是单线程的！ redis 核心就是 如果我的数据全都在内存里，我单线程的去操作 就是效率最高的，因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。redis 用 单个CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。多核CPU可以建立多个Redis来加大利用率，也可以考虑分片（shard）。

应用场景

数据量特别大时，不适合 Redis，我们知道 Redis 是基于内存的，虽然内存很便宜，但是如果你每天的数据量特别大，比如几亿条的用户行为日志数据，用 Redis 来存储的话，成本相当的高。

Redis使用的场景：
分布式缓存：这是 Redis 最主要的功能了，合理地使用缓存不仅可以加快数据的访问速度，而且能够有效地降低后端数据源的压力。

共享Session：对于一些依赖 session 功能的服务来说，如果需要从单机变成集群的话，可以选择 redis 来统一管理 session。

消息队列系统：具有业务解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功能基本可以满足。

分布式锁：在分布式服务中。可以利用Redis的setnx功能来编写分布式的锁，虽然这个可能不是太常用。

当然还有诸如排行榜、计数器、点赞功能、全页缓存都可以使用 Redis 来实现，还可以缓存一些热点的不怎么变动的基础数据。

Redis安装配置

安装

下载地址：http://redis.io/download。

# wget http://download.redis.io/releases/redis-6.0.8.tar.gz
# tar xzf redis-6.0.8.tar.gz
# cd redis-6.0.8
# make

执行完 make 命令后，redis-6.0.8 的 src 目录下会出现编译后的 redis 服务程序 redis-server，还有用于测试的客户端程序 redis-cli。
启动 redis 服务：

cd src
# ./redis-server
注意这种方式启动 redis 使用的是默认配置。也可以通过启动参数告诉 redis 使用指定配置文件使用下面命令启动。

# cd src
# ./redis-server ../redis.conf

redis.conf 是一个默认的配置文件。我们可以根据需要使用自己的配置文件。
启动 redis 服务进程后，就可以使用测试客户端程序 redis-cli 和 redis 服务交互了。 

# cd src
# ./redis-cli
redis> set foo bar
OK
redis> get foo
"bar"

配置

序号	配置项	说明
1	daemonize no	Redis 默认不是以守护进程的方式运行，可以通过该配置项修改，使用 yes 启用守护进程（Windows 不支持守护线程的配置为 no ）
2	pidfile /var/run/redis.pid	当 Redis 以守护进程方式运行时，Redis 默认会把 pid 写入 /var/run/redis.pid 文件，可以通过 pidfile 指定
3	port 6379	指定 Redis 监听端口，默认端口为 6379
4	bind 127.0.0.1	绑定的主机地址
5	timeout 300	当客户端闲置多长秒后关闭连接，如果指定为 0 ，表示关闭该功能
6	loglevel notice	指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice
7	logfile stdout	日志记录方式，默认为标准输出，如果配置 Redis 为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给 /dev/null
8	databases 16	设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
9	save _seconds _changes Redis 默认配置文件中提供了三个条件： save 900 1 save 300 10 save 60 10000	分别表示 900 秒（15 分钟）内有 1 个更改，300 秒（5 分钟）内有 10 个更改以及 60 秒内有 10000 个更改。指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
10	rdbcompression yes	指定存储至本地数据库时是否压缩数据，默认为 yes，Redis 采用 LZF 压缩，如果为了节省 CPU 时间，可以关闭该选项，但会导致数据库文件变的巨大
11	dbfilename dump.rdb	指定本地数据库文件名，默认值为 dump.rdb
12	dir ./	指定本地数据库存放目录
13	slaveof _masterip _masterport	设置当本机为 slave 服务时，设置 master 服务的 IP 地址及端口，在 Redis 启动时，它会自动从 master 进行数据同步
14	masterauth _master-password	当 master 服务设置了密码保护时，slav 服务连接 master 的密码
15	requirepass foobared	设置 Redis 连接密码，如果配置了连接密码，客户端在连接 Redis 时需要通过 AUTH _password 命令提供密码，默认关闭
16	maxclients 128	设置同一时间最大客户端连接数，默认无限制，Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis 会关闭新的连接并向客户端返回 max number of clients reached 错误信息
17	maxmemory _bytes	指定 Redis 最大内存限制，Redis 在启动时会把数据加载到内存中，达到最大内存后，Redis 会先尝试清除已到期或即将到期的 Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis 新的 vm 机制，会把 Key 存放内存，Value 会存放在 swap 区
18	appendonly no	指定是否在每次更新操作后进行日志记录，Redis 在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis 本身同步数据文件是按上面 save 条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为 no
19	appendfilename appendonly.aof	指定更新日志文件名，默认为 appendonly.aof
20	appendfsync everysec	指定更新日志条件，共有 3 个可选值： no：表示等操作系统进行数据缓存同步到磁盘（快） always：表示每次更新操作后手动调用 fsync() 将数据写到磁盘（慢，安全） everysec：表示每秒同步一次（折中，默认值）
21	vm-enabled no	指定是否启用虚拟内存机制，默认值为 no，简单的介绍一下，VM 机制将数据分页存放，由 Redis 将访问量较少的页即冷数据 swap 到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析 Redis 的 VM 机制）
22	vm-swap-file /tmp/redis.swap	虚拟内存文件路径，默认值为 /tmp/redis.swap，不可多个 Redis 实例共享
23	vm-max-memory 0	将所有大于 vm-max-memory 的数据存入虚拟内存，无论 vm-max-memory 设置多小，所有索引数据都是内存存储的(Redis 的索引数据 就是 keys)，也就是说，当 vm-max-memory 设置为 0 的时候，其实是所有 value 都存在于磁盘。默认值为 0
24	vm-page-size 32	Redis swap 文件分成了很多的 page，一个对象可以保存在多个 page 上面，但一个 page 上不能被多个对象共享，vm-page-size 是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page 大小最好设置为 32 或者 64bytes；如果存储很大大对象，则可以使用更大的 page，如果不确定，就使用默认值
25	vm-pages 134217728	设置 swap 文件中的 page 数量，由于页表（一种表示页面空闲或使用的 bitmap）是在放在内存中的，，在磁盘上每 8 个 pages 将消耗 1byte 的内存。
26	vm-max-threads 4	设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
27	glueoutputbuf yes	设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
28	hash-max-zipmap-entries 64	hash-max-zipmap-value 512 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
29	activerehashing yes	指定是否激活重置哈希，默认为开启（后面在介绍 Redis 的哈希算法时具体介绍）
30	include /path/to/local.conf	指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

常用工具

Redis支持的Java客户端都有哪些？官方推荐用哪个？
Redisson、Jedis、lettuce等等，官方推荐使用Redisson。
.NET Core
桌面RedisDeskopManager

常用服务器命令

序号	命令	描述
1	BGREWRITEAOF	异步执行一个 AOF（AppendOnly File） 文件重写操作
2	BGSAVE	在后台异步保存当前数据库的数据到磁盘
3	CLIENT KILL [ip:port] [ID client-id]	关闭客户端连接
4	CLIENT LIST	获取连接到服务器的客户端连接列表
5	CLIENT GETNAME	获取连接的名称
6	CLIENT PAUSE timeout	在指定时间内终止运行来自客户端的命令
7	CLIENT SETNAME connection-name	设置当前连接的名称
8	CLUSTER SLOTS	获取集群节点的映射数组
9	COMMAND	获取 Redis 命令详情数组
10	COMMAND COUNT	获取 Redis 命令总数
11	COMMAND GETKEYS	获取给定命令的所有键
12	TIME	返回当前服务器时间
13	COMMAND INFO command-name [command-name …]	获取指定 Redis 命令描述的数组
14	CONFIG GET parameter	获取指定配置参数的值
15	CONFIG REWRITE	对启动 Redis 服务器时所指定的 redis.conf 配置文件进行改写
16	CONFIG SET parameter value	修改 redis 配置参数，无需重启
17	CONFIG RESETSTAT	重置 INFO 命令中的某些统计数据
18	DBSIZE	返回当前数据库的 key 的数量
19	DEBUG OBJECT key	获取 key 的调试信息
20	DEBUG SEGFAULT	让 Redis 服务崩溃
21	FLUSHALL	删除所有数据库的所有key
22	FLUSHDB	删除当前数据库的所有key
23	INFO [section]	获取 Redis 服务器的各种信息和统计数值
24	LASTSAVE	返回最近一次 Redis 成功将数据保存到磁盘上的时间，以 UNIX 时间戳格式表示
25	MONITOR	实时打印出 Redis 服务器接收到的命令，调试用
26	ROLE	返回主从实例所属的角色
27	SAVE	同步保存数据到硬盘
28	SHUTDOWN [NOSAVE] [SAVE]	异步保存数据到硬盘，并关闭服务器
29	SLAVEOF host port	将当前服务器转变为指定服务器的从属服务器(slave server)
30	SLOWLOG subcommand [argument]	管理 redis 的慢日志
31	SYNC	用于复制功能(replication)的内部命令

Redis 连接

链接密码

我们可以通过 redis 的配置文件设置密码参数，这样客户端连接到 redis 服务就需要密码验证，这样可以让你的 redis 服务更安全。

我们可以通过以下命令查看是否设置了密码密码，默认情况下 requirepass 参数是空的，此时无需密码就可连接到 redis 服务，设置后，就需要密码验证。

127.0.0.1:6379> CONFIG get requirepass
1) "requirepass"
2) ""
可以通过以下命令来修改该参数：
127.0.0.1:6379> CONFIG set requirepass "runoob"
OK
127.0.0.1:6379> CONFIG get requirepass
1) "requirepass"
2) "runoob"
连接时
127.0.0.1:6379> AUTH "runoob"
OK

序号	命令	描述
1	AUTH password	验证密码是否正确
2	ECHO message	打印字符串
3	PING	查看服务是否运行
4	QUIT	关闭当前连接
5	SELECT index	切换到指定的数据库

客户端连接

Redis 通过监听一个 TCP 端口或者 Unix socket 的方式来接收来自客户端的连接，当一个连接建立后，Redis 内部会进行以下一些操作：

首先，客户端 socket 会被设置为非阻塞模式，因为 Redis 在网络事件处理上采用的是非阻塞多路复用模型。
然后为这个 socket 设置 TCP_NODELAY 属性，禁用 Nagle 算法。
然后创建一个可读的文件事件用于监听这个客户端 socket 的数据发送。

最大连接数
maxclients 的默认值是 10000，你也可以在 redis.conf 中对这个值进行修改。

config get maxclients
1) "maxclients"
2) "10000"

客户端命令

SN	命令	描述
1	CLIENT LIST	返回连接到 redis 服务的客户端列表
2	CLIENT SETNAME	设置当前连接的名称
3	CLIENT GETNAME	获取通过 CLIENT SETNAME 命令设置的服务名称
4	CLIENT PAUSE	挂起客户端连接，指定挂起的时间以毫秒计
5	CLIENT KILL	关闭客户端连接

Redis 数据类型

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

Key

Redis 键命令用于管理 redis 的键。

语法
Redis 键命令的基本语法如下：

redis 127.0.0.1:6379> COMMAND KEY_NAME
实例
redis 127.0.0.1:6379> SET Tuffy redis
OK
redis 127.0.0.1:6379> DEL Tuffy 
(integer) 1

在以上实例中 DEL 是一个命令， runoobkey 是一个键。 如果键被删除成功，命令执行后输出 (integer) 1，否则将输出 (integer) 0。

Redis keys 命令

序号	命令	描述
1	DEL key	该命令用于在 key 存在时删除 key。
2	DUMP key	序列化给定 key ，并返回被序列化的值。
3	EXISTS key	检查给定 key 是否存在。
4	EXPIRE key seconds	为给定 key 设置过期时间，以秒计。
5	EXPIREAT key timestamp	EXPIREAT 的作用和 EXPIRE 类似，都用于为 key 设置过期时间。 不同在于 EXPIREAT 命令接受的时间参数是 UNIX 时间戳(unix timestamp)。
6	PEXPIRE key milliseconds	设置 key 的过期时间以毫秒计。
7	PEXPIREAT key milliseconds-timestamp	设置 key 过期时间的时间戳(unix timestamp) 以毫秒计
8	KEYS pattern	查找所有符合给定模式( pattern)的 key 。
9	MOVE key db	将当前数据库的 key 移动到给定的数据库 db 当中。
10	PERSIST key	移除 key 的过期时间，key 将持久保持。
11	PTTL key	以毫秒为单位返回 key 的剩余的过期时间。
12	TTL key	以秒为单位，返回给定 key 的剩余生存时间(TTL, time to live)。
13	RANDOMKEY	从当前数据库中随机返回一个 key 。
14	RENAME key newkey	修改 key 的名称
15	RENAMENX key newkey	仅当 newkey 不存在时，将 key 改名为 newkey 。
16	SCAN cursor [MATCH pattern] [COUNT count]	迭代数据库中的数据库键。
17	TYPE key	返回 key 所储存的值的类型。

string

Redis 字符串数据类型的相关命令用于管理 redis 字符串值。
一个字符串类型的值能存储最大容量是 512M。
基本语法如下：

redis 127.0.0.1:6379> COMMAND KEY_NAME
实例
redis 127.0.0.1:6379> SET runoobkey redis
OK
redis 127.0.0.1:6379> GET runoobkey
"redis"

Redis 字符串命令

序号	命令	描述
1	SET key value
2	GET key	获取指定 key 的值。
3	GETRANGE key start end	返回 key 中字符串值的子字符
4	GETSET key value	将给定 key 的值设为 value ，并返回 key 的旧值(old value)。
5	GETBIT key offset	对 key 所储存的字符串值，获取指定偏移量上的位(bit)。
6	MGET key1 [key2…]	获取所有(一个或多个)给定 key 的值。
7	SETBIT key offset value	对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。
8	SETEX key seconds value	将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)。
9	SETNX key value	只有在 key 不存在时设置 key 的值。
10	SETRANGE key offset value	用 value 参数覆写给定 key 所储存的字符串值，从偏移量 offset 开始。
11	STRLEN key	返回 key 所储存的字符串值的长度。
12	MSET key value [key value …]	同时设置一个或多个 key-value 对。
13	MSETNX key value [key value …]	同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。
14	PSETEX key milliseconds value	这个命令和 SETEX 命令相似，但它以毫秒为单位设置 key 的生存时间，而不是像 SETEX 命令那样，以秒为单位。
15	INCR key	将 key 中储存的数字值增一。
16	INCRBY key increment	将 key 所储存的值加上给定的增量值（increment） 。
17	INCRBYFLOAT key increment	将 key 所储存的值加上给定的浮点增量值（increment） 。
18	DECR key	将 key 中储存的数字值减一。
19	DECRBY key decrement	key 所储存的值减去给定的减量值（decrement） 。
20	APPEND key value	如果 key 已经存在并且是一个字符串， APPEND 命令将指定的 value 追加到该 key 原来值（value）的末尾。

Hash

hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。
Redis 中每个 hash 可以存储 232 - 1 键值对（40多亿）。

127.0.0.1:6379>  HMSET runoobkey name "redis tutorial" description "redis basic commands for caching" likes 20 visitors 23000
OK
127.0.0.1:6379>  HGETALL runoobkey
1) "name"
2) "redis tutorial"
3) "description"
4) "redis basic commands for caching"
5) "likes"
6) "20"
7) "visitors"
8) "23000"

hash 命令

序号	命令	描述
1	HDEL key field1 [field2]	删除一个或多个哈希表字段
2	HEXISTS key field	查看哈希表 key 中，指定的字段是否存在。
3	HGET key field	获取存储在哈希表中指定字段的值。
4	HGETALL key	获取在哈希表中指定 key 的所有字段和值
5	HINCRBY key field increment	为哈希表 key 中的指定字段的整数值加上增量 increment 。
6	HINCRBYFLOAT key field increment	为 哈希表 key 中的指定字段的浮点数值加上增量 increment 。
7	HKEYS key	获取所有哈希表中的字段
8	HLEN key	获取哈希表中字段的数量
9	HMGET key field1 [field2]	获取所有给定字段的值
10	HMSET key field1 value1 [field2 value2 ]	同时将多个 field-value (域-值)对设置到哈希表 key 中。
11	HSET key field value	将哈希表 key 中的字段 field 的值设为 value 。
12	HSETNX key field value	只有在字段 field 不存在时，设置哈希表字段的值。
13	HVALS key	获取哈希表中所有值。
14	HSCAN key cursor [MATCH pattern] [COUNT count]	迭代哈希表中的键值对。

List

List是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
一个列表最多可以包含 232 - 1 个元素 (4294967295, 每个列表超过40亿个元素)。

redis 127.0.0.1:6379> LPUSH runoobkey redis
(integer) 1
redis 127.0.0.1:6379> LPUSH runoobkey mongodb
(integer) 2
redis 127.0.0.1:6379> LPUSH runoobkey mysql
(integer) 3
redis 127.0.0.1:6379> LRANGE runoobkey 0 10
1) "mysql"
2) "mongodb"
3) "redis"

List 命令

序号	命令	描述
1	BLPOP key1 [key2 ] timeout	移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
2	BRPOP key1 [key2 ] timeout	移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
3	BRPOPLPUSH source destination timeout	从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
4	LINDEX key index	通过索引获取列表中的元素
5	LINSERT key BEFORE | AFTER pivot value	在列表的元素前或者后插入元素
6	LLEN key	获取列表长度
7	LPOP key	移出并获取列表的第一个元素
8	LPUSH key value1 [value2]	将一个或多个值插入到列表头部
9	LPUSHX key value	将一个值插入到已存在的列表头部
10	LRANGE key start stop	获取列表指定范围内的元素
11	LREM key count value	移除列表元素
12	LSET key index value	通过索引设置列表元素的值
13	LTRIM key start stop	对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。
14	RPOP key	移除列表的最后一个元素，返回值为移除的元素。
15	RPOPLPUSH source destination	移除列表的最后一个元素，并将该元素添加到另一个列表并返回
16	RPUSH key value1 [value2]	在列表中添加一个或多个值
17	RPUSHX key value	为已存在的列表添加值

Set

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。
集合对象的编码可以是 intset 或者 hashtable。
Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

redis 127.0.0.1:6379> SADD runoobkey redis
(integer) 1
redis 127.0.0.1:6379> SADD runoobkey mongodb
(integer) 1
redis 127.0.0.1:6379> SADD runoobkey mysql
(integer) 1
redis 127.0.0.1:6379> SADD runoobkey mysql
(integer) 0
redis 127.0.0.1:6379> SMEMBERS runoobkey
1) "mysql"
2) "mongodb"
3) "redis"

set命令

序号	命令	描述
1	SADD key member1 [member2]	向集合添加一个或多个成员
2	SCARD key	获取集合的成员数
3	SDIFF key1 [key2]	返回第一个集合与其他集合之间的差异。
4	SDIFFSTORE destination key1 [key2]	返回给定所有集合的差集并存储在 destination 中
5	SINTER key1 [key2]	返回给定所有集合的交集
6	SINTERSTORE destination key1 [key2]	返回给定所有集合的交集并存储在 destination 中
7	SISMEMBER key member	判断 member 元素是否是集合 key 的成员
8	SMEMBERS key	返回集合中的所有成员
9	SMOVE source destination member	将 member 元素从 source 集合移动到 destination 集合
10	SPOP key	移除并返回集合中的一个随机元素
11	SRANDMEMBER key [count]	返回集合中一个或多个随机数
12	SREM key member1 [member2]	移除集合中一个或多个成员
13	SUNION key1 [key2]	返回所有给定集合的并集
14	SUNIONSTORE destination key1 [key2]	所有给定集合的并集存储在 destination 集合中
15	SSCAN key cursor [MATCH pattern] [COUNT count]	迭代集合中的元素

Sorted set

Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。
有序集合的成员是唯一的,但分数(score)却可以重复。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。 集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

redis 127.0.0.1:6379> ZADD runoobkey 1 redis
(integer) 1
redis 127.0.0.1:6379> ZADD runoobkey 2 mongodb
(integer) 1
redis 127.0.0.1:6379> ZADD runoobkey 3 mysql
(integer) 1
redis 127.0.0.1:6379> ZADD runoobkey 3 mysql
(integer) 0
redis 127.0.0.1:6379> ZADD runoobkey 4 mysql
(integer) 0
redis 127.0.0.1:6379> ZRANGE runoobkey 0 10 WITHSCORES

1) "redis"
2) "1"
3) "mongodb"
4) "2"
5) "mysql"
6) "4"

sorted set基本命令:

序号	命令	描述
1	ZADD key score1 member1 [score2 member2]	向有序集合添加一个或多个成员，或者更新已存在成员的分数
2	ZCARD key	获取有序集合的成员数
3	ZCOUNT key min max	计算在有序集合中指定区间分数的成员数
4	ZINCRBY key increment member	有序集合中对指定成员的分数加上增量 increment
5	ZINTERSTORE destination numkeys key [key …]	计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 destination 中
6	ZLEXCOUNT key min max	在有序集合中计算指定字典区间内成员数量
7	ZRANGE key start stop [WITHSCORES]	通过索引区间返回有序集合指定区间内的成员
8	ZRANGEBYLEX key min max [LIMIT offset count]	通过字典区间返回有序集合的成员
9	ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT]	通过分数返回有序集合指定区间内的成员
10	ZRANK key member	返回有序集合中指定成员的索引
11	ZREM key member [member …]	移除有序集合中的一个或多个成员
12	ZREMRANGEBYLEX key min max	移除有序集合中给定的字典区间的所有成员
13	ZREMRANGEBYRANK key start stop	移除有序集合中给定的排名区间的所有成员
14	ZREMRANGEBYSCORE key min max	移除有序集合中给定的分数区间的所有成员
15	ZREVRANGE key start stop [WITHSCORES]	返回有序集中指定区间内的成员，通过索引，分数从高到低
16	ZREVRANGEBYSCORE key max min [WITHSCORES]	返回有序集中指定分数区间内的成员，分数从高到低排序
17	ZREVRANK key member	返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序
18	ZSCORE key member	返回有序集中，成员的分数值
19	ZUNIONSTORE destination numkeys key [key …]	计算给定的一个或多个有序集的并集，并存储在新的 key 中
20	ZSCAN key cursor [MATCH pattern] [COUNT count]	迭代有序集合中的元素（包括元素成员和元素分值）

Redis 事务

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
批量操作在发送 EXEC 命令前被放入队列缓存。
收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。
一个事务从开始到执行会经历以下三个阶段：
开始事务。
命令入队。
执行事务。

序号	命令	描述
1	DISCARD	取消事务，放弃执行事务块内的所有命令。
2	EXEC	执行所有事务块内的命令。
3	MULTI	标记一个事务块的开始。
4	UNWATCH	取消 WATCH 命令对所有 key 的监视。
5	WATCH key [key …]	监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

Redis数据淘汰策略

Redis 过期设置

如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会影响项目性能。

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间，我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。

如何设置redis的过期时间？最简单的就是使用
expire key second，
pexpire key milliseconds，
redis查看过期时间的语法也很简单，ttl key就可以看到还剩多长时间。

同时，redis 的过期策略对于持久化并没有影响。如果使用RDB，在持久化key之前就会检测是否过期，过期的key不会被存进文件中，同时从RDB恢复到内存数据库时也会检测一次是否过期。
如果使用AOF,由于存储的都是指令，如果key过期，程序会向AOF中追加del指令。在触发Rewrite的时候，会判断key是否过期，过期的key指令不会重写到AOF文件中。

Redis 过期处理

如何去删除一个过期的key，最容易想到的就是给每一个key都创建定时器，时间一到就自动删除。这个方法是不靠谱的，虽然它能保证每个过期的key都能被尽快删除，但是创建定时器本身就是一个消耗大量资源的工程，所以并不可取。

惰性删除

redis内置的策略叫做惰性删除，也叫“被动删除”。

key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。

但是仅仅通过设置过期时间还是有问题的。若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露，导致redis内存块耗尽。

定期删除

这时候还是需要redis去主动检索，所以需要使用另一种策略，定期删除又被称作主动删除。
redis间隔一定时间随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。过于频繁会给 CPU 带来很大的负载。

配置删除策略：
配置redis.conf 的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率越快，最Redis性能损耗也越大）
配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略。主动清理策略不同于主动删除，要尽量避免触发主动清理。

Redis 数据淘汰策略

当新数据进入redis时，如果内存不足怎么办？在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新 加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。

注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕， 如不能达到内存清理的要求，将出现错误信息如下

(error) OOM command not allowed when used memory >'maxmemory'

相关配置如下
1。最大可使用内存，即占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上
maxmemory ?mb

2：每次选取待删除数据的个数，采用随机获取数据的方式作为待检测删除数据
maxmemory-samples count

3：对数据进行删除的选择策略

maxmemory-policy policy
maxmemory-policy volatile-lru

数据删除的策略policy
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）.
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。

Redis 发布订阅

pub/sub

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
Redis 客户端可以订阅任意数量的频道。

开启本地 Redis 服务，开启两个 redis-cli 客户端。

在第一个 redis-cli 客户端输入 SUBSCRIBE runoobChat，意思是订阅 runoobChat 频道。
redis 127.0.0.1:6379> SUBSCRIBE runoobChat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

在第二个 redis-cli 客户端输入 PUBLISH runoobChat "Redis PUBLISH test" 往 runoobChat 频道发送消息。
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test"
(integer) 1

这个时候在第一个 redis-cli 客户端就会看到由第二个 redis-cli 客户端发送的测试消息。
1) "message"
2) "runoobChat"
3) "Redis PUBLISH test"

Stream

Redis Stream 是 Redis 5.0 版本新增加的数据结构,主要用于消息队列（MQ，Message Queue）。

发布订阅 (pub/sub) 可以分发消息，但无法持久化记录历史消息,如果出现网络断开、Redis 宕机等，消息就会被丢弃。
而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。

Redis Stream 的结构如下所示，它有一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容：

每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用 xadd 指令追加消息时自动创建。

上图解析：
Consumer Group ：消费组，使用 XGROUP CREATE 命令创建，一个消费组有多个消费者(Consumer)。
last_delivered_id ：游标，每个消费组会有个游标 last_delivered_id，任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动。
pending_ids ：消费者(Consumer)的状态变量，作用是维护消费者的未确认的 id。 pending_ids 记录了当前已经被客户端读取的消息，但是还没有 ack (Acknowledge character：确认字符）。
消息队列相关命令：

XADD - 添加消息到末尾
XTRIM - 对流进行修剪，限制长度
XDEL - 删除消息
XLEN - 获取流包含的元素数量，即消息长度
XRANGE - 获取消息列表，会自动过滤已经删除的消息
XREVRANGE - 反向获取消息列表，ID 从大到小
XREAD - 以阻塞或非阻塞方式获取消息列表
消费者组相关命令：

XGROUP CREATE - 创建消费者组
XREADGROUP GROUP - 读取消费者组中的消息
XACK - 将消息标记为"已处理"
XGROUP SETID - 为消费者组设置新的最后递送消息ID
XGROUP DELCONSUMER - 删除消费者
XGROUP DESTROY - 删除消费者组
XPENDING - 显示待处理消息的相关信息
XCLAIM - 转移消息的归属权
XINFO - 查看流和消费者组的相关信息；
XINFO GROUPS - 打印消费者组的信息；
XINFO STREAM - 打印流信息

Redis 数据备份与恢复

Redis 有两种持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。

RDB

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

从配置文件了解RDB
打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
1 RDB核心规则配置（重点）
save 900 1
save 300 10
save 60 10000
解说：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把 save 的配置改成 save “”。

2 指定本地数据库文件名，一般采用默认的 dump.rdb
dbfilename dump.rdb

3 指定本地数据库存放目录，一般也用默认配置
dir ./

4 默认开启数据压缩
rdbcompression yes
解说：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。

触发RDB快照
1 在指定的时间间隔内，执行指定次数的写操作
2 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令。
3 执行flushall 命令，清空数据库所有数据。
4 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据。

通过RDB文件恢复数据
将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。

RDB 的优缺点
优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

redis 127.0.0.1:6379> CONFIG GET dir
以上命令 CONFIG GET dir 输出的 redis 安装目录为 /usr/local/redis/bin。

AOF

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
1 redis 默认关闭，开启需要手动把no改为yes
appendonly yes

2 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename “appendonly.aof”

3 指定更新日志条件

#appendfsync always 每次执行触发
appendfsync everysec 每秒触发
#appendfsync no 不同步

4 配置重写触发机制
AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件，最后替换旧的aof文件。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

根据AOF文件恢复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。

AOF 的优缺点
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

Redis 其他技术

HyperLogLog

Redis HyperLogLog 是用来做基数统计的算法，优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

Redis GEO

Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作操作方法，有：

命令	描述
geoadd	添加地理位置的坐标。
geopos	获取地理位置的坐标。
geodist	计算两个位置之间的距离。
georadius	根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
georadiusbymember	根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
geohash	返回一个或多个位置对象的 geohash 值。

Redis 管道技术

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

这意味着通常情况下一个请求会遵循以下步骤：
客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。
服务端处理命令，并将结果返回给客户端。

Redis 管道技术可以在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应，这样把多次请求变相成为一次请求提高了 redis 服务的性能。

Redis 分区

为什么要做Redis分区呢？
分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。
分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。

分区的优势

通过利用多台计算机内存的和值，允许我们构造更大的数据库。
通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。

分区的不足

redis的一些特性在分区方面表现的不是很好：
涉及多个key的操作通常是不被支持的。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
涉及多个key的redis事务不能使用。
当使用分区时，数据处理较为复杂，比如你需要处理多个rdb/aof文件，并且从多个实例和主机备份持久化文件。
增加或删除容量也比较复杂。redis集群大多数支持在运行时增加、删除节点的透明数据平衡的能力，但是类似于客户端分区、代理等其他系统则不支持这项特性。然而，一种叫做presharding的技术对此是有帮助的。

分区类型

Redis 有两种类型分区。 假设有4个Redis实例 R0，R1，R2，R3，和类似user:1，user:2这样的表示用户的多个key，对既定的key有多种不同方式来选择这个key存放在哪个实例中。也就是说，有不同的系统来映射某个key到某个Redis服务。

范围分区
最简单的分区方式是按范围分区，就是映射一定范围的对象到特定的Redis实例。
比如，ID从0到10000的用户会保存到实例R0，ID从10001到 20000的用户会保存到R1，以此类推。

这种方式是可行的，并且在实际中使用，不足就是要有一个区间范围到实例的映射表。这个表要被管理，同时还需要各 种对象的映射表，通常对Redis来说并非是好的方法。

哈希分区
另外一种分区方法是hash分区。这对任何key都适用，也无需是object_name:这种形式，像下面描述的一样简单：

用一个hash函数将key转换为一个数字，比如使用crc32 hash函数。对key foobar执行crc32(foobar)会输出类似93024922的整数。
对这个整数取模，将其转化为0-3之间的数字，就可以将这个整数映射到4个Redis实例中的一个了。93024922 % 4 = 2，就是说key foobar应该被存到R2实例中。注意：取模操作是取除的余数，通常在多种编程语言中用%操作符实现。

Redis 集群

所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态，可以保证redis稳定性提升读写能力。但是Redis集群并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

分片 Sharding

基于客户端分片

Redis Sharding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。

简介	优点	缺点
其主要思想是采用哈希算法将Redis数据的key进行散列，将特定的key映射到特定的Redis节点上。	非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。	不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化。

基于代理服务器分片

简介	优点	缺点
客户端发送请求到一个代理组件，代理解析客户端的数据，并将请求转发至正确的节点，最后将结果回复给客户端	透明接入，业务程序不用关心后端Redis实例，切换成本低，Proxy 的逻辑和存储的逻辑是隔离的	多了一次转发，性能有所损耗。

业界开源方案:
Twtter开源的Twemproxy
豌豆荚开源的Codis

主从 master-slave

主从简介

主从复制模型中，有多个redis节点。其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步，但是集群之间的复制是异步的。

主从复制有如下特点：

• 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
• 从数据库一般都是只读的，并且接收主数据库同步过来的数据
• 一个master可以拥有多个slave，但是一个slave只能对应一个master
• slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
• master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
• master挂了以后，不会在slave节点中重新选一个master

主从工作机制：

当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave，slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

缺点：
从上面可以看出，master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务。
所有的slave节点数据的复制和同步都由master节点来处理，会照成master节点压力太大，使用主从从结构来解决。

安全设置：
当master节点设置密码后，客户端访问master需要密码
启动slave需要密码，在配置文件中配置即可
客户端访问slave不需要密码

主从实践：

环境准备,准备三台Redis服务，安装的步骤跳过不讲述
master节点 192.168.30.128
slave节点 192.168.30.129
slave节点 192.168.30.130

修改配置：

192.168.30.128
# mkdir -p /data/redis
# vim /usr/local/redis/redis.conf
bind 192.168.30.128               #监听ip，多个ip用空格分隔
daemonize yes               #允许后台启动
logfile "/usr/local/redis/redis.log"                #日志路径
dir /data/redis                 #数据库备份文件存放目录
masterauth 123456               #slave连接master密码，master可省略
requirepass 123456              #设置master连接密码，slave可省略
appendonly yes                  #在/data/redis/目录生成appendonly.aof文件，将每一次写操作请求都追加到appendonly.aof 文件中
# echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf
# sysctl -p

192.168.30.129
# mkdir -p /data/redis
# vim /usr/local/redis/redis.conf
bind 192.168.30.129
daemonize yes
logfile "/usr/local/redis/redis.log"
dir /data/redis
replicaof 192.168.30.128 6379
masterauth 123456
requirepass 123456
appendonly yes
# echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf
# sysctl -p

192.168.30.130
# mkdir -p /data/redis
# vim /usr/local/redis/redis.conf
bind 192.168.30.130
daemonize yes
logfile "/usr/local/redis/redis.log"
dir /data/redis
replicaof 192.168.30.128 6379          #说明一下，replicaof是新版本的命令，旧版本是slaveof命令
masterauth 123456
requirepass 123456
appendonly yes
# echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf
# sysctl -p

全部启动redis：

# systemctl start redis

查看集群状态：

# redis-cli -h 192.168.30.128 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.

192.168.30.128:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.30.129,port=6379,state=online,offset=168,lag=1
slave1:ip=192.168.30.130,port=6379,state=online,offset=168,lag=1
master_replid:fb4941e02d5032ad74c6e2383211fc58963dbe90
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:168
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:168

# redis-cli -h 192.168.30.129 -a 123456 info replication

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:slave
master_host:192.168.30.128
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:196
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fb4941e02d5032ad74c6e2383211fc58963dbe90
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:196
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:196

至此环境已经搭建完成，下面进行一些数据演示，应用插入查询操作。

192.168.30.128:6379> keys *
(empty list or set)
192.168.30.128:6379> set key1 100
OK
192.168.30.128:6379> set key2 lzx
OK
192.168.30.128:6379> keys *
1) "key1"
2) "key2"

# redis-cli -h 192.168.30.129 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.30.129:6379> keys *
1) "key2"
2) "key1"

192.168.30.129:6379> CONFIG GET dir
1) "dir"
2) "/data/redis"
192.168.30.129:6379> CONFIG GET dbfilename
1) "dbfilename"
2) "dump.rdb"
192.168.30.129:6379> get key1
"100"
192.168.30.129:6379> get key2
"lzx"
192.168.30.129:6379> set key3 aaa
(error) READONLY You can't write against a read only replica.

可以看到，在master节点写入的数据，很快就同步到slave节点上，而且在slave节点上无法写入数据。

哨兵

简介哨兵

主从模式的缺点很明显，就是如果主Redis宕机后，整个系统都会出现问题，所以需要Redis的哨兵组件。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：
集群监控：负责监控 redis master 和 slave 进程是否正常工作。
消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

故障转移时，判断一个 master node 是否宕机了，需要大部分（过半）的哨兵都同意才行，涉及到了分布式选举的问题。即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵至少需要 3 个实例，来保证自己的健壮性。
哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

哨兵主要配置项

配置文件名称为：sentinel.conf

#配置端口
port 26379
#以守护进程模式启动
daemonize yes
#日志文件名
logfile "sentinel_26379.log"
#存放备份文件以及日志等文件的目录
dir "/opt/redis/data"
#监控的IP 端口号 名称 sentinel通过投票后认为mater宕机的数量，此处为至少2个
sentinel monitor mymaster 192.168.14.101 6379 2
#30秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 30000
#故障转移后重新主从复制，1表示串行，>1并行
sentinel parallel-syncs mymaster 1
#故障转移开始，三分钟内没有完成，则认为转移失败
sentinel failover-timeout mymaster 180000

注意三台服务器的端口配置.如果redis服务器配置了密码连接,则要增加如下配置:
sentinel auth-pass mymaster 123
后面的123表示密码.注意这行配置要配置到 sentinel monitor mymaster ip port 后面,因为名称 mymaster要先定义.

哨兵实践

启动主从
在上面主从的基础上启动哨兵
master节点 192.168.30.128
slave节点 192.168.30.129
slave节点 192.168.30.130

redis-sentinel sentinel.conf
[root@192.168.30.128 bin]# ./redis-cli -p 6379
192.168.30.128:6379> info replication
role:master  ##当前节点角色
connected_slaves:2   ##从节点连接个数
slave0:ip=192.168.30.129,port=6379,state=online,offset=392,lag=1   ##从节点连接信息
slave1:ip=192.168.30.130,port=6379,state=online,offset=392,lag=2   ##从节点连接信息
master_replid:6bc06103642acba6430e01ec78ef18ada4736649
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:392
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:392

配置哨兵
主要修改参数 修改端口 ，修改主节点连接信息，其他使用默认就行了，具体参数后面会介绍

port 26379  #Sentinel节点的默认端口是26379
sentinel monitor mymaster 192.168.30.128 6379 1

启动哨兵
3个Sentinel节点的部署方法是完全一致的（端口不同）
./redis-sentinel sentinel-26379.conf
或者使用redis-server命令加–sentinel参数
redis-server sentinel-26379.conf --sentinel
其他两个配置是一样的。

Redis cluster3.0

简介

Redis Cluster是一种服务端Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。每份数据分片会存储在多个互为主从的多节点上,数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)同一分片多个节点间的数据不保持一致性.
将请求发送到任意节点，读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点。
扩容时需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

Redis cluster3.0主要配置和特性

Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低 Redis 集群的性能， 并导致不可预测的行为。

优点
将数据自动切分（split）到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。
无中心架构，支持动态扩容，对业务透明。
具备Sentinel的监控和自动Failover(故障转移)能力。
客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
高性能，客户端直连redis服务，免去了proxy代理的损耗。

缺点
运维也很复杂，数据迁移需要人工干预
只能使用0号数据库
不支持批量操作(pipeline管道操作)
分布式逻辑和存储模块耦合等

Redis cluster3.0实践

要让集群正常工作至少需要3个主节点，在这里我们要创建6个redis节点，其中三个为主节点，三个为从节点，对应的redis节点的ip和端口对应关系如下（为了简单演示都在同一台机器上面）
127.0.0.1:7000
127.0.0.1:7001
127.0.0.1:7002
127.0.0.1:7003
127.0.0.1:7004
127.0.0.1:7005

修改Redis的配置文件，6个服务仅端口不一样，在这就只写一份的。

port 7000
daemonize yes
cluster-enabled yes  开启实例的集群模式
cluster-config-file nodes.conf 设定了保存节点配置文件的路径
cluster-node-timeout 5000
appendonly yes

启动Redis实例。

cd /data/cluster/7000
redis-server redis.conf
cd /data/cluster/7001
redis-server redis.conf
cd /data/cluster/7002
redis-server redis.conf
cd /data/cluster/7003
redis-server redis.conf
cd /data/cluster/7004
redis-server redis.conf
cd /data/cluster/7005
redis-server redis.conf

执行命令创建集群，首先安装依赖，否则创建集群失败。

安装gem-redis   下载地址：https://rubygems.org/gems/redis/versions/3.0.0
yum install ruby rubygems -y
gem install -l redis-3.0.0.gem  
cp redis-3.0.0/src/redis-trib.rb /usr/local/bin/redis-trib   --复制集群管理程序到/usr/local/bin

创建集群：

redis-trib create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
redis-trib.rb  create ， 这表示我们希望创建一个新的集群。
--replicas 1 表示我们希望为集群中的每个主节点创建一个从节点,其他参数则是实例的地址列表。

redis-trib把应用配置应用到集群当中,直接输入yes ：

>>> Creating cluster
Connecting to node 127.0.0.1:7000: OK
Connecting to node 127.0.0.1:7001: OK
Connecting to node 127.0.0.1:7002: OK
Connecting to node 127.0.0.1:7003: OK
Connecting to node 127.0.0.1:7004: OK
Connecting to node 127.0.0.1:7005: OK
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:
127.0.0.1:7000
127.0.0.1:7001
127.0.0.1:7002
Adding replica 127.0.0.1:7003 to 127.0.0.1:7000
Adding replica 127.0.0.1:7004 to 127.0.0.1:7001
Adding replica 127.0.0.1:7005 to 127.0.0.1:7002
M: 2774f156af482b4f76a5c0bda8ec561a8a1719c2 127.0.0.1:7000
   slots:0-5460 (5461 slots) master
M: 2d03b862083ee1b1785dba5db2987739cf3a80eb 127.0.0.1:7001
   slots:5461-10922 (5462 slots) master
M: 0456869a2c2359c3e06e065a09de86df2e3135ac 127.0.0.1:7002
   slots:10923-16383 (5461 slots) master
S: 37b251500385929d5c54a005809377681b95ca90 127.0.0.1:7003
   replicates 2774f156af482b4f76a5c0bda8ec561a8a1719c2
S: e2e2e692c40fc34f700762d1fe3a8df94816a062 127.0.0.1:7004
   replicates 2d03b862083ee1b1785dba5db2987739cf3a80eb
S: 9923235f8f2b2587407350b1d8b887a7a59de8db 127.0.0.1:7005
   replicates 0456869a2c2359c3e06e065a09de86df2e3135ac
Can I set the above configuration? (type 'yes' to accept): 


Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join......
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 2774f156af482b4f76a5c0bda8ec561a8a1719c2 127.0.0.1:7000
   slots:0-5460 (5461 slots) master
M: 2d03b862083ee1b1785dba5db2987739cf3a80eb 127.0.0.1:7001
   slots:5461-10922 (5462 slots) master
M: 0456869a2c2359c3e06e065a09de86df2e3135ac 127.0.0.1:7002
   slots:10923-16383 (5461 slots) master
M: 37b251500385929d5c54a005809377681b95ca90 127.0.0.1:7003
   slots: (0 slots) master
   replicates 2774f156af482b4f76a5c0bda8ec561a8a1719c2
M: e2e2e692c40fc34f700762d1fe3a8df94816a062 127.0.0.1:7004
   slots: (0 slots) master
   replicates 2d03b862083ee1b1785dba5db2987739cf3a80eb
M: 9923235f8f2b2587407350b1d8b887a7a59de8db 127.0.0.1:7005
   slots: (0 slots) master
   replicates 0456869a2c2359c3e06e065a09de86df2e3135ac
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

一切正常输出以下信息：

[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

codis

目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新hash节点。

集群的其他问题

Redis集群方案什么情况下会导致整个集群不可用？
有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。

生产环境中的 redis 的案例
redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。
机器是什么配置？32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g。5 台机器对外提供读写，一共有 50g 内存。
因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。

说说Redis哈希槽的概念？
Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

Redis集群如何选择数据库？
Redis集群目前无法做数据库选择，默认在0数据库。

Redis回收使用的是什么算法？
LRU算法

Redis做过异步队列
使用list类型保存数据信息，rpush生产消息，lpop消费消息，当lpop没有消息时，可以sleep一段时间，然后再检查有没有信息，如果不想sleep的话，可以使用blpop, 在没有信息的时候，会一直阻塞，直到信息的到来。
做队列作用：削峰，解耦，异步

Redis如何实现延时队列
使用sortedset，使用时间戳做score, 消息内容作为key,调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。

Redis引入的一些问题

缓存雪崩
简介：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决办法：
事前：尽量保证整个 redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉
事后：利用 redis 持久化机制保存的数据尽快恢复缓存

缓存穿透
简介：一般是黑客故意去请求缓存中不存在的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决办法：
1.网关就应该做处理，限流，熔断。
2.接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截。
3.应用中处理的话有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

Redis 的并发竞争 Key 问题
所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！
推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）

缓存与数据库双写时的数据一致性问题
你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么如何解决一致性问题？
一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况。
再者，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况，串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。
还有一种方式就是可能会暂时产生不一致的情况，但是发生的几率特别小，就是先更新数据库，然后再删除缓存。
这种情况不存在并发问题么？不是的。假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生
（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存

第一次访问慢的问题
解决办法是缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决方案
直接写个缓存刷新页面，上线时手工操作一下；
数据量不大，可以在项目启动的时候自动进行加载；
定时刷新缓存；

缓存降级
当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
缓存降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：
一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

热点数据和冷数据
热点数据，缓存才有价值
对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。频繁修改的数据，看情况考虑使用缓存
==数据更新前至少读取两次，缓存才有意义。==这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。
那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力。