redis中有key但是删不掉_redis

1、什么是Redis？

Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。

因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。

比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。

另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

Redis有哪些优缺点

优点

• 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。

• 支持数据持久化，支持AOF和RDB两种持久化方式。

• 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。

• 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

2、Redis有哪些数据结构

(一)String最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。(二)hash这里value存放的是结构化的对象，方便操作其中的某个字段。在做单点登录的时候，可以用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。(三)list可以做简单的消息队列的功能。另外可以利用lrange命令，做基于redis的分页功能，性能极佳。(四)set可以做全局去重的功能。(五)sorted setsorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作

3、redis的过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略。为什么不用定时删除策略?定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.定期删除+惰性删除是如何工作的呢?定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。采用定期删除+惰性删除就没其他问题了么?不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。在redis.conf中有一行配置

maxmemory-policy volatile-lru

该配置就是配内存淘汰策略的(

MySQL 里有 2000w 数据，redis 中只存 20w 的数据，如何保证 redis 中的数据都是热点数据？

)volatile-lru：从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰volatile-ttl：从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰volatile-random：从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰allkeys-lru：从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰allkeys-random：从数据集(server.db[i].dict)中任意选择数据淘汰no-enviction(驱逐)：禁止驱逐数据，新写入操作会报错ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

4、设置键的生存时间和过期时间

redis有四种命令可以用于设置键的生存时间和过期时间：

EXPIRE <KEY><TTL> : 将键的生存时间设为 ttl 秒PEXPIRE <KEY><TTL> :将键的生存时间设为 ttl 毫秒EXPIREAT <KEY><timestamp> :将键的过期时间设为 timestamp 所指定的秒数时间戳PEXPIREAT <KEY> <timestamp>: 将键的过期时间设为 timestamp 所指定的毫秒数时间戳.

在数据库结构redisDb中的expires字典中保存了数据库中所有键的过期时间，我们称expire这个字典为过期字典。(1)过期字典是一个指针，指向键空间的某个键对象。(2)过期字典的值是一个longlong类型的整数，这个整数保存了键所指向的数据库键的过期时间–一个毫秒级的 UNIX 时间戳。

计算并返回剩余生存时间：ttl命令以秒为单位返回指定键的剩余生存时间。pttl以毫秒返回。两个命令都是通过计算当前时间和过期时间的差值得到剩余生存期的。

移除过期时间：PERSIST 命令可以移除一个键的过期时间

127.0.0.1:6379> set message "hello"OK127.0.0.1:6379> expire message 60(integer) 1127.0.0.1:6379> ttl message(integer) 54127.0.0.1:6379> persist message(integer) 1127.0.0.1:6379> ttl message(integer) -1

5、Redis 为什么是单线程的

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了(毕竟采用多线程会有很多麻烦！)Redis利用队列技术将并发访问变为串行访问
1)绝大部分请求是纯粹的内存操作(非常快速)

2)采用单线程,避免了不必要的上下文切换和竞争条件

3)非阻塞IO优点：
1.速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
2. 支持丰富数据类型，支持string，list，set，sorted set，hash
3.支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
4. 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除如何解决redis的并发竞争key问题

同时有多个子系统去set一个key。这个时候要注意什么呢？不推荐使用redis的事务机制。因为我们的生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。
(1)如果对这个key操作，不要求顺序：准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可
(2)如果对这个key操作，要求顺序：分布式锁+时间戳。假设这会系统B先抢到锁，将key1设置为{valueB 3:05}。接下来系统A抢到锁，发现自己的valueA的时间戳早于缓存中的时间戳，那就不做set操作了。以此类推。
(3) 利用队列，将set方法变成串行访问也可以redis遇到高并发，如果保证读写key的一致性
对redis的操作都是具有原子性的,是线程安全的操作,你不用考虑并发问题,redis内部已经帮你处理好并发的问题了。

6、Redis 持久化机制

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。
实现：单独创建fork()一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程写入到临时文件中，持久化的过程结束了，再用这个临时文件替换上次的快照文件，然后子进程退出，内存释放。

RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。( 快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。)

优点：

(1)只有一个文件 dump.rdb，方便持久化。

(2)容灾性好，一个文件可以保存到安全的磁盘。

(3)性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis的高性能)

(4)相对于数据集大时，比 AOF 的启动效率更高。

缺点：

数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

AOF：Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

优点：

(1)数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。

(2)通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof工具解决数据一致性问题。

(3)AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前(文件过大时会对命令进行合并重写)，可以删除其中的某些命令(比如误操作的 flushall))

缺点：

(1)AOF 文件比 RDB 文件大，且恢复速度慢。

(2)数据集大的时候，比 rdb 启动效率低。

7、缓存雪崩

