all in one vps 炸了，救了半小时，真刺激。
HTTP 响应超时，SSH 连不上。VPS 后台显示 CPU 100%。
先创建一个快照，然后强制重启，快速进入 SSH 把服务都先关掉，删除缓存。
看起来是数据量上来后 redis 把内存吃光了，然后连带着其他服务一起无响应。数据量上来后，虽然给 redis 的数据设置了过期，但是越积越多。查一下有没有限制 redis 数据量的方法，而且感觉设置过期时间不是好办法，按命中时间来设置过期更合适。
HTTP 响应超时，SSH 连不上。VPS 后台显示 CPU 100%。
先创建一个快照，然后强制重启，快速进入 SSH 把服务都先关掉，删除缓存。
看起来是数据量上来后 redis 把内存吃光了，然后连带着其他服务一起无响应。数据量上来后，虽然给 redis 的数据设置了过期，但是越积越多。查一下有没有限制 redis 数据量的方法，而且感觉设置过期时间不是好办法，按命中时间来设置过期更合适。
🤣10
leveldb 和 redis 的性能对比。
Redis:
随机读取: 约 100,000 ~ 200,000 QPS (每秒查询次数)
性能稳定，延迟通常在微秒级(1-2μs)
批量读取效率高，可以一次获取多个键值
不会随数据量增长而显著降低性能
LevelDB:
随机读取: 约 60,000 ~ 100,000 QPS
延迟相对较高，通常在毫秒级(1-10ms)
读取性能会随数据量增长而下降
顺序读取性能好于随机读取
使用布隆过滤器优化读取性能
写入性能
Redis:
随机写入: 约 100,000 ~ 200,000 QPS
写入延迟稳定，微秒级
批量写入性能好
开启持久化会影响写入性能
LevelDB:
随机写入: 约 300,000 ~ 400,000 QPS
写入延迟较低，微秒到毫秒级
顺序写入性能极好，可达 600,000+ QPS
LSM-Tree 结构对写入特别友好
写入性能基本不随数据量变化
影响性能的因素
Redis:
内存大小和可用性
网络延迟和带宽
持久化策略(RDB/AOF)
数据结构的复杂度
单线程模型的限制
LevelDB:
磁盘性能(特别是 SSD vs HDD)
数据压缩率
缓存大小设置
后台合并(Compaction)的频率
读写比例
具体场景性能对比
小数据量随机访问:
Redis 表现更好，因为纯内存操作
LevelDB 需要磁盘 I/O，性能差距明显
大数据量写入:
LevelDB 可能表现更好，尤其是顺序写入
Redis 受内存限制，可能需要考虑内存淘汰
批量操作:
Redis 的多数据结构支持使得批量操作更高效
LevelDB 批量写入性能好，但批量读取相对较差
性能优化建议
Redis:
合理设置内存大小和淘汰策略
使用 Pipeline 减少网络往返
适当设置持久化策略
避免复杂的命令操作
LevelDB:
使用 SSD 存储
调整写入缓冲区大小
合理设置压缩策略
批量写入而不是单条写入
控制好 Compaction 频率
🐳1