A, Sentinel Sentinel:
Redis Sentinel is a high-availability solutions:
Sentinel Sentinel system consists of one or more instances of the master can monitor any number of servers, and all those under the master server from the server, and when the primary server is monitored to enter the offline state, the master server automatically offline genus an upgrade from the primary server to the new server under.
server1 dropped
server2 upgrade the main server.
Note: After server1 reply nor will become the primary server. Asked the specific configuration of your mother.
advantage:
1, Redis Sentinel simple cluster deployment
2, can solve Redis master mode is switched from the high-availability problems
3, it is easy to achieve linear expansion Redis data node, easily break Redis own single-threaded bottleneck, can greatly meet business needs for large-capacity or high-performance Redis.
4, may be implemented to monitor a set of a Sentinel Redis data nodes or groups of nodes data
Disadvantages:
1, the waste of resources, Redis data node slave node as the backup node does not provide services
2, Redis Sentinel mainly for high availability of the master node Redis switching data node, a node of the Redis data offline to do failure determination of subjective and objective offline into two kinds, for Redis node from the node has to make the subjective line operation, does not perform failover.
3, separate read and write can not solve the problem, is relatively complex to implement
Two, Redis Cluster Community Edition is launched Redis distributed cluster solutions.
The main aspects of addressing the needs of distributed Redis, for example, when faced with a stand-alone memory, concurrency and flow bottlenecks, Redis Cluster can play a good load balancing purposes. Redis Cluster minimum configuration of the node cluster node 6 or more (the third main 3), wherein the master node provides read and write operations, the node as a backup node, the request is not available, use only as a failover. Redis Cluster virtual partition grooves, all keys are mapped to an integer of from 0 to 16,383 slot hash function, each node is responsible for maintaining a portion of the key groove and the groove data printed map.
advantage:
1, no center architecture
2, according to the data slot is stored in a plurality of distributed nodes, inter-node data sharing, data distribution can be dynamically adjusted.
3、可扩展性，可线性扩展到1000多个节点，节点可动态添加或删除。
4、高可用性，部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。
5、降低运维成本，提高系统的扩展性和可用性。
缺点：
1、Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
2、节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。
3、数据通过异步复制,不保证数据的强一致性。
4、多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
5、Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。
6、key批量操作限制，如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。
7、key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个key分布于不同的节点上时无法使用事务功能。
8、key作为数据分区的最小粒度，因此不能将一个很大的键值对象如hash、list等映射到不同的节点。
9、不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。
10、复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
11、避免产生hot-key，导致主库节点成为系统的短板。
12、避免产生big-key，导致网卡撑爆、慢查询等。
13、重试时间应该大于cluster-node-time时间
14、Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。