我们可以简单的理解为：由于原有缓存失效，新缓存未到期间
(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。解决办法：
大多数系统设计者考虑用加锁( 最多的解决方案)或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开。

8、缓存击穿

指一个key非常热点，大并发集中对这个key进行访问，当这个key在失效的瞬间，仍然持续的大并发访问就穿破缓存，转而直接请求数据库。解决方案;在访问key之前，采用SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。

9、缓存穿透缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空(相当于进行了两次无用的查询)。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。解决办法;最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空(不管是数据不存在，还是系统故障)，我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。

10、缓存预热缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！解决思路：1、直接写个缓存刷新页面，上线时手工操作下；2、数据量不大，可以在项目启动的时候自动进行加载；3、定时刷新缓存；

11、Redis实现分布式锁

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。
将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作

解锁：使用 del key 命令就能释放锁解决死锁：1)通过Redis中expire()给锁设定最大持有时间，如果超过，则Redis来帮我们释放锁。2) 使用 setnx key “当前系统时间+锁持有的时间”和getset key “当前系统时间+锁持有的时间”组合的命令就可以实现。

(1)分布式锁

线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量(state)。

进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。

分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

分布式锁应该用来解决分布式情况下的多进程并发问题才是最合适的。

如果是单机情况下(单JVM)，线程之间共享内存，只要使用线程锁就可以解决并发问题。

如果是分布式情况下(多JVM)，线程A和线程B很可能不是在同一JVM中，这样线程锁就无法起到作用了，这时候就要用到分布式锁来解决。

分布式锁实现的关键是在分布式的应用服务器外，搭建一个存储服务器，存储锁信息，这时候我们很容易就想到了Redis。

在实现的时候要注意的几个关键点：

1、锁信息必须是会过期超时的，不能让一个线程长期占有一个锁而导致死锁；

2、同一时刻只能有一个线程获取到锁。

(2)代码实现(单机版)

Maven引入Jedis开源组件

<dependency>    <groupId>redis.clientsgroupId>    <artifactId>jedisartifactId>    <version>2.9.0version>dependency>

加锁代码

public class RedisTool {     private static final String LOCK_SUCCESS = "OK";    private static final String SET_IF_NOT_EXIST = "NX";    private static final String SET_WITH_EXPIRE_TIME = "PX";     /**     * 尝试获取分布式锁     * @param jedis Redis客户端     * @param lockKey 锁     * @param requestId 请求标识     * @param expireTime 超期时间     * @return 是否获取成功     */    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {         String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);         if (LOCK_SUCCESS.equals(result)) {            return true;        }        return false;     } }

五个形参：

• 第一个为key，我们使用key来当锁，因为key是唯一的。

• 第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。

• 第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；

• 第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。

• 第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1. 当前没有锁(key不存在)，那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。2. 已有锁存在，不做任何操作。

解锁代码

public class RedisTool {     private static final Long RELEASE_SUCCESS = 1L;     /**     * 释放分布式锁     * @param jedis Redis客户端     * @param lockKey 锁     * @param requestId 请求标识     * @return 是否释放成功     */    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {         String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));         if (RELEASE_SUCCESS.equals(result)) {            return true;        }        return false;     } 

第一行代码，我们写了一个简单的Lua脚本代码，第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

简单来说，就是在eval命令执行Lua代码的时候，Lua代码将被当成一个命令去执行，并且直到eval命令执行完成，Redis才会执行其他命令。

如果你的项目中Redis是多机部署的，那么可以尝试使用Redisson实现分布式锁，这是Redis官方提供的Java组件。

12、Redis有哪些适合的场景？

1)Session共享(单点登录)2)页面缓存3)队列

Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得 Redis能作为一个很好的消息队列平台来使用。Redis 作为队列使用的操作，就类似于本地程序语言(如 Python)对 list 的 push/pop 操作。4)排行榜/计数器5)发布/订阅

13、Redis 常见性能问题和解决方案：

(1)Master 最好不要写内存快照，如果 Master 写内存快照，save 命令调度 rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务

(2)如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一

(3)为了主从复制的速度和连接的稳定性，Master 和 Slave 最好在同一个局域网

(4)尽量避免在压力很大的主库上增加从

(5)主从复制不要用图状结构，用单向链表结构更为稳定，即：Master

14、Redis 的同步机制了解么？

Redis 可以使用主从同步，从从同步。第一次同步时，主节点做一次 bgsave，并同时将后续修改操作记录到内存 buffer，待完成后将 rdb 文件全量同步到复制节点，复制节点接受完成后将 rdb 镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

15、Redis 支持的 Java 客户端都有哪些？

Redisson、Jedis、lettuce 等等，官方推荐使用 Redisson。

Jedis 是 Redis 的 Java 实现的客户端，其 API 提供了比较全面的 Redis 命令的支持；Redisson 实现了分布式和可扩展的 Java 数据结构，和 Jedis 相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等 Redis 特性。

Redisson 的宗旨是促进使用者对 Redis 的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

16、Redis 的内存用完了会发生什么

如果达到设置的上限，Redis 的写命令会返回错误信息(但是读命令还可以正常返回。)或者你可以将 Redis 当缓存来使用配置淘汰机制，当 Redis 达到内存上限时会冲刷掉旧的内容。

