我的系统版本为CentOS7.5，redis版本5.0.4

首先单一的redis节点提供服务，如果节点故障或者数据丢失将造成很严重的后果。其次随着请求量和数据量的增加单一节点不能提供足够的服务能力，这时需要选择主从或者集群。主从模式可以实现读写分离比较适合读远大于写的应用。另外主从也解决了单一节点故障后的数据丢失等问题，主从复制中通过Sentinel 哨兵机制，当主节点宕机后，可以自动选举新的主节点，无需人为参与提供不间断的服务。但主从方式水平扩展能力有限，如果数据量或者请求量非常大就需要选择集群模式。redis-cluster是redis官方提供的集群解决方案，后续支持比较有保障。codis是豌豆荚团队开发的redis集群方案，目前站比较大的市场。

主从复制

安装：
http://www.redis.cn/topics/replication.html

特点：

1. 一个master可以拥有多个slave
2. 多个slave链接同一个master，也可以链接其它slave
3. 主从复制不会阻塞master,在同步数据时，master可以继续处理client请求
4. slave 配置为slave-read-only on需要升级为主节点或者写入配置文件中, 而不能在默认slave情况下直接设置master与slave断开后会检测心跳, 从新建立连接
5. 可以直接copy DUMP文件从新重启master，在Master为空以后，slave同步数据会抹掉全部数据

实现原理：
6. 从服务器首先同步主服务器的rdb文件实现初始化的同步

1. 从服务器获取主服务器执行过的命令在从服务器再次执行

优点：

1. 实现了数据的读写分离
2. 单一节点故障不会造成全部数据的丢失
3. 对客户端要求低，命令支持与单机一致

缺点：

1. 主服务器宕机后需要人工切换
2. 无法实现水平扩展，每个节点存储完全一致的数据，对整体存储容量没有提升
3. 无法实现写操作的性能提升

Sentinel 哨兵

安装：
http://www.redis.cn/topics/sentinel.html
Sentinel 哨兵是redis官方提供的方案，一般使用26379端口。可以实现redis主从中节点故障发现和转移，自动选举新的主节点，客户端首先连接sentinel 获取主从节点信息，根据信息再进行主从节点的请求操作。除了先请求Sentinel 外，其他操作与主从复制一样。

redis-cluster集群

安装：
http://www.redis.cn/topics/cluster-tutorial.html

特点：

1. Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法是CRC16后16384取模
2. Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移
3. Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作
4. 为了增加集群的可访问性，需要在一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务，Redis Cluster本身提供了故障转移容错的能力
5. Redis Cluster的nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node

优点：

1. 高性能
2. 官方支持
3. 支持动态扩容，对业务透明
4. 搭建简单

缺点：

1. 要求客户端必须支持cluster协议
2. client不能直接像单机一样使用pipeline
3. 相对于单机Redis，功能上有一些限制

（1）key批量操作支持有限

（2）只支持多key在同一节点上的事务操作，当多个key分布在不同节点时，不支持事务操作

（3）key作为数据分区的最小粒度，不能将一个大的键值对象如hash, list等映射到不同的节点

（4）不支持多数据空间

（5）复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构

Codis集群

安装：
https://github.com/CodisLabs/codis/blob/release3.2/doc/tutorial_zh.md

特点：

1. 豌豆荚开源的项目。最新版使用redis3.2.8。使用时在本需要连接redis的地方改为连接codis，它会以一个代理的身份接收请求 并使用一致性hash算法，将请求转接到具体redis，将结果再返回codis
2. codis需要比较多的组件支持。codis的dashboard用于通过web界面可视化的配置codis group和proxy，也可以查看各个节点的状态
3. codis的proxy代理节点，两个节点之间通过pipeline主从互备
4. ZooKeeper用于保存slot状态信息，也可以通过etcd存储这些状态信息，方便client请求的路由，也可以配置多台保证高可用
5. 在codis中需要将数据节点都放在codis group中进行管理，每个group至少保留一个节点，为了保证HA，每个group都配置了一个master一个slave节点，如果一个group中的master挂了，那么同一个group中的slave节点通过选举算法选出新的master节点，并通知到proxy，如果为了较好的高可用可以增加group的个数和每个group中slave节点的个数

优点：

1. codis支持动态水平扩展，对client完全透明不影响服务的情况下可以完成增减redis实例的操作
2. codis对client来说可以像对单机redis一样去操作proxy（除了一些命令不支持），还可以继续使用pipeline并且如果后台redis有多个的话速度会显著快于单redis的pipeline
3. 运维友好，有自带的GUI监控界面和管理工具

缺点：

1. 不支持 SUB/PUB 之类的指令，详见https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.md
2. 除项目组本身的教程外，其他相关资料较少