高性能网站架构之缓存篇—Redis集群增删节点

标签: 性能 网站架构 缓存 | 发表时间:2016-12-17 11:08 | 作者:jaesonchen
分享到:
出处:http://www.iteye.com

Redis集群添加节点

       首先我们要新建立一个节点,将redis01 复制一份改为redis07,然后修改端口号也改为7007 ,然后我们执行[root@localhost redis07]# ./redis-server redis.conf 启动以后,然后进行查看,发现有一个端口号为7007的redis实例已经启动了!我们怎么把这个redis 实例添加到集群中呢。

       在将7007 端口号的redis实例添加到集群之前,一定要确保这个redis实例没有存储过数据,也不能持久化的数据文件,否则在添加的时候会报错的!我们执行命令  ./redis-trib add-node127.0.0.1:7007 to cluster 127.0.0.1:7001 就可以将端口号为7007的实例添加到redis-cluster中。如下如所示。

        

       我们执行在任意一个客户端下执行 cluster nodes 命令,可以看到7007 已经作为主节点添加到我们的集群中了,但是可以看到他没有分配哈希槽,没有分配哈希槽的话表示就没有存储数据的能力,所以我们需要将其他节点上的哈希槽分配到这个节点上。

   

       下边我们看一下如何分配哈希槽。我们随便进入一个客户端,然后我们执行 ./redis-trib.rb reshard 192.168.20.140:7001, 就可以看到如下图所示提示,问我们需要移动多少个哈希槽,我们在这里移动1000个。

        

        完以后,又会问我们需要覆盖的节点id是什么,这个id就是我们新创建的节点id。然后让我们输入源节点,如果这里我们输入all的话,他会随机的从所有的节点中抽取1000个作为新节点的哈希槽。

       

        我们输入all以后,会出下下图所示东西,表示hash槽正在移动。

        

        移动完以后,我们进入客户端,执行cluster nodes 命令,查看集群节点的状态,我们会看到原来没有哈希槽的7007节点,分配到了1000个哈希槽,而且是不连续的。说明是从原来的三个节点中抽取的。

        

        这样我们一个新的节点就添加好了, 但是我们发现总共是7个节点,其中的六个互为住备,但有一个是有主,没有备,所以我们需要在为该节点添加一个备份节点。我们在创建一个实例,端口号为7008,启动以后我们只命令./redis-trib.rb add-node --slave127.0.0.1:7008  127.0.0.1:7007 ,第一个实例127.0.0.1:7008为备份节点,第二个实例127.0.0.1:7007为主节点。然后我们在执行,cluster nodes 命令,就会发现新添加的节点已经作为7007 备份节点开始工作了!

       

  

Redis 集群删除节点

        删除节点也分两种,一种是主节点,一种是从节点。在从节点中,我们没有分配哈希槽,所以删除很简单,我们直接执行./redis-trib.rb del-node 127.0.0.1:700865ee465423c925326a5137668541151b4c37d2d9 有两个参数ip:port  和节点的id。 我们就可以将从节点从集群中删除了。

        

        而在删除主节点的时候,因为在主节点中存放着数据,所以我们在删除之前,要把这些数据迁移走,并且把该节点上的哈希槽分配到其他主节点上。

       我们执行./redis-trib.rb reshard 127.0.0.1:7007,问我们有多少个哈希槽要移走,因为我们这个节点上有1000 个所以我们这里输入1000,如下如所示。

       

        这样期间会询问我们是否要从新分配,我们输入yes。然后就看到7007上的所有节点都被移动到了7001.这样我们就操作完了。然后再执行./redis-trib.rb del-node127.0.0.1:7007 61f786c40bcc170006a440abd7dc773e6dd15a19 ,就会看到7007 端口的实例也被从集群中移除了。

       

 

        我们进入客户端,看一下集群节点的情况。会看到7007 节点和7008 节点就都被我们移除集群了!   



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [性能 网站架构 缓存] 推荐:

