说说Redis分布式锁是如何实现的。含Redis面试专题及答案

前言

近来，分布式的问题被广泛提及，比如分布式事务、分布式框架、ZooKeeper、SpringCloud等等。本文先回顾锁的概念，再介绍分布式锁，以及如何用Redis来实现分布式锁。

一、锁的基本了解

首先，回顾一下我们工作学习中的锁的概念。

为什么要先讲锁再讲分布式锁呢？

我们都清楚，锁的作用是要解决多线程对共享资源的访问而产生的线程安全问题，而在平时生活中用到锁的情况其实并不多，可能有些朋友对锁的概念和一些基本的使用不是很清楚，所以我们先看锁，再深入介绍分布式锁。

通过一个卖票的小案例来看，比如大家去抢dota2 ti9门票，如果不加锁的话会出现什么问题？此时代码如下：

**代码分析：**这里有8张ti9门票，设置了10个线程（也就是模拟10个人）去并发抢票，如果抢成功了显示成功，抢失败的话显示失败。按理说应该有8个人抢成功了，2个人抢失败，下面来看运行结果：

我们发现运行结果和预期的情况不一致，居然10个人都买到了票，也就是说出现了线程安全的问题，那么是什么原因导致的呢？

原因就是多个线程之间产生了时间差。

如图所示，只剩一张票了，但是两个线程都读到的票余量是1，也就是说线程B还没有等到线程A改库存就已经抢票成功了。

怎么解决呢？想必大家都知道，加个synchronized关键字就可以了，在一个线程进行reduce方法的时候，其他线程则阻塞在等待队列中，这样就不会发生多个线程对共享变量的竞争问题。

举个例子

比如我们去健身房健身，如果好多人同时用一台机器，同时在一台跑步机上跑步，就会发生很大的问题，大家会打得不可开交。如果我们加一把锁在健身房门口，只有拿到锁的钥匙的人才可以进去锻炼，其他人在门外等候，这样就可以避免大家对健身器材的竞争。代码如下：

运行结果：

果不其然，结果有两个人没有成功抢到票，看来我们的目地达成了。

二、锁的性能优化

2.1 缩短锁的持有时间

事实上，按照我们对日常生活的理解，不可能整个健身房只有一个人在运动。所以我们只需要对某一台机器加锁就可以了，比如一个人在跑步，另一个人可以去做其他的运动。

对于票务系统来说，我们只需要对库存的修改操作的代码加锁就可以了，别的代码还是可以并行进行，这样会大大减少锁的持有时间，代码修改如下：

这样做的目的是充分利用cpu的资源，提高代码的执行效率。

这里我们对两种方式的时间做个打印：

果然，只对部分代码加锁会大大提供代码的执行效率。

所以，在解决了线程安全的问题后，我们还要考虑到加锁之后的代码执行效率问题。

2.2 减少锁的粒度

举个例子，有两场电影，分别是最近刚上映的魔童哪吒和蜘蛛侠，我们模拟一个支付购买的过程，让方法等待，加了一个CountDownLatch的await方法，运行结果如下：

执行结果：

魔童哪吒的剩余票数为：20

我们发现买哪吒票的时候阻塞会影响蜘蛛侠票的购买，而实际上，这两场电影之间是相互独立的，所以我们需要减少锁的粒度，将movie整个对象的锁变为两个全局变量的锁，修改代码如下：

执行结果：

魔童哪吒的剩余票数为：20

蜘蛛侠的剩余票数为：100

现在两场电影的购票不会互相影响了，这就是第二个优化锁的方式：减少锁的粒度。顺便提一句，Java并发包里的ConcurrentHashMap就是把一把大锁变成了16把小锁，通过分段锁的方式达到高效的并发安全。

2.3 锁分离

锁分离就是常说的读写分离，我们把锁分成读锁和写锁，读的锁不需要阻塞，而写的锁要考虑并发问题。

三、锁的种类

• 公平锁： ReentrantLock
• 非公平锁： Synchronized、ReentrantLock、cas
• 悲观锁： Synchronized
• 乐观锁：cas
• 独享锁：Synchronized、ReentrantLock
• 共享锁：Semaphore

这里就不一一讲述每一种锁的概念了，大家可以自己学习，锁还可以按照偏向锁、轻量级锁、重量级锁来分类。

四、Redis分布式锁

了解了锁的基本概念和锁的优化后，重点介绍分布式锁的概念。

