Redis Cluster集群

無熵

已于 2024-08-15 21:11:07 修改

阅读量1k

点赞数 23

分类专栏： linux 进阶文章标签： redis 数据库缓存

于 2024-08-14 21:14:38 首次发布

本文链接：https://blog.csdn.net/m0_54563444/article/details/141181601

版权

linux 同时被 2 个专栏收录

35 篇文章 0 订阅

订阅专栏

进阶

4 篇文章 0 订阅

订阅专栏

redis-cluster集群

Redis Cluster是Redis官方提供的分布式解决方案。当遇到内存、并发、流量等瓶颈时，就可以采用Cluster架构达到负载均衡目的。

1.Redis单实例主要有单点故障，容量有限，流量压力上限的问题。
Redis单点故障，可以通过主从复制replication，和自动故障转移sentinel哨兵机制。但Redis单Master实例提供读写服务，仍然有容量和压力问题。

2.并发问题
redis官方声称可以达到 10万/每秒,每秒执行10万条命令，假如业务需要每秒100万的命令执行呢？

Redis集群采用的原因
Redis集群通过分布式存储和复制机制，提供了高可用性、扩展性、负载均衡和数据一致性等优势，能够更好地满足大规模数据存储和高并发访问的需求。
1. 高可用性： Redis单实例存在单点故障的问题，一旦实例出现故障，业务将无法正常访问。通过使用Redis集群，可以实现数据的分布和复制，在节点故障时可以进行自动故障转移。这样可以保证系统的可用性，减少因为单点故障而导致的服务中断。
2. 扩展性： Redis单实例的容量有限，无法满足大规模数据存储和高并发访问的需求。通过使用Redis集群，可以将数据分布在多个节点上，提供更大的存储空间。同时，多个节点可以并行处理请求，提高了系统的并发能力。
3. 负载均衡： Redis集群会自动将数据均匀地分配到不同的节点上，实现负载均衡。这样可以避免单个节点的负载过高，提高整个系统的性能和稳定性。
4. 数据一致性： Redis集群采用主从复制的机制，可以保证数据在不同节点之间的一致性。当主节点写入数据后，会自动将数据同步到从节点上。这样可以提高数据的可靠性和冗余备份。


解决方案
正确的应该是考虑分布式，加机器，把数据分到不同的位置，那么一堆机器做一件事，分摊集中式的压力。但是还需要一定的机制保证数据分区，并且数据在各个主Master节点间不能混乱。

总结
redis cluster:主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster

从redis 3.0之后版本支持redis-cluster集群，它是Redis官方提出的解决方案：

Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。其redis-cluster架构图如下

2.1.redis cluster特点

1.所有的redis节点彼此互联(PING-PONG机制)。
2.客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
3.节点的fail是通过集群中超过半数的节点检测失效时才生效。

2.2redis-cluster数据分布

分布式数据分布方式为一致性hsah方式。
redis集群的hash slot方式：
Redis集群中有16384个哈希槽，每个redis实例负责一部分slot，集群中的所有信息通过节点数据交换而更新。

2.3数据分布存储原理

Redis 集群使用数据分片（sharding）来实现。

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，Redis会先对键使用CRC16算法计算出一个16位的结果。然后，该结果会被16384取余，得到一个范围在0到16383之间的数字，即哈希槽编号（hash slot）。每个键都会被分配到对应编号的哈希槽上，这样就实现了数据的分布式存储。无论是写入还是读取操作，Redis都会根据键的哈希槽编号将请求路由到相应的节点上。

例如三个节点：哈希槽分布的值如下：

cluster1:  0-5460
cluster2:  5461-10922
cluster3:  10923-16383
假设有一个键为"mykey"，经过CRC16算法计算后得到的结果为12345。然后，将12345对16384取余，得到哈希槽编号为4567。那么Redis会将"mykey"分配到哈希槽编号为4567的节点cluster1上进行存储。

3、Redis Cluster主从模式

redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉.

1.主从切换机制
选举过程是集群中所有master参与,如果半数以上master节点与故障节点通信超过(cluster-node-timeout),认为该节点故障，自动触发故障转移操作。故障节点对应的从节点自动升级为主节点

