阻塞解决
阻塞发现
1.客户端日志统计报警
2.服务端监控
阻塞原因
1.慢查询（线上设置1毫秒，避免O(n)命令，分拆大对象）
2.大对象（redis-cli —bigkeys）
cpu饱和
统计使用情况（Redis-cli —stat）
单台redis ops一万以内垂直优化，5万以上 水平优化
1.fork阻塞 - p194
2.aof刷盘阻塞 - p194
3.huge page写阻塞 （关闭Linux huge page）
Ziplist：减少内存使用，增加cpu和命令时间，平衡内存和效率
内存优化（优先考虑垂直优化，再考虑水平扩展）
一.简化键
pencilnews:user:{uid}:identity 简化为 p:u:{uid}:idty
二.简化值
1.业务简化，去掉不必要的数据
2.选择高效的序列化工具（protostuff,kryo）(json可使用snappy,压缩效率高于gzip)
三.整数对象池[0-9999](设置maxmemory并开启lru类淘汰策略时无效)（ziplist无法使用 - 压缩且内存连续存储）
字符串(优化)预分配
追加修改字符串，redis会预分配一定内存，防止多次修改重新分配内存和字节数据拷贝
追加修改字符串内存导致重新分配会造成内存碎片
字符串预分配造成了内存浪费
优化
1.避免频繁使用append ,setrange，直接使用set
2.改为hash存储(ziplist,避免使用hashtable)
编码类型优化
编码类型转换不可逆，只能由小内存编码向大内存编码转换,重启redis，重新加载数据可完成转换
编码控制参数表 - p218
Ziplist:（内存要求较高场景）
1.连续内存数组
2.数据量更大时耗时： list < hash < zset
优化
1.建议长度不超过1000,元素大小控制在512字节内
Intset:（少量整数集合场景）
1.有序不重复整数
2.int16、int32、int64（根据集合内最长数据确定类型）
优化
1.保持整数范围一致，如控制在int-16范围内，避免内存浪费
控制键规模（小对象场景）
避免大量使用set/get，当做memcache来用
大量键分组映射到hash（ziplist），也可以节省大量内存（写入更耗时，随着value空间减少而降低）
如100w个键，分1000个hash存储，每个存储1000个value
Hash优化后开发需手动删除过期键
网友评论