在项目中，你是如何设计和实现 Redis 缓存的？具体使用了哪种 Redis 数据结构，并说明选择的理由和适用场景。

回答思路

1. 【回答框架 1】在项目中实现 Redis 缓存，通常遵循缓存读写的基本流程：先查缓存，命中则直接返回；未命中则查数据库，将结果写入缓存并设置过期时间，返回给调用方。同时需要考虑缓存穿透、击穿、雪崩等问题的防护，例如使用空值缓存、布隆过滤器、互斥锁或逻辑过期等手段。
2. 【回答框架 2】数据结构的选择取决于业务场景。例如，对于热点数据的简单键值存储，使用 String 类型，可设置 TTL 并支持原子操作；对于对象或用户信息的存储，可以使用 Hash，方便修改单个字段；对于排行榜或计数器，则使用 ZSet 或 String 的 INCR 命令；对于分布式锁，通常使用 String 结合 SET NX EX 或 Redisson 实现。
3. 【回答框架 3】在选型时，需要权衡数据结构的性能、内存占用和操作复杂度。例如，String 类型内存占用相对较高（因为包含元数据），而 Hash 适合存储紧凑对象；SDS 简单动态字符串适合存储小数据，而 ZSet 适合排序。需要根据数据量、访问模式、一致性要求等因素做出选择。
4. 【回答框架 4】实际项目中，还需要考虑缓存与数据库的一致性。常见策略是 Cache Aside Pattern，即更新数据库后删除或更新缓存，并处理可能的并发问题。对于强一致场景，可能需要使用事务或消息队列，但通常业务可接受最终一致性。
5. 【回答框架 5】在实施过程中，需要监控缓存的命中率、内存使用量、过期策略等，并根据业务特征调整过期时间、缓存大小或淘汰策略（如 LRU/LFU）。
6. 【关键点 1】缓存读写基本流程：先查缓存，未命中则查库并回填，设置过期时间。
7. 【关键点 2】根据业务场景选择数据结构：String 适合简单值，Hash 适合对象，ZSet 适合排序，Set 适合去重。
8. 【关键点 3】必须考虑缓存穿透、击穿、雪崩的防护方案，如空值缓存、布隆过滤器、互斥锁。
9. 【关键点 4】缓存与数据库一致性通常采用 Cache Aside 模式，更新DB后删缓存或更新缓存。
10. 【关键点 5】监控缓存命中率和内存使用，调整过期时间与淘汰策略。
11. 【易错点 1】误以为缓存能保证数据强一致，实际上缓存与数据库的同步存在延迟，通常只能保证最终一致性。
12. 【易错点 2】忽视缓存穿透问题，导致大量请求直接打到数据库，应采用空值缓存或布隆过滤器。
13. 【易错点 3】数据结构选型不当，如用 String 存储大对象导致内存浪费，应使用 Hash 或考虑序列化压缩。