在开发过程中，我们为什么倾向于用 Redis 和 Lua 脚本的组合来完成对用户访问题目频率的统计，而不是单纯依赖 Redis 原生命令或数据库查询？
考察说明
考察对 Redis 与 Lua 脚本结合使用的优势及适用场景的理解。
回答思路
- 【回答框架 1】用户访问频率统计属于高并发写操作，需要原子性保证。Redis 单线程模型下，多个命令之间不是原子的，若使用 GET、INCR 组合可能因并发导致计数不准确，而 Lua 脚本执行时是原子的，Redis 保证同一脚本执行期间不会被其他命令插入，从而保证统计的正确性。
- 【回答框架 2】Lua 脚本将多条 Redis 命令封装为一次网络往返，减少网络开销，适合需要频繁操作的频率统计。同时脚本逻辑集中，便于维护和复用，避免客户端多次调用带来的性能损耗。
- 【回答框架 3】相比 Redis 事务（MULTI/EXEC），Lua 脚本更灵活，支持流程控制（如条件判断、循环），可实现更复杂的统计逻辑，如检查窗口期、计数上限等。事务虽有原子性，但无法在事务中根据中间结果决定后续操作。
- 【回答框架 4】频率统计还需考虑过期策略，Redis 的 EXPIRE 可结合设键，Lua 脚本可原子地设置键和过期时间，防止因过期设置遗漏导致数据堆积。同时，脚本应处理键不存在和过期判断，避免脏读；但需注意，分布式环境下 Lua 脚本并非解决分布式一致性，只保证单个 Redis 实例内的原子性。
- 【关键点 1】Redis 单线程模型下多命令组合不具备原子性，Lua 脚本执行时原子，保证计数不丢失。
- 【关键点 2】Lua 脚本减少网络往返，提升性能，并支持流程控制，比事务更灵活。
- 【关键点 3】频率统计需结合过期时间与键策略，Lua 可原子设置，但分布式环境需额外设计。
- 【易错点 1】避免认为 Lua 脚本可以保证分布式事务或跨实例一致性，它只保证单实例内原子性。
- 【易错点 2】注意避免在脚本中执行过长操作，否则会阻塞 Redis 其他请求。
- 【易错点 3】防止脚本逻辑复杂导致错误难以排查，应做好测试和异常处理。