Redis 文档阅读笔记 (一)

平常使用Redis大概就是须要的时候就查一下文档,因而决定开始完整地看一遍,并作一些笔记.须要说明的是,部分笔记我的理解可能有不对的地方,欢迎指正交流.

1. Pipelining

1. Redis是一个TCPServer,使用CS模型

2. 1次请求将命令集合发送,Redis执行命令后将结果队列化后,再写入返回

3. 队列化执行结果须要使用内存,若是屡次大批量操做须要注意内存的使用

4. 使用Redis脚本可以处理更快处理批量命令.管道没法在脚本中使用,由于使用管道时在写入以前须要返回响应给客户端(须要注意:这里我的理解可能存在误差).反之,管道可使用脚本

2. Redis Pub/Sub

1. 发布订阅模式: 发布者发布消息到Channel,订阅者订阅Channel接收消息

2. Redis客户端一旦为订阅模式,不能接收其余命令

3. redis-cli命令行客户端时进入订阅模式以后只能经过ctrl-c取消订阅,由于此时客户端阻塞等待接收订阅消息

4. 发布订阅无关于key所在空间,db10发布的,db1订阅仍能接收

5. 可用模式匹配发布多个channel 和订阅多个channel

3. Redis Lua scripting

1. EVAL,EVALSHA命令执行Lua脚本

2. Lua 脚本可使用redis.call 或redis.pcall执行redis命令

3. redis.call执行遇到错误时直接抛出Lua异常结果,redis.pcall则会把异常处理成Lua table返回

4. Lua调用redis命令时把数据转成redis对应数据类型,脚本执行结果返回给客户端时Lua的数据类型转成redis对应数据类型

5. 使用Lua脚本时对于浮点数最好使用字符串替代

6. 若是Lua返回数组中包含nil,则数据转换终止,最终只能返回nil以前的结果

7. redis.error_reply,redis.status_reply 在Lua脚本中是比较有用的按redis数据类型返回结果的方法

8. 执行Lua脚本时,其余客户端的命令和脚本将没法执行

9. redis内部缓存机制会缓存脚本,使用EVALSHA,若是redis经过匹配SHA1文摘匹配到脚本,则执行脚本,不然返回错误信息通知使用EVAL代替

10. 使用SCRIPT FLUSH或重启redis实例会刷新脚本缓存

11. 脚本自身会被从库复制或写入AOF文件,而不是脚本的结果命令.不过从3.2版本开始,已经可选设置复制结果命令

12. 脚本不容许设置全局变量

4. Debugging Lua scripts

1. Redis Lua debugger默认,每个新的Debug session是一个forked session,这意味着当脚本在debug中时,不会阻塞redis server执行其余命令,同时也意味着debug结束后会回滚脚本执行的结果

2. 官网有视频详解https://redis.io/topics/ldb

5. Memory optimization

1. 经过修改redis.conf调整每一种数据类型的最大数量和最大空间

2. RDB和AOF文件兼容32位和64位,之间能够互转

3. 合理利用bit和byte操做

4. 尽量使用hash结构存储数据

5. 每一个hash最多存储100个field是cpu和内存之间的最佳妥协

6. redis根据配置文件maxmemory分配内存

7. 被删除的key实际上并不会马上释放内存,例如在同一页中存在其余的key未被删除,须要根据峰值内存使用量限定内存使用

8. redis底层内存分配器会尽量重复利用被删除key的内存,因此也不用太担忧被删除key没有及时释放的问题

9. 若是不设置maxmemory,全部的内存将可能被吃光

10. 当超过最大内存限制时,致使写入时out of memory error,但不会所以致使整个机器挂掉

6. Expires

1. 过时时间只针对key不针对值

2. 过时时间能够经过persist命令清除

3. 经过rename重命名key,原key的过时时间仍然有效,若是由别的key rename覆盖,则该key具备别的key的特性

4. 若是设置的过时时间为过去时间,则key至关于del 而不是expired

5. 消极检查: 当客户端获取该key时才检查该key是否过时

6. 积极检查: redis 1秒内执行10个检查过时,每次随机选取20个key,发现过时的则清除,若是发现超过25%过时,则继续下一个检查

7. 过时执行删除的命令会传递给从库和AOF文件同步执行.从库不会检查key过时,当切换为主库时才会去检查

7. Redis as an LRU (Less Recently Used) cache

7.1 Redis达到最大内存限制时策略

1. noeviction: 直接抛出异常

2. allkeys-lru: 将最近不经常使用的key清除腾出空间

3. volatile-lru: 将带有过时时间的最近不经常使用的key清除腾出空间

4. allkeys-random: 随机将key清除腾出空间

5. volatile-random: 随机将带有过时时间的key清除腾出空间

6. volatile-ttl: 将较小剩余存活时间的key清除腾出空间

7. 若是不肯定使用哪一种策略,allkeys-lru是一个较好选择

8. volatile-lru和volatile-random比较适用于只用单个实例,混用缓存和持久key

7.2 近似LRU算法

1. redis使用的并非实际的LRU算法,而是大体评估必定样本量中选取最符合的key

2. 能够经过设置配置样本量参数maxmemory-samples调节精度

7.3 LFU (Least Frequently Used)

1. 4.0版本之后新增了新策略,根据命中的频率决定清除哪些key

2. lfu-log-factor和lfu-decay-time是两项主要调节参数

8. Redis transactions

1. 事务中的全部命令会序列化并串行化执行,在事务过程当中,其余客户端发起的请求不会被处理

2. 全部命令要么所有被处理或不处理(这里的处理并不表示必定执行成功),保证了原子性

3. 若是使用append-only file,在发生崩溃或强制关闭redis时有可能致使执行事务中部分命令.redis重启后会检测到直接退出.使用redis-check-aof tool修复

4. MULTI开启事务,命令存储到队列,命令EXEC执行事务全部命令

5. 执行EXEC检测到命令错误时,会在EXEC直接返回错误信息,并丢弃全部命令

6. 执行EXEC后,部分命令执行失败,对应的命令返回错误信息,其余命令执行成功

7. redis不支持回滚:由于官方认为不须要,语法上的错误,在命令队列化时就能检测到,而编码错误致使命令执行失败redis表示不背这个锅,redis追求更简单,更快

8. 使用WATCH命令实现乐观锁,若是多个客户端对同一个key进行操做并存储时,被观察的key被改变后,其余客户端对该key的修改的事务则会失败,实现了对该key的原子操做

9. 须要注意的一点,当WATCH某个key以后,key过时了,那EXEC就会正常执行

10. 使用WATCH能够实现对有序集合操做的原子性

11. 对事务的操做在脚本中也能实现,并且脚本能够更简单更快