Redis 进阶使用（二）

一、Redis 的AFK 原理

单机会有3个问题，通过AFK 来进行集群维度的划分，来解决相应的问题；比如x 主备 划分解决单点故障等；

AFK 会引起一些问题，比如数据的一致性，不同程度的一致性，会有不同的问题；可以通过以上的方式进行解决，最终异步kafka  等方式；

二、 Redis 中的CAP原理

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

主备：只能访问主，备是不参与业务的，只有主有问题，备才顶上；主从： 主和从都可访问

三、主从复制原则

http://redis.cn/topics/replication.html

Redis使用默认的异步复制，其特点是低延迟和高性能，是绝大多数 Redis 用例的自然复制模式。但是，从 Redis 服务器会异步地确认其从主 Redis 服务器周期接收到的数据量。

• 前往某一个服务实例配置文件，比如6379.conf
• daemonize yes   后台运行是否开启；
• logfile /var/log/redis_6379.log 这行注释掉，将日志打到前台观察；
• appendonly  yes  是否开启aof
• 启动6379，作为主；

实验：

准备一个空的test 文件，里面复制有三个实例的配置文件

启动某一个实例，的命令行，更换实例端口逐个启动；后续逐个启动3个客户端

在启动的实例中，追随6379，作为从属机器；这个是手动追随；

主机器操作完之后，从机器通过手动追随，将6379 的数据同步过来；

以下为自动追随，在启动实例的时候，加上追随哪台实例的 ip 及端口号；

不止自动追随，还开了aof 

以下，是操作完了之后，会在实例文件夹里增加aof  文件；

取消从机器身份，恢复到主机器，就是谁也不追随；

还有一些主从复制的命令，在配置文件中都有，以下四中截图的主从复制有，常用的

 

四、Redis 的高可用HA，sentinel 哨兵

http://redis.cn/topics/sentinel.html

 

增加26379哨兵，监控主机；增加26379.conf  配置文件

开一个实例，以哨兵的形式运行，不参与值的存储等；

当主机6379 挂掉，哨兵之间可以发起投票，选出6381

更改完主机器之后，实例26379 的配置文件会相应的发生变化，如下：

五、sharding 分片

六、代理的引入

分片机制等，可以转移到代理中来实现；

git hub  搜索 twemproxy  查看 twitter twemproxy  项目中的 readme.txt;学习如何hash ,如何散列等；

 

三种代理：twitter,predixy,cluster 是redis 自身的代理；

• twemproxy  

https://github.com/twitter/twemproxy

readme.txt 部分构建内容

根据readme 来进行构建；

拉下来代码，报错的话，yum update nss后重新拉代码；

安装automake ，因为autoreconf -fvi && ./configure needs automake and libtool to be installed

当需要的版本比较小的时候，yum 不能满足，则可以去阿里云镜像里找

搜索o'psx 找到阿里云官方镜像站，到epel ，获取下载新repo 到/etc/yum.repos.d/仓库的相应版本的命令

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo

到yum 仓库文件中，可以看到现有的配置文件中默认仓库，执行完以上命令之后，再看yum.repos.d 会发现多了epel.repo仓库；vi rpel.repo 查看，可以看到新的源库位置配置进去了；

重新下载需要的高版本

然后执行 $ cd twemproxy     和 $ autoreconf -fvi

后边分别执行 $ ./configure （--enable-debug=full   括号里的可以不跟） 和 $ make

cd src/ 可见一个编译好的程序目录 /nutcracker ；

---------------------------

创建一个twemproxy   随时可以开的服务的流程：

回到clone的源文件 cd twemproxy/scripts/  查看  nutcracker.init  即  vi nut cracker.init ；这个是服务启动的脚本文件；进入可以看到，如果作为服务执行下边start 函数的时候的时候，需要一个配置文件，位置在OPTIONS  这个变量里面；另外 prog = nutcracker  这句，表示，需要有一个可执行的程序，就是源码编译完之后生成的那个可执行程序；后边要拷贝到相应的位置；

假如，要把服务的实例程序放在/etc/init.d/twemproxy 文件夹中（/etc/init.d 里是service  XXX start  启动的可执行程序的文件夹），则有下边的操作；chmod +x的意思就是给执行权限；目标是为了执行  service  twemproxy 的时候可以启动之前编译过的代理程序；

vi twemproxy,可以看到复制的里面有OPTIONS 变量，要想实现service 启动，就要按照那个地址/etc/numcracker存放一个numcracker.yml   文件，这个文件去哪里找，去编译过的 源文件夹里numcracker  里的conf   文件夹里去复制；另外

cd soft/twemproxy/conf 

接下来就是copy  可执行程序soft/twemproxy/src/numcracker 到   /usr/bin

最后就是更改它对应的配置文件numcracker.yml   ；具体参数代表的意义，可以参看 github 的readme  里的配置相关；以下配置是代理redis 中的两个实例  6379  和 6380 ；

至此；就可以利用  service  twemproxy start  在任何时候开代理实例了 

----------------------------

启动22121  的代理端口，进行数据的操作，会分别打到两台被代理的机器中；

代理的一个确定是，分治了之后，不能进行一些聚合后的管理，会报错；

• predixy  代理示例

git hub 搜索 predixy  

可以用直接release 版本，即已经编译过的版本；利用 wget  以及tar 等来获取；

predix支持单group的主从的，watch 以及事务等；

七、 Cluster 的引用

http://redis.cn/topics/partitioning.html

• Cluster  示例

根据readme  进行操作，create-cluster  目录里给了自动创建cluster 的练习方法；  这个一般是在同一台机器中创建；

vi create-cluster  更改nodes和 REPLICAS；看到nodes = 6 表示有6个实例节点；REPLICAS =1 代表一组主从中从的数目；那么有几套，就是 nodes/(1+REPLICAS) ,这里就是 6/2 = 3 ，3套主从；

  

启动cluster  会自动启动6个实例节点；并且分好主从group;

正确的开启客户端的命令是要加-c ,代表以cluster 的模式启动，这样就可以找到正确的主实例，

注意set 后不同的key 值路由到不同的主实例上；根据key 值来计算槽位；执行watch 是可支持的，但是执行事务的时候就报错了；就是因为从一台路由到另一台的时候，执行事务的那台没有缓存命令队列；

解决这个问题的话，就用标志，这样会一直在一台主实例上来执行；

停掉 这些机器，并且清理之后，就回到了原始的状态；

那么这些只是自动分配，要人工分配槽位以及主从的实例，则需要一些命令，这些命令才是我们真正需要掌握的知识；

首先，我们启动这6台机器；

然后看 create 命令；

IP:PORT  的命令模式，可以建立真正的分布式集群了；执行完之后，类似配置了nodes 和REPLICAS ；后续效果跟前边的自动配置是一样的；

根据help 可以学习很多的手动命令，例如 reshard,重新分配槽位；  从3001 向3002 分配2000个槽位；然后done回车，即可自动转移，但是具体转移哪些控制不了；

可以看移动之后的槽位信息