17、如果有大量的 key 需要设置同一时间过期，一般需要注意什么？

答：如果大量的 key 过期时间设置的过于集中，到过期的那个时间点，redis 可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

18、怎么理解 Redis 事务

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

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

Redis 事务相关的命令：MULTI、EXEC、DISCARD、WATCH

redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务的三个阶段

1. 事务开始 MULTI

2. 命令入队

3. 事务执行 EXEC

Redis事务相关命令：

　　watch key1 key2 ... : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 ( 类似乐观锁 )

　　multi : 标记一个事务块的开始( queued )

　　exec : 执行所有事务块的命令 ( 一旦执行exec后，之前加的监控锁都会被取消掉 )　

　　discard : 取消事务，放弃事务块中的所有命令

　　unwatch : 取消watch对所有key的监控

Redis事务使用案例：

(1)正常执行

 

(2)放弃事务

(3)若在事务队列中存在命令性错误(类似于java编译性错误)，则执行EXEC命令时，所有命令都不会执行

(4)若在事务队列中存在语法性错误(类似于java的1/0的运行时异常)，则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。

 

19、使用过Redis做异步队列么，你是怎么用的？有什么缺点？

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

缺点：

在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

能不能生产一次消费多次呢？

使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

20、Pipeline有什么好处，为什么要用pipeline？

可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。

21、redis集群环境

Redis有三种集群模式，分别是：

* 主从模式

* Sentinel模式

* Cluster模式

主从模式

主从复制中，数据库分为两类：主数据库(master)和从数据库(slave)。

主从复制有如下特点：

* 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库* 从数据库一般都是只读的，并且接收主数据库同步过来的数据* 一个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需要密码启动slave需要密码，在配置文件中配置即可客户端访问slave不需要密码

缺点：

从上面可以看出，master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务。

主从模式搭建

• 环境准备：

master节点                  192.168.30.128slave节点                   192.168.30.129slave节点                   192.168.30.130

全部下载安装：

# cd /software# wget http://download.redis.io/releases/redis-5.0.4.tar.gz# tar zxf redis-5.0.4.tar.gz && mv redis-5.0.4/ /usr/local/redis# cd /usr/local/redis && make && make install

全部配置成服务：

# vim /usr/lib/systemd/system/redis.service[Unit]Description=Redis persistent key-value databaseAfter=network.targetAfter=network-online.targetWants=network-online.target[Service]ExecStart=/usr/local/bin/redis-server /usr/local/redis/redis.conf --supervised systemdExecStop=/usr/libexec/redis-shutdownType=notifyUser=redisGroup=redisRuntimeDirectory=redisRuntimeDirectoryMode=0755[Install]WantedBy=multi-user.target

 vim /usr/libexec/redis-shutdown#!/bin/bash## Wrapper to close properly redis and sentineltest x"$REDIS_DEBUG" != x && set -xREDIS_CLI=/usr/local/bin/redis-cli# Retrieve service nameSERVICE_NAME="$1"if [ -z "$SERVICE_NAME" ]; then   SERVICE_NAME=redisfi# Get the proper config file based on service nameCONFIG_FILE="/usr/local/redis/$SERVICE_NAME.conf"# Use awk to retrieve host, port from config fileHOST=`awk '/^[[:blank:]]*bind/ { print $2 }' $CONFIG_FILE | tail -n1`PORT=`awk '/^[[:blank:]]*port/ { print $2 }' $CONFIG_FILE | tail -n1`PASS=`awk '/^[[:blank:]]*requirepass/ { print $2 }' $CONFIG_FILE | tail -n1`SOCK=`awk '/^[[:blank:]]*unixsocket\s/ { print $2 }' $CONFIG_FILE | tail -n1`# Just in case, use default host, portHOST=${HOST:-127.0.0.1}if [ "$SERVICE_NAME" = redis ]; then    PORT=${PORT:-6379}else    PORT=${PORT:-26739}fi# Setup additional parameters# e.g password-protected redis instances[ -z "$PASS"  ] || ADDITIONAL_PARAMS="-a $PASS"# shutdown the service properlyif [ -e "$SOCK" ] ; then        $REDIS_CLI -s $SOCK $ADDITIONAL_PARAMS shutdownelse        $REDIS_CLI -h $HOST -p $PORT $ADDITIONAL_PARAMS shutdownfi

# chmod +x /usr/libexec/redis-shutdown# useradd -s /sbin/nologin redis# chown -R redis:redis /usr/local/redis# chown -R reids:redis /data/redis# yum install -y bash-completion && source /etc/profile                 #命令补全# systemctl daemon-reload# systemctl enable redis

• 修改配置：

192.168.30.128

# mkdir -p /data/redis# vim /usr/local/redis/redis.confbind 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.confbind 192.168.30.129daemonize yeslogfile "/usr/local/redis/redis.log"dir /data/redisreplicaof 192.168.30.128 6379masterauth 123456requirepass 123456appendonly yes# echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf# sysctl -p

