redis集群 官方方案redis-cluster搭建实战

1.为什么使用redis？

redis是一种典型的no-sql 即非关系数据库 像python的字典一样 存储key-value键值对 工作在memory中

所以很适合用来充当整个互联网架构中各级之间的cache 比如lvs的4层转发层 nginx的7层代理层

尤其是lnmp架构应用层如php-fpm或者是Tomcat到mysql之间 做一个cache 以减轻db的压力

因为有相当一部分的数据 只是简单的key-value对应关系，而且在实际的业务中常常在短时间内迅速变动 

如果用关系数据库mysql之类存储 会大大增加对db的访问 导致db的负担很重 因为所有的require中的大部分最后都要汇聚到db

所以如果想要业务稳定 那么解决db的压力 就是关键 所以现在大部分的解决方案就是在db层之上的各级使用多级的no-sql 

像memcache redis 等 来为db提供缓冲  

2.为什么使用redis-cluster？

为了在大流量访问下提供稳定的业务，集群化是存储的必然形态

未来的发展趋势肯定是云计算和大数据的紧密结合 只有分布式架构能满足要求

如果没有集群化 何来的分布式？

3.顺带一提总结一波今天的redis原理之数据持久化

虽然redis这种no-sql一般都是作为cache来服务  但是如果完全没有数据可持久化的方法 那么显得有些单薄

就像memcache 由于这种no-sql是工作在memory的 那么由于memory的实体是ram

所以如果重启或者宕机 memory中的数据就全没了 数据的一致性的不到保障 

但是 redis不同 redis有相对的数据持久化的方案 由两种方式构成 aof & rdb

aof就像关系数据库中的binlog一样  把每一次写操作以追加的形式记录在其中以文件的形式刷到磁盘里 

并且可以使用不同的fsync策略     无fsync,每秒fsync,每次写的时候fsync.

使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求)

一旦出现故障，最多丢失1秒的数据.

但是缺点也随之而来 那就是aof文件的大小会随着时间线性增长 一段时间之后 就会变得很大 

如果要在一端以AOF的形式来恢复数据 那么由于AOF文件的巨大体积 可能会让进程如同假死一样 十分的慢

rdb则是一种快照机制 

redis工作在内存中 rdb就是每隔一段时间 对内存中的数据做一次快照  保存在rdb文件中 

而且redis的主从同步可以实现异步 也是由于rdb的机制 他在做快照时会fork出一个子进程 由子进程来做快照

父进程完全处理请求 毫不影响 很适合数据的备份 

但是问题是 如果数据量很大的话 rdb它要保存一个完整的数据集 是一个大的工作 如果时间间隔设置的太短 

那么严重影响redis的性能 但是按照常规设置的话 如5分钟一次 那么如果宕机或者重启 就会基于上次做rdb的时间

从而丢失分钟级的数据

point：在redis4.0的新特性中 采用了aof-rdb的混合方案来保障数据的持久性 但是官方的说法是还不成熟

是一个长期的工作  所以有待观察吧 

4.redis集群实现方案： 

关于redis的集群化方案 目前有三种 

（1）Twitter开发的twemproxy

（2）豌豆荚开发的codis

（3）redis官方的redis-cluster

简介：twemproxy架构简单 就是用proxy对后端redis server进行代理 但是由于代理层的消耗性能很低 而且通常涉及多个key的操作都是不支持的 而且本身不支持动态扩容和透明的数据迁移 而且也失去维护 Twitter内部已经不使用了

          redis-cluster是三个里性能最强大的 因为他使用去中心化的思想 使用hash slot方式 将16348个hash slot 覆盖到所有节点上 对于存储的每个key值 使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上 然后由当前访问节点从实际被分配了这个hash slot的节点去取数据 节点之间使用轻量协议通信 减少带宽占用 性能很高 自动实现负载均衡与高可用 自动实现failover  并且支持动态扩展 官方已经玩到可以1000个节点 实现的复杂度低 总之个人比较喜欢这个架构 因为他的去中心化思想免去了proxy的消耗 是全新的思路

           但是它也有一些不足 例如官方没有提供图形化管理工具 运维体验差 全手工数据迁移 并且自己对自己本身的redis命令支持也不完全等 但是这些问题 我觉得不能掩盖他关键的新思想所带来的的优势 随着官方的推进 这些问题应该都能在一定时间内得到解决 那么这时候去中心化思想带来的高性能就会表现出他巨大的优势 

          codis使用的也是proxy思路 但是做的比较好 是这两种之间的一个中间级 而且支持redis命令是最多的 有图形化GUI管理和监控工具 运维友好 这个过段时间会详细另外写出来原理 工作机制和搭建实现

5.redis-cluster搭建过程

基本上按照官方的文档走 但是其中遇见了不少的坑 而且还遇到一个 应该可以算是官方的坑（完全是官方的疏忽）   /闹心

所以必须好好的写出来 

首先下载官方的包 我这里使用的系统环境是rhel6 并且redis是使用最新版的稳定版4.0.8

然后解压官方的tar.gz包 的得到redis-4.0.8的目录

cd ./redis-4.0.8 

vim redis.conf

能起来集群的配置文件应该至少如下：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

