Redis

使用场景

Redis是一个内存数据库，常作为缓存使用。Redis小巧、轻快，但是也要注意Redis的应用场景。
因为Redis是一个内存数据库，所以如果存储处理不当，会占用大量内存，对系统性能有影响。

对存储的数据进行划分，可以从两个角度划分：1是数据量的大小；2是数据的冷热程度。
Redis 最适合处理的是小而热，而且是写频繁，或者读写都比较频繁的热数据。对于大而热的数据，
如果其它方式很难解决问题，也可以考虑使用 Redis 解决，但是一定要非常谨慎，防止数据无限膨胀。

Redis 提供不同的持久化方式：

RDB持久化方式，可以在指定间隔内生成快照。
AOF持久化方式，通过日志的方式记录Redis的每一次操作命令。当Redis启动时，重新执行一遍这些命令来恢复数据。当AOF文件过大时，后台进程会对AOF文件进行精简优化。
如果你的缓存不需要持久化，可以不开启Redis的持久化。
可以同时结合AOF和RDB两种持久化方式。需要注意的是，Redis启动后是按照AOF文件来进行重塑数据的。

最重要的事是我们需要理解RDB和AOF的区别：

RDB通过高度压缩精简的文件来重塑Redis数据。RDB文件非常适合于备份。例如，你希望在最近30天里每天生成一份快照，当发生灾难时可以轻松恢复到某一天的状态。这时候RDB是非常合适的。
由于RDB是单个压缩文件，所以有利于长距离数据传输。
RDB可以保持Redis性能的最大化。Redis父进程通过fork子进程来完成RDB文件的磁盘IO操作。父进程永远不会直接操作磁盘。
和AOF方式相比，当Redis数据量很大时，RDB方式能让Redis更快的完成重启。

如果你想让数据丢失最小化，RDB并不是很好的方式。通常每5分钟生成一份RDB快照，所以当Redis不正确的关闭时，最后一分钟对Redis的操作数据就有可能丢失。
RDB需要频繁地fork子进程来完成数据持久化到磁盘上。然而当数据集很大时，fork操作是非常耗时的，从而可能导致数毫秒甚至数秒内Redis定时对客户端提供服务。AOF也需要fork，但是你可以调整多久需要重写log并且不需要很大的消耗。

使用AOF的方式，Redis就可靠多了：你可以使用不同的同步策略：不同步、每秒同步、每次操作同步。默认使用每秒钟同步，这种策略仍然能保持较高的写性能。
AOF日志是一种只往尾部追加的日志，所以当异常退出时也不会存在问题。即使日志末尾只完成了一半的写入操作，redis-check-aof 工具仍能轻松地完成修复。
当AOF文件很大时，Redis可以自动地在后台对AOF文件进行重写。重写的过程是完全安全的，Redis继续对旧的文件进行追加，一个全新的临时AOF文件通过最小化命令集来构造当前Redis的数据集。当第二个文件准备好了，Redis进行切换，开始往新的AOF文件进行追加。
AOF方式把每一个Redis操作指令都易读的格式按顺序写入到文件中。你可以轻松生成AOF文件。例如，即使你不小心使用FLUSHALL命令清空了所有数据，你可以在AOF文件没有被重写时将最后的FLUSHALL命令删除，然后重启Redis来恢复数据。

通常的建议是，如果你想达到像PostgreSQL一样让数据安全可靠，你需要同时使用RDB和AOF方式。

如果你能忍受一段时间内数据丢失，你可以单独使用RDB。有很多用户只使用AOF方式，但是我们不鼓励，因为使用RDB快照是一个非常好的方式来完成备份、快速完成重启。