2.什么时候整个集群就不能用了？
如果集群任意一个主节点挂掉,且当前主节点没有从节点，则集群将无法继续，因为没有办法为这个节点承担范围内的哈希槽提供服务。但是，如果这个主节点和所对应的从节点同时失败，则Redis Cluster无法继续运行。

二、集群部署

在准备环境部署 Redis 集群之前，需要做以下准备工作：
1.准备三台机器，并关闭防火墙和 SELinux： 在集群中，至少需要三台机器，每台机器都需要安装
和配置 Redis。在每台机器上，需要关闭防火墙和 SELinux，以确保 Redis 集群的正常通信。
2.制作解析并相互做解析： 在每台机器上设置主机名，并在 DNS 服务器上添加相应的解析。确保每
台机器可以相互解析主机名，以便集群中的节点可以通过主机名进行通信。（可选）
3.在规划架构时，有两种方案可选，一种是单机多实例，另一种是多机器部署。在此示例中，我们采用
多机器部署方案：
第一台机器：
    主库1：192.168.116.172:7000    备库1：192.168.116.172:7001
第二台机器：
    主库2：192.168.116.173:7002    备库2：192.168.116.173:7003
第三台机器：
    主库3：192.168.116.174:7004    备库3：192.168.116.174:7005
在此配置下，每台机器上部署了两个 Redis 实例，一个作为主库，一个作为备库。这样可以提供主
从复制和故障转移的功能。
在集群中，还需要选出一个控制节点，该节点用于管理整个集群的状态和配置。可以在其中一台机器上
指定为控制节点。

三台机器相同操作

1.安装redis
[root@redis-cluster1 ~]# mkdir /data
[root@redis-cluster1 ~]# yum -y install gcc automake autoconf libtool make
[root@redis-cluster1 ~]# wget https://download.redis.io/releases/redis-6.2.0.tar.gz
[root@redis-cluster1 ~]# tar xzvf redis-6.2.0.tar.gz -C /data/
[root@redis-cluster1 ~]# cd /data/
[root@redis-cluster1 data]# mv redis-6.2.0/ redis
[root@redis-cluster1 data]# cd redis/
[root@redis-cluster1 redis]# make    #编译
[root@redis-cluster1 redis]# mkdir /data/redis/data #创建存放数据的目录

2.创建节点目录:按照规划在每台redis节点的安装目录中创建对应的目录（以端口号命名）
[root@redis-cluster1 redis]# pwd
/data/redis
[root@redis-cluster1 redis]# mkdir cluster #创建集群目录
[root@redis-cluster1 redis]# cd cluster/
[root@redis-cluster1 cluster]# mkdir 7000 7001 #创建节点目录

[root@redis-cluster2 redis]# mkdir cluster
[root@redis-cluster2 redis]# cd cluster/
[root@redis-cluster2 cluster]# mkdir 7002 7003

[root@redis-cluster3 redis]# mkdir cluster
[root@redis-cluster3 redis]# cd cluster/
[root@redis-cluster3 cluster]# mkdir 7004 7005

3.拷贝配置文件到节点目录中，#三台机器相同操作
[root@redis-cluster1 cluster]# cp /data/redis/redis.conf 7000/
[root@redis-cluster1 cluster]# cp /data/redis/redis.conf 7001/

[root@redis-cluster2 cluster]# cp /data/redis/redis.conf 7002/
[root@redis-cluster2 cluster]# cp /data/redis/redis.conf 7003/

[root@redis-cluster3 cluster]# cp /data/redis/redis.conf 7004/
[root@redis-cluster3 cluster]# cp /data/redis/redis.conf 7005/

