Sentry mode, still only one Master node, when concurrent write request is large, can not be written to ease the pressure, appears to solve this problem in version 3.0 Redis-Cluster
Redis-Cluster Cluster features:
1) distributed network service cluster consists of multiple servers Redis
2) among a plurality of clusters Master main nodes, each node can read a master writable
3 communicate with each other) nodes, between two connected
4) Redis no central node cluster
Redis-Cluster in the cluster may be added for each node from the master node, the master node and the master node from the follow characteristic model (add a node can be extended to read from the performance of the system)
Failover mechanism Redis-Cluster Cluster:
Failover mechanism and Redis Sentinel Redis-Cluster Cluster essentially the same, except that Redis-Cluster failover cluster is responsible for a cluster of other online master node, it is not necessary to additionally use Redis Sentinel cluster
Redis-Cluster cluster fragmentation strategy:
Fragmentation strategy is to address key storage location
The entire database cluster into 16,384 slots (solt), all key-value data is stored in one of these solt, and can store a plurality of data slots, the key slot is calculated as: slot_number = crc16 (key)% 16384, which is a 16-bit cyclic redundancy crc16 checksum function.
Each active node in the cluster can handle 0-16383 grooves, when 16,384 slot has a node at the handles, the cluster enters the online state (and vice versa in a paralyzed state), and start processing transmitted by the client data request command.
Redis-Cluster Cluster redirect
Since Redis no central node cluster, the request will be randomly distributed to any of the master node:
The master node will only be responsible for handling its own command slot request, the other slot request command, the master node will be returned to the client a steering error;
The client re-initiates the command request from the address and port to correct errors contained in the master node is responsible.
Configuration process:
1. environmental structures
Ruby 1.1 installation environment
1.2安装ruby和redis的接口程序,利用xftp将redis-3.0.0.gem拷贝至/usr/local下安装
2.集群的规划
由于物理机数量有限,本文将采用同一台主机构建一个伪分布式集群,以不同端口表示不同的redis节点:
主节点:192.168.93.4:7001 192.168.93.4:7002 192.168.93.5:7003
从结点:192.168.93.4:7004 192.168.93.4:7005 192.168.93.5:7006
在/usr/local/下创建redis-cluster目录,7001~7006
3.将redis解压路径下的配置文件redis.conf,依次拷贝到7001~7006目录中,并修改(port、bind、protected-mode、cluster)
建议配置(daemonized yes 后台启动,logfile /usr/local/redis/redis-cluster/700X/node.log日志输出位置)
7001的配置
其他节点配置同7001
4.指定各个节点的配置文件启动客户端
5.执行创建集群的命令(进入redis安装源码src下)
创建成功
利用客户端查看集群信息
-c表示以集群方式连接redis,
-h指定ip地址,
-p指定端口号
cluster nodes 查询集群结点信息;
cluster info 查询集群状态信。
添加主节点:
下面是添加一个master主节点添加7007节点,添加一个“7007”目录作为新节点,配置信息同前面7001~7006配置
通过客户端7007发现已加入到集群中
为7007节点分配hash槽,才能存储数据
1)先连上集群
2)输入hash槽的数量
3)输入7007节点的id值
4)输入分配槽点的源节点id
输入all则为从每一主节点中分配
5)同意分配计划,或取消重新分配
通过客户端查看集群状态
添加从节点(先配置7008的基础信息,同上7001~7007)
到src目录下添加从节点
添加成功
通过客户端查看集群状态