Redis开发与运维
2018-05-04 00:29:35 152 举报AI智能生成
《Redis 开发与运维 》读书笔记
作者其他创作
大纲/内容
键的管理
单个键管理
键重命名
rename key newKey
随机返回键
randomkey
键过期
exipre key seconds
取消键过期
persist key
键迁移
move key db
实例内部db间迁移
migrate
实例间迁移
遍历键
keys pattern
性能损耗较大，阻塞请求。
渐进式遍历
scan，类似与分页扫描
数据库操作
切换数据库 select dbindex
不建议一个实例中多个db，由于实例中是单线程的，db间是互相影响的
清空数据库
flushdb/flushall
客户端使用
主要讲解redis通信协议以及客户端的使用（链接池）和客户端问题定位的案例
总结：Redis的协议RESP协议比较简单，因此对我们实现一个简单代理是可行的（本地调试需要）。
参考文章
https://blog.csdn.net/mawming/article/details/52171116
Resis 噩梦：阻塞
如何定位
slowlog get 发现满查询
bigkeys 发现大对象
内在原因
API或数据结构使用不合理
CPU饱和
-- stat 看redis 统计 ，如果6w+ OPS 说明确实到极限
info commandstats看命令的耗时，如果吞吐量不大，CPU高，则分析是否是数据结构的问题。
持久化阻塞
fork 会阻塞足线程，info stats查看 lastest_fock_usec
AOF刷盘会阻塞线程，内存缓存到磁盘的同步策略要对
HugePage linux 配置优化问题
外在因素
CPU竞争
排除其他进程占用CPU的可能
CPU 绑定，开启了持久化的Redis不要绑定CPU，因为子进程会和父进程竞争一个CPU
SWAP
保证内存够大、合理设置maxmemory
网络问题
网络延迟，通过 latency 查看延迟统计
尽量使用链接池方式
链接溢出，考虑文件句柄限制、backlog队列溢出
数据类型
字符串
最大值512M
内部编码：int，embstr，raw
8个字节的长整形为int、小于等于39个字节的字符串为embstr、大于39的字符串为raw
应用场景
缓存
计数
共享session
哈希
内部编码
ziplist
节省内存
元素个数小于hash-max-ziplist-entries（512个）
所有值 小于hash-max-ziplist-value （64字节）
hashtable
读写O（1）
使用场景
以缓存用户信息为例
原生字符串类型，每个属性一个键
优点
简单直观，每个属性都支持独立更新
缺点
占用过多的键，内存占用大，用户信息内聚性差，通常不推荐使用
序列化字符串型
优点
简化编程，提高内存使用率
缺点
序列化与发序列化会有性能开销，同时每次更新属性都必须全部数据的读取。
哈希类型
优点
简单直观，合理使用情况下可以减少内存空间的使用
缺点
要注意控制ziplist与hashtable的类型转换，hashtable会消耗更多的内存
列表
最大元素个数2的23次方-1
反向关系链可存储
内部编码
ziplist
当元素个数小于 list-max-ziplist-entries 默认512
当每一个元素值都小于 list-max-ziplist-value 默认64字节
linkedlist
https://blog.csdn.net/fengfengdiandia/article/details/52097146
quicklist
redis3.2 优化
使用场景
消息队列
列表存储
例如报名关系，用户最近观看记录等，但是hgetall、lrange性能都要考虑
栈、队列的数据结构
集合
最大元素个数2的23次方-1
lrange、hgetall、smembers都是比较重的操作，考虑使用sscan命令
内部编码
intset
元素都是整数且元素个数小于set-max-intset-entries 默认512
hashtable
使用场景
用户关注类目
类目交集、找相关度
生成随机数，抽奖--srandmember
有序集合
内部编码
ziplist
元素个数小于zset-max-ziplist-rentires 默认128个
每个元素值都小于zset-max-ziplist-value 默认64字节
skiplist
原理解析：https://blog.csdn.net/fengfengdiandia/article/details/52097146
使用场景
排行榜
上课时常、积分排行
常用技巧
慢查询分析
showlog-log-slower-than、showlog-max-len
showlog get [n]
Redis Shell 工具
redis-cli
--latency 测试客户端到目标redsi的网络延迟
--stat 查看redis统计信息，例如db的存储信息
--bigkeys 找出内存中占用比较大的键值
redis-server
--test-memory size，检查当前机器能否稳定的分配制定的容量
redis-benchmark
redis 压测工具
Pipeline
与批量命令区别
原生批量命令为原子的，pipeline则不是
原生批量命令一个命令对应多个key，pipeline则对应多个命令
原生批量命令是Redis服务端支持实现，Pipleline则两端都需要
事务
mutli-exec
编译时错误
执行失败
运行时错误
部分会成功
没有回滚操作
总结：弱事务，通常需要与watch配合使用，但是redis的成功率一半比较高，实际应用分场景。
乐观锁
watch
Bitmaps
实际类型为字符串，提供位操作。无压缩
应用场景：记录用户是否有访问过
HyperLogLog
利用极小的空间完成独立总数的统计
应用场景：例如，应用（UUID）的安装量
发布订阅
channel 简易的消息队列，由于消息不会持久化，简单场景可用
GEO
支持存储地理位置信息，使用zset存储
功能
两个位置的距离
一个位置一定范围内其他位置的信息
持久化
RDB 内存快照
优点
占用空间小，适合全量复制
Redis加载速度快
缺点
无法实时持久化，Fork子进程操作比较重。因此不宜频繁执行
RDB格式复杂，会有和Reids版本不兼容的问题
AOF 类bin-log
优点
性能影响小、文件格式简单（兼容性好）、用于实时备份
缺点
文件占用空间大，磁盘写入对性能有一定影响。因此引入了重写机制来优化文件大小，以及利用缓冲区来减少磁盘写。
常见问题以及定位
fork 耗时
单个redis实例OPS可达到5W/s，因此阻塞会导致大量的命令失败。
每个实例的内存控制大小，太大持久化时常大。虽然父子进程共用物理内存空间，但是子进程会复制父进程的内存页表。10G大概20M
多实例部署，要注意不要同时进行AOF重写操作。可以使用外部程序控制
数据复制
拓扑
一主一从
当主节点写并发高时，可以把持久化工作交给从节点，但是重启时需要注意。
一主多从
可以读写分离，但是也个主节点带来负担
树状主从结构
可以有效降低主节点负载。redis-cluster模式下不可用。
复制
redis采用异步复制的机制，主节点运行 info replication可以看到从节点的复制状态 偏移量
0 条评论
下一页
