面试题答案
一键面试1. 数据类型分析与修复思路
- 计数器型（粉丝数量）
- 日志记录：系统在每次粉丝数量变动时，记录详细的操作日志，包括操作类型（关注/取消关注）、操作时间、操作的用户ID等信息。例如，使用MySQL的二进制日志或者专门设计的日志表来记录这些信息。
- 定期对账：设定一个定时任务（如每天凌晨低峰时段），通过扫描日志，重新计算每个用户的粉丝数量。具体做法是统计所有关注操作记录数减去所有取消关注操作记录数，得到该用户正确的粉丝数量，然后更新到数据库中。
- 实时补偿：在高并发场景下，当发现某个用户粉丝数量不一致时（如通过监控系统检测到），可以从当前时间往前追溯一小段时间（如5分钟）的日志记录，快速进行局部重新计算并修正。
- 列表型（关注列表）
- 版本控制：为每个用户的关注列表添加版本号。每次关注或取消关注操作时，版本号递增。同时，记录操作日志，日志中包含操作类型、被操作的用户ID以及操作发生时的版本号。
- 基于版本比对：在修复数据一致性时，比较不同副本或者不同存储节点上关注列表的版本号。如果版本号不一致，以版本号高的为准。对于低版本的关注列表，根据日志中记录的操作，按照版本号顺序依次应用这些操作，将其更新到最新版本。
- 双向校验：除了版本比对，还可以通过双向校验来确保关注关系的一致性。即A关注B，那么B的粉丝列表中应该有A。在修复时，检查这种双向关系，对于缺失的关系，根据日志进行添加。
2. 高并发场景下的修复效率优化
- 异步处理：将数据一致性修复任务放入消息队列（如Kafka）中，由专门的消费者线程池进行处理。这样可以避免修复任务直接阻塞系统的正常业务流程，保证在高并发情况下系统的正常运行不受太大影响。
- 分布式计算：对于大规模数据的修复，可以采用分布式计算框架（如Spark）。将数据按照一定规则（如用户ID哈希）进行分区，并行处理各个分区的数据修复任务，提高修复效率。
- 缓存辅助：在修复过程中，使用缓存（如Redis）来暂存中间计算结果或者频繁访问的数据。例如，在重新计算粉丝数量时，可以将部分用户的操作记录缓存起来，减少对数据库的频繁读取。
3. 对系统正常运行影响的控制
- 资源限制：为修复任务分配固定的系统资源，如CPU、内存和数据库连接数。避免修复任务占用过多资源导致系统正常业务无法运行。例如，通过设置线程池的最大线程数、数据库连接池的最大连接数等方式进行资源限制。
- 监控与预警：建立实时监控系统，对修复任务的执行情况、系统资源使用情况以及业务指标进行监控。当发现修复任务影响到系统正常运行（如响应时间变长、业务请求失败率上升等）时，及时发出预警，并暂停或调整修复任务的执行策略。
- 灰度发布：在实施新的数据一致性修复策略时，先在一小部分用户（如1%的用户）中进行灰度发布，观察修复策略对系统正常运行的影响。如果没有问题，再逐步扩大到更多用户，直到全量用户。