标签：集群 blank 高可用性 文件 模型 cluster 服务端 中间 部分
一、集群
互联网每天都会产生大量的数据，单实例已经不能满足需求。但是如果依赖于硬件成本的提升，那就不是所有人能够负担的起的。
集群这个时候出现，一定程度上解决了这个问题。它通过互联网，将多个单实例连接在一起，对外隐藏实现细节，这样在用户看来跟单实例是一样的。你不需要去购买昂贵的服务器，甚至于只需要通过多台廉价的服务器就可以满足需要。
二、redis集群
1、简介
在redis3.0之前是它的无集群时代，大家只能够通过一些中间件来完成集群。而3.0开始，redis内部集群的实现开始逐渐替代很多中间件。redis集群主要有以下两个特点：
1）数据会自动地被分布到集群节点上；
2）它以主从模式提高集群的高可用性。
2、TCP端口
每一个集群节点都有两个TCP端口需要开启：
1）用于服务客户端的端口（通常是6379）
2）用于集群节点的通信端口（服务端口加上10000，如：16379）
你需要确保防火墙没有关闭这两个端口，否则集群将无法通信从而失效。
3、数据分片
redis并没有采用一致性哈希算法，而是使用哈希槽（slot）来包含数据，一个哈希槽可以存放很多数据。
在redis集群里，总共有16384个哈希槽，每一个key都会根据CRC16算法获得一个值，然后把这个值对16384求余，那么也就是说，每一个key都会落在[0,16384]这个区间当中。而这16384个哈希槽将被分配到集群的节点当中，根据计算出的值寻找落在哪个节点，并找到该节点的对应哈希槽，进行操作。
4、主从模型
redis集群的主节点如果挂掉，那么集群就失效了。为了让集群高可用，redis实现了主从模式。
例如：
主节点是A、B、C那么我们将设立从节点A1、B1、C1。主节点A挂掉，那么从节点A1将会被提升为主节点，以保证集群可用。当然，如果从节点也挂掉，或者一半的主节点挂掉了，那么集群也就直接失效。
5、一致性
redis集群并不是强一致性，例如：
1）客户端向主节点A写入数据
2）主节点A写入完成并返回OK
3）主节点A再向从节点A1，A2...写入数据。
我们看到，主节点A写入数据就立马返回了，而不是同步对A1，A2...写入数据以后再返回。那么如果主节点A写入完毕，这时主节点A挂掉呢？从节点A1或者A2会被提升为主节点，而从节点还未写入数据，也就产生了数据不一致的问题。当然，还有很多其它情况会产生数据不一致，这里只是简单举个例子。
6、集群参数配置
在开始构建集群之前，我们先了解一些redis.conf的参数配置：
1）cluster-enabled<yes/no>: 这个配置表示当前的redis实例是否开启集群支持，如果是那么配置yes如果你希望它保持单实例那么配置no;
2) cluster-config-file<filename>: 注意：你看到这里filename是可配置的，但事实上这里配置的这个文件是用户永远无法接触到的，也就是说你无法去编辑这个文件。而是当程序启动的时候，由redis集群节点自动持久化生成并维护的。这个文件里面包含了一些其它节点的信息，状态，变量等。
3）cluster-node-timeout<milliseconds>: 这里配置的是集群节点的超时时间，意思就是当该节点被判断为不可达（无法通信）的时间超过这个最大时间限制，那么将会被判定为该节点失效。
4）cluster-slave-validity-factor<factor>: 这里配置从节点的有效因子，如果设置为0，那么从节点将会不断尝试替换主节点。如果值为正数，那么不可达的超时时间将乘以这个有效因子来计算主节点什么时候判定为失效并替换主节点。如果当前节点是从节点，那么会反过来，也就是说超过该计算结果的话，当前节点将不会尝试替换主节点。
5）cluster-migration-barrier<count>: 这里配置最小的从节点数量，如果该主节点没有任何从节点，那么会从其它主节点那移一个过来作为当前主节点的从节点。
6）cluster-require-full-coverage<yes/no>: 配置集群的可用情况，例如：当一个key所在的节点挂掉，并且没有从节点可用的情况下，那么意味着该集群不完整，如果配置为yes集群将不可用。如果配置为no，那么意味着即使集群有部分不完整，也需要处理可用的那些key。redis默认设置为yes，也就是集群需要完整可用。
详细内容参考官网：https://redis.io/topics/cluster-tutorial
标签：集群 blank 高可用性 文件 模型 cluster 服务端 中间 部分
原文地址：https://www.cnblogs.com/lay2017/p/9275122.html
