业务发展过程中遇到的峰值瓶颈
- redis提供的服务OPS可以达到10万/秒，当前业务OPS已经达到10万/秒
- 内存单机容量达到256G，当前业务需求内存容量1T
- 使用集群的方式可以快速解决上述问题
集群就是使用网络将若干台计算机联通起来，并提供统一的管理方式，使其对外呈现单机的服务效果
作用：
- 分散单台服务器的访问压力，实现负载均衡
- 分散单台服务器的存储压力，实现可扩展性
- 降低单台服务器宕机带来的业务灾难
Redis集群结构设计
单机：
集群如何设置？
Redis提供一个函数将key转换成一个值（类似于hash值），在通过%16384得到一个数（对Redis进行16384的等分，每一份代表一个存储空间，每台计算机保存若干台空间），假设为37，这个37用来确定该数据在集群中存在的位置
如果一台计算机宕机，或者新加入一台计算机之后该怎么办？
假设，目前有三个台机器，现在又加了一台机器
其会优化，将每个Redis机器的数据都拿出一部分给到新的Redis中的存储空间
之前所计算出的37，称之为---槽
集群内部通讯设计
假设目前有三台机器互联，每台计算机中都有与之相连的各个计算机中存储空间的槽是几到几
假设现在来发过来一条指令key，这个key通过两次算法计算出对应的存储槽的位置，会根据槽位置在该指令所访问的机器中寻找槽的位置是在哪太机器，然后让指令直接去B机器（找到槽的机器）中找，可以保证最多两次访问就可以找到槽的位置
Cluster集群搭建
配置三主三从的结构
添加配置，当Redis称为集群中的一个节点
开启cluster
配置cluster配置文件名
设置下线时间
配置6379~6385端口号的机器
启动6379服务器：
启动6380服务器：
依次启动6379~6384
检查是否成功，是否以结点方式出现
使用redis-trib.rb指令创建集群
--replicas：指定集群的内部结构
1：一个master连接一个slave
2：一个master连接两个slave
127.0.0.1:6379：master的地址，按照数量识别，写6个地址那么前三个就是maste后三个就是slave
在继续执行之前（输入yes之前）已经生了一些配置文件
目前只包含自己节结点的信息，因为此时还没有输入yes，即所有机器还没有真正的连接成集群
输入yes：
此时再去查看配置文件：
发现此时的配置文件记录的信息理论上都是相同的，此时cluster集群已经搭建完成
此时集群已经全部搭建完成
数据测试：
在6379机器上测试，发现数据报错，让其移动到5798这个槽中去操作数据，即对name进行转换之后所对应的的槽是5798，如果想要就该name只能去换到6381机器上
通过 -c 参数可以解决这个问题：
在6382机器中去查询name值：
主从下线与主从切换
- salve出现问题：宕机
salve宕机之前，先看一下master日志的信息，最后是synchronize
slave最后的日志是：background
将6382的slave停机：
查看8379的master：因为设置的是10秒才认为slave下线，所以在10秒内的日志：
6380的机器日志：收到了一个关于6379和6382机器的消息
现在将宕机的slave连接上来，并再次查看6379主机
即slave下线之后，对应的master为其标记为下线状态，当slave再次上线之后再恢复数据的同步
现在将6379的master停机，并查看对应的6382从节点
即1s重试一次
如果10次只有还是没有重连成功：
在客户端中查询结点信息：
只是标记为失败，因为有可能恢复
此时将6379的master恢复
查看6382的日志：
总结：
