复制部分:

#只在slave添加该参数,用于创建一个镜像服务;
slaveof <masterip><masterport>

#如果master使用了requirepass参数,slave就要使用上述参数,进行密码验证。
masterauth <master-password>

#当slave丢失与master端的连接,或者复制仍在处理,那么slave会有下列两种表现:
#当本参数值为yes时,slave为继续响应客户端请求,尽管数据已不同步甚至没有数据(出现在初次同步的情况下);
#当本参数值为no时,slave会返回"SYNC with master in progreee"的错误信息;
#(这样就 屏蔽了读取数据过于陈旧的问题了吧?)
slave-serve-stale-data yes

# slave是可以写入的数据可以短暂存储,(会被master的数据同步掉);read only slave 并不是
#暴漏给不信任的客户端,对于master 传过来的 administrative commands,可以用 rename-command 进行隐藏。
slave-read-only yes

#slave根据指定的时间间隔向服务器发送ping请求,默认10s,个人的疑问:前面已经有了和“client” 进行沟通的tcp-keepalive
#什么还要加上 这个参数呢? master 没有把slave 当做一个 client?
repl-ping-slave-period 10 

#设置了大块数据I/O、向master请求数据和ping响应的过期时间,默认60s,
#确保这个值比 repl-ping-slave-period 大,否则master和slave之间的传输过期时间比预想的要短。
repl-timeout 60 
 


#默认为no,当选择yes的时候, master会向slave发送少量的tcp packets,(当然占用的带宽是很少的)
#这样的一个负面影响 delay slave接受数据时间,40 milliseconds 的延迟,在 高流量或者 master slave之间中间节点数很多的情况下,建议变为 yes
repl-disable-tcp-nodelay no

#该参数主要是在HA 方面的应用, 优先级越低,月可能成为master候选人(当master宕机的时候),Redis Sentinel 来决定哪个可以作为候选的 master, 如果该参数为0, 那么slave 就永远不会成为master。
slave-priority 100

安全部分

requirepass foobared
#详细请看:http://weipengfei.blog.51cto.com/1511707/1217872

#rename-command 重命名或禁用某些命令
#在redis你可以禁用某些命令或者将命令重命名成难以猜测的名字,这样一般的用户就只能使用部分命令了。
#例如,虚拟服务器提供商提供管理redis实例的服务,这样的话,普通用户就不能调用CONFIG命令来修改配置了,但能新增,删除redis实例的系统必须能修改配置。
#可以重命名命令,也可以完全禁用该命令。Redis.conf文件支持这样的这样配置。例如:
rename-command CONFIGb840fc02d524045429941cc15f59e41cb7be6c52
#在上面这个例子里,CONFIG命令重命名成一个毫无意义的名字。把命令重命名成空字符串即可将命令完全禁用,例如下面这个例子:rename-command CONFIG 

Limits 部分

#最大并发连接数,默认为一万,这个跟系统本身的 open-file-limit 有关;超过这个限制后,会提示:max number of clients reached
maxclients 10000

内存

#最大使用内存;
maxmemory <bytes>

查看当前内存使用情况:

#或者:redis-cli -h 127.0.0.1 -p6379 info |grep memory
redis 192.168.1.85:6379> info

#redis 数据占用的内存
used_memory:  
used_memory_human:

#redis占用的物理内存
used_memory_rss:

#使用的物理内存峰值
used_memory_peak:
used_memory_peak_human:

(当used_memory_rss 接近maxmemory 或者 used_memory_peak超过maxmemory时要加大maxmemory的值)
不要用比设置的上限更多的内存。一旦内存使用达到上限,Redis会根据选定的回收策略删除key
如果因为删除策略问题Redis无法删除key,或者策略设置为 "noeviction",Redis会回复需要更多内存的错误信息给命令
但是会继续合理响应只读命令,比如:GET。
在使用Redis作为LRU缓存,或者为实例设置了硬性内存限制的时候(使用 "noeviction" 策略)的时候,这个选项还是满有用的。

