redis集群方案

2016Redis集群方案介绍目录TwemproxyCodisRedis3.0集群RedisClusterTwemproxy•Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。•Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群Twemproxy架构图Twemproxy特点•优点：–客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑；–支持无效Redis实例的自动删除；–Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数；–应用最广；•缺点：–由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。–没有友好的监控管理后台界面，不利于运维监控。–Twemproxy无法平滑地增加Redis实例。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。Codis•一个支持平滑增加Redis实例的Redis代理软件。其基于Go和C语言开发。•分为以下四部分：•CodisProxy：Redis客户端连接到Redis实例的代理，实现了Redis的协议，Redis客户端连接到CodisProxy进行各种操作。CodisProxy是无状态的，可以用Keepalived等负载均衡软件部署多个CodisProxy实现高可用。•CodisRedis：Codis项目维护的Redis分支，添加了slot和原子的数据迁移命令。Codis上层的CodisProxy和Codisconfig只有与这个版本的Redis通信才能正常运行。•Codisconfig：Codis管理工具。可以执行添加删除CodisRedis节点、添加删除CodisProxy、数据迁移等操作。另外，Codisconfig自带了HTTPserver，里面集成了一个管理界面，方便运维人员观察Codis集群的状态和进行相关的操作，极大提高了运维的方便性，弥补了Twemproxy的缺点。•Zookeeper：分布式的、开源的应用程序协调服务，是Hadoop和Hbase的重要组件，其为分布式应用提供一致性服务，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。Codis依赖于Zookeeper存储数据路由表的信息和CodisProxy节点的元信息。另外，Codisconfig发起的命令都会通过Zookeeper同步到CodisProxy的节点。Codis架构图Codis特点•Codis引入了RedisServerGroup，其通过指定一个主CodisRedis和一个或多个从CodisRedis，实现了Redis集群的高可用。•Codis中最多可以指定1024个RedisServerGroup。•Codis支持平滑增加（减少）RedisServerGroup（Redis实例），能安全、透明地迁移数据；Redis3.0集群RedisCluster•Redis3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384个slot，每个Redis实例负责其中一部分slot。集群中的所有信息（节点、端口、slot等），都通过节点之间定期的数据交换而更新。•Redis客户端在任意一个Redis实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例PPT模板：素材：背景：图表：下载：教程：资料下载：范文下载：试卷下载：教案下载：论坛：课件：语文课件：数学课件：英语课件：美术课件：科学课件：物理课件：化学课件：生物课件：地理课件：历史课件：架构图RedisClusters实现的功能•可线性扩展到上千个节点•可使数据自动路由到多个节点•实现了多个节点间的数据共享•可支持动态增加或删除节点•可保证某些节点无法提供服务时不影响整个集群的操作•不保证数据的强一致性RedisCluster的数据分布•HashSlotRedis集群没有使用一致性hash，而是引入了哈希槽（HashSlot）的概念。Redis集群一共有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定对应哪个槽。HASH_SLOT=CRC16(key)mod16384•所有的哈希槽必须配置在集群中的某一个节点上•Node每个主节点都负责处理16384个哈希槽的其中一部分，由于Redis集群的key被分割为16384个slot，所以集群的最大节点数量也是16384个。推荐的最大节点数量为1000个左右。•节点和哈希槽之间的对应关系在搭建集群时配置，集群使用中也支持动态迁移RedisCluster的节点交互•Redis集群中的节点不仅记录哈希槽到正确节点的映射，还能够自动发现其他节点、识别异常节点以及在有需要时在从节点中选举出新的主节点，并更新保存最新的集群状态。•Redis集群中的节点间相互建立一个TCP连接，使用二进制协议相互通讯各自的节点属性信息和掌握的集群状态信息。•节点属性信息每个节点在集群中都有一个独一无二的ID，该ID是一个十六进制表示的160位随机数，节点会将它的ID保存到配置文件，只要这个配置文件不被删除，节点就会一直沿用这个IDRedisCluster的节点交互•节点关联信息•节点所使用的IP地址和TCP端口号。•节点的标志，即节点ID。•节点负责处理的哈希槽。•节点最近一次使用集群连接发送PING数据包的时间。•节点最近一次在回复中接收到PONG数据包的时间。•集群将该节点标记为下线的时间。•该节点的从节点数量。•如果该节点是从节点的话，那么它会记录主节点的节点IDRedisCluster的节点交互•集群状态信息•集群状态信息是该集群中所有节点属性信息的汇总，每个节点都会保存一份集群信息在cluster_file配置文件中，可以通过向集群中的任意节点（主或从节点都可以）发送CLUSTERNODES命令来获得•节点识别方式•方式一：是节点使用MEETmessage介绍自己：这里MEETmessage命令是强制其他节点把自己当成是集群的一部分。只有系统管理员使用CLUSTERMEETipport命令，节点才会发送MEETmessage给指定节点•方式二：通过集群节点间的推荐机制RedisCluster的容错机制•Redis集群中的节点间相互建立集群连接后，节点间使用Gossip协议进行强制发送、信息传播、随机检测三种方式的交互；•节点1向节点2发送ping数据包，目标节点在给定时间未回复，节点1会将节点2标记为PFAIL(possiblefail),同时消息传播到其他节点；其他节点记下失效节点信息，作为失效报告；•当集群中大部分主节点认为节点2为失效，节点2会从PFAIL变成FAIL状态；RedisCluster的容错机制RedisCluster的容错机制•节点2成为FAIL状态，节点2的一个从节点会被升级为新的主节点，而其他从节点则会开始对这个新的主节点建立新的主从关系同步数据。整个从节点选举的过程可分为申请、授权、升级、同步四个阶段申请授权升级同步RedisCluster的容错机制•申请：从节点申请成为主节点需满足以下条件：–这个节点是已下线主节点的从节点–已下线主节点负责处理的哈希槽数量非空–主从节点之间的复制连接的断线时长有限•授权：主节点遵信以下三点标准来进行判断：–发送授权请求的是从节点，而且它所属的主节点处于FAIL状态–在已下线主节点的所有从节点中，这个从节点的ID在排序中最小–这个从节点处于正常的运行状态，没有被标记为FAIL或PFAIL状态RedisCluster的容错机制•升级：授权通过后，从节点会接管原主节点负责的哈希槽，并主动向其他节点发送PONG数据包，该数据包包含以下内容：–告知其他节点自己现在是主节点了–告知其他节点自己是一个ROMOTEDSLAVE，即已升级的从节点–告知其他节点都根据自己新的节点属性信息对配置进行相应的更新•同步：–其他节点在接收到ROMOTEDSLAVE的告知后，会根据新的主节点对配置进行相应的更新，而且所有被新的主节点接管的哈希槽会被更新–已下线主节点的其他从节点会察觉到PROMOTED标志开始对新主节点进行复制；–已下线的主节点若重新回到上线状态，那么它会察觉到PROMOTED标志，并将自身调整为现任主节点的从节点在集群的生命周期中，如果一个带有PROMOTED标识的主节点因为某些原因转变成了从节点，那么该节点将丢失它所带有的PROMOTED标识RedisCluster特点•优点：–一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计；–部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖•缺点：–很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群–对协议进行了较大的修改，对应的Redis客户端也需要升级。对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情