在服务开发中，由于存在单点故障的问题，以及服务导入到1台服务器上，服务器宕机时服务就无法使用，因此为了使服务具有高可用性，出现了分布式服务，将同一服务导入到多台机器上，其中的几台服务器
群集优势可扩展性：服务器群集具有高度可扩展性。 随着需求和负载的增加，可以向集群系统中添加服务器。 在这种配置中，多个服务可以执行相同的APP应用程序和数据库操作。
高可用性：高可用性是指不需要操作员干预就能防止系统故障或自动从故障中恢复的能力。 通过将故障服务器上的APP应用程序移动到备份服务器上并运行，群集系统可以将正常运行时间提高到99.9%以上，从而大大减少服务器和APP应用程序的停机时间。
可管理性更高：系统管理员可以像独立系统一样远程管理一个或多个群集。
因此，为了以大流量访问提供稳定的业务，集群化是存储器的必然形态
Redis-Cluster redis cluster是公式的redis簇的实现
redis-cluster采用去中心化的思想，采用hash slot方法将16348个hash slot复盖到所有节点，每个保存的key值使用CRC16(key )，16348=slot是他对应的hash slot 在访问key时查找自己的hash slot位于哪个节点，在当前访问节点实际从分配了hash slot的节点获取数据节点的过程中，使用轻量级协议通信降低带宽占用率的性能较高，加载
cluster (集群) cluster满足了sentinel的一些特性，实现了高可用性。 不同的是，通过使用hash算法基于key自动将数据分配给不同的节点，添加节点非常方便。 如果数据量太大，可以添加更多的机器来扩展容量，从而解决了独立容量的限制。
集群特性1、多个redis节点的直接数据共享
2、所有节点均为一主一从或一主多从
3、不支持同时处理多个key，如MSET/MGET。 由于群集必须将key分配给节点，因此在并发量较大的同时创建key-value可能会导致性能下降和不可预测的行为
4、支持在线添加、删除节点
5、不支持多数据库选择
构建集群和部署集群至少需要六个节点。 个人学习测试只需以本机方式创建和使用，而生产部署在多台计算机上即可实现高可用性
创建节点
配置vim …/redis.conf以修改配置。 由于此文件的内容很多，因此也可以在finalshell中使用编辑器进行修改
请更改选项
放在port 6379 #节点目录中，将节点端口cluster-enabled yes #群集cluster-node-timeout 5000 #超时时间protected-mode no #更改为启用此时，外部网络可以直接访问daemonize yes #后台启动bind
修改完成后保存Ctrl s
可以在grep内容.…/redis.conf中确认修改是否成功
保存后，将其一个接一个地复制到节点目录中，并修改该节点的端口保存
在每个节点目录中启动
查看服务和防火墙的状态
创建集群
./redis-CLI---cluster create 172.31.0.22433606370 . 172.31.0.22433606375-- cluster-replica S1
查看群集信息
./redis-CLI-- cluster check 172.31.0.22433606375
3主站3从站
尝试用redis桌面管理器连接
使用问题：使用6379保存值时发现错误。 (error )群集关闭主机插槽不可用)
原因：使用集群创建命令时显示
Can I set the above configuration？ (type‘yes’to accept ) :
必须输入yes，而不是省略y。 因为习惯了做linux的人，所以输入y，但在这里不行。 必须全部输入yes。 由于这个错误导致分配槽失败。
redis-CLI-- -检测群集检查127.0.0.133606379
检测结果
[ err ] notall 16384 slotsarecoveredbynodes
redis-CLI--修复cluster fix 127.0.0.133606379
修复结束后添加key-value吧
没有问题。 在节点中添加key-value吧
发现错误报告(error ) MOVED 9439 172.31.0.224:6371
原因是没有在集群模式下连接。 正在执行不带-c参数的节点连接命令
./redis-CLI-c-h 172.31.0.22433606371
浏览redis桌面管理器
连接6372个节点，还存在密钥值
模拟节点停机时间，以验证节点的主从关系
6370.6371.6372是Mater，6373、6374、6375是slave，对这些单词很不愉快。 主人，奴隶
我们是处决6372个主的基尔
再看节点的主从身份
发现6370、6371还是主人，6374、6375是奴隶
6372不见了，6373成为了主人，
瘫痪节点的数据不会丢失吗？
Redis Cluster无法保证强一致性，在某些特殊场景中，客户端即使收到写入确认也可能会丢失数据。
Redis Cluster无法保证较强的一致性，存在数据丢失的场景：
异步复制
主机写入成功，但在slave同步完成之前，主机关闭，slave成为主机，数据丢失。
具体了解