redis集群练习1(redis cluster tutorial)

redis目录

• redis集群练习1(redis cluster tutorial)
• redis集群练习2
• redis集群练习3
• centos防止redis crash的配置

概要

这篇文章主要是想通过一个简单的方式去介绍redis集群，而不会涉及到比较复杂的分布式算法概念。本文的内容主要涉及如何搭建集群、测试、操作三个方面，相信这篇文章可以让大家明白redis集群是如何跟用户进行交互的。

但是作者也希望从用户的角度，以一种容易理解的方式，向大家介绍redis在高可用以及数据的一致性充当的角色。

需要注意的是，本文介绍的所有内容，都要求是redis 3.0或以上的版本

Redis Cluster 101

Redis Cluster 支持自动复制数据到多个Redis节点上，Redis Cluster也支持网络分区下一定程度的高可用，例如某些节点失败或者不能通信这些常见的失败环境。但Redis 集群会在半数以上的节点都失败的情况下终止服务。

那么，如果在实际环境里面，你可以通过Redis 集群做什么呢？

• 自动复制数据到多个节点
• 保证可用，即使部分节点失败

Redis集群TCP端口

每一个节点都会需要监听两个TCP端口，基本的TCP端口6379（command port）用来向客户端提供服务，而另外一个端口则通过基本端口加10000的方式来获得，例如如果基本端口设置为6379，则另外一个端口是16379（cluster bus port）。

第二个端口，即cluster bus port，是用来进行失败检测，配置更新以及失败授权的；通信采用的协议是基于二进制的，可以节省带宽，提高通信效率。客户端不应该与第二个端口进行连接，而必须通过第一个端口；不过要注意的是，在linux系统中，你需要保证你的端口没有被防火墙阻止，否则集群中的redis节点之间就不能进行通信了。

Redis集群的数据复制

Redis集群没有使用一致性Hash算法，而是使用
一种将键值对的key保存在Hash槽(hash slot)的算法。
集群中将会有16384个Hash槽，为了计算一个给定的key是如何放进Hash槽里面的，我们会计算这个key的 CRC16校验值，然后再通过16384取模确认，即location = CRC16(KEY) MOD 16384。

每个节点都必须要负责管理Hash槽中的一个子集，假如你的集群里面共有3个节点，那么：

• 节点A包括0到5500的Hash槽
• 节点B包括5501到11000的Hash槽
• 节点C包括11001到16383的Hash槽

这样设置将会使从集群中删除和添加节点更容易。例如，如果想添加新的节点D，需要的是将A,B,CHash槽的部分移动到D节点；同样的，如果想从集群中移除A节点，可以把A中的Hash槽移动到B和C，等到A节点的Hash槽都移动完毕，是空的时候，就可以完全把A节点从集群中移除。因为移动Hash槽的过程中不需要停止节点的操作，更新、删除节点或者更新节点Hash槽的持有量不需要任何的停止时间。
（这里没有提到Hash槽的实现，而只是提到了Hash槽的作用）

Redis集群支持多键操作，在同一个命令或者同一个事务或者同一个lua脚本中的多键操作需要所有的key都在同一个Hash槽中，用户可以通过使用hash tags来让当前所有的key都在同一个Hash槽中。
Hash tags的核心概念是一个Key中的字符串中包含字符{}，那么只有括号里面的字符串会进行Hash，例如键 "this{foo}key"或者键"another{foo}key"会被哈希到同一个hash槽里面，因为中括号里面括起来的字符串才能被哈希，而不是整一个Key包含的字符串。这样，两个不同Key的值，实际上可以通过相同的Key来访问了。

Redis 集群主从模式(Redis Cluster master-slave model)

Redis 集群无法保证强一致性。在实际环境里面，Redis集群有可能会丢失已经写入的数据，首个原因是因为Redis集群是异步复制数据的。也就是说会存在下面的场景：

• 你向主节点B写入数据
• 主节点B向客户端响应OK
• B1，B2，B3从节点从B主节点异步复制数据

在上面的条件下，B不会等待B1，B2，B3复制完就直接向客户端响应，这是一个潜在的非常大的不利因素，因为如果你的客户单在写入某些数据，B响应了，但是在从节点复制完数据之前挂了，从节点被选举为主节点后，这部分没复制完的数据将会永久丢失。

当然，Redis 也可以提供更强的一致性，但是这样就会让集群性能变得很低。一般的，需要在强一致性与性能之间做一个平衡。

Redis集群支持同步写入，通过WAIT命令实现，可以极大的减少数据写入丢失的情况。不过，Redis集群没有实现强一致性，即使使用了同步复制。因为还有更复杂的场景导致数据不一致的情况，例如一个不允许写入数据的从节点被选举为主节点。

假设有6个节点，由A,B,C,A1,B1,C1组成，A,B,C是主节点，另外三个是从节点，另外有一个客户端叫Z1。6个节点原来是出于同一个网络，后面因为网络问题，A,C,A1,B1,C1构成一个网络，B不能再跟其他5个节点进行通信，但是Z1客户端还是能够跟这6个节点通信，即集群发生了网络分区。如果网络分区发生时间较短，集群可以恢复，但是如果发生时间足够长，直到B1被选举成新的主节点，而Z1始终还是向B节点写入数据，那么Z1写入的数据就会丢失。

也就是说，对于Z1写入到B节点的数据会有一个最大的发送窗口：如果有足够的时间让主网络分区从新选举一个新的主节点，每一个在另外一个较少节点的网络分区的主节点会停止写入数据。

这个足够的时间对于配置Redis集群非常重要，可以叫它为节点超时（node timeout），当一个节点超时发生，一个主节点就会被判断为失败了，并且会被他的复制节点所代替。如果超时发生依然没有主节点能够感知其他的住节点，那么集群就会进入错误状态并且停止接收写请求
https://redis.io/topics/cluster-tutorial