如果认为Redis是一个key value存储, 可以使用它来代替MySQL；如果认为它是一个可以持久化的cache, 可能只是用它保存一些频繁访问的临时数据（代替Memcached）；除此之外，还可以把Redis当做一个轻量级的消息队列使用，因为它内置就支持 list数据结构和PUB/SUB命令；还可以当做一个轻量级的分布式锁系统。Redis是REmote DIctionary Server的缩写，在Redis在官方网站的解释是：
本文将会详细介绍Redis的配置文件。
1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
4. 绑定的主机地址
5.当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
Redis默认配置文件中提供了三个条件：
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
11. 指定本地数据库文件名，默认值为dump.rdb
12. 指定本地数据库存放目录
13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
14. 当master服务设置了密码保护时，slav服务连接master的密码
15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
19. 指定更新日志文件名，默认为appendonly.aof
20. 指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折衷，默认值）
21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不确定，就使用默认值
25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
本文将通过分析代码来介绍Redis的启动过程，通过查看Redis 的启动脚本，得知Redis的启动时从Redis.c的main方法开始的。Redis启动可以分为以下几个步骤：
1.初始化Redis服务器全局配置
2.重置服务器Save参数（具体下文详解）和加载配置文件
3.初始化服务器
4.加载数据库
5.开始网络监听
一，初始化Redis服务器全局配置。这一步骤主要是主要是根据Redis.h中设置的Static值来初始化Redis服务器配置，这里设置是Redis服务器的默认配置。如：
·TCP Port，Redis Client的缺省Timeout；
·Redis缺省的数据库数目；
·Redis Append 持久化方式的参数设置；
·Redis的所支持的各种数据结构的缺省值的设置；
·Redis内存Swap相关设置；
·Redis Master & Slave相关的配置；
·Redis Command Table初始化。
二，加载配置文件：
这一步是通过读取的配置文件来对Redis服务器进行设置，将会覆盖上一步的某些缺省设置。打开下载下来的Redis源代码，我们可以看到其根目录下有一个默认的配置文件redis.conf。需要注意的是，如果在启动Redis的时候没有指定配置文件，则Redis服务器在启动的时候是不会加载这个默认的配置文件进行配置的。而且这个默认的配置文件和第一步中得全局默认缺省配置不尽相同，比如针对Redis的Append模式的数据保存策略的配置，redis.conf里面的设置是：
save 900 1 -------15分钟内一次更新
save 300 10 ------5分钟内10次更新
save 60 10000 ---1分钟内10000次更新。
而上一步里面的默认缺省配置确实：
save 60*60 1 -------一个小时内1次更新
save 300 100 ------5分钟内100次更新
save 60 10000 ---1分钟内10000次更新。
因此我们在启动Redis的时候如果默认配置不能满足要求，则需要指明配置文件进行配置。
三，初始化服务器：
初始化服务器是在initServer()方法中完成的，次方法利用上两步设置的参数进一步初始化服务器：
·创建用来维护clients和slaves的list
·创建共享对象。redisObject这个struct里有个变量叫做refcount，这个变量就是用来实现共享的。Redis的对象目前Redis只支持共享StringObject。Redis的共享对象有两大类比：第一类：Redis server的各种操作需要经常用到的各类对象，如：Redis Command的分隔符"\r\n",用于Redis command的reply的"+OK\r\n"或者"-ERR\r\n"等对象，因为在Redis的各种操作这类对象要被频繁使用，所以就在启动Redis的时候创建好，然后共用这些对象，减少时间成本和空间成本；第二，类的共享对象就是对应于数字的StringObject，如：Set "olylakers1" 1234; Set "olylakes2" 1234;在Redis内部，"olylakers1"和"olylakers2"这两个key都指向由数字1234转化的StringObject。这样在海量数据和特定存储内容下，可以节省大量的内存空间。可用通过REDIS_SHARED_INTEGERS这个参数来指定Redis启动的时候创建多少个第二类共享对象，默认的参数是10000，即创建的StrongObject个取值范围是0-9999之间。
·创建Pub/Sub通道
·初始化网络监听EventLoop的相关内容，如eventLoop，timeEvent，fileEvent等
·如果开启了VM，则初始化虚拟内存相关的IO/Thread
四，加载数据：
根据配置的不同，Redis加载数据的源也不一样，如果在配置文件里设置了appendonly yes（默认是no），那么就从appendfile加载数据，反之则从RedisDb加载数据
·从appendfile加载数据：我们先来看一下appendfile的内容是什么。下面的一条记录摘取自appendfile：SET $9 olylakers $3 oly。很显，appendfile保存的就是redis server接收到的各种命令，那么从appendfile加载数据就是redis server从appenfile里面读取这些命令的记录，然后重新把这些命令执行一遍即可。需要注意的是，如果开启了VM，那么在从appendfile加载数据的时候可能要涉及swap操作。
·从redisdb加载数据：如果没有开启appendonly，那么则需要从db file加载数据到内存，其过程是：
1.通过处理select命令，选择DB
2.然后从db file读取key和value
3.检查key是否过期，如果过期则跳过这个key，如果不过期，则把数据Add到对应的db的dict中
4.如果开启了VM，则从db file中load数据，也可能涉及到swap操作
五，开始网络监听：
Redis的网络监听没有采用libevent等，而是自己实现了一套简单的机遇event驱动的API，具体见ae.c。
redis使用了两种文件格式：全量数据和增量请求。全量数据格式是把内存中的数据写入磁盘，
便于下次读取文件进行加载；增量请求文件则是把内存中的数据序列化为操作请求，用于读取文件进行replay得到数据，序列化的操作包括SET、RPUSH、SADD、ZADD。
redis对interger根据值范围采用不同的编码存储，具体如下：
值范围 | 字节数(byte) | 编码格式 |
[0, 1 << 6 – 1] | 1 | 00 | value |
[1 << 6, 1 << 14 – 1] | 2 | 01 | (value >> 8) | value & oxFF |
[1 << 14, 1 << 31 – 1] | 5 | 10 000000 | htonl(value) |
redis对数值类的string object编码存储格式如下：
值范围 | 字节数(byte) | 编码格式 |
[-(1 << 7), 1 << 7 – 1] | 2 | 1100 0000 | value & 0xFF |
[-(1 << 15), 1 << 15 – 1] | 3 | 1100 0001 | (value >> 8) & 0xFF | value & oxFF |
[-(1 << 31)], 1 << 31 – 1] | 5 | 1100 0010 | value & oxFF | (value >> 8) & 0xFF | (value >> 16) & 0xFF | (value >> 24) & 0xFF |
redis支持字符串压缩存储，压缩的编码格式如下：
1100 0011 | compl_len (压缩后的长度) | orig_len (压缩前的长度) | comp_value (压缩后的内容) |
2.6.1data文件格式
2.6.2append文件格式
RedisDb | *2 | $6 | SELECT | $length(index) | index:long | ||||
entry | *3 | $3 | SET | $length(key) | key | $length(value) | value | ||
entry | *3 | $5 | RPUSH | $length(key) | key | $length(value) | value | ||
entry | *3 | $4 | SADD | $length(key) | key | $length(value) | value | ||
entry | *3 | $4 | ZADD | $length(key) | key | $length(score) | score:double | $length(value) | value |
entry | … | ||||||||
RedisDb | … | ||||||||
RedisDb | … | ||||||||
entry | |||||||||
entry | |||||||||
entry | |||||||||
Snapshotting
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久 化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000
下面介绍详细的快照保存过程
1.redis调用fork,现在有了子进程和父进程。
2. 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数 据是fork时刻整个数据库的一个快照。
3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不 是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。
另外由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式。下面介绍
Append-only file
aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）
appendonly yes //启用aof持久化方式
# appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
# appendfsync no //完全依赖os，性能最好,持久化没保证
aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下
1. redis调用fork ，现在有父子两个进程
2. 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
3.父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
4.当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
5.现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。
需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
