redis 常用配置

daemonzie: 是否后台 运行 默认 no

pidfile: pid 文件路径

bind: 指定redis只接收来自于该ip地址的请求，如果不进行设置，那么处理所有请求。

port: 监听端口

timeout:客户端链接超时时间，单位秒。当客户端在这段时间爱你没有任何指令，那么关闭该链接。

loglevel:debug,verbose,notice和warning，一半使用notice就可以。

logfile: log文件地址。

databases：数据库个数

snapShotting：
save 60 1000 在60秒内有1000个keys发生变化时 进行镜像备份
save 300 10 在300秒内有10个keys发生变化时 进行镜像备份
save 900 1 在900秒内有1个keys发生变化时 进行镜像备份

rdbcompression: 在镜像备份时，是否进行压缩。redis采用Lzf压缩，如果为了节省cpu时间 可以关闭该选项，但是会导致数据文件变得巨大

dbfilename: 镜像备份文件的文件名， 后缀为.rdb

slaveof: 设置该数据库为其他数据库的从数据库

masterauth: 主数据库链接密码。

requirepass: 设置连接密码。

maxclients: 同时链接的客户端数量限制

maxmemory: 设置redis能够使用的最大内存，当内存满了的时候，如果还接收到set命令，redis将先尝试剔除设置过expire信息的key,而不管该key的过期时间还没有到达，
在删除时，按照过期时间进行删除 ，最早将要过期的key将最先删除，如果带有expire信息的key都删光了，那么将返回错误，这样redis将不会再接收set请求，
只接收get请求。

appendonly: 默认情况下,redis会在后天异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能频繁，如果发生诸如拉闸限电，拔插头等状况 ，
那么将照成大范围的数据丢失，所以redis提供了另外一种更加高效的数据备份及灾难恢复模式，开启append only模式后，
redis会把锁接收到的每次写操作请求都追加到appendonly.aof文件中,当redis重启时，会从该文件恢复出之前的状态,但这样会造成appendonly.aof文件过大，
所以redis还支持bgrewriteaof指令,对appendonly.aof进行重新整理，可以关闭镜像，开启 appendonly.aof，同时可以选择在访问较少时每天对 appendonly.aof 进行重写一次。

appendfsync: 设置appendonly.aof文件进行同步的频率，always表示对每次有写操作都进行同步，everysec表示对写操作进行累计，每秒同步一次，

vm-enabled: 是否开启虚拟内存支持，默认是no。因为redis是一个内存数据库，而且当内存满的时候，无法接受新的请求，所以在redis2.0中，提供了虚拟内存的支持。
但是需要注意的是，redis中，所有的key都会放在内存中,当内存不够时，只会把value值放入到交换区中。这样保证了虽然使用虚拟内存，但性能基不受影响，同时，你需要注意的是你需要把
vm-max-memory设置足够来放下你的所有的key,简单介绍一下,vm机制将数据分页存放,由于redis将访问量较少的页即冷数据swap到磁盘上，访问多页面由磁盘自动换出到内存中。

vm-swap-file: 设置虚拟内存的交换文件路径，不可多个redis实例共享。
vm-max-memory: 设置开启虚拟内存之后，redis将使用最大的物理内存的大小。默认0,redis将把所有的能放到交换文件的都放到交换文件中。以尽量少的使用物理内存。
在生产环境下，需根据实际情况设置该值。

vm-page-size: 设置交换文件的总page数量，需要注意的是，page table信息会房间物理内存中，每8个page就会占据RAM中的1个byte。总的虚拟内存大小=vm-page-size*vm-pages
vm-max-threads: 设置 vm io 同时使用的线程数量。因为在进行内存交换时，对数据有编码和解码的过程，所以尽管IO设备在硬件上本不能支持很多的并发读写，
但是如果你保存的value值比较大，将该值设大一些。还是能够提升性能的。

glueoutputbuf: 把小的输出缓存放在一起，以便能够在一个tcp packet中为客户端发送多个响应。

hash-max-zipmap-entries 64:
hash-max-zipmap-values 512:

redis2.0中引入了hash数据结构，当hash中包含超过指定元素个数或者最大的元素超过临界时，hash 将以一种特殊编码方式来存储。

avtiverehashing: 开启之后，redis将在每100毫秒时使用1毫秒的cpu时间来对redis的hash表进行重新hash，可以降低内存的使用。当你的使用场景中有严格的实时性需要，
不能够接受redis时不时对请求有2毫秒的延时的话，把这项设置为no。如果没有那么严格的实时性需求可以设置为yes以便能够尽快的释放内存。

cluster-enabled:是否开启集群功能

cluster-config-file node-6379.conf: 虽热此配置的名字叫集群配置文件，但此文件不能人工编辑，它是集群节点自动维护的文件，主要用于记录集群中有哪些节点，
他们的状态以及一些持久化参数等，方便在重启时恢复这些状态，通常这些是在收到请求之后这个文件就会被更新。

cluster-node-timout 15000;单位毫秒
这是集群中的节点能够失联的最大时间，超过这个时间，该节点就会被认为是故障。如果主节点超过这个时间还是不可达，则用它的从节点将启动故障迁移，升级为主节点。
注意，任何一个节点在这个时间内如果还没有连上大部分主节点，将会停止接收请求。

cluster-slave-validity-factor 10:
如果设置为0，则无论从节点与主节点失联多久，从节点都会尝试升级为主节点。如果设置成正数，则cluster-node-timeout*cluster-slave-validity-factor 得到的时间，
是从节点与主节点失联后，此从节点有效的最长时间，超过这个时间，从节点不会启动故障迁移，假设cluster-node-timeout=5，cluster-slave-validity-factor=10，
则从节点跟主节点失去联系50秒，此从节点不能成为主节点。注意，如果此参数配置为非0 ，将可能出现由于某主节点失去联系却没有从节点能顶上的情况，
从而导致集群不能正常工作,这种情况只有等待原来的主节点重新回归到集群，集群才能恢复运作。