面试题：复杂业务场景下Redis rehash时机的精准把控与优化策略

Question

在一个涉及多种数据类型频繁交互、数据量动态变化且对响应时间要求极高的复杂业务场景中，如何精准地把控Redis rehash的时机？请提出一套完整的优化策略，并说明策略在不同极端情况下（如数据量瞬间剧增、读写请求突然暴增）的有效性及应对措施。

Answer 1

优化策略

1. 监控内存使用：通过定期（例如每秒）使用 INFO memory 命令获取 Redis 内存使用情况，包括 used_memory 等指标。当内存使用达到预先设定的阈值（如80%）时，考虑手动触发或调整 rehash 策略。可以使用脚本（如 Python 结合 Redis 客户端库）实现自动化监控和决策。
2. 关注负载因子：Redis 内部维护负载因子（哈希表已使用的桶数与总桶数的比率）。虽然无法直接获取此值，但可通过观察键的数量增长和内存使用趋势来间接推断。如果键数量快速增长而内存使用没有显著下降（意味着哈希表桶的利用率增加），可能需要提前触发 rehash。
3. 主动触发：在业务低峰期，手动执行 CONFIG SET hash-max-ziplist-entries <new_value> 和 CONFIG SET hash-max-ziplist-value <new_value> 等配置参数，以调整哈希表的编码方式，从而触发 rehash。也可以使用 FLUSHDB 或 FLUSHALL 命令后重新加载数据，强制进行一次全面的 rehash，但要注意此操作会清空数据，需谨慎使用。

不同极端情况的有效性及应对措施

1. 数据量瞬间剧增：
   • 有效性：上述策略中监控内存使用和关注负载因子仍然有效。数据量剧增会导致内存使用快速上升，负载因子增大，从而触发优化策略。
   • 应对措施：快速检查内存使用情况，如果超过阈值，立即手动触发 rehash，以避免哈希表性能急剧下降。同时，可以考虑临时增加 Redis 实例的内存资源，以应对数据量的突发增长，待数据量稳定后再调整资源。
2. 读写请求突然暴增：
   • 有效性：监控内存和负载因子的策略在这种情况下仍可作为长期优化的依据，但在读写请求暴增的瞬间，直接调整 rehash 可能会加重系统负担。
   • 应对措施：首先启用缓存分层策略，如在应用层增加本地缓存（如 Ehcache 等），减少对 Redis 的直接请求。对于写请求，采用批量写入的方式，并在业务逻辑允许的情况下，适当延迟写入，以降低瞬间的写压力。在请求高峰过去后，根据监控指标适时触发 rehash 操作，对 Redis 进行优化。