4.修改集群每个redis配置文件。(主要是端口、ip、pid文件，三台机器相同操作)，修改如下：
[root@redis-cluster1 cluster]# cd 7000/
[root@redis-cluster1 7000]# vim redis.conf #修改如下
bind 192.168.116.172  #每个实例的配置文件修改为对应节点的ip地址
protected-mode no
port 7000   #监听端口，运行多个实例时，需要指定规划的每个实例不同的端口号
daemonize yes #redis后台运行
pidfile /var/run/redis_7000.pid #pid文件，运行多个实例时，需要指定不同的pid文件
logfile /var/log/redis_7000.log #日志文件位置，运行多实例时，需要将文件修改的不同。
dir /data/redis/data #存放数据的目录
appendonly yes #开启AOF持久化，redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中，当redis重新启动时，会从该文件恢复出之前的状态。
appendfilename "appendonly.aof"  #AOF文件名称
appendfsync everysec #表示对写操作进行累积，每秒同步一次。
以下为打开注释并修改
cluster-enabled yes #启用集群
cluster-config-file nodes-7000.conf #集群配置文件，由redis自动更新，不需要手动配置，运行多实例时请注修改为对应端口
cluster-node-timeout 5000 #单位毫秒。集群节点超时时间，即集群中主从节点断开连接时间阈值，超过该值则认为主节点不可以，从节点将有可能转为master
cluster-replica-validity-factor 10 #在进行故障转移的时候全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了导致数据过于陈旧，不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。
cluster-migration-barrier 1 #一个主机将保持连接的最小数量的从机，以便另一个从机迁移到不再被任何从机覆盖的主机
cluster-require-full-coverage yes #集群中的所有slot（16384个）全部覆盖，才能提供服务

#注：
所有节点配置文件全部修改切记需要修改的ip、端口、pid文件...避免冲突。确保所有机器都修改。
%s/7000/7001/g

5.启动三台机器上面的每个节点(三台机器相同操作)
[root@redis-cluster1 ~]# cd /data/redis/src/
[root@redis-cluster1 src]# ./redis-server ../cluster/7000/redis.conf 
[root@redis-cluster1 src]# ./redis-server ../cluster/7001/redis.conf

[root@redis-cluster2 7003]# cd /data/redis/src/
[root@redis-cluster2 src]# ./redis-server ../cluster/7002/redis.conf 
[root@redis-cluster2 src]# ./redis-server ../cluster/7003/redis.conf

[root@redis-cluster3 7005]# cd /data/redis/src/
[root@redis-cluster3 src]# ./redis-server ../cluster/7004/redis.conf 
[root@redis-cluster3 src]# ./redis-server ../cluster/7005/redis.conf

查看端口

6.创建集群：在其中一个节点操作就可以
redis节点搭建起来后，需要完成redis cluster集群搭建，搭建集群过程中，需要保证6个redis实例都是运行状态。
Redis是根据IP和Port的顺序，确定master和slave的，所以要排好序，再执行。

参数:
--cluster-replicas 1:表示为集群中的每个主节点创建一个从节点.书写流程:主节点ip+port 
对应一个从节点ip+port（正常是前面三个节点为主节点，后面的为从节点）

[root@redis-cluster1 src]# cd /data/redis/src/
[root@redis-cluster1 src]# ./redis-cli --cluster create --cluster-replicas 1 192.168.116.172:7000 192.168.116.172:7001 192.168.116.173:7002 192.168.116.173:7003 192.168.116.174:7004 192.168.116.174:7005

>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.116.173:7003 to 192.168.116.172:7000
Adding replica 192.168.116.174:7005 to 192.168.116.173:7002
Adding replica 192.168.116.172:7001 to 192.168.116.174:7004
M: de5b4b2f6a559362ed56d4de1e3994fd529917b5 192.168.116.172:7000
   slots:[0-5460] (5461 slots) master
S: 2e8c1caa63ac4a1b9a6eea4f0fd5eab4c6b73c21 192.168.116.172:7001
   replicates 60e3755761c9cbdacb183f59e3d6205da5335e86
M: e0370608cd33ddf5bb6de48b5627799e181de3b6 192.168.116.173:7002
   slots:[5461-10922] (5462 slots) master
S: 4035841f20f07674671e6bff5d4c6db99c00626b 192.168.116.173:7003
   replicates de5b4b2f6a559362ed56d4de1e3994fd529917b5
M: 60e3755761c9cbdacb183f59e3d6205da5335e86 192.168.116.174:7004
   slots:[10923-16383] (5461 slots) master
S: e200afc33b10bd6975160bfeda7277d02371981a 192.168.116.174:7005
   replicates e0370608cd33ddf5bb6de48b5627799e181de3b6
Can 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
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 192.168.116.172:7000)
M: de5b4b2f6a559362ed56d4de1e3994fd529917b5 192.168.116.172:7000
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: e0370608cd33ddf5bb6de48b5627799e181de3b6 192.168.116.173:7002
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 2e8c1caa63ac4a1b9a6eea4f0fd5eab4c6b73c21 192.168.116.172:7001
   slots: (0 slots) slave
   replicates 60e3755761c9cbdacb183f59e3d6205da5335e86
