注：转载请注明出处o(^▽^)o

    Redis就不多介了，博客中有更多Redis教程。

    本文会总结Redis的整个配置，并附上示例。

概述

    Redis可以在没有配置文件的情况下通过内置的配置来启动，但是这种启动方式只适用于开发和测试。 合理的配置Redis的方式是提供一个Redis配置文件，这个文件通常叫做 redis.conf。 redis.conf文件中包含了很多格式简单的指令如下：

   keyword argument1 argument2 ... argumentN
 

 

 

  
  

    如果参数中有空格，机上“"”双引号即可。

配置方式

    Redis支持多种配置方式。

1、通过命令行参数配置

    这种方式既是在启动服务时将配置命令以参数形式传入：

   ./redis-server --port 6380 --slaveof 127.0.0.1 6379
 

 

 

  
  

    这里配置一个新运行并以 6380 为端口的Redis实例，使配置它为 127.0.0.1:6379 Redis实例的slave。

    通过命令行传递的配置参数的格式和在redis.conf中设置的配置参数的格式完全一样， 唯一不同的是需要在关键字之前加上 前缀--。

    需要注意的是通过命令行传递参数的过程会在内存中生成一个临时的配置文件(也许会直接追加在命令指定的配置文件后面)，这些传递的参数也会转化为跟Redis配置文件一样的形式。

2、运行时配置更改

    Redis允许在运行的过程中，在不重启服务器的情况下更改服务器配置，同时也支持 使用特殊的 CONFIG SET 和 CONFIG GET 命令用编程方式查询并设置配置。

    并非所有的配置指令都支持这种使用方式，但是大部分是支持的。

    更多相关的信息请查阅博客中配置命令相关文章。

    需要确保的是在通过CONFIG SET命令进行的设置的同时，也需在redis.conf文件中进行了相应的更改。

    Redis2.8开始提供一个CONFIG REWRITE命令在不更改现有配置文件的同时， 根据当下的服务器配置对redis.conf文件进行重写。

配置详解

    需要注意的是，为了读取配置文件，Redis的必须与作为第一个参数的文件路径开始(路径以配置文件实际路径位置，下面采用默认路径)：

   ＃./redis-server ../redis.conf
 

 

 

  
  

    配置内存时请注意单位：

    1k => 1000 bytes

    1kb => 1024 bytes

    1m => 1000000 bytes

    1mb => 1024*1024 bytes

    1g => 1000000000 bytes

    1gb => 1024*1024*1024 bytes

    不区分大小写。

    Include one or more other config files here.  This is useful if you have a standard template that goes to all Redis servers but also need to customize a few per-server settings.  Include files can include other files, so use this wisely.

   Notice option "include" won't be rewritten by command "CONFIG REWRITE" from admin or Redis Sentinel. Since Redis always uses the last processed line as value of a configuration directive, you'd better put includes at the beginning of this file to avoid overwriting config change at runtime.

    If instead you are interested in using includes to override configuration options, it is better to use include as the last line.

    #include /path/to/local.conf

    #include /path/to/other.conf

    下面的配置示例，若写在描述前表示默认配置，否则为无默认配置或其他情况。

1、通用配置

    配置Redis一些最基本的属性。

   （1）后台程序

    daemonize no

    配置Redis是否作为后台程序运行，如果需要，配置为”yes“即可（当运行多个 redis 服务时，需要指定不同的 pid 文件和端口）。

    （2）pid文件

    pidfile /var/run/redis.pid

    当以后台程序运行的时候，Redis在/var/run/redis.pid默认写入一个pid文件。可以在这里指定自定义pid文件的位置。

    （3）TCP端口

    port 6379

   接受指定端口上的连接，默认为6379.端口指定为0的Redis不会监听TCP套接字。

    （4）tcp-backlog

    tcp-backlog 511

    此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度， 当然此值必须不大于Linux系统定义的/proc/sys/net/core/somaxconn值，默认是511，而Linux的默认参数值是128。当系统并发量大并且客户端速度缓慢的时候，可以将这二个参数一起参考设定。

    （5）指定可接收请求的IP地址

    bind [ip...]

    默认的Redis监听来自所有的服务器上可用的网络接口的连接，可以设置一个或多个IP地址：

   bind 192.168.1.100 10.0.0.1
  
 
  
 
  
 
   
   bind 127.0.0.1
 

 

 

  
  

    （6） Unix套接字监听

    应该是用于进程间通信的，此处没有深究。

    指定将用于侦听传入连接的Unix套接字的路径。没有默认，所以没有指定时Redis不会监听Unix套接字。

    配置：

   unixsocket /tmp/redis.sock
  
 
  
 
  
 
   
   unixsocketperm 700
 

 

 

  
  

    （7）客户端连接超时

    timeout 0

    客户端和Redis服务端的连接超时时间，单位为秒。默认是0，表示永不超时。

    （8）客户端连接检测

    tcp-keepalive 0

    如果值非0，单位是秒，表示将周期性的使用SO_KEEPALIVE检测客户端是否还处于健康状态，避免服务器一直阻塞，官方给出的建议值是60S。

    两个原因：

