redis achieve high concurrency mainly depends on master-slave architecture , a master multi-slave. From the master to availability, we should add guards , may be implemented in any instance of a down, the switchover can be performed. After high concurrency availability want to accommodate big data, to redis cluster
master-slave architecture: master-slave architecture
redis clusters: Cluster
First, the mechanism introduced Sentinel
1.1, Sentinel function / Sentinel mechanism
You can run multiple processes in a sentinel architecture, these processes using a protocol to receive the master whether the offline information, and the use of voting protocols to determine whether to perform automatic failover, as well as select which slave as the new master;
Each Sentinel will regularly send messages to other guards, master, slave, in order to determine whether the other party alive, if the other party does not respond in the specified time, the other party has hung up a temporary task;
Most agree that if the master did not respond Sentinel system will consider the master of death (select one from the remaining slave was promoted to master node through a certain algorithm).
Redis Sentinel mechanism for managing multiple servers, the Distributed Systems (Sentinel mechanism) performs the following three tasks (functions):
(1) a cluster monitor : responsible for monitoring redis master and slave processes are working properly .
(2) message notification : If a redis instance fails, then the sentry responsible for sending notification messages to the administrator as an alarm.
(3) Failover : If the master node hang, will be automatically transferred to the slave node (sentinel need most agree that the job involves a distributed election ).
Configuration Center: If a failover occurs, notify the client the client a new master address.
1.2, Sentinel Precautions
(1) failover, determine a master node is down, and most of the guards are required consent to it, it involves a distributed election issue
(2) Sentinel requires at least three instances , to ensure their robustness
Sentinel cluster must deploy two or more nodes, the cluster only if the sentinel sentinel deployed two instances, quorum = 1 
configuration quorum = 1, if the master down, s1 and s2 as long as there is a Sentinel that the master is down, can be carried out switching, while s1 and s2 sentinel will elect to perform a failover. But at the same time this is required majority (the number of guards to run). If this time is just down the M1 process, Sentinel s1 normal operation, the failover is OK. But if the whole machine downtime M1 and S1 run, then only one sentry, this time there will be no majority to allow failover, although on another machine as well as a R1, but does not perform failover
classic 3 sentinel node cluster like this: 
configuration quorum = 2, if the machine where M1 is down, then the remaining three Sentinel 2, S2 and S3 may agree that the master is down, then elected to perform a failover while the majority Sentinel 3 is 2, so the remaining two guards running, you can allow failover
(3) Sentinel + redis deployment architecture master-slave is not going to guarantee zero data loss, only redis clusters ensure high availability
1.3, Sentinel main loss problem (in both cases) from the data switching
Data (1) asynchronous replication lead to loss :
Because master-> slave replication is asynchronous, it may not have a part of the data copied to the slave, master it down, and at this time which part of data is lost
data (2) results in loss of split brain :
split brain: a a master of the machine's sudden departure from the normal network, the machine can not connect with other slave, but in fact master is also running. At this time, Sentinel might think that master is down, and then turn the election, the other slave switch became master. This time, the cluster will have two Master , the so-called split-brain
at this time, although a slave is switched became a master, but the client may not had time to switch to a new master, but also continued to write data to the old master. So when the old master once again restored, it will be as a slave to hang up the new master, your data will be cleared , re-copy the data from the new master. The new master data later client did not write, so this part of the data will be lost
1.4, data loss solution
As follows
min-slaves-to-write 1 //要求至少有 1 个 slave
min-slaves-max-lag 10 //数据复制和同步的延迟不能超过 10 秒
- 1
- 2
(1) reducing asynchronous replication of data loss
with min-slaves-max-lag this configuration, you can ensure that once the slave to copy data and ack delay is too long, they think too much data could master the downtime losses , then reject a write request, thus the downtime caused when the master data is not synchronized to the data portion of the slave missing due to the decrease in the controllable range
(2) reduction of split brain data loss
if a master split brain occurs, with other slave lost connection, then the above two configuration ensures that if you can not continue to send data to specify the number of slave and slave no more than 10 seconds to give yourself ack message, then refused to write directly to the client's request. Therefore, in split-brain scenario, up to 10 seconds of data is lost
1.5, and odown down type switching mechanism sdown
sdown downtime is subjective: it is a sentinel if they feel that a master is down, down is the subjective is objective odown down: If the quorum number of sentinel feel a master is down, down is the objective
1.6, auto-discovery mechanism sentry Clusters
Sentinel found each other, by redis the pub / sub system implemented
(1) Each Sentinel will go Sentinel : the Hello this channel. Send a message, this time can be consumed all the other guards to the news, and perception to the presence of other sentinels.
(2) every two seconds, the sentinel will each go to their master + slaves monitor a corresponding channel in transmitting a message, the contents of their own host, ip and also for monitoring the master runid configuration.
(3) Each Sentinel will go to the same perceived to exist in listening to this master of slaves + other sentinels of
synchronous (4) Each sentinel surveillance will be exchanged with other configuration of the master of Sentinel, configured to monitor each other
1.7, quorum and majority understand
Every time a sentry to do the switchover, first quorum required number of Sentinel think odown (objective downtime), and then elected to switch to do a sentinel, the sentinel sentry majority also need to be authorized in order to execute the formal handover.
If the quorum <majority, such as 5 sentinel, Majority is 3, quorum is set to 2, then the three sentinel can perform handover authorization.
However, if the quorum> = majority, you must have authorization quorum number of sentries, such as five Sentinel, quorum is 5, then you must have agreed to authorize five guards to perform switching
1.8, modify the configuration mode Sentinel
实现步骤:
1.拷贝到etc目录
cp sentinel.conf /usr/local/redis/etc
2.修改sentinel.conf配置文件
sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
sentinel auth-pass mymaster 123456
3. 修改心跳检测 5000毫秒
sentinel down-after-milliseconds mymaster 5000
4.sentinel parallel-syncs mymaster 2 --- 做多多少合格节点
5. 启动哨兵模式
./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
6. 停止哨兵模式
