【redis】-- 集群

集群
复制（master、slave）

配置过程
修改11.140和11.141的redis.conf文件，增加slaveof masterip masterport
slaveof 192.168.11.138 6379
实现原理
1. slave第一次或者重连到master上以后，会向master发送一个SYNC的命令
2. master收到SYNC的时候，会做两件事
a) 执行bgsave（rdb的快照文件，同步当前内存数据库的数据到磁盘上）
b) master会把新收到的修改命令存入到缓冲区
缺点
没有办法对master进行动态选举

问题：

1. 主从数据库数据不一致现象？
   方案：主数据库的RDB快照文件复制过来，恢复就行。
   补充：slave在同步master的时候不会被阻塞，因为是读操作，仍然可以处理客户端的命令。
2. 如何保证不会出现脏数据？
   默认情况下，slave同步前的数据命令进行响应，如果希望在读取过程中不会出现脏数据，（master和slave同步完成之前（或者失去连接时或复制过程中时，），保证slave的数据不会出现变化。）？
   方案：修改slave配置

复制的方式
1. 基于rdb文件的复制（第一次连接或者重连的时候）
2. 无硬盘复制
3. 增量复制
PSYNC master run id. offset
哨兵机制

sentinel
1. 监控master和salve是否正常运行
2. 如果master出现故障，那么会把其中一台salve数据升级为master

补充：
1. 也可以对哨兵做集群，哨兵之间相互监控
2. 哨兵的配置：

引入哨兵后，把master挂掉，执行，（这里有一个机制，会确定多长时间之内，认为master没有响应，才会确定master已经挂掉。所以关掉后，该机制会检测master状态）

集群（redis3.0以后的功能）
根据key的hash值取模 服务器的数量 。
hash
集群的原理
Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

slot（槽）的概念，在redis集群中一共会有16384个槽，
根据key 的CRC16算法，得到的结果再对16384进行取模。 假如有3个节点
node1 0 5460
node2 5461 10922
node3 10923 16383
节点新增
node4 0-1364,5461-6826,10923-12287
删除节点
先将节点的数据移动到其他节点上，然后才能执行删除

市面上提供了集群方案
1. redis shardding 而且jedis客户端就支持shardding操作 SharddingJedis ； 增加和减少节点的问题； pre shardding
3台虚拟机 redis 。但是我部署了9个节点 。每一台部署3个redis增加cpu的利用率
9台虚拟机单独拆分到9台服务器
2. codis基于redis2.8.13分支开发了一个codis-server
3. twemproxy twitter提供的开源解决方案