而且 官方推荐集群中至少有三个主节点 所以我们建立redis-cluster目录 然后在其中再建立7000 7001 7002目录 

在另一台节点上 同样建立7003 7004 7005目录 官方给的集群实在一台节点上实现的  因为redis只要有端口就可以起一个进程

所以一台节点上理论可以起最大端口数支持的redis个数 有多少端口 就可以起多少个独立的redis-server 我这里则是在另一台节点上做其他三个redis-server 所以如果像这样搭建集群的话 需要修改每个服务的配置文件中的bind参数为172.25.xx.xx 就是可以让其他node访问的网络IP 而不是默认的127.0.0.1 

然后就是把src路径中的redis.conf 拷贝到每个刚刚建立的节点文件夹中 并做对应的修改 然后用redis-server redis.conf启动redis-server

使用netstat命令查看端口 我这里起了3个redis-server 700*是供cli访问的端口 1700*是各个redis之间通信的端口

我感觉到这样一个一个切过去启动十分麻烦 所以写了一个简单的shell脚本一次性启动当前节点上的配置的所有redis

脚本如下

两台主机的共6个redis-server都起来之后就可以搭建集群了 这里官方有创建集群的脚本 在源码包解压路径的

/src 下 名叫redis-trib.rb 我们把它cp到/usr/bin下 方便启动 

但是这里如果直接启动的话 会报错 因为这个redis-trib.rb是依赖于ruby的 所以我们需要执行 gem install redis

接下来就开始我的惨痛经历了 

首先没有gem 于是yum install ruby ruby-devel rpm-build

然后还要自行从网上下载 rubygems的包

好 搞定 执行gem install redis 果断报错 

报错说install redis need ruby version 》=2.2.2

好 yum里没有 去到ruby官网下载ruby-2.2.9 源码包 tar zxf 解压 

./configure --prefix=/usr/local/ruby  

make && make install

安装完成 rm -rf /usr/bin/ruby 删掉原来旧版本的ruby    再 ln -s /usr/local/ruby/bin/ruby    /usr/bin 

把新版ruby 连接过去

执行 ruby -v    显示ruby版本 是2.2.9 成功 

再次执行gem install redis 

果断又报错 ！！

报错说ruby 找不到zlib库 好 yum install zlib 再次执行 geminstall 

依旧报错 ！ 查了下攻略 说要用ruby源码包里./ext/zlib 自带的zlib库

cd  ruby-2.2.9/ext/zlib  执行ruby ./extconf.mk    本来想着应该看到create makefile 然后make && make install就OK

再次报错！！！ 输出

check ******* z   no

check ********zlib    no

check ********* zlib1    no

check *********  libz    no         can't  create makefile

咋回事啊？ 啥玩意啊？ 我在这瞬间蒙蔽了

又去查攻略 找不到相似问题 折腾到1点 无果

今天冷静下来后 机智的我 vim extconf.mk 这个文件 进去看看咋回事 

发现有这样的ruby语句 本人虽然不懂ruby但是有一定编程功底 大概看懂了这个语句的逻辑

 就是他 循环check (z |zlib |zlib1| libz )& if source path have zlib.h    then  return yes     

else return no 

然后瞬间想到 可能是我没有这个zlib.h 才导致返回no 因为之前 yum install 的zlib库里有zlib.so模块  

于是 yum provides */zlib.h   发现了zlib-devel这个包提供这个文件

果断 yum install zlib-devel   再次进入/ruby-2.2.9/ext/zlib 执行 ruby  ./extconf.mk 

直接返回4个yes    creating Makefile  

之后make && make install  看到他就是把一个模块链接到了 ruby家目录下的lib/zlib里 

问题解决

终于可以再次执行 gem install redis了   流泪

还没流完泪  再次报错！！

ruby又需要openssl了    好 yum install openssl openssl-devel   -y

重新执行 还是报错 看来ruby只认从他源码目录安装的模块  果断进入/ruby-2.2.9/ext/  发现果然有openssl这个目录

cd 进入 执行 ruby ./extconf.mk           这次没有报错 直接create Makefile

欢喜进行make 然后猝不及防的报错！！！

make ** can' make target /include/ruby.h , need "ossl_pkey.o"  大概是这样

一波折腾 没搞出来 最后查到一个国外的论坛上 看到国外大神解答 说这个是因为Makefile里面官方忘了给路径变量赋值 

需要在Makefile里面添加一行  top_srcdir = ../..

果断vim /ruby-2.2.9/ext/openssl/Makefile  添加这一行 然后 继续make && make install 终于成功

这下终于可以gem install redis了       难受 上图 

终于成功 然后按照官方命令 

./redis-trib.rb create --replicas 1 172.25.44.1:7000 172.25.44.1:7001 \
172.25.44.1:7002 172.25.44.2:7003 172.25.44.2:7004 172.25.44.2:7005

启动集群！！！

看到 All 16384 slots coverd  所有的16384个哈希槽覆盖完成   表示集群启动成功

测试 使用 redis-cli   -c（表示连接到集群 ）-h 172.25.44.1（指定IP） -p 7000（指定端口）   连接到集群 进行测试

从terminal的输出就能看到 集群的hash slot工作模式 集群成功