面试题答案
一键面试缓存场景
- 影响：
- 数据一致性问题：部分重同步失败导致缓存与数据库数据不一致，应用从缓存读取到旧数据，影响业务展示正确性。例如电商商品价格，用户看到旧价格可能导致交易异常。
- 缓存击穿：若重同步丢失的数据是热点数据，会使缓存缺失，大量请求直接打到数据库，增加数据库压力，甚至导致数据库崩溃。
- 应对策略：
- 技术选型：采用Redis Cluster模式，多节点备份数据，增加数据可靠性。同时结合哨兵（Sentinel）机制，自动检测主节点故障并进行故障转移。
- 架构调整：在应用层增加缓存预热机制，启动时预先加载热点数据到缓存。设置多级缓存，如浏览器缓存、CDN缓存、应用本地缓存和Redis缓存，减轻Redis压力。
- 代码层面：在更新数据库时，采用双写模式，先更新数据库，再删除Redis缓存。读取数据时，若缓存缺失，从数据库读取后，先写入缓存再返回给应用，同时记录缓存重建日志，以便排查重同步问题。
消息队列场景
- 影响：
- 消息丢失：重同步数据丢失可能导致部分消息未被正确持久化，消费者无法消费到完整消息，业务流程中断。如订单系统中，支付消息丢失，导致订单状态无法更新。
- 数据不一致：消息的部分丢失可能使上下游业务数据不一致。例如库存系统收到减少库存消息，但订单系统因消息丢失未记录订单，造成库存与订单数据不匹配。
- 应对策略：
- 技术选型：选用支持持久化和高可用性的消息队列，如Kafka结合Redis。Kafka负责消息的可靠存储和分发，Redis作为辅助存储，存储消息的关键元数据。
- 架构调整：构建消息确认机制，生产者发送消息后等待Broker确认，Broker持久化消息后返回确认。消费者消费消息后也向Broker发送确认。增加消息补偿机制，定期检查未确认消息，重新发送。
- 代码层面：在生产者端，为每个消息生成唯一ID，记录发送状态。消费者端，对已消费消息进行幂等处理，防止重复消费。同时，在Redis中记录消息的消费进度，以便故障恢复后从正确位置继续消费。
实时统计场景
- 影响：
- 统计数据不准确：重同步数据丢失会导致实时统计数据不完整，影响业务决策。如网站实时访问量统计，因部分数据丢失，统计结果比实际访问量低，无法准确评估网站流量。
- 趋势分析偏差：由于数据丢失，实时统计数据的趋势分析不准确，误导业务方向。例如APP日活跃用户数趋势图因数据丢失出现异常波动，无法真实反映用户活跃度变化。
- 应对策略：
- 技术选型：使用Redis的HyperLogLog数据结构进行基数统计，结合InfluxDB等时间序列数据库存储历史统计数据。InfluxDB可保证数据的持久化和查询效率，与Redis配合实现高效的实时统计。
- 架构调整：建立数据备份和恢复机制，定期将Redis中的统计数据备份到持久化存储（如硬盘）。增加数据校验机制，定时对比不同数据源的统计数据，发现差异及时修复。
- 代码层面：在统计逻辑中，对每次统计操作进行日志记录，包括时间、操作类型、数据来源等信息。若发生重同步数据丢失，可根据日志进行数据修复。同时，优化统计算法，使其具有一定的容错性，在部分数据丢失时仍能给出接近准确的统计结果。