注意:当slave连接上一个达到内存上线的实例的时候,响应slave需要的输出缓存所需内存不计算在使用内存当中。当请求一个删除掉的key的时候就不会触发网络问题/重新同步的事件,然后slave就会收到一堆删除指令
直到数据库空了为止。简而言之,如果你有slave连上一个master的话,确保有足够的系统内存用作输出缓存。

maxmemory-policy  
# 内存策略:如果达到内存限制了,Redis如何删除key。你可以在下面五个策略里面选
volatile-lru -> 根据LRU算法生成的过期时间来删除。
allkeys-lru -> 根据LRU算法删除任何key。
volatile-random -> 根据过期设置来随机删除key。
allkeys->random -> 无差别随机删。
volatile-ttl -> 根据最近过期时间来删除(辅以TTL)
noeviction -> 谁也不删,直接在写操作时返回错误。
#对所有策略来说,如果Redis找不到合适的可以删除的key都会在写操作时返回一个错误。

maxmemory-samples 3
#个人认为该参数主要用于测试达到内存最大的时候的,现象吧。
LRU和最小TTL算法的实现都不是很精确,但是很接近(为了省内存),可以用样例做测试。
例如:默认Redis会检查三个key然后取最旧的那个,该参数用来配置项来设置样本的个数。

APPEND ONLY MODE部分:

redis 内存中的数据默认是异步同步到磁盘上的,如果发生宕机断电等情况,会造成几分钟数据的丢失。
Append Only File也是数据持久化的一种方式,可以提供更好的数据可靠性,
默认使用fsync() 刷写磁盘数据,发生断电,或者Redis出现内部错误的时候最多丢失1秒数据。
AOF and RDB 这两种持久化方式可以同时开启不会发生冲突,开始AOF模式的话,Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件。
每次启动时Redis都会把这个文件的数据读入内存里。

appendfilename appendonly.aof
#append file 的文件名称

appendfsync everysec
#append log AOF日志文件同步的频率刷写磁盘的频率
fsync() 请求操作系统马上把数据写到磁盘上
Redis支持三种不同的模式:
no:不要立刻刷,只有在操作系统需要刷的时候再刷。比较快。
always:每次写操作都立刻写入到aof文件。慢,但是最安全。
everysec:每秒写一次。折衷方案。
默认的 "everysec" 通常来说能在速度和数据安全性之间取得比较好的平衡。

no-appendfsync-on-rewrite no
# 如果AOF的同步策略设置成 "always" 或者 "everysec",那么后台的存储进程(后台存储或写入AOF日志)会产生很多磁盘I/O开销。
某些Linux的配置下会使Redis因为 fsync() 而阻塞很久。
目前对这个情况还没有完美修正,甚至不同线程的 fsync() 会阻塞我们的 write(2) 请求。
为了缓解这个问题,可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理时阻止 fsync()。
这就意味着如果有子进程在进行保存操作,那么Redis就处于"不可同步"的状态。
这实际上是说,在最差的情况下可能会丢掉30秒钟的日志数据。(默认Linux设定)
如果有延迟的问题那就把这个设为 "yes",否则就保持 "no",这是保存持久数据的最安全的方式。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#AOF文件自动重写。
如果AOF日志文件大到指定百分比,Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。
工作原理:Redis记住上次重写时AOF日志的大小(或者重启后没有写操作的话,那就直接用此时的AOF文件),
基准尺寸和当前尺寸做比较。如果当前尺寸超过指定比例,就会触发重写操作。
你还需要指定被重写日志的最小尺寸,这样避免了达到约定百分比但尺寸仍然很小的情况还要重写。
指定百分比为0会禁用AOF自动重写特性。(不是很明白它的作用)

LUA_SCRIPT lua脚本的支持;