192.168.30.130

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

全部启动redis：

# systemctl start redis

查看集群状态：

# redis-cli -h 192.168.30.128 -a 123456Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.192.168.30.128:6379> info replication# Replicationrole:masterconnected_slaves:2slave0:ip=192.168.30.129,port=6379,state=online,offset=168,lag=1slave1:ip=192.168.30.130,port=6379,state=online,offset=168,lag=1master_replid:fb4941e02d5032ad74c6e2383211fc58963dbe90master_replid2:0000000000000000000000000000000000000000master_repl_offset:168second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:168

# redis-cli -h 192.168.30.129 -a 123456 info replicationWarning: Using a password with '-a' or '-u' option on the command line interface may not be safe.# Replicationrole:slavemaster_host:192.168.30.128master_port:6379master_link_status:upmaster_last_io_seconds_ago:1master_sync_in_progress:0slave_repl_offset:196slave_priority:100slave_read_only:1connected_slaves:0master_replid:fb4941e02d5032ad74c6e2383211fc58963dbe90master_replid2:0000000000000000000000000000000000000000master_repl_offset:196second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:196

数据演示：

192.168.30.128:6379> keys *(empty list or set)192.168.30.128:6379> set key1 100OK192.168.30.128:6379> set key2 lzxOK192.168.30.128:6379> keys *1) "key1"2) "key2"

# redis-cli -h 192.168.30.129 -a 123456Warning: 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 dir1) "dir"2) "/data/redis"192.168.30.129:6379> CONFIG GET dbfilename1) "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.

# redis-cli -h 192.168.30.130 -a 123456Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.192.168.30.130:6379> keys *1) "key2"2) "key1"192.168.30.130:6379> CONFIG GET dir1) "dir"2) "/data/redis"192.168.30.130:6379> CONFIG GET dbfilename1) "dbfilename"2) "dump.rdb"192.168.30.130:6379> get key1"100"192.168.30.130:6379> get key2"lzx"192.168.30.130:6379> set key3 aaa(error) READONLY You can't write against a read only replica.

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

Sentinel模式

主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。

sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，特点如下：

* sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义* 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master* 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据* sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群* 多sentinel配置的时候，sentinel之间也会自动监控* 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心* 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis* sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了

工作机制：

* 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令 * 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。* 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态* 当有足够数量的sentinel(大于等于配置文件指定的值)在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线 * 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令 * 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次 * 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；  若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

Sentinel模式搭建

• 环境准备：

master节点              192.168.30.128          sentinel端口：26379

slave节点               192.168.30.129          sentinel端口：26379

slave节点               192.168.30.130          sentinel端口：26379

修改sentinel配置文件

192.168.30.128

# vim /usr/local/redis/sentinel.confdaemonize yeslogfile "/usr/local/redis/sentinel.log"dir "/usr/local/redis/sentinel"                 #sentinel工作目录sentinel monitor mymaster 192.168.30.128 6379 2                 #判断master失效至少需要2个sentinel同意，建议设置为n/2+1，n为sentinel个数sentinel auth-pass mymaster 123456sentinel down-after-milliseconds mymaster 30000                 #判断master主观下线时间，默认30s

这里需要注意，sentinel auth-pass mymaster 123456需要配置在sentinel monitor mymaster 192.168.30.128 6379 2下面，否则启动报错：

# /usr/local/bin/redis-sentinel /usr/local/redis/sentinel.conf*** FATAL CONFIG FILE ERROR ***Reading the configuration file, at line 104>>> 'sentinel auth-pass mymaster 123456'No such master with specified name.

全部启动sentinel：

# mkdir /usr/local/redis/sentinel && chown -R redis:redis /usr/local/redis# /usr/local/bin/redis-sentinel /usr/local/redis/sentinel.conf

任一主机查看日志：

# tail -f /usr/local/redis/sentinel.log21574:X 09 May 2019 15:32:04.298 # Sentinel ID is 30c417116a8edbab09708037366c4a7471beb77021574:X 09 May 2019 15:32:04.298 # +monitor master mymaster 192.168.30.128 6379 quorum 221574:X 09 May 2019 15:32:04.299 * +slave slave 192.168.30.129:6379 192.168.30.129 6379 @ mymaster 192.168.30.128 637921574:X 09 May 2019 15:32:04.300 * +slave slave 192.168.30.130:6379 192.168.30.130 6379 @ mymaster 192.168.30.128 637921574:X 09 May 2019 15:32:16.347 * +sentinel sentinel 79b8d61626afd4d059fb5a6a63393e9a1374e78f 192.168.30.129 26379 @ mymaster 192.168.30.128 637921574:X 09 May 2019 15:32:31.584 * +sentinel sentinel d7b429dcba792103ef0d80827dd0910bd9284d21 192.168.30.130 26379 @ mymaster 192.168.30.128 6379