上图所示是我们搭建的分布式环境，有三个购票项目，对应一个库存，每一个系统会有多个线程，和上文一样，对库存的修改操作加上锁，能不能保证这6个线程的线程安全呢？

当然是不能的，因为每一个购票系统都有各自的JVM进程，互相独立，所以加synchronized只能保证一个系统的线程安全，并不能保证分布式的线程安全。

所以需要对于三个系统都是公共的一个中间件来解决这个问题。

这里我们选择Redis来作为分布式锁，多个系统在Redis中set同一个key，只有key不存在的时候，才能设置成功，并且该key会对应其中一个系统的唯一标识，当该系统访问资源结束后，将key删除，则达到了释放锁的目的。

4.1 分布式锁需要注意哪些点

1）互斥性

在任意时刻只有一个客户端可以获取锁。

这个很容易理解，所有的系统中只能有一个系统持有锁。

2）防死锁

假如一个客户端在持有锁的时候崩溃了，没有释放锁，那么别的客户端无法获得锁，则会造成死锁，所以要保证客户端一定会释放锁。

Redis中我们可以设置锁的过期时间来保证不会发生死锁。

3）持锁人解锁

解铃还须系铃人，加锁和解锁必须是同一个客户端，客户端A的线程加的锁必须是客户端A的线程来解锁，客户端不能解开别的客户端的锁。

4）可重入

当一个客户端获取对象锁之后，这个客户端可以再次获取这个对象上的锁。

4.2 Redis分布式锁流程

Redis分布式锁的具体流程：

1）首先利用Redis缓存的性质在Redis中设置一个key-value形式的键值对，key就是锁的名称，然后客户端的多个线程去竞争锁，竞争成功的话将value设为客户端的唯一标识。Java学习圈子:14 201 9 080

2）竞争到锁的客户端要做两件事：

• 设置锁的有效时间 目的是防死锁 （非常关键）

需要根据业务需要，不断的压力测试来决定有效期的长短。

• 分配客户端的唯一标识，目的是保证持锁人解锁（非常重要）

所以这里的value就设置成唯一标识(比如uuid)。

3）访问共享资源

4）释放锁，释放锁有两种方式，第一种是有效期结束后自动释放锁，第二种是先根据唯一标识判断自己是否有释放锁的权限，如果标识正确则释放锁。

4.3 加锁和解锁

4.3.1 加锁

1）setnx命令加锁

set if not exists 我们会用到Redis的命令setnx，setnx的含义就是只有锁不存在的情况下才会设置成功。

2）设置锁的有效时间，防止死锁 expire

加锁需要两步操作，思考一下会有什么问题吗？

假如我们加锁完之后客户端突然挂了呢？那么这个锁就会成为一个没有有效期的锁，接着就可能发生死锁。虽然这种情况发生的概率很小，但是一旦出现问题会很严重，所以我们也要把这两步合为一步。

幸运的是，Redis3.0已经把这两个指令合在一起成为一个新的指令。

来看jedis的官方文档中的源码：

这就是我们想要的！

4.3.2 解锁

• 检查是否自己持有锁（判断唯一标识）；
• 删除锁。

解锁也是两步，同样也要保证解锁的原子性，把两步合为一步。

这就无法借助于Redis了，只能依靠Lua脚本来实现。

这就是一段判断是否自己持有锁并释放锁的Lua脚本。

为什么Lua脚本是原子性呢？因为Lua脚本是jedis用eval()函数执行的，如果执行则会全部执行完成。

五、Redis分布式锁代码实现

• 用一个上下文全局变量来记录持有锁的人的uuid，解锁的时候需要将该uuid作为参数传入Lua脚本中，来判断是否可以解锁。
• 要记录当前线程，来实现分布式锁的重入性，如果是当前线程持有锁的话，也属于加锁成功。
• 用eval函数来执行Lua脚本，保证解锁时的原子性。

六、分布式锁的对比

6.1 基于数据库的分布式锁

1）实现方式

获取锁的时候插入一条数据，解锁时删除数据。

2）缺点

• 数据库如果挂掉会导致业务系统不可用。
• 无法设置过期时间，会造成死锁。

6.2 基于zookeeper的分布式锁

1）实现方式

加锁时在指定节点的目录下创建一个新节点，释放锁的时候删除这个临时节点。因为有心跳检测的存在，所以不会发生死锁，更加安全。

2）缺点

性能一般，没有Redis高效。

所以：

