redis入门笔记

我将自己今天一天所学到关于redis的重点写在这里。

1.expire name 2

   设置2秒过期，单位为seconds

2.ttl name

 查看生命期

3.exists name

查看是否存在

4.expire name 1477571450

利用时间戳设置过期，上面后面的数字是从1970年到目标时间的时间戳，通过命令行输入

date +%s -d "Oct 27, 2016 12:30:50" 可以得到。

 

一：redis的多实例配置：

修改conf文件中所有涉及的端口号：如将默认的6379改为6380，6381等等，新的实例用新的配置文件启动即可。

 

二：主从分布设置：

在REPLICATION部分加上：

1.slaveof 127.0.0.1 6379   //本实例作为6379的奴隶节点

2.masterauth weeyanghuang   //加上master的密码，我的是weeyanghuang

 

*在主从redis-server启动时，一定要先启动master，否则slave启动后由于connect
refused 一直死循环，成为僵尸进程。

 

三：redis的发布订阅机制：

可以先 help subscribe来了解命令。

a>比如一个redis-cli客户端订阅：subscribe channel01     //订阅频道1

b>另外一个redis-cli客户端向同一个redis-server发布消息：publish
channel01 hello //在频 道1发布hello，那么此时订阅的客户端就会直接看到这个消息。

 

如果要订阅所有频道可以用psubscribe channel*，那么另一个客户端无论向那个频道发布都可以收到。

 

四：redis 的key过期机制，有两种方法：

1.主动模式，redis会随机抽样检测key,每秒测10次，每次测试100个，判断是否过期，过期会删除。可能有的key已经过期，没有被删除。

2.被动模式，redis对过期key采用lazy expiration，在访问key的时候判断是否过期，如果过期可能删除。同样有的可能过期未删除。

 
 
五：redis的事务性：
1.setnx
key有value存在的时候，
假设 get name
输出 ‘weeyanghuang’
再用setnx name ‘lichao’，这是就无法更改name的value，如果没有value，则可以改。
2.批量执行exec
 执行multi
     set name 1
 set name 2
     此处出错...
 set name 3
 exec   //执行
此时redis不会批量执行，因为中间步骤出错了。
 
六：redis的持久化：
主要有两种方式：
1.Snapshotting（快照）
快照方式直接生成文件名，rdb文件。
默认  save 900 1
  save 300 10
      save 60  100
快照的时候redis产生一个frok，父进程继续处理客户端请求。子进程将快照写入临时文件，用临时文件替换原来的快照文件。
客户端也可以用save或bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有client请求，所以不推荐使用。
每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步变更数据。如果数据量比较大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。
数据快照的原理是将整个redis中存的所有数据遍历一遍存到rdb数据文件中，通过save命令可以调用这个过程。
 
redis-cli shutdown 正常退出可以自动保存。
kill -9 那么不会保存。
 
2.Append-OnlyFile （追加式的操作日志记录aof)
由于快照是一定时间间隔做一次的，所以redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式。
 
aof在持久化时，redis将每一个收到的写命令都通过write函数追加到文件中。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。所以aof也可能丢失部分修改。
 
可以通过配置文件设置redis通过fsync函数强制os写入到磁盘的时机。
有三种方式：
a.appendonly yes    //收到命令就写入，持久化好，性能不足
b.appendfsync everysec //每秒一次，性能和持久化折中
c.appendfsync no       //完全依赖os，性能最好，持久化不足
 
aof缺点，持久化文件变得越来越大，为了压缩aof文件，redis提供了一条命令，可以重写aof。
 
redis 可以在aof文件体积变得过大时，自动地在后台对aof进行重写： 重写后的新aof文件包含了恢复当前数据集所需的最小命令集合。
整个重写操作是绝对安全的，因为 redis 在创建新aof文件的过程中，会继续将命令追加到现有的aof文件里面，即使重写过程中发生停机，现有的aof文件也不会丢失。
 
bgrewriteaof命令可以智能的降低文件体积。
比如incr 1，一直到10，那么可以优化为直接到10。
 
*修改了配置文件一定要让redis-server以更新文件的方式启动，我在修改aof文件路径的时候，修改完毕，每次都用redis-server
&启动，结果毫无反应。