Sentinel模式下的几个事件：

+reset-master ：主服务器已被重置。·       +slave ：一个新的从服务器已经被 Sentinel 识别并关联。·       +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。·       +failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。·       +slave-reconf-sent ：领头(leader)的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。·       +slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。·       +slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。·       -dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。·       +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。·       +sdown ：给定的实例现在处于主观下线状态。·       -sdown ：给定的实例已经不再处于主观下线状态。·       +odown ：给定的实例现在处于客观下线状态。·       -odown ：给定的实例已经不再处于客观下线状态。·       +new-epoch ：当前的纪元(epoch)已经被更新。·       +try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中(waiting to be elected by the majority)。·       +elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。·       +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。·       no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。·       selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。·       failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。·       failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器(slaves will eventually be configured to replicate with the new master anyway)。·       failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。·       +switch-master ：配置变更，主服务器的 IP 和地址已经改变。这是绝大多数外部用户都关心的信息。·       +tilt ：进入 tilt 模式。·       -tilt ：退出 tilt 模式。

• master宕机演示：

192.168.30.128

# systemctl stop redis# tail -f /usr/local/redis/sentinel.log22428:X 09 May 2019 15:51:29.287 # +sdown master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:29.371 # +odown master mymaster 192.168.30.128 6379 #quorum 2/222428:X 09 May 2019 15:51:29.371 # +new-epoch 122428:X 09 May 2019 15:51:29.371 # +try-failover master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:29.385 # +vote-for-leader 30c417116a8edbab09708037366c4a7471beb770 122428:X 09 May 2019 15:51:29.403 # d7b429dcba792103ef0d80827dd0910bd9284d21 voted for 30c417116a8edbab09708037366c4a7471beb770 122428:X 09 May 2019 15:51:29.408 # 79b8d61626afd4d059fb5a6a63393e9a1374e78f voted for 30c417116a8edbab09708037366c4a7471beb770 122428:X 09 May 2019 15:51:29.451 # +elected-leader master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:29.451 # +failover-state-select-slave master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:29.528 # +selected-slave slave 192.168.30.129:6379 192.168.30.129 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:29.528 * +failover-state-send-slaveof-noone slave 192.168.30.129:6379 192.168.30.129 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:29.594 * +failover-state-wait-promotion slave 192.168.30.129:6379 192.168.30.129 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:30.190 # +promoted-slave slave 192.168.30.129:6379 192.168.30.129 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:30.190 # +failover-state-reconf-slaves master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:30.258 * +slave-reconf-sent slave 192.168.30.130:6379 192.168.30.130 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:30.511 # -odown master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:31.233 * +slave-reconf-inprog slave 192.168.30.130:6379 192.168.30.130 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:31.233 * +slave-reconf-done slave 192.168.30.130:6379 192.168.30.130 6379 @ mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:31.297 # +failover-end master mymaster 192.168.30.128 637922428:X 09 May 2019 15:51:31.297 # +switch-master mymaster 192.168.30.128 6379 192.168.30.129 637922428:X 09 May 2019 15:51:31.298 * +slave slave 192.168.30.130:6379 192.168.30.130 6379 @ mymaster 192.168.30.129 637922428:X 09 May 2019 15:51:31.298 * +slave slave 192.168.30.128:6379 192.168.30.128 6379 @ mymaster 192.168.30.129 637922428:X 09 May 2019 15:52:31.307 # +sdown slave 192.168.30.128:6379 192.168.30.128 6379 @ mymaster 192.168.30.129 6379

从日志中可以看到，master已经从192.168.30.128转移到192.168.30.129上

192.168.30.129上查看集群信息

# /usr/local/bin/redis-cli -h 192.168.30.129 -p 6379 -a 123456Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.192.168.30.129:6379> info replication# Replicationrole:masterconnected_slaves:1slave0:ip=192.168.30.130,port=6379,state=online,offset=291039,lag=1master_replid:757aff269236ed2707ba584a86a40716c1c76d74master_replid2:47a862fc0ff20362be29096ecdcca6d432070ee9master_repl_offset:291182second_repl_offset:248123repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:291182192.168.30.129:6379> set key4 linuxOK

当前集群中只有一个slave——192.168.30.130，master是192.168.30.129，且192.168.30.129具有写权限。

192.168.30.130上查看redis的配置文件也可以看到replicaof 192.168.30.129 6379，这是sentinel在选举master是做的修改。

重新把192.168.30.128上进程启动

