主要观点总结
文章介绍了使用eBPF技术实现Redis大key实时发现的方案，解决了传统方法实时性差、需要修改Redis代码的问题。方案通过eBPF的uprobe机制，无需修改Redis代码即可实时统计大key，并通过用户空间程序将大key信息输出到控制台。同时，文章还讨论了优化方法，提高了方案的性能。
关键观点总结
关键观点1: Redis大key危害
频繁读写大key导致网络流量打满、影响其他正常请求，可能引发Redis Master阻塞不可用，处理解析大key导致客户端变慢。
关键观点2: 传统发现大key方案
如每天定时做RDB快照分析，但存在实时性差、可能漏掉过期时间很短暂的key等问题。
关键观点3: eBPF技术介绍
eBPF（Extended Berkeley Packet Filter）是Linux内核中动态插入“钩子”的技术，无需修改内核代码或重启系统。eBPF提供了uprobe类型的程序，可以插入钩子到Redis内部，实现不修改Redis代码的大key实时发现。
关键观点4: 实现方案
通过内核部分的eBPF程序采集Redis执行命令的关键信息，包括响应字节数、客户端ip、执行的命令等，判断响应字节数超过阈值后，将信息上报给用户空间程序处理。
关键观点5: 性能优化
通过优化eBPF程序，减少上下文切换次数，提高方案性能。使用bpftime项目等技术，进一步提高性能。
文章预览
相信很多小伙伴都知道 Redis 要尽量避免 大key 的读写， 网上也有很多文章在介绍如何拆分、如何解决大key问题，但如何找到大key这一问题很多文章都没有涉及。 在这篇文章里我将介绍一种完全无侵入（不改一行代码），轻量级但可以做到毫秒级实时发现大key的方案，你感兴趣吗？一起来看看吧！ 背景 为什么要治理Redis大key？ 频繁读写大key导致网络流量打满，影响其他正常请求！ 频繁读大key导致客户端响应缓冲区积压占用Redis内存，达到 maxmemory 阈值导致key被驱逐！ 导致 Redis Master 阻塞不可用，引发意外的主从切换！ 处理解析大key导致客户端变慢！ 传统发现Redis大key的方案有哪些？ 了解了那么多大key产生的危害，可见大key必须消除，但如何做到呢？ 以我们公司举例，之前我们通过每天凌晨定时给 Redis 做 RDB 快照分析找大key，但是这种方案存在
………………………………
