艾斯比

背景最近, 我们有个接口不再走 redis. 然而, 我们在监控看板上看到 redis 的 qps 仍然很高, 达到 130k.目标需要排查 redis qps 虚高的原因, 到底在执行哪些命令行动监控看板上提取最近 8000 条命令,看到 35% 的命令都是 ping 命令, 猜想是客户端连接为了判断存活状态而发出的命令.查看项目的 redison 配置, 发现是每个连接 1s 发出一次 ping 命令, 其实很频繁了.对比最近 redisson 的版本更新, 配置的是 30s解决

redis 自带性能测试工具 redis-benchmark查看帮助redis-benchmark -h常用命令100 并发, 总共请求 10w 次连接 192.168.1.201 端口 6379redis-benchmark -h 192.168.1.201 -p 6379 -c 200 -n 100000可以看到 支持 4.4w qps, p99 在 5.663ms, 性能还是非常高的...

执行 bgrewriteaof 命令子线程就记录当前内存的数据作为命令内容保存到新的 aof 文件, 期间的写操作会记录到 aof buf, 当记录都保存到 aof 文件后, 再把 aof buff 命令写入. 最后, 替换掉旧的 aof 文件

全量同步slave 启动后, 发送 sync 命令到 master, 同步全量数据master 执行 bgsave 命令, 生成 rdb 快照, 并记录之后的写命令slave 收到快照后, 丢弃本地数据, 还原快照到内存数据库, 还原后, master 再把同步期间记录的写命令传给 slave, 同步结束增量同步每次 master 写操作后, 都会同步命令给 slave 执行...

基于内存的数据库, 内存比硬盘读取快太多单线程执行命令没有线程切换的消耗 redis 基于 c 语言实现的数据结构, 数据结构简单高效

stringlistsetsorted sethash

keys 和 scan 都可以用于搜索某个模式的 keykeys 会返回所有匹配的 key; scan 是利用游标, 迭代每次返回一部分 key, 并不是全部keys 在数据量大的 redis 中, 由于耗时久, 可能阻塞影响其他线程; scan 不糊阻塞其他线程keys# keys <pattern># 匹配 redis 中所有 a 开头的 keykeys a*# scan <cursor> [match pattern] [count count]# 游标.

先介绍这些概念:缓存穿透: 请求不存在的数据, 缓存中没有查到, 会去数据库中查找缓存击穿: 数据较为热点, 当 key 过期时, 同一时刻, 大量请求进来, 此时缓存还未存入, 请求都落到数据库查找缓存雪崩: 同一时刻, 大量设置过期时间的 key 失效缓存一致性: 缓存和数据库数据不一致解决办法:缓存穿透: 把这些不存在的数据也缓存起来, 值为 null, 设置较短的过期时间 (例如 30s), 避免攻击者恶意请求不存在的数据, 给数据库造成压力缓存击穿: 有 2 种方式设置热点

当 redis 占用内存超过 redis.conf 中配置的 maxmemory 最大内存值时, 会触发 redis 的内存淘汰策略noeviction 不淘汰任何 key (默认策略) all-keys-random 所有 key 随机删除 all-keys-lru 所有 key 中最近最少使用的优先删除 volatile-random 带过期时间的 key 随机删除 volatile-lru 带过期时间的 key 最近最少使用的优先删除 volatile-ttl 带过期时间的 key 快要

redis 的 key 过期, 有两种删除策略定时删除, 每隔 100ms 扫描部分有过期时间的 key, 执行删除惰性删除, 在获取 key 的时候, 会判断该 key 是否过期, 如果是, 那么删除该 key, 并返回 nil