高性能网站架构之缓存篇—Redis集群搭建

- - 开源软件 - ITeye博客
1.  Redis Cluster的架构图.          (1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽..          (2)节点的fail是通过集群中超过半数的节点检测失效时才生效..          (3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可.

高性能网站架构之缓存篇—Redis集群增删节点

- - 开源软件 - ITeye博客
       首先我们要新建立一个节点,将redis01 复制一份改为redis07,然后修改端口号也改为7007 ,然后我们执行[root@localhost redis07]# ./redis-server redis.conf 启动以后,然后进行查看,发现有一个端口号为7007的redis实例已经启动了.

从12306.cn谈大网站架构与性能优化

- - 服务器运维与网站架构|Linux运维|X研究
PS:关于12306.cn网站,前些时间,骂的人很多,但是这网站的压力和架构不是一般非专业人生想得这么简单. 下文是资深架构师陈皓写的关于12306.cn购票网站的架构和性能系列分析,个人认为很有参考价值,转载如下:. 12306.cn网站挂了,被全国人民骂了. 我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题.

一例千万级pv高性能高并发网站架构[原创]

- - 运维进行时
      受CU管理员的邀请参考“ 千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流,发表了一案例与大家分享.       一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面,有兴趣也可以讨论). 现抛出一个系统层面的架构,不保证是最优的方案,但也许适合你.

千万级pv高性能高并发网站架构与设计(转)

- - BlogJava-
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”. 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.

Facebook 网站架构

- - idea's blog
我收集到一些文章和视频, 可以带你窥探 Facebook 的架构. Facebook 承载了几十亿的用户, 它的架构(包括思想和实现)是非常值得参考的. 当然, 你要小心不要照搬 Facebook 的每一字一句, 因为任何思想和实现都是有自己的应用场景的.. Google Talk 界面开发分析. 使用Python POST任意的HTTP数据以及使用Cookie.

网站架构演进

- - CSDN博客互联网推荐文章
很多年前,世界上出了互联网这个东东,不久之后又出来了网站这个家伙. 那时的程序员还只是程序员,有的程序员Deid,But他依然live的. 不像现在,他虽然活着,但已经不仅仅是程序员那么简单了,因为他更喜欢用屌丝来形容自己. 网站的远古时代就好像我们的原始时代一个意思的. 作者:enson16855 发表于2013-7-8 22:43:36 原文链接.

[转载]【摘】SNS社区网站架构

- - 网站架构_搜搜博客搜索
  SNS网站:全称Social Network Site,就是依据六度理论建立的网站,也是基于社会网络关系建立的网站.   原本经济危机来了,FACEBOOK估值从150亿美金跌至40亿;国内互联网创投环境也日趋寒冷,而在舆论界,关于SNS的话题似乎热度未减,,当然在精彩文章之中也夹杂着一些隔靴搔痒式的讨论;.

大型门户网站架构分析

- - 网站架构_搜搜博客搜索
   大型门户网站架构分析.   千万人同时访问的网站,一般是有很多个数据库同时工作,说明白一点就是数据库集群和并发控制,这样的网站实时性也是相对的. 这些网站都有一些共同的特点:数据量大,在线人数多,并发请求多,pageview高,响应速度快. 总结了一下各个大网站的架构,主要提高效率及稳定性的几个地方包括:.

Flickr 网站架构研究(1,2)(zt)

- - 网站架构_搜搜博客搜索
  Flickr.com 是网上最受欢迎的照片共享网站之一,还记得那位给Windows Vista拍摄壁纸的Hamad Darwish吗. 他就是将照片上传到Flickr,后而被微软看中成为Vista壁纸御用摄影师.   Flickr.com 是最初由位于温哥华的Ludicorp公司开发设计并于2004年2月正式发布的,由于大量应用了WEB 2.0技术,注重用户体验,使得其迅速获得了大量的用户,2007年11月,Flickr迎来了第20亿张照片,一年后,这个数字就达到了30亿,并且还在以加速度增长.