•     检测死同行。
•     取出可用的连接。

    在Linux上，指定的值（以秒为单位）是用于发送ACK的时期。请注意，关闭连接需要两倍的时间。在其它内核的周期取决于内核配置。

    （9）日志记录等级

    loglevel notice

    共有4个等级：

•     Debug：记录很多信息，用于开发和测试
•     Varbose：有用的信息，不像debug会记录那么多
•     Notice：普通的verbose，常用于生产环境
•     Warning：只有非常重要或者严重的信息会记录到日志

    （10）日志目录

    # logfile ""

    logfile stdout

    配置 log 文件地址,默认打印在命令行终端的窗口上，也可设为/dev/null屏蔽日志。

    另外，空字符串可以用来强制Redis使用标准输出。请注意，如果您使用标准输出但Redis以后台运行，日志将被发送到/dev/null。

     （11）记录到系统日志

    syslog-enabled no

    可以将日志记录到系统日志，将值设置为yes即可。

     （12）指定系统日志身份

    如下设置：

   syslog-ident redis
 

 

 

  
  

    （13）指定系统日志设备

    必须为USER或LOCAL0-LOCAL7中的一个值：

   syslog-facility local0
 

 

 

  
  

    （14）设置数据库数量

    databases 16

    默认为16个（015），默认使用DB 0，可以通过SELECT [0数据库数量-1]来选择要使用的数据库。

2、数据持久化 RDB

    RDB 的优点:

    RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

    RDB 的缺点:

    如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

    将数据库快照保存到磁盘。

    （1）保存策略

    save <时间> <改变的数量>

    比如save 300 10，表示300s后至少有10个key发生改变就触发持久化事件，可以配置多个策略。

    注释掉所有save即可禁用持久化功能。

    可以通过如下配置（空字符串）删除所有之前配置的保存点：

   save ""
 

 

 

  
  

    （2）持久化出错

    stop-writes-on-bgsave-error no

    当持久化出现错误之后，是否继续提供写服务，若需继续提供，配置为yes即可。

    默认的Redis将停止接受写入如果RDB快照启用了（至少有一个保存点）并且最近的后台保存失败。这会使用户指定数据没有正确的保存到硬盘上，否则，没人会注意到这些问题，就会出现更大的问题！

    （3）持久化时是否压缩

    rdbcompression yes

    是否使用LZF压缩字符串对象，默认为yes（综合考虑yes更佳），即压缩后保存。

    如果想节约一点点cpu资源，可设置为no，但会占用更大的存储空间。

    （4）支持CRC64校验

    rdbchecksum yes

    读取和写入的时候是否支持CRC64校验，默认是开启的。这会一定程度上影响性能，但是可以关闭它。

    （5）持久化文件名

    dbfilename dump.rdb

    （6）持久化文件存放路径

    dir ./

    只能配置为目录（而不是文件）。

3、主从配置

    Redis能很好的支持和配置数据库主从复制。

    使用 slaveof，使Redis实例称为另一个Redis服务器的副本。

    需要知晓几点：

