redis默认配置文件解释

daemonize yes                             开启守护进程模式

pidfile "/var/run/redis_6399.pid"         指定pid文件

port 6399                                 指定端口

tcp-backlog 511                           TCP 监听的最大容纳数量
                                          在高并发的环境下，你需要把这个值调高以避免客户端连接缓慢的问题。
                                          Linux 内核会一声不响的把这个值缩小成 /proc/sys/net/core/somaxconn 对应的值，
                                          所以你要修改这两个值才能达到你的预期。
                       
timeout 0                                 指定在一个 client 空闲多少秒之后关闭连接（0 就是不管它）

tcp-keepalive 0                           如果设置为非零，则在与客户端缺乏通讯的时候使用 SO_KEEPALIVE 发送 tcp acks 给客户端。

loglevel notice                           定义日志级别

logfile ""                                指定日志文件的位置

databases 16                              设置数据库的数目。
                                          默认数据库是 DB 0，你可以在每个连接上使用 select <dbid> 命令选择一个不同的数据库，
                                          但是 dbid 必须是一个介于 0 到 databasees - 1 之间的值


save 900 1           
save 300 10
save 60 10000                             存 DB 到磁盘
                                          根据给定的时间间隔和写入次数将数据保存到磁盘
                                          下面的例子的意思是：
                                          900 秒内如果至少有 1 个 key 的值变化，则保存
                                          300 秒内如果至少有 10 个 key 的值变化，则保存
                                          60 秒内如果至少有 10000 个 key 的值变化，则保存
                                          注意：你可以注释掉所有的 save 行来停用保存功能。
                                          也可以直接一个空字符串来实现停用：
                                          save ""
                                                                                  
stop-writes-on-bgsave-error yes           默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，
                                          这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，
                                          否则就会没人注意到灾难的发生。
                                          如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。
                                          然而你要是安装了靠谱的监控，你可能不希望 redis 这样做，那你就改成 no 好了。
                                          
rdbcompression yes                        是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串
                                          默认都设为 yes
                                          如果你希望保存子进程节省点 cpu ，你就设置它为 no ，不过这个数据集可能就会比较大
                                          
rdbchecksum yes                           是否校验rdb文件

dbfilename "p2p_6399.rdb"                 持久化的写入文件

dir "/mapbar/app/redis-2.8.23/data"       持久化文件所在的目录

slave-serve-stale-data yes                当 slaves 和 master 失去联系或者 复制数据工作仍然在进行。这个适合slave 会有两种选择
                                          当配置 yes(默认的) 意味着slave 会反馈 客户端的请求

slave-read-only yes                       当配置yes(默认)的时候，意味着客户端没法给slave 节点写入数据，一写就会报错" READONLY You can't write against a read only slave ."
                                          当配置成 no 的时候，任何客户端都可以写入                  

repl-diskless-sync no                     无硬盘复制功能(关闭)
 
repl-diskless-sync-delay 5                无磁盘diskless方式在进行数据传递之前会有一个时间的延迟，以便slave端能够进行到待传送的目标队列中，这个时间默认是5秒

repl-disable-tcp-nodelay no               在slave和master同步后（发送psync/sync），后续的同步是否设置成TCP_NODELAY
                                          假如设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟（40ms），造成master与slave数据不一致
                                          假如设置成no，则redis master会立即发送同步数据，没有延迟
                                          前者关注性能，后者关注一致性

slave-priority 100                        适用Sentinel模块(unstable,M-S集群管理和监控),需要额外的配置文件支持。slave的权重值,默认100.
                                          当master失效后,Sentinel将会从slave列表中找到权重值最低(>0)的slave,并提升为master。
                                          如果权重值为0,表示此slave为"观察者",不参与master选举         

maxmemory 2gb                             redis的maxmemory参数用于控制redis可使用的最大内存容量。
                                          如果超过maxmemory的值，就会动用淘汰策略来处理expaire字典中的键。
                                          关于maxmemory的设置，如果redis的应用场景是作为db使用，那不要设置这个选项，因为db是不能容忍丢失数据的。
                                          该选项是告诉Redis当使用了多少物理内存后就开始拒绝后续的写入请求,
                                          该参数能很好的保护好你的Redis不会因为使用了过多的物理内存而导致swap,最终严重影响性能甚至崩溃。
                                          
                                          
appendonly no                             默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁。
                                          所以redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。
                                          开启append only 模式之后，redis 会把所接收到的每一次写操作请求都追加到appendonly.aof 文件中，当redis 重新启动时，会从该文件恢复出之前的状态。
                                          但是这样会造成appendonly.aof 文件过大，所以redis 还支持了BGREWRITEAOF 指令，对appendonly.aof 进行重新整理。如果不经常进行数据迁移操作，
                                          推荐生产环境下的做法为关闭镜像，开启appendonly.aof，同时可以选择在访问较少的时间每天对appendonly.aof 进行重写一次。
                                          另外，对master机器,主要负责写，建议使用AOF,对于slave,主要负责读，挑选出1-2台开启AOF，其余的建议关闭            

appendfilename "appendonly.aof"           指定aof文件的文件名称

appendfsync everysec                      指定更新日志条件，共有3个可选值：
                                          no：表示等操作系统进行数据缓存同步到磁盘（快）
                                          always：表示每次更新操作后将数据写到磁盘（安全）
                                          everysec：表示每秒同步一次（折中，默认值）

no-appendfsync-on-rewrite no              
                                          现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，
                                          而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，
                                          现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。
                                          如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，
                                          因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。
                                          丢失多少数据呢？在Linux的操作系统的默认设置下，最多会丢失30s的数据。
                                          因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