# systemctl start redis# tail -f /usr/local/redis/sentinel.log22428:X 09 May 2019 15:51:31.297 # +switch-master mymaster 192.168.30.128 6379 192.168.30.129 637922428:X 09 May 2019 15:51:31.298 * +slave slave 192.168.30.130:6379 192.168.30.130 6379 @ mymaster 192.168.30.129 637922428:X 09 May 2019 15:51:31.298 * +slave slave 192.168.30.128:6379 192.168.30.128 6379 @ mymaster 192.168.30.129 637922428:X 09 May 2019 15:52:31.307 # +sdown slave 192.168.30.128:6379 192.168.30.128 6379 @ mymaster 192.168.30.129 637922428:X 09 May 2019 16:01:24.872 # -sdown slave 192.168.30.128:6379 192.168.30.128 6379 @ mymaster 192.168.30.129 6379

查看集群信息

# /usr/local/bin/redis-cli -h 192.168.30.128 -p 6379 -a 123456Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.192.168.30.128:6379> info replication# Replicationrole:slavemaster_host:192.168.30.129master_port:6379master_link_status:upmaster_last_io_seconds_ago:0master_sync_in_progress:0slave_repl_offset:514774slave_priority:100slave_read_only:1connected_slaves:0master_replid:757aff269236ed2707ba584a86a40716c1c76d74master_replid2:0000000000000000000000000000000000000000master_repl_offset:514774second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:376528repl_backlog_histlen:138247192.168.30.128:6379> get key4"linux"192.168.30.128:6379> set key5(error) ERR wrong number of arguments for 'set' command

即使192.168.30.128重新启动redis服务，也是作为slave加入redis集群，192.168.30.129仍然是master。

Cluster模式

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。

cluster集群特点：

* 多个redis节点网络互联，数据共享* 所有的节点都是一主一从(也可以是一主多从)，其中从不提供服务，仅作为备用* 不支持同时处理多个key(如MSET/MGET)，因为redis需要把key均匀分布在各个节点上，  并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为  * 支持在线增加、删除节点* 客户端可以连接任何一个主节点进行读写

Cluster模式搭建

• 环境准备：

三台机器，分别开启两个redis服务(端口)

192.168.30.128              端口：7001,7002

192.168.30.129              端口：7003,7004

192.168.30.130              端口：7005,7006

• 修改配置文件：

192.168.30.128

# mkdir /usr/local/redis/cluster# cp /usr/local/redis/redis.conf /usr/local/redis/cluster/redis_7001.conf# cp /usr/local/redis/redis.conf /usr/local/redis/cluster/redis_7002.conf# chown -R redis:redis /usr/local/redis# mkdir -p /data/redis/cluster/{redis_7001,redis_7002} && chown -R redis:redis /data/redis

# vim /usr/local/redis/cluster/redis_7001.confbind 192.168.30.128port 7001daemonize yespidfile "/var/run/redis_7001.pid"logfile "/usr/local/redis/cluster/redis_7001.log"dir "/data/redis/cluster/redis_7001"#replicaof 192.168.30.129 6379masterauth 123456requirepass 123456appendonly yescluster-enabled yescluster-config-file nodes_7001.confcluster-node-timeout 15000

# vim /usr/local/redis/cluster/redis_7002.confbind 192.168.30.128port 7002daemonize yespidfile "/var/run/redis_7002.pid"logfile "/usr/local/redis/cluster/redis_7002.log"dir "/data/redis/cluster/redis_7002"#replicaof 192.168.30.129 6379masterauth "123456"requirepass "123456"appendonly yescluster-enabled yescluster-config-file nodes_7002.confcluster-node-timeout 15000

其它两台机器配置与192.168.30.128一致，此处省略

• 启动redis服务：

# redis-server /usr/local/redis/cluster/redis_7001.conf# tail -f /usr/local/redis/cluster/redis_7001.log# redis-server /usr/local/redis/cluster/redis_7002.conf# tail -f /usr/local/redis/cluster/redis_7002.log

其它两台机器启动与192.168.30.128一致，此处省略

• 安装ruby并创建集群(低版本)：

如果redis版本比较低，则需要安装ruby。任选一台机器安装ruby即可

# yum -y groupinstall "Development Tools"# yum install -y gdbm-devel libdb4-devel libffi-devel libyaml libyaml-devel ncurses-devel openssl-devel readline-devel tcl-devel# mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}# wget http://cache.ruby-lang.org/pub/ruby/2.2/ruby-2.2.3.tar.gz -P ~/rpmbuild/SOURCES# wget http://raw.githubusercontent.com/tjinjin/automate-ruby-rpm/master/ruby22x.spec -P ~/rpmbuild/SPECS# rpmbuild -bb ~/rpmbuild/SPECS/ruby22x.spec# rpm -ivh ~/rpmbuild/RPMS/x86_64/ruby-2.2.3-1.el7.x86_64.rpm# gem install redis                 #目的是安装这个，用于配置集群

# cp /usr/local/redis/src/redis-trib.rb /usr/bin/# redis-trib.rb create --replicas 1 192.168.30.128:7001 192.168.30.128:7002 192.168.30.129:7003 192.168.30.129:7004 192.168.30.130:7005 192.168.30.130:7006

• 创建集群：

高版本不需要安装ruby，直接创建集群即可