• 从性能角度： Redis > zookeeper > 数据库
• 从可靠性（安全）性角度： zookeeper > Redis > 数据库

七、总结

本文从锁的基本概念出发，提出多线程访问共享资源会出现的线程安全问题，然后通过加锁的方式去解决线程安全的问题，这个方法会性能会下降，需要通过：缩短锁的持有时间、减小锁的粒度、锁分离三种方式去优化锁。

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适合的场景主要局限在较小数据量的高性能操作和运算上。

2 Redis的全称是什么？

Remote Dictionary Server

3 redis有哪些数据类型？

string字符串list可以重复的集合set不可以重复的集合hash类似于Mapzset(sorted set）带分数的set

4 一个字符串类型的智能存储最大容量是多少？

512M

5 怎么理解Redis事务？

Redis无法做到像关系型数据库事务那样严格的ACID属性，特别是Redis官网明确指出了Redis为什么不支持回滚。

为了内部结构简单、运行效率更高，Redis舍弃了事务控制过程中的回滚支持。一个队列中的多个命令除非是在加入队列时发现错误会做到整个事务都不执行，否则所有命令都会执行，哪怕是队列中有的命令执行失败——显然Redis并没有在这里对队列中的多条命令进行回滚处理。Redis认为这些错误都应该在开发过程中被发现，而不是产品上线之后。

配合WATCH命令之后Redis的事务可以实现乐观锁效果：一个队列中的命令在执行时如果检测到碰撞，则放弃自己的操作。

6 Redis事务相关的命令有哪几个？

MULTI、EXEC、DISCARD、WATCH

7 Redis key的过期时间和永久有效分别怎么设置？

EXPIRE和PERSIST命令。

8 Redis持久化数据和缓存怎么做扩容？

如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。

如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。4、Redis主要消耗什么物理资源？

内存。

9 为什么Redis需要把所有数据放到内存中？

Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度会严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。 如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。

10 Redis如何做内存优化？

尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.

11 缓存穿透

缓存系统定义：

按照KEY去查询VALUE，当KEY对应的VALUE一定不存在的时候并对KEY并发请求量很大的时候，就会对后端造成很大的压力。（查询一个必然不存在的数据。比如文章表，查询一个不存在的id，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。）

由于缓存不命中，每次都要查询持久层。从而失去缓存的意义。

解决方法：

（1）缓存层缓 存空值。

缓存太多空值，占用更多空间。（优化：给个空值过 期时间）

存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存空值进去）

（2）将数据库中所有的查询条件，放布隆过滤器中。当一个查询请求来临的时候，先经过布隆过滤器进行查，如果请求存在这个条件中，那么继续执行，如果不在，直接丢弃。

备注 ：

比如数据库中有10000个条件，那么布隆过滤器的容量size设置的要稍微比10000大一些，比如12000.

对于误判率的设置，根据实际项目，以及硬件设施来具体定。但一定不能设置为0，并且误判率设置的越小，哈希函数跟数组长度都会更多跟更长，那么对硬件，内存中间的要求就会相应 的高

private st atic BloomFilter bloomFi lt er = BloomFilter.create(Funnels.integerFue l(), s ize, 000 01) ;

有了siz跟误判率，那么布隆过滤器会产相应的哈希函数跟数组。

综上：我们可以利用布隆过滤器，将redis缓存击穿制在一个可容的范围内。

12 哨兵模式

如果Master异常，则会进行Master-Slave切换，将其中一Slae作为Master，将之前的Master作为Slave

下线：

①主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

②客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.

工作原理：

（1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 ；

（2）如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线；

（3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态；

（4）当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 ；

（5）在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

（6）当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 ；

（7）若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除；

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除；

13 悲观锁

执行操作前假设当前的操作肯定（或有很大几率）会被打断（悲观）。基于这个假设，我们在做操作前就会把相关资源锁定，不允许自己执行期间有其他操作干扰。

Redis不支持悲观锁。Redis作为缓存服务器使用时，以读操作为主，很少写操作，相应的操作被打断的几率较少。不采用悲观锁是为了防止降低性能。

14 乐观锁

执行操作前假设当前操作不会被打断（乐观）。基于这个假设，我们在做操作前不会锁定资源，万一发生了其他操作的干扰，那么本次操作将被放弃。

15 持久化

（1）RDB持久化：

每隔一段时间，将内存中的数据集写到磁盘

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

保存策略：

save 9 00 1 900 秒内如果至少有 1 个 key 的值变化，则保存

save 300 10 300 秒内如果至少有 10 个 key 的值变化，则保存

save 60 1 0000 60 秒内如果至10000 个 key 的值变化，则保存

（2）AOF 持久化: 以日志形式记录每个更新（(总结、改）操作

Redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。

保存策略：

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。

appendfsync no：将数据库保存操作的触发时机交给操作系统来进行调度更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

缺点：

1 比起RDB占用更多的磁盘空间

2 恢复备份速度要慢

3 每次读写都同步的话，有一定的性能压力

4 存在个别Bug，造成恢复不能

（3）选择策略：

可读的日志文本，通过操作AOF

官方推荐：

如果对数据不敏感，可以选单独用RDB；不建议单独用AOF，因为可能出现Bug;如果只是做纯内存缓存，可以都不用

16 Redis提供了哪几种持久化方式？

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

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

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

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

17 如何选择合适的持久化方式？

一般来说， 如果想达到足以媲美PostgreSQL的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

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

18 分布式Redis是前期做还是后期规模上来了再做好？为什么？

既然Redis是如此的轻量（单实例只使用1M内存）,为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。

一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。

这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。

19 Redis的内存占用情况怎么样？

给你举个例子： 100万个键值对（键是0到999999值是字符串“hello world”）在我的32位的Mac笔记本上 用了100MB。同样的数据放到一个key里只需要16MB， 这是因为键值有一个很大的开销。 在Memcached上执行也是类似的结果，但是相对Redis的开销要小一点点，因为Redis会记录类型信息引用计数等等。

当然，大键值对时两者的比例要好很多。

64位的系统比32位的需要更多的内存开销，尤其是键值对都较小时，这是因为64位的系统里指针占用了8个字节。 但是，当然，64位系统支持更大的内存，所以为了运行大型的Redis服务器或多或少的需要使用64位的系统。

20 都有哪些办法可以降低Redis的内存使用情况呢？

如果你使用的是32位的Redis实例，可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。

21 查看Redis使用情况及状态信息用什么命令？

info

22 Redis的内存用完了会发生什么？

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

23 redis是单线程的，为什么那么快？

1)完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)