M: 60e3755761c9cbdacb183f59e3d6205da5335e86 192.168.116.174:7004
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: 4035841f20f07674671e6bff5d4c6db99c00626b 192.168.116.173:7003
   slots: (0 slots) slave
   replicates de5b4b2f6a559362ed56d4de1e3994fd529917b5
S: e200afc33b10bd6975160bfeda7277d02371981a 192.168.116.174:7005
   slots: (0 slots) slave
   replicates e0370608cd33ddf5bb6de48b5627799e181de3b6
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

7.查看集群状态可连接集群中的任一节点，此处连接了集群中的节点192.168.116.172:7000
#登录集群客户端，-c标识以集群方式登录
[root@redis-cluster1 src]# ./redis-cli -h 192.168.116.172 -c -p 7000
192.168.116.172:7000> ping
PONG
192.168.116.173:7002> cluster info  #查看集群信息
cluster_state:ok  #集群状态
cluster_slots_assigned:16384 #分配的槽
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6 #集群实例数
......

192.168.116.172:7000> cluster nodes  #查看集群实例

参数解释：
runid: 该行描述的节点的id。
ip:prot: 该行描述的节点的ip和port
flags: 分隔的标记位，可能的值有：
1.master: 该行描述的节点是master
2.slave: 该行描述的节点是slave
3.fail?:该行描述的节点可能不可用
4.fail:该行描述的节点不可用（故障）
master_runid: 该行描述的节点的master的id,如果本身是master则显示-
ping-sent: 最近一次发送ping的Unix时间戳，0表示未发送过
pong-recv：最近一次收到pong的Unix时间戳，0表示未收到过
config-epoch: 主从切换的次数
link-state: 连接状态，connnected 和 disconnected
hash slot: 该行描述的master中存储的key的hash的范围

三、集群操作

1、客户端登陆

测试链接redis，存取数据(链接集群中任意一台机器就可以。)
存：
[root@redis-cluster1 src]# ./redis-cli -h 192.168.116.172 -c -p 7000
192.168.116.172:7000> ping
PONG
192.168.116.172:7000> set name qianfeng
-> Redirected to slot [5798] located at 192.168.116.173:7002
OK
192.168.116.173:7002>

读
[root@redis-cluster3 src]# ./redis-cli -h 192.168.116.173 -c -p 7002
192.168.116.173:7002> ping 
PONG
192.168.116.173:7002> get name
"qianfeng"
192.168.116.173:7002> exists name  #查看某一个key是否存在
(integer) 1

四、主从切换

测试：
1.将节点cluster1的主节点7000端口的redis关掉
[root@redis-cluster1 src]# ps -ef |grep redis 
root      15991      1  0 01:04 ?        00:02:24 ./redis-server 192.168.116.172:7000 [cluster]
root      16016      1  0 01:04 ?        00:02:00 ./redis-server 192.168.116.172:7001 [cluster]
root      16930   1595  0 08:04 pts/0    00:00:00 grep --color=auto redis
[root@redis-cluster1 src]# kill -9 15991

查看集群信息：
192.168.116.173:7002> CLUSTER nodes

可以看到7000端口这个redis已经是fail失败的了。

2.将该节点的7000端口redis启动在查看
[root@redis-cluster1 log]# cd /data/redis/src/
[root@redis-cluster1 src]# ./redis-server ../cluster/7000/redis.conf

查看节点信息：
192.168.116.173:7002> CLUSTER nodes

可以看到已经主从切换了

redis面试问题整理

一、实现Redis，mysql的双写一致性

双写一致性是指在Redis和MySQL两个存储系统中进行数据写入时，保证两个系统中的数据保持一致。以下是几种常见的解决方案：

