单机Redis的读写速度非常快，能够支持大量用户的访问。虽然Redis的性能很高，但是对于大型网站来 说，每秒需要获取的数据远远超过单台redis服务所能承受的压力，所以我们迫切需要一种方案能够解决 单台Redis服务性能不足的问题。这就需要使用到Redis的集群了。Redis集群有多种方案，下面分别进 行讲解
2.1 主从复制Replication
redis支持主从复制的模式。 在主从复制模式下Redis节点分为两种角色：主节点(也称为master)和从节点(也称为slave)。这种模式 集群是由一个主节点和多个从节点构成。
原则：Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来 同步数据。
这是一个典型的分布式读写分离模型。我们可以利用master来处理写操作，slave提供读操作。这样可 以有效减少单个机器的并发访问数量。
要实现主从复制这种模式非常简单，主节点不用做任何修改，直接启动服务即可。从节点需要修改 redis.conf配置文件，加入配置：slaveof <主节点ip地址> <主节点端口号>，例如master的ip地址为 192.168.200.129，端口号为6379，那么slave只需要在redis.conf文件中配置slaveof 192.168.200.129 6379即可。
分别连接主节点和从节点，测试发现主节点的写操作，从节点立刻就能看到相同的数据。但是在从节点 进行写操作，提示 READONLY You can’t write against a read only slave 不能写数据到从节 点。
现在我们就可以通过这种方式配置多个从节点进行读操作，主节点进行写操作，实现读写分离。
2
3
4
5
2特点： master节点可以写数据，slave不可以写数据，只可以读取数据
3 从节点会自动从主节点拉取数据
4
5
2.2 哨兵sentinel
我们现在已经给Redis实现了主从复制，可将主节点数据同步给从节点，实现了读写分离，提高Redis的 性能。但是现在还存在一个问题，就是在主从复制这种模式下只有一个主节点，一旦主节点宕机，就无 法再进行写操作了。也就是说主从复制这种模式没有实现高可用。那么什么是高可用呢？如何实现高可 用呢？
2.2.1 高可用介绍
高可用(HA)是分布式系统架构设计中必须考虑的因素之一，它是通过架构设计减少系统不能提供服务的 时间。保证高可用通常遵循下面几点：
- 单点是系统高可用的大敌，应该尽量在系统设计的过程中避免单点。
- 通过架构设计而保证系统高可用的，其核心准则是：冗余。
- 实现自动故障转移。
sentinel(哨兵)是用于监控redis集群中Master状态的工具，其本身也是一个独立运行的进程，是Redis 的高可用解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。 sentinel可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master 服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请 求，并且其余从节点开始从新的主节点复制数据。
在redis安装完成后，会有一个redis-sentinel的文件，这就是启动sentinel的脚本文件，同时还有一个 sentinel.conf文件，这个是sentinel的配置文件。 sentinel工作模式：
Redis 集群是采用一种叫做 哈希槽 (hash slot) 的方式来分配数据的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用 CRC16 算法来取模得到所属的 slot ，然后将这个key 分到 哈希槽区间的节点上，具体算法就是： CRC16(key) % 16384
假设现在有3个节点已经组成了集群，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口， 也可以是三台不同的服务器。那么，采用 哈希槽 (hash slot) 的方式来分配16384个slot 的话，它们 三个节点分别承担的slot 区间是：