•     主从复制是异步的
•     支持部分同步
•     连接断开会自动重连

    （1）配置从服务

    slaveof

    参数为主服务器的ip和端口

    （2）密码验证

    masterauth

    如果主服务器设置了密码验证，需要在开始复制前进行身份验证，否则主服务器会拒绝连接请求。

    （3）主从连接断开处理

    slave-serve-stale-data yes

    当slave丢失与master的连接时，或slave仍然在于master进行数据同步时（未与master保持一致）slave可有两种方式来响应客户端请求：

•     如果 slave-serve-stale-data 设置成 'yes'(默认)，slave仍会响应客户端请求,此时可能会有问题
•     如果 slave-serve-stale-data 设置成 'no'，slave会返回"SYNC with master in progress"错误信息，但 INFO 和SLAVEOF命令除外。

    （4）从服务器是否只读

    slave-read-only yes

    你可以配置一个从实例接受写入与否。写对一个从实例可能是存储一些临时数据（因为写在从属数据将与主机同步后容易删除）有用的，但也可能导致如果客户因为错误配置的写入它的问题。

    Redis的2.6开始，默认的从服务器是只读的。

    注：只读slave没有设计被暴露在不受信任的客户在互联网上。这只是对实例的误操作的保护层。还是只读从动出口在默认情况下所有的行政指令，如CONFIG，调试等等。要在有限的范围内，可以使用“rename-command”暗影所有行政/危险命令提高只读奴隶的安全性。

    （5）同步策略

    repl-diskless-sync no

    新的slave和重新连接的slave是不能继续接收差异复制，需要做“完全同步”。 RDB文件是主到从的传送。发送可以以两种不同的方式发生：

•     磁盘备份（默认）：Redis的主服务器创建一个新的进程，在磁盘上写入文件RDB。然后由父进程以增量的方式传输到slave。
•     无盘：Redis的主创建一个新的进程，直接写入RDB文件到slave的socket。不经过硬盘盒主进程。

    基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的slave。基于socket的话， 新slave来了后，得排队（如果超出了repl-diskless-sync-delay还没来），完事儿一个再进行下一个。

    当用diskless的时候，master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了。否则就可以一起传。

    由于现在带宽已经很大了，对于缓慢的硬盘，无盘备份效果会更好。

    （6）无盘同步延迟时间

    repl-diskless-sync-delay 5

    单位为秒，设为0时可以禁用，传输会马上的开始。

    （7）slave ping设置

    repl-ping-slave-period 10

    Slave发送ping给master。默认10s。

    （8）复制超时设置

    repl-timeout 60

    超时时间，包括从master看slave，从slave看master，要大于上边的repl-ping-slave-period。

    （9）同步完毕后是否关闭TCP_NODELAY

    repl-disable-tcp-nodelay no

    SYNC完毕后，在slave的socket里关闭TCP_NODELAY。

    如果是yes,reids发送少量的TCP包给slave，但可能导致最高40ms的数据延迟。

    如果是no，那可能在复制的时候，会消耗 少量带宽。

    默认为了低延迟优化而设置成no，如果主从之间有很多网络跳跃。就设置成yes。

    （10）设置backlog的大小

    repl-backlog-size 1mb

    复制集后台backlog大小。

    越大，slave可以丢失的时间就越长。

    （11）backlog释放时间设置

    repl-backlog-ttl 3600

    从最后一个slave断开连接后，多久释放backlog，当确认master不再需要slave的时候，多久释放。0是永远不释放。

    （12）次主服务器配置

    slave-priority 100

    当master不可用，Sentinel会根据slave的优先级选举一个master。最低的优先级的slave，当选master。而配置成0，永远不会被选举（必须≥0）。默认是100。

    （13）slave在线数及延迟设置

    min-slaves-to-write 0

    min-slaves-max-lag 10

    slave小于几个，网络lag（延迟）大于几秒的时候，master停止接受write请求。为0时表示禁用功能。所以默认为不限制slave数量，网络延迟设置为10s。