# redis-cli -a 123456 --cluster create 192.168.30.128:7001 192.168.30.128:7002 192.168.30.129:7003 192.168.30.129:7004 192.168.30.130:7005 192.168.30.130:7006 --cluster-replicas 1Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.>>> Performing hash slots allocation on 6 nodes...Master[0] -> Slots 0 - 5460Master[1] -> Slots 5461 - 10922Master[2] -> Slots 10923 - 16383Adding replica 192.168.30.129:7004 to 192.168.30.128:7001Adding replica 192.168.30.130:7006 to 192.168.30.129:7003Adding replica 192.168.30.128:7002 to 192.168.30.130:7005M: 80c80a3f3e33872c047a8328ad579b9bea001ad8 192.168.30.128:7001   slots:[0-5460] (5461 slots) masterS: b4d3eb411a7355d4767c6c23b4df69fa183ef8bc 192.168.30.128:7002   replicates 6788453ee9a8d7f72b1d45a9093838efd0e501f1M: 4d74ec66e898bf09006dac86d4928f9fad81f373 192.168.30.129:7003   slots:[5461-10922] (5462 slots) masterS: b6331cbc986794237c83ed2d5c30777c1551546e 192.168.30.129:7004   replicates 80c80a3f3e33872c047a8328ad579b9bea001ad8M: 6788453ee9a8d7f72b1d45a9093838efd0e501f1 192.168.30.130:7005   slots:[10923-16383] (5461 slots) masterS: 277daeb8660d5273b7c3e05c263f861ed5f17b92 192.168.30.130:7006   replicates 4d74ec66e898bf09006dac86d4928f9fad81f373Can I set the above configuration? (type 'yes' to accept): yes                  #输入yes，接受上面配置>>> Nodes configuration updated>>> Assign a different config epoch to each node>>> Sending CLUSTER MEET messages to join the cluster

192.168.30.128:7001是master，它的slave是192.168.30.129:7004；192.168.30.129:7003是master，它的slave是192.168.30.130:7006；192.168.30.130:7005是master，它的slave是192.168.30.128:7002

自动生成nodes.conf文件：

# ls /data/redis/cluster/redis_7001/appendonly.aof  dump.rdb  nodes-7001.conf# vim /data/redis/cluster/redis_7001/nodes-7001.conf 6788453ee9a8d7f72b1d45a9093838efd0e501f1 192.168.30.130:7005@17005 master - 0 1557454406312 5 connected 10923-16383277daeb8660d5273b7c3e05c263f861ed5f17b92 192.168.30.130:7006@17006 slave 4d74ec66e898bf09006dac86d4928f9fad81f373 0 1557454407000 6 connectedb4d3eb411a7355d4767c6c23b4df69fa183ef8bc 192.168.30.128:7002@17002 slave 6788453ee9a8d7f72b1d45a9093838efd0e501f1 0 1557454408371 5 connected80c80a3f3e33872c047a8328ad579b9bea001ad8 192.168.30.128:7001@17001 myself,master - 0 1557454406000 1 connected 0-5460b6331cbc986794237c83ed2d5c30777c1551546e 192.168.30.129:7004@17004 slave 80c80a3f3e33872c047a8328ad579b9bea001ad8 0 1557454407366 4 connected4d74ec66e898bf09006dac86d4928f9fad81f373 192.168.30.129:7003@17003 master - 0 1557454407000 3 connected 5461-10922vars currentEpoch 6 lastVoteEpoch 0

集群操作

• 登录集群：

# redis-cli -c -h 192.168.30.128 -p 7001 -a 123456                  # -c，使用集群方式登录

查看集群信息：

192.168.30.128:7001> CLUSTER INFO                   #集群状态cluster_state:okcluster_slots_assigned:16384cluster_slots_ok:16384cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:3cluster_current_epoch:6cluster_my_epoch:1cluster_stats_messages_ping_sent:580cluster_stats_messages_pong_sent:551cluster_stats_messages_sent:1131cluster_stats_messages_ping_received:546cluster_stats_messages_pong_received:580cluster_stats_messages_meet_received:5cluster_stats_messages_received:1131

列出节点信息：

192.168.30.128:7001> CLUSTER NODES                  #列出节点信息6788453ee9a8d7f72b1d45a9093838efd0e501f1 192.168.30.130:7005@17005 master - 0 1557455176000 5 connected 10923-16383277daeb8660d5273b7c3e05c263f861ed5f17b92 192.168.30.130:7006@17006 slave 4d74ec66e898bf09006dac86d4928f9fad81f373 0 1557455174000 6 connectedb4d3eb411a7355d4767c6c23b4df69fa183ef8bc 192.168.30.128:7002@17002 slave 6788453ee9a8d7f72b1d45a9093838efd0e501f1 0 1557455175000 5 connected80c80a3f3e33872c047a8328ad579b9bea001ad8 192.168.30.128:7001@17001 myself,master - 0 1557455175000 1 connected 0-5460b6331cbc986794237c83ed2d5c30777c1551546e 192.168.30.129:7004@17004 slave 80c80a3f3e33872c047a8328ad579b9bea001ad8 0 1557455174989 4 connected4d74ec66e898bf09006dac86d4928f9fad81f373 192.168.30.129:7003@17003 master - 0 1557455175995 3 connected 5461-10922

