redis的集群

使用redis-trib.rb命令创建redis集群
1.redis-trib.rb命令的使用
为了使用方便，我们将该命令放到/usr/local/bin中。
cp /usr/local/redis-3.2.11/src/redis-trib.rb /usr/local/bin
拷贝过去备用。
2.环境准备
6383.....6388共6个redis实例，并修改配置文件为最小配置。
3.创建集群
1)修改redis.conf配置文件使得redis支持集群
cluster-enabled yes
cluster-config-file nodes-6383.conf
cluster-node-timeout 5000
2)集群的创建
a.首先启动6个redis实例
备注：
在启动redis实例的时候，nodes-port.conf文件就在启动目录被创建了。
运行ps -ef |grep redis的时候会发现配置了集群支持的实例后面都跟着一个[cluster]
b.执行运行redis-trib.rb命令创建集群
redis-trib.rb create --replicas 1 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 127.0.0.1:6386 127.0.0.1:6387 127.0.0.1:6388
备注：
redis分配了一些master和一些slave,并且做了一对一的配对
每一个redis实例，包括master/slave都有一个唯一的id号
标明了每一个slave的master是谁，并且slave将会从属于它的master哪里复制信息，换句话说说，集群中包含着很多主从复制架构。
每一个master都分了若干个slots(槽/分片)，每一个slave没有分slots.即只有master分配了槽。
众多的master在分槽的时候，按照一个相对均衡的策略进行分配，即这就是redis集群的负载均衡策略。
一个集群总共有16384个槽，即一个集群最多有16384个master。
4.常见错误
1)最小配置没有准备好
2)在主从复制的配置6380,6381....的基础改的集群配置
报错：slaveof...不能运行在cluster...环境下，即必须注销slaveof。
也就是说同一个redis实例要么单机运行、要么在主从复制中运行、要么在集群中运行。
不能即在主从中运行又在集群中运行。
3)执行redis-trib.rb的时候提示Permiission denies即没有执行权限，先修改该文件的权限。
4)redis实例中有密码导致redis-trib.rb执行时报Can't connect 127.0.0.1:6385,解决方案有：
a.先将集群创建成功后再用config set requirepass XXX添加密码，添加的时候所有实例的密码必须相同。
b.修改redis-trib.rb的源代码，将密码付给该程序
5)redis-server /usr/local/bin/6384.conf不报错
ps -ef | grep redis却看不到6384.
6)粗心
7)版本3.2.11版本，要求ruby版本大于2.2
8)不能开启maxmemory配置

 

redis集群的特性分析
1.上节作业
127.0.0.1:6388> set name liubei
-> Redirected to slot [5798] located at 127.0.0.1:6384
OK
127.0.0.1:6384> keys *
1) "name"
127.0.0.1:6384> get name
"liubei"
127.0.0.1:6384> set age 18
-> Redirected to slot [741] located at 127.0.0.1:6383
OK
127.0.0.1:6383> set no 124234243
-> Redirected to slot [13676] located at 127.0.0.1:6385
OK
127.0.0.1:6385> get name
-> Redirected to slot [5798] located at 127.0.0.1:6384
"liubei"
2.节点通信
1)从任何一个节点，不管是master还是slave均可登录集群；
2)任何一个节点的配置文件nodes-port.conf文件中除了自身信息以外还有其他节点的信息；
3)集群的节点包含master和slave等节点(也包含宕机的节点)；
4)在任意一个节点均可运行get/set等命令，但是在Redirected的时候不可能定位到slave上面；
5)集群中的任意节点都是彼此互联的，每一个节点的状态其他节点都能感知；
6)在集群的slave节点可以执行set/sadd/del等命令；
7)master节点的中数据彼此之间不会进行同步；
8)master和自己的slave数据会做同步，同步规则遵循“主从复制”架构；
9)整个集群架构是“分布式集群”。
3.最低要求
1)如果master有从节点，则master宕机的数据不能大于一半；
2)如果master没有从节点，则宕掉任何一个节点就会因为缺少槽导致集群不可用；
备注：宕机后立即运行cluster info可能状态还没更改过来。
4.负载均衡
16384个槽基本均衡的分布到了所有的master上，这样访问的时候就保证了负载均衡。
5.主从复制
1)主从复制只发生在master和隶属它的slave之间，master和master之间、master和非隶属它的slave之间不存在主从复制。
2)在从节点可以执行set等命令
6.容错机制
1)容错机制分宕机检测和主从切换两个操作。
2)宕机检测，集群内超过一半master节点检测到某一个master节点宕机，该节点才算宕机
3)主从切换，集群内部从宕机的master隶属的slave节点中选择一个切换成master
4)集群的容错机制不依赖于哨兵，这是跟主从架构的一个重要区别
7.事务支持
在集群中，是不支持事务的，因为各个命令可能跨不同的节点，命令在各个节点已经执行，不会再放到Queued。
8.集群效率
由于集群在set/get的时候需要redirect寻找相应的槽，因此它的运行效率没有单机高。
我们搭建集群的目的是为了提高整个系统的“可用性”。另外，通过负载均衡也相应的
提高了访问的效果。
9.集群命令
cluster info
cluster myid
cluster nodes
cluster meet
cluster foget

 

使用spring集成redis的访问
1.操作单机/主从
见spring.xml和TestSpring.java
2.操作集群
见springcluster.xml和TestSpringCluster.java
3.主要学习如何注入，不要死记硬背属性名称
4.注意
1)以上java程序是使用getBean()方法手动从ApplicationContext对象中获取对象的。
如果要使用注解注入的方式获取对象，需要在配置文件中增加如下代码：
<!-- 采用注释的方式配置bean -->
<context:annotation-config />
<!-- 配置要扫描的包 -->
<context:component-scan base-package="cn.buba.redis.spring" />
<!-- proxy-target-class默认"false",更改为"ture"使用CGLib动态代理 -->
<aop:aspectj-autoproxy proxy-target-class="true" />
2)在操作集群的时候无需声明ShardedJedisPool，JedisCluster自己会根据JedisPoolConfig创建连接池。

 

高级理论部分—acid和cap
ACID是整个关系型数据的理论基础，如果这4个方面其中有一个做不到，那么该产品
也无法使用。
1.ACID理论
A原子性：该操作(或者是批量的操作)不可分割，要么全部执行，要么全部回滚
C一致性：无论由多少个线程(客户端)操作数据库得到的结果跟1个线程(客户端)操作的结果必须是相同的
I隔离性：事务跟事务之间互不影响
D持久性：指的是事务必须支持提交(持久化)一旦commit()则不会再修改，即commit()执行完毕代表着一个事务的结束

2.CAP理论
nosql产品的理论基石，nosql产品的需要从下面3个方面考虑，但是下面这3个方面又不能同时满足，最多只能满足其中2个
C一致性：牺牲部分的一致性,若事务，强一致性即要求某一个节点修改了数据另外一个节点立马看到
A可用性：必须保留，以为可用性直接影响了系统的健壮和用户体验
P分区容错：一旦一个分区发送故障或者需要增加新的分区的时候，能够很好的进行水平扩展
备注：这里的分区不是指的槽，而是指的是“单例”
区块链：去中心化的分布式数据库，去中心化就是没有中心，只有没有中心节点的架构才能很方便进行水平扩展。