原内容来自redis官方文档: redis-replication官方文档
基本来说，只要在配置文件里加上
# slaveof <ip> <port> slaveof 127.0.0.1 6379 就可以完成配置.
如下配置可能有用
# 不使用磁盘同步 repl-diskless-sync # 同步前的延时, 以等待其他的要链接的slave repl-diskless-sync-delay 安全问题 如果redis开启复制特性，同时master节点关闭持久化特性。
这时应该避免master节点的自动重启，避免slave节点上的数据被重启的master节点清空。
同步策略 redis默认使用磁盘同步, 数据被存到RDB file文件, 之后通过同步该文件做full-sync.
但是如果磁盘太慢会导致性能不好，2.8新增直接通过socket来同步的方式.(该方式目前仍然是实验阶段)
只读复制 redis默认slave是只读的,所有写操作会报错. 通过如下方式可以打开读写
# 配置文件 slave-read-only noconfig # redis-cli运行时 set slave-read-only no 即便是只读slave也不应该暴露在公网下. debug/config等命令仍会带来完全问题(使用rename-command配置)
读写slave在较少场景下会有用。未来redis有可能移除该特性.
认证 redis很快，所以需要设置足够强的密码，不然会很容易被破解。
master节点可以通过配置，要求所有链接需要认证
requirepass <password> 这时slave节点需要做如下配置
# 运行时 config set masterauth <password> # 配置文件 masterauth <password> 部分同步 TODO
控制slave链接数 TODO
sentinel功能 监控集群中所有节点是否正常工作.
在任一节点fail, 可以通过api通知管理员或pramgram
自动故障转移， 如果一个master节点fail, 会自动把slaver节点提升为master节点.并通知client使用新的节点.
配置提供， client通过链接sentinel获取所有节点信息等。相当与是proxy的作用, 类似mogos
提供redis高可用性
sentinel分布式特性 sentinel天生具有分布式特性，sentinel被设计为使用多个sentinel进程协同合作。
这样做有以下好处:
由多台sential做fail判断, 减少误判。
避免sentinel单点故障。
快速试用 sentinel当前稳定版本是2, 在redis2.8/redis3.0上工作. 早先的sentinel 1 在redis2.6上工作，已被depressed.
sentinel使用更好的预测算法重写而成。
使用如下方式启动sentinel
redis-sentinel sentinel.conf redis-server sentinel.conf --sentinel sentinel默认使用 26379端口监听client和其他sentinel链接。确保打开这一端口。并正确设置防火墙.
sentinel部署须知 一个稳健的redis集群，应该使用至少三个sentinel实例，并且保证讲这些实例放到不同的机器上，甚至不同的物理区域。
sentinel无法保证强一致性, 大概分布式环境都会有这方面的权衡.
确保client库支持sentinel.
sentinel需要通过不断的测试和观察，才能保证高可用。
sentinel配合docker使用时，要注意端口映射带来的影响.
sentinel配置 实例如下
sentinel monitor mymaster 127.
介绍redis分片相关内容.
分片相关 分片是将数据分布到不同的redis实例上, 让每个redis服务实例只保存部分数据。
为何需要分片 突破单机的内存和磁盘存储限制.
复用多机的cpu计算和网络传输能力。
分片方法 分片有不同的实现方式, 如
范围分片, R0(1-10000), R1(10001-2000)… 缺点: 需要记录键的对应情况，所以比较低效, redis中不建议这种方式.
hash分片. 对每个key通过hash函数，计算到对应的实例。 redis中部分client和proxy实现了一致性hash来做分片处理。
分片实现层面 分片可以做不同层面实现.
客户端, 直接在客户端选择正确的实例完成操作。部分redis-client库实现这一功能.
proxy, 类似mogos. 客户端链接到proxy, 由proxy代为转发到正确的redis实例上. 比如twemproxy::
https://github.com/twitter/twemproxy
查询路由. 查询被发到集群中任一台实例上, 由实例来转发到正确的实例上. redis集群实现了一个混合风格的查询路由，需要配合client端使用(不是由redis来做定位，而是重定向client来实现).
分片的缺点 跨越多个key的操作通常都不能使用, 部分操作可以通过间接的方式实现.
跨越多个key的事务无法被支持.
XXX 以key的粒度来做分片，所以无法通过很多的key来共享一个大数据集，比如一个很大的sortedSet.
使用分片会让业务逻辑更加复杂，包括运维工作。
增加和删除节点/容量比较麻烦，是要平衡重新分片。redis集群支持这一个特性。 client/proxy实现需要通过Pre-sharding来支持。
数据库还是缓存 redis作为缓存和数据库时，对待分片的策略有所不同.