下面的使用方式没有绝对的那个好，要考虑实际情形(业务，成本，资源等)选择合适的方式。
Redis master
最简单的模式，有单点问题，只合适进行memcache的缓存使用；
建议：作为缓存，不要进行数据持久化，只做内存缓存使用。
Redis master - slave
一主一从：部分解决了数据丢失问题，不能支持主从切换，还是存在单点问题。
可以支持读写分离，提高读吞吐率，机器使用率。
具体使用方式：
1 打开数据持久化（建议appendonly方式）, 提供系统数据容灾能力；
2 关闭数据持久化，提供读写分离，业务场景不需要数据容灾性，性能好
一主多从：
相对1M-1S，可以提供海量读请求业务场景，替代多memcache提供读请求（使用redis自动主从同步功能）。
Redis keepalive
方式：keepalive+ haproxy + redis(M-S)
keepalive VIP 方式提供了业务不需要关注redis 的IP和port 变更问题。
系统做到无单点问题，基本上两种方式：
1 开发脚本监控redis master 运行状况，通知haproxy 更新来解决；
2 集成 sentinel 监控来实现（推荐方案）。
在集群部署，对运维要求高；
在集群扩容，需要运维和前端应用程序一起调整（比如基于1024维度进行业务hash分组）；
由于VIP方式，对短连请求业务合适，tcp长连业务有单点瓶颈。
标准部署方式：
系统基本无单点，可以自动扩容，运维部署要求高，业务使用方简单；
由于VIP方式，对短连请求业务合适，tcp长连业务有单点瓶颈。
Redis-Sentinel
Redis官方推荐的高可用性(HA)解决方案.
标准部署：
系统基本无单点，运维部署要求高，系统复杂度高。
集群扩容，业务使用方，运维都需要一起参与，比如redis分组在扩容的时。
由于直接访问redis（master，slave），性能最好；不管短连请求，tcp长连业务
都可以发挥到最佳性能，也没有VIP单台性能瓶颈问题。
Redis Cluster
(2).Redis提供一定程度的可用性,可以在某个节点宕机或者不可达的情况下继续处理命令.
(3).Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linearscalability）。
整体感觉下来，类似DHT，或者BT协议网络；无中心节点，自动发现，自动扩容，自动容灾等，很强大。
从架构思路上，是否可以驾驭，决定了是否要使用；目前了解到，大的互联网公司都在观望，我们也在观望。
Redis master
Redis（M-S）
Redis
Keepalive
Redis
Codis
Redis
Sentinel
数据安全
基本无
集群方式
不支持，需应用方解决
不支持，需应用方解决
不支持，应用方需知道分组策略
有集群提供；
应用方不关心
sentinel集群；应用方需知道分组策略
扩容方式
应用方参与解决
应用方参与解决
应用方参与解决
应用方不关心
应用方参与解决
运维复杂度
低
中
复杂
Dashboard，较复杂
复杂
系统单点
是
是
无
无
无
系统瓶颈
---
---
VIP 瓶颈
VIP 瓶颈
基本无
系统监控
无
无
脚本监控提供
需自己开发提供
需自己开发提供
适合业务场景
Memcache类似方式
读写分离场景，一写多读。
短连请求业务
短连请求业务
Tcp长短连都行。
