# Redis可靠性（持久化、主从同步、sentinel、集群）
在实际使用redis时，我们需要考虑redis的可靠性。 一个是服务可靠性一个是数据可靠性。 比如如果redis机器故障，如何快速恢复、如何避免数据丢失，请求量数据量时，如何进行横向扩容？
这些redis官方以及开源社区都给出了很多解决方案。
# redis持久化
我们都知道redis是内存数据库，它的数据存放在内存中，处理请求也是直接读写内存。 那么如果机器重启或者进程被oom kill，redis重启后内存中的数据丢失了怎么办？
别担心，redis提供了内存数据持久化的机制，能够将内存中的数据「及时」保存到磁盘中。
redis提供了几种持久化选项
- RDB(Redis Database): redis定期保存内存数据快照到磁盘中
- AOF(Append Only File): AOF会把每次的修改操作保存到log文件中，重启时可以用类似mysql的binlog。
- 不持久化：不开启
- RDB + AOF: 同时开启AOF和RDB
RDB的实现方式是定期fork redis进程，利用copy-on-write的机制，在子进程中把数据保存到磁盘中，缺点是因为是定期执行，可能会丢失一部分数据。 AOF会把修改操作保存到write buffer中，然后可以配置每次修改都fsync（不建议）或定期（比如一秒一次，推荐）fsync刷新到磁盘（还可以配置不fsync，利用linux自己的同步机制flush数据)，这样对于redis主线程保存log很快，fsync会在后台线程执行。 这样redis极端情况也只会丢失最近没有fsync到磁盘的修改操作。
当AOF文件过大时，redis会对它进行压缩，这样能够减小文件大小、提高重启时的启动速度。 比如连续对一个key incr调用100次，会产生100个修改日志数据，但是其实只需要保存最后的key的结果就可以了。
# redis主从同步
redis replication即redis复制是一种数据同步机制，类似于mysql的主从同步。 通过将数据在不同机器间同步，能够在master节点故障（比如出现不可恢复的机器故障）时切换到从节点对外提供服务， 也可以使用从节点处理读请求提升总体的读能力。
实现机制为
- replica会连接到master, master持续向replica发送修改日志数据
- 连接因为网络等原因断开时，replica会重连
# 更多参考
← hyperloglog redis概述 →