redis阻塞问题
以下是学习笔记
- 出现cpu过高的原因有：
1、连接数过多，通过info clients查看
2、慢查询，因为redis是单线程，如果有慢查询的话，会阻塞住之后的操作，通过redis日志查 待补充
3、value值过大？比如value几十兆，当然这种情况比较少，其实也可以看做是慢查询的一种
4、aof重写/rdb fork发生？瞬间会堵一下Redis服务器
# 修改慢查询时间与队列长度
# 方式一
修改配置文件
# The following time is expressed in microseconds, so 1000000 is equivalent
# to one second. Note that a negative number disables the slow log, while
# a value of zero forces the logging of every command.
# 这里默认是10ms 10毫秒
slowlog-log-slower-than 10000
# There is no limit to this length. Just be aware that it will consume memory.
# You can reclaim memory used by the slow log with SLOWLOG RESET.
# 慢日志队列长度
slowlog-max-len 128
# 方式二
config set slowlog-log-slower-than 20000
config set slowlog-max-len 1000
config rewrite
# 查看命令
# 显示队列长度
127.0.0.1:6379> SLOWLOG LEN
128
# 默认显示队列尾部的10个
127.0.0.1:6379> SLOWLOG GET
# 默认显示队列尾部的最后一个
127.0.0.1:6379> slowlog get 1
71057 // slowlog唯一编号id
1574822285 // 查询的时间戳
10184 // 查询的耗时（微秒），如表示本条命令查询耗时47微秒
KEYS // 查询命令，完整命令为 KEYS history_1_*，slowlog最多保存前面的31个key和128字符
history_1_*
-
对应解决方案：
1、连接数过多解决：
1.1 关闭僵尸连接
采用redi-cli登录,采用client kill ip:port(redis远程连接的ip和端口)。
需要采用脚本批量删除多个连接
1.2 修改redis timeout参数
采用redis-cli登录，采用config set timeout xx 设置redis的keepalive时间
1.3 修改redis进程的文件数限制
echo -n "Max open files 3000:3000" > /proc/PID/limits
1.4 修改系统参数的最大文件数限制
/etc/security/limits.conf
2、对慢查询进行持久化，比如定时存放到mysql之类。（redis的慢查询只是一个list，超过list设置的最大值，会清除掉之前的数据，也就是看不到历史）
3、限制key的长度和value的大小 -
使用redis的注意事项:
1、Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2、如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3、为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4、尽量避免在压力较大的主库上增加从库
5、为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<--Slave1<--Slave2<--Slave3.......，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变
6、使用Redis负载监控工具：redis-monitor，它是一个Web可视化的 redis 监控程序
针对keys*的解决方案
方案一：初步方案采用scan，一个基于游标的迭代器，进行处理
// jedis.jar的版本为3.1.0
ScanParams scanParams = new ScanParams();
scanParams.match(patternKey);
scanParams.count(1000);
ScanResult<String> scanResult = jedis.scan(cursor, scanParams);
Redis的SCAN操作由于其整体的数据设计，无法提供特别准的scan操作，仅仅是一个“can't guarantee,just do my best”的实现：
- 提供键空间的遍历操作，支持游标，复杂度O(1), 整体遍历一遍只需要O(N)；
提供结果模式匹配； - 支持一次返回的数据条数设置，但仅仅是个hints，有时候返回的会多；
- 弱状态，所有状态只需要客户端需要维护一个游标；
- 无法提供完整的快照遍历，也就是中间如果有数据修改，可能有些涉及改动的数据遍历不到；
- 每次返回的数据条数不一定，极度依赖内部实现；
- 返回的数据可能有重复，应用层必须能够处理重入逻辑；上面的示例代码中， redisTemplate.execute方法是个Set，相当于已经对于返回的key去重
- count是每次扫描的key个数，并不是结果集个数。count要根据扫描数据量大小而定，Scan虽然无锁，但是也不能保证在超过百万数据量级别搜索效率；count不能太小，网络交互会变多，count要尽可能的大。在搜索结果集1万以内，建议直接设置为与所搜集大小相同。
方案二：主从集群，进行分离 待补充……
方案三：在放入之前想策略 待补充……
Redis 如何高效安全删除大 Hash Key
Redis删除大的集合键的耗时, 测试估算，可参考；和硬件环境、Redis版本和负载等因素有关
| Key类型 | Item数量 | 耗时 |
|---|---|---|
| Hash | ~100万 | ~1000ms |
| List | ~100万 | ~1000ms |
| Set | ~100万 | ~1000ms |
| Sorted Set | ~100万 | ~1000ms |