缓存+数据库读写模式：
- 读取数据时，先从缓存中读取，如果缓存中不存在，则从数据库读取数据，并将数据存入缓存，然后返回响应。
- 更新数据时，先更新数据库，然后再删除缓存。这样下次读取时会重新从数据库中获取最新数据并更新缓存。
设置缓存过期时间：
- 设置缓存的过期时间，在写入缓存时，只更新数据库，缓存会在一定时间后自动过期。
- 下次读取数据时，如果缓存已过期，则从数据库中读取最新数据并存入缓存。
使用消息队列：
- 在写入数据时，将写操作以消息的形式发送到消息队列中，然后由消费者去更新Redis和MySQL。
- 消费者首先更新MySQL，然后再更新Redis，保证两个存储系统的数据一致性。
使用数据库的Binlog：
- 数据库的Binlog记录了所有的写操作，可以通过读取Binlog来更新Redis。
- 将写操作转发到Binlog解析器，解析器会将写操作同步到Redis，从而保证两者的数据一致性。

二、缓存雪崩

数据未加载到缓存中，或者缓存同一时间大面积的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。
产生雪崩的过程

redis集群大面积故障
缓存失效，但依然大量请求访问缓存服务redis
redis大量失效后，大量请求转向到mysql数据库，mysql的调用量暴增，很快就扛不住了，甚至直接宕机
由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各服务器集群的雪崩，最后网站彻底崩溃。

解决
1. 缓存的高可用性
缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

2. 缓存降级
可以利用ehcache等本地缓存(暂时支持)，主要还是对源服务访问进行限流、资源隔离（熔断）、降级等。
当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。
降级的最终目的是保证核心服务可用，即使是有损的。
在进行降级之前要对系统进行梳理，比如：哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体。

3. Redis备份和快速预热
1)Redis数据备份和恢复
2)快速缓存预热

4. 提前演练
最后，建议还是在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题。

三、缓存穿透

缓存穿透是指在缓存中找不到数据，导致请求直接访问数据库。缓存穿透一般发生在以下情况下：

请求的数据在数据库中不存在，导致缓存中也没有对应的数据。
请求的数据故意设置为不存在，以此来绕过缓存，直接访问数据库。

缓存穿透可能会导致以下问题：

较高的数据库负载：由于缓存未命中，所有请求都会直接访问数据库，导致数据库负载增加。
较慢的响应时间：直接访问数据库的请求响应时间较长，可能导致相应的用户体验较差。
数据库压力过大：频繁的缓存穿透可能会导致数据库压力过大，甚至导致数据库宕机。

为了解决缓存穿透问题，可以采取以下措施：

布隆过滤器（Bloom Filter）：使用布隆过滤器判断请求的数据是否存在，如果不存在，则不需要进一步查询数据库，直接返回数据不存在的结果。
空值缓存（Null Cache）：在缓存中缓存空值，当请求的数据为不存在时，从缓存中直接返回空值，避免直接访问数据库。
数据预加载（Cache Pre-loading）：在系统启动时，预先加载热门数据到缓存中，避免在用户请求时才去查询数据库。
限制频繁请求：对于频繁请求的数据，可以设置短暂有效期的缓存，避免多次请求直接访问数据库。

四、缓存并发

缓存并发是指多个并发请求同时访问缓存系统。缓存并发可能会导致以下问题：

缓存竞争：当多个并发请求同时读取或写入缓存时，可能会导致缓存的数据不一致。例如，如果多个并发请求同时读取缓存中的数据，当缓存中的数据已经过期或被其他请求修改时，可能会导致读取到的数据不准确。
缓存雪崩：当缓存中的大量数据同时过期时，会导致大量的并发请求直接访问数据库，导致数据库负载过大，甚至导致数据库宕机。

为了解决缓存并发问题，可以采取以下措施：

互斥锁（Mutex Lock）：在并发读取或写入缓存时使用互斥锁，确保同一时刻只有一个线程可以访问或修改缓存。这可以防止缓存竞争和数据不一致。
缓存分片（Cache Sharding）：将缓存数据分散到多个缓存节点上，让不同的数据分散到不同的缓存节点上，从而减少并发请求对同一个缓存节点的竞争。
缓存预热（Cache Warm-up）：在系统启动时，预先加载热门数据到缓存中，避免在并发请求到来时才去访问数据库，以减少数据库负载。
使用分布式缓存（Distributed Cache）：将缓存数据存储到分布式缓存系统中，通过多个缓存节点分担并发请求的负载，提高系统的并发能力。

五、缓存预热

缓存预热是指在系统启动或者重启之后，提前将一些热门数据加载到缓存中，以避免在实际请求到来时才去访问数据库或其他数据源，从而减少请求的响应时间。