4、安全配置

    （1）设置密码

    多数情况下无需密码鉴别slave。同时，由于redis处理速度太快，所以爆破速率可达150K/S。所以如果你要设置密码，必须设置超强的密码:

   requirepass password
 

 

 

  
  

    （2）命令重命名

    可以对一些对于安全比较重要的命令重命名，比如CONFIG：

   rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
 

 

 

  
  

    这样，只有内部知道命令该如何使用，当然，也可以使用如下方式完全屏蔽一个命令：

   rename-command CONFIG ""
 

 

 

  
  

    记录进AOF或者传给slave的重命名操作可能会引发问题！

5、限制相关配置

    （1）客户端数量

    maxclients 10000

    设置最大client连接数。默认10000个。如果redis没法控制最大文件数，则给到最低32。

    如果达到了限制，Redis会返回一个错误：客户端数量已经达到最大了。

    （2）最大内存设置

    maxmemory [bytes]

    不要超过指定的字节数量使用更多的内存。当达到内存限制的Redis将尝试根据所选的驱逐策略删除key。

    如果配置成了noeviction。所有write都会拒绝，比如set，lpush等。所有读请求可以接受。

    主要用在把redis作为LRU缓存时，或者用在一个内存吃紧又不能删除的策略上。

    如果你有slave，你应该把最大内存别设置的太大，留一些内存给slave output buffers（如果是noeviction策略，就无需这样设置了）。

    （3）内存策略配置

    maxmemory-policy noeviction

    volatile-lru ->用LRU删除设置了ttl的key

    allkeys-lru ->用LRU删除任何key

    volatile-random ->随机删除有ttl的key

    allkeys-random ->随机删除任何key

    volatile-ttl ->删除即将ttl到期的key

    noeviction ->不删，有write的时候报错

    这些操作会返回错误： set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort

    （4）删除设置

    maxmemory-samples 5

    LRU和最小TTL并不是最精确的，但是也差不多。默认redis每次取5个key然后取最符合删除策略的删除。可以配置这个数，越低，删除的东西就会越多，删除也越快。比如设置100个，就能删百分之一，但是较慢，会占用更多cpu资源。

6、数据持久化 AOF（APPEND ONLY MODE：追加模式）

    AOF 的优点:

    使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。 Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

    AOF 的缺点:

    对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

    （1）是否启用AOF

    appendonly no

    默认情况下Redis异步转储磁盘上的数据集。这种模式很多时候都是挺好的，但如果Redis运行出现问题或停电可能造成几分钟的写入丢失（根据配置的保存点）。

    AOF提供更好模式。比如用默认的AOF，redis只丢失最近一秒的数据（断电情况），或者最后一个write操作（redis自身错误，os正常）。每个write操作写一次AOF。

    当AOF文件太大了，redis会自动重写一个AOF文件出来。

    AOF和RDB可以同时启用，没有任何冲突。AOF会优先被用来恢复数据。

    更多信息可以访问：http://redis.io/topics/persistence

    开启AOF：

   appendonly yes
 

 

 

  
  

    （2）AOF文件名

    appendfilename "appendonly.aof"

    此为默认的文件名，当然也可以自定义。

    （3）fsync模式

    appendfsync everysec

    有三种：

    no：让OS托管，这样更快，但是如果出现问题，可能会丢失更多的数据。

    always：每次write都刷到log，慢，但是对数据来说最安全。

    everysec：每秒一次flush（默认），这是一种折衷的做法，使速度和数据安全之间取得适当的平衡。

    （4）AOF设置

    no-appendfsync-on-rewrite no

    当fsync为always或者everysec时，一个bgsave或者AOF rewrite线程正在耗费大量I/0，redis可能会在fsync上阻塞很久。发生之后就无法fix，即使是另一个线程跑fsync，也会阻塞我们同步的write方法。

    如下方法可以解决这个问题：当bgsave()或bgrewriteaof()在跑，主进程的fsync()就无法调用。也就是当子进程在save，那段时间相当于redis是appendaof no的。也就是有可能会丢失最多30s的log。

    所以如果你有lag问题，把下边改成yes，否则就用no。yes意思是暂停aof，拒绝主进程的这次fsync。no是redis是排队的，不会被prevent了，但主进程是阻塞的。

    （5）自动重写AOF

    auto-aof-rewrite-percentage 100

    auto-aof-rewrite-min-size 64mb

    当AOF文件大小到一定比例，就自动隐式调用BGREWRITEAOF。

    过程：redis记住最后一次rewrite时aof文件大小（重启后没rewrite的话，就是启动时AOF文件的大小），如果现在AOF大小和上次的比例达到特定值就重写。也要指定最小AOF大小。

    百分比（percentage）设置为0时，禁用自动重写功能。

    （6）容错

    aof-load-truncated yes

    AOF文件可能在尾部是不完整的（上次system关闭有问题，尤其是mount ext4文件系统时没有加上data=ordered选项。只会发生在os死时，redis自己死不会不完整）。那redis重启时load进内存的时候就有问题了。

    发生的时候，可以选择redis启动报错，或者load尽量多正常的数据。

    如果aof-load-truncated是yes，会自动发布一个log给客户端然后load（默认）。

    如果是no，用户必须手动redis-check-aof修复AOF文件才可以。