redis cluster集群是去中心化的，每个节点都是平等的，连接哪个节点都可以获取和设置数据。

当然，平等指的是master节点，因为slave节点根本不提供服务，只是作为对应master节点的一个备份。

• 增加节点：

192.168.30.129上增加一节点：

# cp /usr/local/redis/cluster/redis_7003.conf /usr/local/redis/cluster/redis_7007.conf# vim /usr/local/redis/cluster/redis_7007.confbind 192.168.30.129port 7007daemonize yespidfile "/var/run/redis_7007.pid"logfile "/usr/local/redis/cluster/redis_7007.log"dir "/data/redis/cluster/redis_7007"#replicaof 192.168.30.129 6379masterauth "123456"requirepass "123456"appendonly yescluster-enabled yescluster-config-file nodes_7007.confcluster-node-timeout 15000# mkdir /data/redis/cluster/redis_7007# chown -R redis:redis /usr/local/redis && chown -R redis:redis /data/redis# redis-server /usr/local/redis/cluster/redis_7007.conf

集群中增加节点：

192.168.30.129:7003> CLUSTER MEET 192.168.30.129 7007OK192.168.30.129:7003> CLUSTER NODES4d74ec66e898bf09006dac86d4928f9fad81f373 192.168.30.129:7003@17003 myself,master - 0 1557457361000 3 connected 5461-1092280c80a3f3e33872c047a8328ad579b9bea001ad8 192.168.30.128:7001@17001 master - 0 1557457364746 1 connected 0-5460277daeb8660d5273b7c3e05c263f861ed5f17b92 192.168.30.130:7006@17006 slave 4d74ec66e898bf09006dac86d4928f9fad81f373 0 1557457362000 6 connectedb6331cbc986794237c83ed2d5c30777c1551546e 192.168.30.129:7004@17004 slave 80c80a3f3e33872c047a8328ad579b9bea001ad8 0 1557457363000 4 connectedb4d3eb411a7355d4767c6c23b4df69fa183ef8bc 192.168.30.128:7002@17002 slave 6788453ee9a8d7f72b1d45a9093838efd0e501f1 0 1557457362000 5 connectede51ab166bc0f33026887bcf8eba0dff3d5b0bf14 192.168.30.129:7007@17007 master - 0 1557457362729 0 connected6788453ee9a8d7f72b1d45a9093838efd0e501f1 192.168.30.130:7005@17005 master - 0 1557457363739 5 connected 10923-16383

• 更换节点身份：

将新增的192.168.30.130:7008节点身份改为192.168.30.129:7007的slave

# redis-cli -c -h 192.168.30.130 -p 7008 -a 123456 cluster replicate e51ab166bc0f33026887bcf8eba0dff3d5b0bf14

删除节点：

192.168.30.130:7008> CLUSTER FORGET 1a1c7f02fce87530bd5abdfc98df1cffce4f1767(error) ERR I tried hard but I can't forget myself...               #无法删除登录节点192.168.30.130:7008> CLUSTER FORGET e51ab166bc0f33026887bcf8eba0dff3d5b0bf14(error) ERR Can't forget my master!                 #不能删除自己的master节点192.168.30.130:7008> CLUSTER FORGET 6788453ee9a8d7f72b1d45a9093838efd0e501f1OK              #可以删除其它的master节点192.168.30.130:7008> CLUSTER NODES277daeb8660d5273b7c3e05c263f861ed5f17b92 192.168.30.130:7006@17006 slave 4d74ec66e898bf09006dac86d4928f9fad81f373 0 1557458887328 3 connected80c80a3f3e33872c047a8328ad579b9bea001ad8 192.168.30.128:7001@17001 master - 0 1557458887000 1 connected 0-54604d74ec66e898bf09006dac86d4928f9fad81f373 192.168.30.129:7003@17003 master - 0 1557458886000 3 connected 5461-10922b4d3eb411a7355d4767c6c23b4df69fa183ef8bc 192.168.30.128:7002@17002 slave - 0 1557458888351 5 connected1a1c7f02fce87530bd5abdfc98df1cffce4f1767 192.168.30.130:7008@17008 myself,slave e51ab166bc0f33026887bcf8eba0dff3d5b0bf14 0 1557458885000 7 connectedb6331cbc986794237c83ed2d5c30777c1551546e 192.168.30.129:7004@17004 slave 80c80a3f3e33872c047a8328ad579b9bea001ad8 0 1557458883289 1 connectede51ab166bc0f33026887bcf8eba0dff3d5b0bf14 192.168.30.129:7007@17007 master - 0 1557458885310 0 connected