【问题描述】：JOY x 小猪妖奇遇乐园会场活动中奖用户无法填写地址， 中奖后我的奖品无中奖信息展示
https://prodev.m.jd.com/mall/active/yBtz1ak3u77cLxDxNSiWGpQRqYj/index.html
【问题影响】：
影响时段：22:58-23:18
用户体验影响：热点用户咨询量20+.,
【原因分析】：
根因分析：JIMDB里是以项目维度存储的用户pin，项目ID，获奖明细等信息。当晚共有1700个用户中了实物奖，导致JIMDB存放了一个1700个元素的hash结构，value值过大，任一用户查中奖相关信息(queryInteractiveRewardInfo)看都会全量获取这个hash数据（使用的是hGetAll方法，拿到所有用户的中奖信息）。出问题的时间点查看中奖信息的用户较多，产生大概每秒500次访问请求，导致CPU打满，内存积压最终实例内存打满被杀。
5001700500b（单个用户存储大小） ≈ 400M/s 的瞬时内存写入
【处理过程】：问题发生、发现到解决整体时间线
22:58 JIMDB团队侧收到3248集群一个实例故障切换告警，排查故障原因；
23:02 发现切换上来的实例发生阻塞，定位到大量hgetall访问大key，CPU打满；
23:04 联系业务研发反馈该情况；
23:08 该实例内存持续积压被杀，该分片数据丢失；
23:15 经业务确认，JIMDB团队执行切换空分片预案；
23:18 分片切换完成，可用性恢复。
【后续改进】：
短期方案：使用hGet方法，把全量获取这个key改成只获取该用户的中奖信息（1700个元素中的1个），会大大减小CPU开销。已压测通过，jimdb奖励记录数据开发回源能力，已上线。
长期方案：修改数据结构，不使用一个hash结构存储所有地址。
梳理项目中所有因活动差异可能产生的大key。重点排查hgetall等操作。
测试优化：压测方案对该场景进行压测数据高保真补充，原压测仅使用了预发活动id（压测脚本中查询接口queryInteractiveRewardInfo脚本中入参未传addressFlag，未调用查询用户是否需要填写地址），关注了查询qps量级，但后续需要还原大量级的中奖人数下查询地址场景已确保全方位的高保真场景；