7、LUA 脚本

    （1）执行时间

    lua-time-limit 5000

    以毫秒为单位的最大脚本执行时间。

    如果打到了这个值，脚本还没执行完Redis会记录并返回错误。

    当一个脚本超过了最大时限时只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。第一个可以杀没有调write命令的东西。要是已经调用了write，就只能用第二个命令杀。

    设置为0时执行时间无限制。

8、集群（REDIS CLUSTER）

    此处暂不介绍（暂时用不上）。

9、慢日志（SLOW LOG）

    Redis的慢日志是一个记录超过规定的执行时间查询的系统。执行时间不包括I/O操作，如与客户端通信，回复等，只是实际执行该命令所需要的时间。

    （1）时间

    slowlog-log-slower-than 10000

    线程阻塞不能服务其他请求的时间长度，以微秒计时，1s=1000*1000微秒。设置为负值时禁用慢日志，设置为0是记录所有请求。

    （2）长度

    slowlog-max-len 128

    长度没有限制，但是会消耗内存。可以通过SLOWLOG RESET回收旧日志的内存。

10、延迟监控

    （1）延时监控

    latency-monitor-threshold 0

    收集运行时不同命令的耗时，可以通过LATENCY命令打印这些图表。计时单位为毫秒，系统只记录比latency-monitor-threshold值大的记录。如果配置为0表示关闭监控（默认）。

    也可以通过命令“CONFIG SET latency-monitor-threshold ”来动态开始此功能。

11、事件通知

    （1）事件通知

    notify-keyspace-events ""

    可以通知pub/sub（发布/订阅）客户端关于key空间的变化。比如：如果开着开关，一个client在db0上key=“foo”上进行了DEL操作，两个消息将会通过 pub/sub 发布

    PUBLISH __keyspace@0__:foo del

    PUBLISH __keyevent@0__:del foo

    每一种通知由一个字母表示：

•     K     Keyspace events, published with __keyspace@__ prefix.
•     E     Keyevent events, published with __keyevent@__ prefix.
•     g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
•     $     String commands
•     l     List commands
•     s     Set commands
•     h     Hash commands
•     z     Sorted set commands
•     x     Expired events (events generated every time a key expires)
•     e     Evicted events (events generated when a key is evicted for maxmemory)
•     A     Alias for g$lshzxe, so that the "AKE" string means all the events.

    参数由以上字母组成，若配置为空字符串，表示不开启此功能。

    例如，可能会如下配置：

   notify-keyspace-events Ex
 

 

 

  
  

    大部分人不需要这个功能，并且还需要一定开销，所以默认关闭。详情见：http://redis.io/topics/notifications

12、高级配置

    暂不介绍〒_〒，主要是抽不出那么多时间。。。后期再补。

更多

1、RDB 和 AOF间的选择

    一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免AOF 程序的 bug 。 如上篇中所述，RDB与AOF可以同时启用，那么就做到了“数据高同步不丢失”的效果，可是你会应此付出高昂的网络IO开销，因为在使用AOF进行数据同步时造成的网络读写也是开销很大的。 因此这就要看你的设计了，一般来说一个设计不能够因为缓冲服务宕了或者不可用了而影响到整个应用不能使用，如果设计成这样那么这样的架构是比较糟糕的。