众所周知Redis是基于内存的数据库,其所有的数据都在内存中,而内存又是属于成本较高且容量有上限的硬件资源,因此需要时刻关注Redis内存的情况 。特别是在生产环境,Redis内存占用过高会带来很多风险,甚至是灾难性的后果:
- 庞大的数据导致持久化时间冗长,期间大量消耗主机资源,服务器压力陡升
- Redis启动过程变慢,主从全量同步耗时增加,需要较长时间才能达到可用状态
- 一旦达到Redis内存上限,轻则无法写入数据,重则直接宕机,且宕机后无法立即恢复,除非丢弃所有数据 。
- 内存数据分布准实时监控
- 数据写入流量实时监控
Redis为了避免进程退出导致内存数据的永久丢失,可以定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复 。Redis持久化分为RDB持久化和AOF持久化:
- RDB(Redis DataBase)持久化:将当前内存中的Redis完整数据保存到硬盘
- AOF(AppendOnly File)持久化:将写操作命令追加的保存到硬盘
![Redis内存数据监控实战](http://img.yunnanlong.com/220624/155A2N04-0.png)
分析工具选择使用redis-rdb-tools + sqlite + 自研工具 。redis-rdb-tools是一款开源的以python语言开发的解析redis的rdb文件的工具,它可以生成内存报告、转储文件到JSON以及对两个rdb文件进行比较 。这里主要用它生成csv格式的内存报告,执行命令:
/redis-rdb-tools-rdbtools-0.1.14/build/lib/rdbtools/cli/rdb.py-c memory /redis/rdb/dump-main1.rdb > /redis/rdb/report-main1.csv
生成的报告内容如下:![Redis内存数据监控实战](http://img.yunnanlong.com/220624/155A22594-1.png)
其中:
Database:key所在的数据库编号Type:key的数据结构key:key的名称size_in_bytes:value的大小encoding:底层存储的编码类型num_elements:包含的元素数量,例如string里有多少字符、hash里面有多少项、set里面有多少元素len_largest_element:包含的所有元素中的最大长度expiry:key的过期时间接下来可以对这份报告进行统计,由于csv文件不方便进行各类统计查询,可以将其导入数据库 。这里选择最轻量级的sqlite:
sqlite3/redis/sqlite/main1-memory.db
createtable memory(database int,type varchar(128),key varchar(128),size_in_bytesint,encoding varchar(128),num_elements int,len_largest_elementvarchar(128),expiry varchar(128));
.modecsv memory
.import/redis/rdb/report-main1.csv memory
之后就可以进行下一步操作:统计数据并上报监控预警平台 。在开发设计阶段对redis的key命名时,都会增加一个业务缩写前缀,例如:User:xxxxxx、Bill:xxxx,这样可以方便进行统计查询,能够快速得知每一块业务的key的数量和大小 。因为所有的操作均在linux上,所以需要开发一个.netcore的统计上报工具部署在服务器上,进行统计和上报每一块业务的数据量 。工具核心统计代码如下:
推荐阅读
- 干货 | 云数据中心网络与SDN
- 更新后蜂窝数据问题
- 「收纳小妙招」数据线收纳,数据线如何收纳
- 魅蓝blus蓝牙耳机送数据线吗 Blus降噪耳机打几分
- HTC有3G运行内存手机吗
- 内存泄漏问题分析之非托管资源泄漏
- 企业数据上云最佳实践
- 数据库备份到OSS
- 基于对象存储OSS的数据库低成本实时备份最佳实践
- mann zug 5s root,公网的Redis还敢不设置密码