lua-time-limit 5000(毫秒单位)
lua 脚本执行时间限制
如果lua脚本执行时间超过了最大限制时间,那redis会将其记录到日志中,
当一个脚本运行时间超过了最大执行时间
只有SCRIPT KILL和 SHUTDOWN NOSAVE两个命令可以使用。
SCRIPT KILL用于停止没有调用写命令的脚本。
SHUTDOWN NOSAVE是唯一的一个,在脚本的写命令正在执行用户又不想等待脚本的正常结束的情况下,关闭服务器的方法;
设置为0或负数就会取消脚本执行时间限制;

SLOW LOG 部分:

#Redis慢查询日志可以记录超过指定时间的查询。运行时间不包括各种I/O时间。
例如:连接客户端,发送响应数据等。只计算命令运行的实际时间(这是唯一一种命令运行线程阻塞而无法同时为其他请求服务的场景
slowlog-log-slower-than 10000(单位微秒)
#慢查询日志长度,这个长度没有限制。只要有足够的内存就行可以通过 SLOWLOG RESET 来释放内存(当一个新的命令被写进日志的时候,最老的那个记录会被删掉。)。
slowlog-max-len 128
(ps:日志居然是在内存里面的,)

对于虚拟内存的使用,
### 警告!虚拟内存在Redis 2.4是反对的。
### 非常不鼓励使用虚拟内存!!
在2.6中 根本没有其相关配置,

高级配置部分

hash-max-ziplist-entries 512
hash-max-ziplist-value 64
#当有大量数据时,适合用哈希编码(需要更多的内存),元素数量上限不能超过给定限制。

list-max-ziplist-entries 512
list-max-ziplist-value 64
#与哈希相类似,list数据元素较少的情况下,可以用另一种方式来编码从而节省大量空间。

set-max-intset-entries 512
#set 编码形式为是64位无符号整型数字构成的字符串。
该参数来限制这种情况下使用这种编码的最大上限的。

有序序列也可以用一种特别的编码方式来处理,可节省大量空间。
# 这种编码只适合长度和元素都符合下面限制的有序序列:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

activerehashing yes
#哈希刷新,每100个CPU毫秒会拿出1个毫秒来刷新Redis的主哈希表(顶级键值映射表)。
redis所用的哈希表实现(见dict.c)采用延迟哈希刷新机制:你对一个哈希表操作越多,哈希刷新操作就越频繁;
反之,如果服务器非常不活跃那么也就是用点内存保存哈希表而已。
默认是每秒钟进行10次哈希表刷新,用来刷新字典,然后尽快释放内存。
建议:
如果你对延迟比较在意的话就用 "activerehashing no",每个请求延迟2毫秒不太好嘛。
如果你不太在意延迟而希望尽快释放内存的话就设置 "activerehashing yes"。

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

Redis 的output buffer限制 用来强行断开那么些读取速度比较慢的客户端(比如发布订阅模式,订阅者不能像发布者发布消息那样很快的接受到订阅信息),
3种不同的客户端:
normal -> normal clients
slave  -> slave clients and MONITOR clients
pubsub -> 客户端至少订阅了一个频道或者模式
基本语法为:
client-output-buffer-limit <class><hard limit><soft limit><soft seconds>
当达到hard limit 限制的时候,server立即断开连接,或者当达到soft limit限制后,持续时间达到 soft seconds 。
把参数都变为0,就不会有限制。

hz 10
#Redis 调用内部函数来执行后台task,比如关闭已经timeout连接,删除过期的keys并且永远不会被访问到的,
执行频率根据 hz 后面的值来确定。在Redis 比较空闲的时候,提高这个值,能充分利用CPU,让Redis相应速度更快,
可取范围是1-500 ,建议值为 1--100

aof-rewrite-incremental-fsync yes
当子进程重写AOF文件,以下选项开启时,AOF文件会每产生32M数据同步一次。
# 这有助于更快写入文件到磁盘避免延迟