2)数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的

3)采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗

4)使用多路I/O复用模型，非阻塞IO

5)使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

24 Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。

25 一个Redis实例最多能存放多少的keys？List、Set、Sorted Set他们最多能存放多少元素？

理论上Redis可以处理多达2^32的keys，并且在实际中进行了测试，每个实例至少存放了2亿5千万的keys。我们正在测试一些较大的值。

任何list、set、和sorted set都可以放2^32个元素。

换句话说，Redis的存储极限是系统中的可用内存值。

26 Redis常见性能问题和解决方案？

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

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

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

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

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

这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

27 Redis相比memcached有哪些优势？

(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis的速度比memcached快很多

• redis可以持久化其数据

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

redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

29 Redis有哪几种数据淘汰策略？

noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）

allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。

volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。

allkeys-random: 回收随机的键使得新添加的数据有空间存放。

volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。

volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。

30 Redis集群方案应该怎么做？都有哪些方案？

（1）twemproxy，大概概念是，它类似于一个代理方式，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本地需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。使用方式简便(相对redis只需修改连接端口)，对旧项目扩展的首选。 问题：twemproxy自身单端口实例的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。

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

（3）redis cluster3.0自带的集群，特点在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。

（4）在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key 进行hash计算，然后去对应的redis实例操作数据。 这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。

31 说说Redis哈希槽的概念？

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

32 Redis集群最大节点个数是多少？

16384个。

33 怎么测试Redis的连通性？

ping

34 修改配置不重启Redis会实时生效吗？

针对运行实例，有许多配置选项可以通过 CONFIG SET 命令进行修改，而无需执行任何形式的重启。 从 Redis 2.2 开始，可以从 AOF 切换到 RDB 的快照持久性或其他方式而不需要重启 Redis。检索 ‘CONFIG GET *’ 命令获取更多信息。

但偶尔重新启动是必须的，如为升级 Redis 程序到新的版本，或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候。

35 Redis有哪些适合的场景？

（1）会话缓存（Session Cache）

最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

（2）全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。

此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

（3）队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。

如果你快速地在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。

（4）排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。

（5）发布/订阅

最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！

总结

小伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我，后面会有很多干货。我有一些面试题、架构、设计类资料可以说是程序员面试必备！所有资料都整理到网盘了，需要的话欢迎下载！私信我回复【999】即可免费获取