特点
- 内存+磁盘的持久化保存
- 具有非常丰富的数据类型，尤其擅长数组类数据的高速度处理
- 数据快照
- 自带的主从复制
- 丰富的数据类型
- 字符串
- 链表
- 集合
- 有序集合
- 散列表
适用场景
- 时间线应用
得益于链表的高速实现
- 对数组形式数据频繁添加和删除
不限于常规数组，包括链表，有向集合
安装
centos 上 : yum install redis
windows 下载安装，网上教程很多。
启动及配置
我是用windows 时配置文件中有一项
# On Windows, daemonize and pidfile are not supported.
# However, you can run redis as a Windows service, and specify a logfile.
# The logfile will contain the pid.
说明在windows中不支撑守护进程程（后台启动）的方式启动，但可以注册为woindows的后服务程序，因为我没有这个需求，所以没有去进一步的折腾。
常用配置
基本配置说明
n 参考http://blog.csdn.net/willability/article/details/7676384
windows启动
启动服务端：打开一个cmd窗口使用cd命令切换目录到redis安装目录，运行redis-server.exe启动redis.
启动客户端：打开另一个cmd窗口使用cd命令切换目录到redis安装目录运行redis-cli.exe -h 127.0.0.1 -p 6379，其中的-h和-p是可以省略的，保持默认。
退出 quit
常用命令及操作
set a 1 a 为键，1 为值
set b [1,2,3,4,5] value为列表。
setex c 5 3 表示5秒过期时间
get a 取数
lpush data foo 向链表data 左向push一个值foo
zadd sets 1 abc 向有向集体中增加值 第一个参数是位置，第二个参数是值。
zadd set 2 bcd
zrange sets 0 -1 第一个参数表示取数开头的位置，0就从开始取。，第一个参数是取数结尾的位置，-1表示取到最后
redis记录点击数
INCR visits:635:totals 自增长visits:635:totals
INCR visits:635:totals
get visits:635:totals 得到结果是2.
查看当前系统所有的数据
可以使用正则表达式的表达式
keys *
keys h*llo
keys h?llo
key h[ae]llo
Redis的主从复制
一、设置配置文件
把conf文件复制两份，一份改名为redis.windows-master.conf，里面以默认配置就行，另一份改名为redis.windows-service.conf，里面改两个地方 ，1 ，port 改为6389（因为默认是6379，已经被master占用，）另一个方是：# slaveof <masterip> <masterport> 在这一行的下边加一行 slaveof 127.0.0.1 6379 (也就是master服务器的地址和端口 )
二、启动
启动master redis-server.exe redis.windows-master.conf
启动slave redis-server.exe redis.windows-slave.conf
也就是带上配置文件启动，这样启动的两个服务器用的是两个不同的配置文件
三、验证
连接master redis-cli.exe -h 127.0.0.1 -p 6379
插入数据rpush data value1
连接slave redis-cli.exe -h 127.0.0.1 -p 6389
取数 lrange data 0 -1 也能得到数据 ，说明自动实现了主从复制。
Redis的持久化
快照（snapshot）
设置一个触发条件，当这个触发条件满足时，redis 就往硬盘中写入数据。触发时间可以是时间，也可时是修改的数量，甚至是手工触发条件。所保存的文件一般是以rdo作为后缀（文件类型名）。如果你当前进程关闭或宕机了，当你下一次打开redis时，他们把这个数据重新装回内存。装载回存是一次完成的。
快照原理
Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。
Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性 rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。
同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。
我们可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到 Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。
优点：
对相同变量只保存最后一次的最终结果
缺点：
快照备份不是实时的，所以可能丢失数据
运行redis时是一次全部写入到内存，对IO操作的性能影响很大，
设置配置文件
- # save ""
- save 900 1 # 900秒内有一次修改就save
- save 300 10 #300秒内有10次修改就save
- save 60 10000 # 60 秒内有10000次修改就save
- rdbcompression yes 表示是否压缩，默认为yes
- dbfilename dump.rdb 表示备份文件名字
- # Note that you must specify a directory here, not a file name.
dir ./ 表示日志文件存放的目录，注意的是所选的目录一定要有写权限
- # requirepass foobared 表示在连接等操作时是否需要口令，默认是关闭的。
- appendonly no 表示是否只使用appendonly，默认是no
- slowlog-log-slower-than 10000 记录执行时间长于10000毫秒的命令
动态修改配置参数
- config get * 列出所有配置项
- config set time out 280 动态的把timeout的值设为280 这样就不用重新启动
AOF（Append Only File）仅追加日志
记录全部对数据改写的命令，如果你当前进程关闭或宕机了，当你下一次打开redis时，redis就会重写执行这写日志文件的命令。
优点：
记录所有数据，所以不会丢失数据。写入时不是一次性全部写入，对IO影响较小
缺点：
如果同一变量修改多次，那么会记住所有的修改，这样就可能执行很多次才能得到最终结果，装载速度变慢。解决办法是让redis在一定条件下合并日志，这样就可以把前面无用的日志过滤掉，但是合并日志也会消耗大量的性能。
设置配置文件
appendonly yes
特点
- 启动装载 AOF优先于RDB
源码如下：
- RDB性能优于AOF，因为里面没有重复
- Redis一次性将数据加载到内存中，一次性预热
AOF rewrite
重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似， 也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的 rename命令用新的 AOF文件取代老的AOF文件。
VM （虚拟内存 2.4版之后就已经去掉了）
在未打开VM的情况下，Redis的数据全部装入内存，将受限于内存的大小 打开VM后，Redis把全部Key放入内存，热Value也装进内存，冷Value放在磁盘的交换文件
配置
常见性能问题：
写快照产生阻塞
写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务
方法是 1、采用主从复制，Master不写快照，slave去写
2、使用bgsave
AOF引发的问题
AOF持续写入，产生阻塞的可能较小
AOF重写对性能影响很大，会引发服务暂停响应。但不重写，AOF太大，影响启动装载数据速度
将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题，设置为yes表示 rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入。最好是不开启Master的AOF备份功能
内存瓶颈
maxmemory <bytes> 设置最大使用内存，当内存达到这个最大值时，redis就会抛弃旧的变量。可以用算法设置抛弃那种变量。
主从复制阻塞
Redis主从复制的性能问题，第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb 文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master 将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存 快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于磁盘io的限制，如果Master快照文件比较 大，那么dump会耗费比较长的时间，这个过程中Master可能无法响应请求，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。
