干货:一文轻松搞懂Redis集群原理核心内容_第1页
干货:一文轻松搞懂Redis集群原理核心内容_第2页
干货:一文轻松搞懂Redis集群原理核心内容_第3页
干货:一文轻松搞懂Redis集群原理核心内容_第4页
干货:一文轻松搞懂Redis集群原理核心内容_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、干货:一文轻松搞懂Redis集群原理核心内容这里总结一下redis集群的搭建以便日后所需同时也希望能对你有所 帮助。一、redis的安装Redis是c语言开发的。安装redis需要c语言的编译环境。如果没有gcc需要在线安装:yum install gcc-c+第一步: 获 取 源 码 包:wget :/download.redis.io/releases/redis-3.0.0.tar.gz第二步: 解压缩 redis: tar zxvf redis-3.0.0.tar.gz第三步:编译。进入redis源码目录(cd redis-3.0.0)。执行make第 四步:安装。make insta

2、ll PREFIX=/usr/local/redisPREFIX参数指定redis的安装目录。一般软件安装到/usr目录 下这样Redis就成功装在了我们的usr/local/redis目录下。第五步:设置后台启动:rootlocalhost redis-3.0.0# cp redis.conf /usr/local/redis/bin/(把/root/redis-3.0.0/redis.conf 复制到/usr/local/redis/bin 目录下)修改配置文件:把daemonize后面的参数改为yes测试启动:rootlocalhost bin#./redis-server redis.

3、conf查看 redis 进程:rootlocalhost bin#ps aux|grep redis二、集群原理一个系统建立集群主要需要解决两个问题:数据同步问题和集群容错问题。三、Naive方案一个简单粗暴的方案是部署多台一模一样的Redis服务,再用 负载均衡来分摊压力以及监控服务状态。这种方案的优势在于容错简 单,只要有一台存活,整个集群就仍然可用。但是它的问题在于保证 这些Redis服务的数据一致时,会导致大量数据同步操作,反而影响 性能和稳定性。四、Redis集群方案Redis集群方案基于分而治之的思想。Redis中数据都是以 Key-Value形式存储的,而不同Key的数据之间是

4、相互独立的。因此 可以将Key按照某种规则划分成多个分区,将不同分区的数据存放 在不同的节点上。这个方案类似数据结构中哈希表的结构。在Redis 集群的实现中,使用哈希算法(公式是CRC16(Key) mod 16383)将 Key映射到016383范围的整数。这样每个整数对应存储了若干个 Key-Value数据,这样一个整数对应的抽象存储称为一个槽(slot)。 每个Redis Cluster的节点准确讲是master节点负责一定范围的槽,所有节点组成的集群覆盖了 016383整个范围的槽。据说任何计算机问题都可以通过增加一个中间层来解决。槽的 概念也是这么一层。它介于数据和节点之间,简化了

5、扩容和收缩操作 的难度。数据和槽的映射关系由固定算法完成,不需要维护,节点只 需维护自身和槽的映射关系。五、Slave上面的方案只是解决了性能扩展的问题,集群的故障容错能力 并没有提升。提高容错能力的方法一般为使用某种备份/冗余手段。 负责一定数量的槽的节点被称为master节点。为了增加集群稳定性, 每个master节点可以配置若干个备份节点称为slave节点。Slave节点一般作为冷备份保存master节点的数据,在master节点宕机时 替换master节点。在一些数据访问压力比较大的情况下,slave节点 也可以提供读取数据的功能,不过slave节点的数据实时性会略差一 下。而写数据的

6、操作则只能通过master节点进行。六、请求重定向当Redis节点接收到对某个key的命令时,如果这个key对应 的槽不在自己的负责范围内,则返回MOVED重定向错误,通知客 户端到正确的节点去访问数据。如果频繁出现重定向错误,势必会影响访问的性能。由于从key 映射到槽的算法是固定公开的,客户端可以在内部维护槽到节点的映 射关系,访问数据时可以自己通过key计算出槽,然后找到正确的节 点,减少重定向错误。目前大部分开发语言的Redis客户端都会实现 这个策略。这个地址s:/redis.io/clients可以查看主流语言的Redis客 户端。七、节点通信尽管不同节点存储的数据相互独立,这些节

7、点仍然需要相互通 信以同步节点状态信息。Redis集群采用P2P的Gossip协议,节点之 间不断地通信交换信息,最终所有节点的状态都会达成一致。常用的 Gossip消息有下面几种:01、ping消息:每个节点不断地向其他节点发起ping消息,用 于检测节点是否在线和交换节点状态信息。02、pong消息:收到ping、meet消息时的响应消息。03、meet消息:新节点加入消息。04、fail消息:节点下线消息。05、forget消息:忘记节点消息,使一个节点下线。这个命令必 须在60秒内在所有节点执行,否则超过60秒后该节点重新参与消息 交换。实践中不建议直接使用forget命令来操作节点下