auto-aof-rewrite-percentage 100           当Aof log增长超过指定比例时，重写log file， 设置为0表示不自动重写Aof 日志，重写是为了使aof体积保持最小，而确保保存最完整的数据。
                                          （比例为auto-aof-rewrite-min-size）

auto-aof-rewrite-min-size 64mb            触发aof rewrite的最小文件尺寸

aof-load-truncated yes                    是否加载不完整的aof文件来进行启动
                                          aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。
                                          重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）
                                          出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。
                                          如果是no，用户必须手动redis-check-aof修复AOF文件才可以。

lua-time-limit 5000                       设置lua脚本的最大运行时间，单位为毫秒

slowlog-log-slower-than 10000             设定执行时间，单位是毫秒，执行时长超过该时间的命令将会被记入log。-1表示不记录slow log; 0强制记录所有命令。

slowlog-max-len 128                       slow log的长度。最小值为0。如果日志队列已超出最大长度，则最早的记录会被从队列中清除。
                                          这个长度没有限制。只是要主要会消耗内存。你可以通过 SLOWLOG RESET 来回收内存。

latency-monitor-threshold 0               redis延时监控系统在运行时会采样一些操作，以便收集可能导致延时的数据根源。
                                          通过 LATENCY命令 可以打印一些图样和获取一些报告，方便监控
                                          这个系统仅仅记录那个执行时间大于或等于预定时间（毫秒）的操作,
                                          这个预定时间是通过latency-monitor-threshold配置来指定的，
                                          当设置为0时，这个监控系统处于停止状态
                                          
notify-keyspace-events ""                 *带一个由 0 到多个字符组成的字符串参数。空字符串意思是通知被禁用。
                                          默认所用的通知被禁用，因为用户通常不需要改特性，并且该特性会有性能损耗。
                                          
hash-max-ziplist-entries 512              (散列类型)指hashtable中元素的总个数不超过设定数量时，就用zipmap的方式来存储hashtable以节省内存,
                                          hash-max-zipmap-value 含义是当 value这个Map内部的每个成员值长度不超过多少字节就会采用线性紧凑存储来节省空间。

hash-max-ziplist-value 64                 （散列类型）hashtable中的key以及value的长度小于设定的值时，就用zipmap的方式来存储hashtable以节省内存
                                          含义是当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储，
                                          默认是64,即value内部有64个以下的成员就是使用线性紧凑存储，超过该值自动转成真正的HashMap。
       
                                          以上2个条件任意一个条件超过设置值都会转换成真正的HashMap，也就不会再节省内存了，那么这个值是不是设置的越大越好呢，答案当然是否定的，
                                          HashMap的优势就是查找和操作的时间复杂度都是O(1)的，而放弃Hash采用一维存储则是O(n)的时间复杂度，如果成员数量很少，则影响不大，否则会严重影响性能，
                                          所以要权衡好这个值的设置，总体上还是最根本的时间成本和空间成本上的权衡。
                                          
list-max-ziplist-entries 512              （列表类型）list数据类型多少节点以下会采用去指针的紧凑存储格式。

list-max-ziplist-value 64                 （列表类型）list数据类型节点值大小小于多少字节会采用紧凑存储格式。

set-max-intset-entries 512                set数据类型内部数据如果全部是数值型，且包含多少节点以下会采用紧凑格式存储。

zset-max-ziplist-entries 128              （有序集合类型）与上面类似

zset-max-ziplist-value 64                 （有序集合类型）与上面类似  

hll-sparse-max-bytes 3000                 value大小小于等于hll-sparse-max-bytes使用稀疏数据结构（sparse），大于hll-sparse-max-bytes使用稠密的数据结构（dense）。
                                          一个比16000大的value是几乎没用的，建议的value大概为3000。如果对CPU要求不高，对空间要求较高的，建议设置到10000左右。

activerehashing yes                       指定是否激活重置哈希，默认为开启
                                          Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用
                                          当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。
                                          如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存

client-output-buffer-limit normal 0 0 0   输出缓冲区限制
                                          对于普通客户端来说，限制为0，也就是不限制。因为普通客户端通常采用阻塞式的消息应答模式，何谓阻塞式呢？如：发送请求，等待返回，再发送请求，再等待返回。
                                          这种模式下，通常不会导致Redis服务器输出缓冲区的堆积膨胀。

client-output-buffer-limit slave 256mb 64mb 60    输出缓冲区限制
                                                  对于slave客户端来说，大小限制是256M，持续性限制是当客户端缓冲区大小持续60秒超过64M，则关闭客户端连接。

client-output-buffer-limit pubsub 32mb 8mb 60     输出缓冲区限制
                                                  对于Pub/Sub客户端（也就是发布/订阅模式），大小限制是8M，当输出缓冲区超过8M时，会关闭连接。持续性限制是，当客户端缓冲区大小持续60秒超过2M，则关闭客户端连接；

hz 10                                      redis使用一个内部程序来处理后台任务，例如关闭超时的client连接，清除过期的key等等。它并不会同时处理所有的任务，redis通过指定的hz参数去检查和执行任务。
                                           hz默认设为10，提高它的值将会占用更多的cpu，当然相应的redis将会更快的处理同时到期的许多key，以及更精确的去处理超时。
                                           hz的取值范围是1~500，通常不建议超过100，只有在请求延时非常低的情况下可以将值提升到100。

aof-rewrite-incremental-fsync yes          当一个子进程要改写AOF文件，如果以下选项启用，那文件将会在每产生32MB数据时进行同步，这样提交增量文件到磁盘时可以避免出现比较大的延迟。