redis及redis集群

一. Redis 的原理与特点

Redis (REmote DIctionary Server) 是一个开源的键值存储系统，它支持多种数据结构如字符串（strings）、散列（hashes）、列表（lists）、集合（sets）和有序集合（sorted sets），并提供了原子操作。Redis 运行在内存中，因此它的读写速度非常快。

二. Redis 的重要角色及作用

• 缓存: Redis 可以作为应用程序的缓存层，减轻后端数据库的压力。
• 消息队列: Redis 支持发布/订阅模式，可以实现简单的消息队列。
• 计数器: 使用 Redis 的原子操作特性来实现高性能的计数器，比如统计网站访问量等。
• 会话存储: 存储用户的会话信息，可以提高会话处理的性能。
• 实时数据分析: Redis 提供的数据结构非常适合实时分析场景，例如统计在线用户数量。

三. 基本使用

1.docker安装与启动:

docker run --restart=always -p 6379:6379 --name myredis -d redis:6.2.1  --requirepass test123

备注：在宿主机没有镜像的情况，会自动在 Docker hub 的公开仓库中进行寻找和下载。

2.基本命令:

• SET key value: 设置键值对。
• GET key: 获取键对应的值。
• DEL key: 删除键。
• LPUSH key value: 将一个值插入到列表头部。
• LRANGE key start stop: 获取列表指定范围内的元素。
• SADD key member: 向集合添加成员。
• SMEMBERS key: 获取集合中的所有成员。

四. redis集群

1.什么场景下使用redis集群

当单一redis实例在性能、容量、可用性或扩展性上无法满足应用需求时需要使用redis集群。

2.redis集群之间是什么关系

redis集群中会有多个主节点，每个主节点有0个或多个从节点，数据分别存储在多个主节点。主节点和从节点之间的关系是一种主从复制关系，其中从节点是主节点的一个数据副本。从节点持续地与主节点同步数据，保持与主节点数据的一致性。一旦主节点发生故障，集群可以自动将一个从节点晋升为主节点，接替原主节点的工作，确保服务的高可用性。

如果集群由3个主节点构成，并且每个主节点配置了1个从节点，那么总共需要启动6个Redis进程：3个主节点进程和3个从节点进程。每个从节点分别与一个特定的主节点配对，维护该主节点所负责数据的副本。这样的配置既增加了数据的安全性，也提升了整个集群处理故障的能力。

3.redis集群如何搭建

• 3.1创建用户自定义网络

docker network create redis-net

• 3.2启动 Redis 容器

docker run -d --name redis-node-1 --privileged=true --network redis-net -v /data/redis/share/redis-node-1:/data redis:6.2.1 --cluster-enabled yes --appendonly yes --port 6381

docker run -d --name redis-node-2 --privileged=true --network redis-net -v /data/redis/share/redis-node-2:/data redis:6.2.1 --cluster-enabled yes --appendonly yes --port 6382

docker run -d --name redis-node-3 --privileged=true --network redis-net -v /data/redis/share/redis-node-3:/data redis:6.2.1 --cluster-enabled yes --appendonly yes --port 6383

docker run -d --name redis-node-4 --privileged=true --network redis-net -v /data/redis/share/redis-node-4:/data redis:6.2.1 --cluster-enabled yes --appendonly yes --port 6384

docker run -d --name redis-node-5 --privileged=true --network redis-net -v /data/redis/share/redis-node-5:/data redis:6.2.1 --cluster-enabled yes --appendonly yes --port 6385

docker run -d --name redis-node-6 --privileged=true --network redis-net -v /data/redis/share/redis-node-6:/data redis:6.2.1 --cluster-enabled yes --appendonly yes --port 6386

• 3.3查看redis容器的ip地址

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' redis-node-1

• 3.4创建集群

redis-cli --cluster create 172.18.0.2:6381 172.18.0.3:6382 172.18.0.4:6383 172.18.0.5:6384 172.18.0.6:6385 172.18.0.7:6386 --cluster-replicas 1

• 3.5可以通过以下指令进入到redis客户端，查看集群情况——

redis-cli -c -h 172.18.0.2 -p 6381
cluster info
cluster nodes

4.redis集群的数据存取
在 Redis 集群中，数据的存储位置是由键（key）的哈希值决定的，而不是由客户端连接的节点决定的。这意味着即使你通过某个节点（例如节点 1）进行数据操作，数据实际上可能会被存储在集群中的其他节点上。这种机制称为哈希槽（hash slot）分配。

