持久化级别 redis提供如下四中持久化方案:
完全不持久化，纯内存操作。比如做缓存服务器时。
RDB持久化，配置时间间隔，异步持久化。默认的持久化方案。
AOF持久化，所有操作都是记录到日志文件，保证所有数据都被记录。 在redis重启时，会使用AOF重建数据集。
结合使用RDB和AOF的持久化方案.重启时会使用AOF重建。
RDB优缺点 优点:
结构紧凑的文件，相当与系统的实时快照，很适合做数据库备份和灾难恢复。
性能优秀，服务线程不需要处理i/o.
大数据集上重启很快。不需要重建
缺点:
间隔性同步到磁盘，导致有可能会丢失部分数据。
fork有可能堵塞导致暂不可用.
AOF优缺点 优点:
更加稳定，可以设置为 不同步/每秒同步/完全同步.
redis可以rewrite过大的AOF log.
保存了所有操作，可以从误操作中回复数据库。
缺点:
所需的文件通常比RDB更大
查询性能相对比RDB更差。
有很稀有的bug存在，RDB没有此类bug.
如何使用 如果想要更强的数据一致性，则应该组合使用AOF和RDB
如果可以容忍少量的数据丢失,可以只使用RDB.
不推荐只是AOF.
介绍一些redis部署时的注意事项
注意事项 建议使用linux部署。
sysctl vm.overcommit_memory=1 或者 vm.overcommit_memory = 1 (/etc/sysctl.conf)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
设置一个和内存一样大或更大的swap分区，不然redis有可能在内存不足时被系统杀死。
设置一个明确的maxmemory. 这样redis会在内存到限后抛出错误，而不会falling.
在写比较重的场景下需要有大约2倍于normal的内存。这些是来在内存中保留那些需要被写回磁盘的数据.
配置supervisor类工具时，设置 daemonize no
开启slave特性时，即便不使用持久化特性,redis也会perform RDB save. 除非使用实验性的diskless-sync.
开启slave特性时，要确保要么打开master节点的保存特性，要么关闭master节点的自动重启。
注意开发redis安全相关配置. require-pass/rewrite-command/bind-ip
aws注意事项 使用HWS实例，不要使用pv实例
不要使用太老的实例。 m3 good than m1
redis在EBS的持久话需要注意，EBS可能会太慢。
你可能想尝试diskless-sync. 如果replication-sync有问题的话。
redis升级或重启建议 TODO
原内容来自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