8、线。八、节点下线当某个节点出现问题时,需要一定的传播时间让多数master节 点认为该节点确实不可用,才能标记标记该节点真正下线。Redis集 群的节点下线包括两个环节:主观下线(pfail)和客观下线(fail)。01、主观下线:当节点A在cluster-node-timeout时间内和节点 B通信(ping-pong消息)一直失败,则节点A认为节点B不可用, 标记为主观下线,并将状态消息传播给其他节点。02、客观下线:当一个节点被集群内多数master节点标记为主 观下线后,则触发客观下线流程,标记该节点真正下线。九、故障恢复一个持有槽的master节点客观下线后,集群会从slave节点中

9、 选出一个提升为master节点来替换它。Redis集群使用选举-投票的算 法来挑选slave节点。一个slave节点必须获得包括故障的master节 点在内的多数master节点的投票后才能被提升为master节点。假设 集群规模为3主3从,则必须至少有2个主节点存活才能执行故障恢 复。如果部署时将2个主节点部署到同一台服务器上,则该服务器不 幸宕机后集群无法执行故障恢复。默认情况下,Redis集群如果有master节点不可用,即有一些 槽没有负责的节点,则整个集群不可用。也就是说当一个master节 点故障,到故障恢复的这段时间,整个集群都处于不可用的状态。这 对于一些业务来说是不可忍受的

10、。可以在配置中将 cluster-require-full-coverage配置为no,那么master节点故障时只会影 响访问它负责的相关槽的数据,不影响对其他节点的访问。十、搭建集群启动新节点修改Redis配置文件以启动集群模式:#开启集群模式cluster-enabled yes #节点超时时间,单位毫秒 cluster-node-timeout 15000 # 集群节点信息文件 cluster-config-file nodes-6379.conf然后启动新节点。发送meet消息将节点组成集群使用客户端发起命令cluster ip port,节点会发送meet消息将指 定IP和端口的新

11、节点加入集群。十一、分配槽上一步执行完后我们得到的是一个还没有负责任何槽的“空”集 群。为了使集群可用,我们需要将16384个槽都分配到master节点 数。在客户端执行cluster add addslots a.b命令,将ab范围的槽 都分配给当前客户端所连接的节点。将所有的槽都分配给master节 点后,执行cluster nodes命令,查看各个节点负责的槽,以及节点的 ID。接下来还需要分配slave节点。使用客户端连接待分配的slave 节点,执行cluster replicate nodeld命令,将该节点分配为nodeld指定 的master节点的备份。十二、使用命令直接创建集

12、群在Redis 5版本中redis-cli客户端新增了集群操作命令。如下所示,直接使用命令创建一个3主3从的集群:redis-cli -cluster create 127.0.0.1:7000127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003127.0.0.1:7004 127.0.0.1:7005 -cluster-replicas 1如果你用的是旧版本的Redis,可以使用官方提供的redis-trib.rb 脚本来创建集群:./redis-trib.rb create -replicas 1 127.0.0.1:7000 127.0.0.1:700

13、1 127.0.0.1:7002 127.0.0.1:7003十三、集群伸缩1、扩容127.0.0.1:7004 127.0.0.1:7005扩容操作与创建集群操作类似,不同的在于最后一步是将槽从已有的节点迁移到新节点。01、启动新节点:同创建集群。02、将新节点加入到集群:使用redis-cli -cluster add-node命令 将新节点加入集群(内部使用meet消息实现)。03、迁移槽和数据:添加新节点后,需要将一些槽和数据从旧 节点迁移到新节点。使用命令redis-cli -cluster reshard进行槽迁移操 作。2、收缩为了安全删除节点,Redis集群只能下线没有负责槽的

14、节点。因 此如果要下线有负责槽的master节点,则需要先将它负责的槽迁移 到其他节点。01、迁移槽:使用命令redis-cli -cluster reshard将待删除节点的 槽都迁移到其他节点。02、忘记节点:使用命令redis-cli -cluster del-node删除节点(内 部使用forget消息实现)。十四、集群配置工具如果你的redis-cli版本低于5,那么可以使用redis-trib.rb脚本 来完成上面的命令。点击这里查看redis-cli和redis-trib.rb操作集群的 命令。持久化Redis有RDB和AOF两种持久化策略。一个RDB持久化的坑RDB持久化神坑:即使设置了 save试图关闭RDB,然而RDB持久化仍然有可能 会触发。从节点全量复制(比如新增从节点时),主节点触发RDB持久 化产生RDB文件。然后发送RDB文件给从节点。最后该从节点和对 应的主节点都会有RDB文件。执行shutdown时,如果没有开启AOF,也会触发RDB持久化。不管save如何设置,只要RDB文件存在,redis启动

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论