Redis 集群的数据分布
哈希槽（Hash Slot）:
Redis 集群将整个键空间划分为 16384 个哈希槽。
每个键根据其哈希值映射到其中一个哈希槽。
集群中的每个主节点负责一部分哈希槽，这样就实现了键的分布。
键的哈希计算:
当客户端发送一个 SET 命令时，Redis 会计算键的哈希值。
根据哈希值，Redis 确定键属于哪个哈希槽。
然后 Redis 将请求转发到负责该哈希槽的节点上。
节点间的通信:
如果客户端连接的节点不是负责该哈希槽的节点，那么这个节点会将请求转发给正确的节点。
这种机制确保了数据始终被存储在正确的节点上。

5.cluster-require-full-coverage配置
cluster-require-full-coverage 是 Redis 集群中的一个配置选项，它控制着集群的行为，特别是在集群的哈希槽（hash slots）分配方面。当此选项被设置为 yes 时，Redis 集群会确保所有 16384 个哈希槽都被正确分配给集群中的主节点。如果集群中的哈希槽分配不完整，Redis 集群将拒绝执行写操作，直到所有哈希槽都被正确分配。

cluster-require-full-coverage 的意义
保证数据一致性:
当集群中的某个节点故障或被移除时，可能会导致部分哈希槽未被分配给任何节点。
如果设置 cluster-require-full-coverage 为 yes，Redis 集群会确保所有哈希槽都被正确分配，以防止数据丢失或不一致的情况发生。
避免数据丢失:
如果集群中的哈希槽分配不完整，新写入的数据可能会找不到合适的节点来存储。
通过设置 cluster-require-full-coverage 为 yes，可以避免这种情况发生，确保数据始终能够被正确存储。
提高集群稳定性:
当集群中的哈希槽分配不完整时，可能会导致客户端请求失败或返回错误的结果。
设置 cluster-require-full-coverage 为 yes 可以提高集群的整体稳定性和可靠性。
使用场景
生产环境:
在生产环境中，为了确保数据的一致性和完整性，通常建议将 cluster-require-full-coverage 设置为 yes。
这样可以确保集群在任何情况下都能提供可靠的服务。
测试和开发环境:
在测试和开发环境中，可能需要频繁地添加或移除节点。
在这些环境中，可以暂时将 cluster-require-full-coverage 设置为 no，以允许集群在哈希槽分配不完整的情况下继续运行。
配置方法
你可以在 Redis 的配置文件 redis.conf 中设置 cluster-require-full-coverage 的值。例如：
cluster-require-full-coverage yes
或者，如果你需要动态更改此设置，也可以通过 Redis 的命令行工具 redis-cli 更改配置：
redis-cli config set cluster-require-full-coverage yes
6.哈希槽
哈希槽的基本概念
哈希槽总数:
Redis 集群将整个键空间划分为 16384 个哈希槽。
每个哈希槽都有一个唯一的编号，范围是从 0 到 16383。
键的哈希值:
每个键（key）都会被计算出一个哈希值。
哈希值用于确定键应该被分配到哪个哈希槽。
哈希槽的分配:
集群中的每个主节点负责一部分哈希槽。
当键的哈希值映射到某个哈希槽时，这个键就会被分配到负责该哈希槽的主节点上。
实际例子
假设我们有一个包含三个主节点的 Redis 集群，分别是 Node 1、Node 2 和 Node 3。每个主节点负责一定范围的哈希槽。

哈希槽分配:
Node 1 负责哈希槽 0-5460。
Node 2 负责哈希槽 5461-10922。
Node 3 负责哈希槽 10923-16383。
键的哈希值计算:
当客户端发送一个命令，例如 SET mykey value，Redis 会计算 mykey 的哈希值。
假设 mykey 的哈希值为 7000。
哈希槽查找:
根据哈希值 7000，我们可以确定它属于 Node 2 负责的哈希槽范围（0-5460）。
因此，mykey 将被存储在 Node 2 上。

7.重启redis集群后查看之前的数据
进入挂载到宿主机的文件/data/redis/share/redis-node-1当中，可以看到存在有持久化的文件：dump.rdb和appendonly.aof。

重启所有的redis集群节点的容器后查看之前存储的数据：