redis入门笔记(2)

redis入门笔记(2)

上篇文章介绍了redis的基本状况和支持的数据类型，本篇文章将介绍redis持久化、主从复制、简单的事务支持及发布订阅功能。

持久化

•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表示不使用工做线程