76 lines
5.0 KiB
JSON
76 lines
5.0 KiB
JSON
{
|
|
"topic": "lua-bucketing-sync",
|
|
"type": "short_answer",
|
|
"schema_version": "1.0.0",
|
|
"generated": "2026-09-09T21:42:00+08:00",
|
|
"questions": [
|
|
{
|
|
"id": "sa-001",
|
|
"type": "short_answer",
|
|
"difficulty": 3,
|
|
"tags": [
|
|
"lua-bucketing-sync",
|
|
"time-bucket"
|
|
],
|
|
"question": "请说明时间片分桶（Bucketing）机制在此点赞系统中的设计思路，包括为什么需要分桶、分桶粒度如何选择，以及分桶对读写分离的贡献。",
|
|
"explanation": "本题考查对时间片分桶架构设计的综合理解，需要从动机、参数选择和架构价值三个维度回答。",
|
|
"answer": "时间片分桶将同一 10 秒窗口内的点赞请求聚合到同一个 Redis Key 中，核心目的是将高频写操作（每次点赞都写 DB）转化为低频批量写（每 10 秒批量同步一次）。分桶粒度选择 10 秒是在实时性和写入压力之间的平衡——太短则批量收益小、Key 数量多，太长则内存占用大、数据丢失风险增加。分桶实现了'热数据在 Redis、冷数据在 DB'的读写分离：用户的点赞状态实时从 Redis 读取保证即时性，写 DB 延迟不超过 10 秒保证最终一致性，大幅降低了数据库的写入 QPS。",
|
|
"keywords": [
|
|
"分桶",
|
|
"聚合写入",
|
|
"10 秒",
|
|
"读写分离",
|
|
"最终一致性",
|
|
"降低 DB QPS",
|
|
"批量同步"
|
|
],
|
|
"scoring_rubric": "答出聚合写入/减少 DB 写入次数给 1 分；答出 10 秒粒度及选择理由给 1 分；答出 Redis 与 DB 分工（热/冷数据分离）给 1 分；答出最终一致性语义给 1 分；答出分桶 Key 的命名规则（时间片作为 Key）给 1 分。满分 5 分。"
|
|
},
|
|
{
|
|
"id": "sa-002",
|
|
"type": "short_answer",
|
|
"difficulty": 4,
|
|
"tags": [
|
|
"lua-bucketing-sync",
|
|
"sync-job",
|
|
"lua"
|
|
],
|
|
"question": "请分析此系统中可能出现数据不一致的三种场景，以及系统如何通过补偿机制保证最终一致性。",
|
|
"explanation": "本题考查对分布式系统数据一致性问题的分析能力，需要列举具体故障场景并说明系统的容错设计。",
|
|
"answer": "场景一：定时同步任务宕机或重启，导致某些时间片的 Key 未被处理。补偿任务每天凌晨扫描所有残留 Key 并重新同步，确保数据不丢失。场景二：同步任务在 DB 写入后、Redis Key 删除前崩溃。下次同步会重复处理（因为 Key 还在），落库阶段需要做幂等处理（如 UPSERT 而非 INSERT）避免重复计数。场景三：并发取消点赞和同步同时发生——Lua 脚本保证了 Redis 内操作原子性，但落库阶段读取快照后到写入 DB 之间存在时间差，可能导致少量数据偏差，补偿任务的定时清理可以纠正。系统通过'Redis Lua 原子操作 + 定时批量落库 + 每日补偿兜底'三层机制保证最终一致性。",
|
|
"keywords": [
|
|
"宕机",
|
|
"残留 Key",
|
|
"补偿任务",
|
|
"幂等处理",
|
|
"UPSERT",
|
|
"最终一致性",
|
|
"三层机制"
|
|
],
|
|
"scoring_rubric": "每答出一个场景给 1 分（共 3 分），每答出对应的补偿/解决手段给 1 分（共 3 分），答出'最终一致性'总概念给 -1 分（扣分项不影响，此处视为加分）。满分 5 分。"
|
|
},
|
|
{
|
|
"id": "sa-003",
|
|
"type": "short_answer",
|
|
"difficulty": 5,
|
|
"tags": [
|
|
"lua-bucketing-sync",
|
|
"sync-job",
|
|
"lua"
|
|
],
|
|
"question": "如果要将此系统的 10 秒时间片粒度调整为 1 秒以提高实时性，需要改动哪些组件？会带来什么新的问题？请从代码层面和架构层面分别阐述。",
|
|
"explanation": "本题考查对系统参数调整的全局影响分析能力，需要从代码改动和架构代价两个角度深入思考。",
|
|
"answer": "代码层面需要改动：1) getTimeSlice() 方法的分桶公式从 (second/10)*10 改为直接使用秒数，或改为更细的计算逻辑；2) SyncThumb2DBJob 的 fixedRate 从 10000 改为更短的值（如 1000），但要注意任务执行时间不能超过调度间隔，否则任务堆积；3) SyncThumb2DBJob 的 second 计算逻辑需要同步调整。架构层面的问题：1) Key 数量增加 10 倍，内存占用显著增加；2) 批量合并效果减弱，数据库写入频率接近原来的 10 倍，失去了分桶的主要价值；3) 虚拟线程删除 Key 的并发压力增大；4) 补偿任务扫描的 Key 数量也增加 10 倍。建议的折中方案是采用滑动窗口或按热度分区，而非简单缩小时间片。",
|
|
"keywords": [
|
|
"getTimeSlice",
|
|
"fixedRate",
|
|
"Key 数量",
|
|
"内存",
|
|
"批量合并",
|
|
"任务堆积",
|
|
"滑动窗口"
|
|
],
|
|
"scoring_rubric": "代码改动点答出 2 个以上给 2 分；架构问题答出 2 个以上给 2 分；提出合理替代方案给 1 分。满分 5 分。"
|
|
}
|
|
]
|
|
} |