持久化
•redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化，这是相对memcache来说的一个大的优势。redis支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是Append-only file（缩写aof）的方式。
Snapshotting
快照是默认的持久化方式。这种方式将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以配置自动做快照持久 化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000
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，性能最好,持久化没保证
主从复制
•
主从复制允许多个
slave server
拥有和
master server
相同的数据库副本。下面是关于
redis
主从复制的一些特点
–
1.master
可以有多个
slave
–
2.
除了多个
slave
连到相同的
master
外，
slave
也可以连接其他
slave
形成图状结构
–
3.
主从复制不会阻塞
master
。也就是说当一个或多个
slave
与
master
进行初次同步数据时，
master
可以继续处理
client
发来的请求。相反
slave
在初次同步数据时则会阻塞，不能处理
client
的请求。
–
4.
主从复制可以用来提高系统的可伸缩性（我们可以用多个
slave
专门用于
client
的读请求，比如
sort
操作可以使用
slave
来处理），也可以用来做简单的数据冗余。
-5.可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。
事物
•
redis
对事务的支持目前还比较简单。
redis
只能保证一个
client
发起的事务中的命令可以连续的执行，而中间不会插入其他
client
的命令。
–
Multi
事物开始
–
Exec
执行事务
–
Discard
放弃事物
–
Watch
监听
key
–
Unwatch
放弃所有
key
的监听
•
watch
命令会监视给定的
key,
当
exec
时候如果监视的
key
从调用
watch
后发生过变化，则整个事务会失败。注意
watch
的
key
是对整个连接有效的，和事务一样，如果连接断开，监视和事务都会被自动清除。
发布订阅（pub/sub ）
•
发布订阅
(pub/sub)
是一种消息通信模式。订阅者可以通过
subscribe
和
psubscribe
命令向
redis
server
订阅自己感兴趣的消息类型，
redis
将消息类型称为通道
(channel)
。当发布者通过
publish
命令向
redis
server
发送特定类型的消息时。订阅该消息类型的全部
client
都会收到此消息。这里消息的传递是多对多的。一个
client
可以订阅多个
channel,
也可以向多个
channel
发送消息。
–
Subscribe
–
Unsubscribe
–
Psubscribe
–
Punsubscribe
–
Publish
管道（pipeline）
•
redis
是一个
cs
模式的
tcp
server
，使用和
http
类似的请求响应协议。一个
client
可以通过一个
socket
连接发起多个请求命令。每个请求命令发出后
client
通常 会阻塞并等待
redis
服务处理，
redis
处理完后请求命令后会将结果通过响应报文返回给
client
。基本的通信过程如下
Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
•
基本上四个命令需要
8
个
tcp
报文才能完成。由于通信会有网络延迟
,
假如从
client
和
server
之间的包传输时间需要
0.125
秒。那么上面的四个命令
8
个报文至少会需要
1
秒才能完成。
利用pipeline的方式从client打包多条命令一起发出，不需要等待单条命令的响应返回，而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端。通信过程如下
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
虚拟内存(VM)
VM的作者已经放弃该功能
•
redis
没有使用
os
提供的虚拟内存机制而是自己实现了自己的虚拟内存机制 ，但是思路和目的都是相同的。就是暂时把不经常访问的数据从内存交换到磁盘中，从而腾出内存空间用于其他需要访问的数据。尤其是对于
redis
这样的内存数据库，内存总是不够用的。除了可以将数据分割到多个
redis
server
外。另外的能够提高数据库容量的办法就是使用
vm
把那些不经常访问的数据交换的磁盘上。如果我们的存储的数据总是有少部分数据被经常访问，大 部分数据很少被访问，对于网站来说确实总是只有少量用户经常活跃。当少量数据被经常访问时，使用
vm
不但能提高单台
redis
server
数据库的容量，而且也不会对性能造成太多影响。
–
vm
-enabled yes #
开启
vm
功能
–
vm
-swap-file /
tmp
/
redis.swap
#
交换的
value
保存的文件路径
/
tmp
/
redis.swap
–
vm
-max-memory 1000000 #
最大内存上限，超过后开始交换
value
到磁盘文件
–
vm
-page-size 32 #
每个页面的大小
32
个字节
–
vm
-pages 134217728 #
最多使用在文件中使用多少页面
vm
-max-threads 4 #
用于执行
value
对象换入换出的工作线程数量，
0
表示不使用工作线程
from:http://www.cnblogs.com/visionwang/p/3234477.html