缓存预热的目的是通过预先加载热门数据到缓存中，提高系统的响应速度和性能，避免在系统启动初期或者重启后出现大量的缓存穿透或缓存击穿现象，并且提供稳定的性能。

缓存预热的实现可以通过以下方式：

定时任务：在系统启动时，通过定时任务将一些热门数据加载到缓存中。定时任务可以每隔一段时间执行一次，或者按照一定的时间间隔来执行。
懒加载：在系统启动后，根据业务需求，当有请求到来时，如果发现缓存中没有对应的数据，那么先从数据源（如数据库）加载数据到缓存中，然后再返回数据给请求方。
批量加载：在系统启动时，通过批量加载的方式一次性将多个热门数据加载到缓存中。这种方式可以减少单次加载的次数，提高效率。

其他面试
1.Redis官方为什么不提供Windows版本？
因为目前Linux版本已经相当稳定，而且用户量很大，无需开发windows版本，反而会带来兼容性等问题。
2.一个字符串类型的值能存储最大容量是多少？512M
3.Redis集群方案什么情况下会导致整个集群不可用？
有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。
4.说说Redis哈希槽的概念？
Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。
5.Redis集群之间是如何复制的？
异步复制
6.Redis集群最大节点个数是多少？
16384个。
7.Redis集群如何选择数据库？
Redis集群目前无法做数据库选择，默认在0数据库。
8.怎么测试Redis的连通性？
ping
9.如何与Redis互动？
安装服务器后，您可以运行redis安装提供的Redis客户端，也可以打开命令提示符并使用以下命令：
redis-cli
10.使用Redis有什么好处？
Redis非常快。
它支持服务器端锁定。
它有一个丰富的客户端库。
这是一个很好的反击。
它支持原子操作。
11.使用Redis有哪些缺点/限制？
它是单线程的。
它对一致哈希的客户端支持有限。
它具有很大的持久性开销。
它没有广泛部署。
12.Redis和RDBMS有什么区别？
Redis是NoSQL数据库，而RDBMS是SQL数据库。
Redis遵循键值结构，而RDBMS遵循表结构。
Redis非常快，而RDBMS相对较慢。
Redis将所有数据集存储在主存储器中，而RDBMS将其数据集存储在辅助存储器中。
Redis通常用于存储小型和常用文件，而RDBMS用于存储大文件。
Redis仅为Linux，BSD，Mac OS X，Solaris提供官方支持。它目前没有为Windows提供官方支持，而RDBMS提供对两者的支持
13.什么是redis的事务？
a）事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
b）事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
14.Redis单点吞吐量
单点TPS达到8万/秒，QPS达到10万/秒，补充下TPS和QPS的概念
1.QPS: 应用系统每秒钟最大能接受的用户访问量
每秒钟处理完请求的次数，注意这里是处理完，具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
2.TPS：每秒钟最大能处理的请求数
每秒钟处理完的事务次数，一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较合理。

问题2:Redis的多数据库机制，了解多少？
正常：Redis支持多个数据库，并且每个数据库的数据是隔离的不能共享，单机下的redis可以支持16个数据库（db0 ~ db15）
集群: 在Redis Cluster集群架构下只有一个数据库空间，即db0。因此，我们没有使用Redis的多数据库功能！

问题3:Redis集群机制中，你觉得有什么不足的地方吗？
假设我有一个key，对应的value是Hash类型的。如果Hash对象非常大，是不支持映射到不同节点的！只能映射到集群中的一个节点上！还有就是做批量操作比较麻烦！

问题4:懂Redis的批量操作么？
正常: 比如mset、mget操作等
集群: 我们在生产上采用的是Redis Cluster集群架构，不同的key会划分到不同的slot中，因此直接使用mset或者mget等操作是行不通的。

问题6:你们有对Redis做读写分离么？
正常:没有做
集群:不做读写分离。我们用的是Redis Cluster的架构，是属于分片集群的架构。而redis本身在内存上操作，不会涉及IO吞吐，即使读写分离也不会提升太多性能，Redis在生产上的主要问题是考虑容量，单机最多10-20G，key太多降低redis性能.因此采用分片集群结构，已经能保证了我们的性能。其次，用上了读写分离后，还要考虑主从一致性，主从延迟等问题，徒增业务复杂度。