一、剧情核心冲突与细节
数据库设计阶段，DBA 老周提出：“订单表预估年数据量 8000 万条，单库单表肯定撑不住，分库分表势在必行！” 但团队对分片策略产生争议：小李建议 “按订单 ID 哈希分库”，简单易实现；老周主张 “按用户 ID 哈希分库 + 订单创建时间分表”，理由是用户查询订单时多按 “用户 + 时间” 筛选，该策略能减少跨库查询。更紧急的是，测试发现 “预约购票” 流程中，当支付服务超时后，出现 “库存已扣减但订单未支付” 的超售风险，分布式事务补偿机制失效。
二、知识点融入与解决路径（深化技术细节）
分库分表的 “业务驱动” 策略：最终确定 “双维度分片” 方案：①分库键：用户 ID（哈希取模，分为 4 个库），确保同一用户的订单落在同一库，减少跨库查询；②分表键：订单创建时间（按季度分表，每个库分 4 个表），兼顾查询效率与表数量控制。ShardingSphere 配置细节：①绑定表：将 “订单表” 与 “订单明细表” 绑定，确保关联查询在同一分片；②广播表：将 “景区信息表”“商品分类表” 设为广播表，每个库都存储全量数据，避免跨库关联；③分片算法：用户 ID 采用 “哈希取模算法”，订单时间采用 “范围分片算法”（如 2024Q1、2024Q2）。同时设计 “历史数据归档策略”，超过 1 年的订单数据归档到低成本的 OSS 对象存储，查询时通过数据中台透明访问。
分布式事务的 “SAGA + 本地消息表” 双重保障：针对 “预约购票” 流程，优化事务方案：①第一步：预约服务创建订单（状态 = 待支付），同时写入 “本地消息表”（消息状态 = 待发送）；②第二步：调用库存服务扣减库存，库存服务扣减成功后写入本地消息表；③第三步：调用支付服务，若支付成功，支付服务发送 “支付成功” 消息到 RabbitMQ；若支付超时 / 失败，发送 “支付失败” 消息；④第四步：预约服务消费消息，更新订单状态，同时更新本地消息表状态；⑤补偿机制：定时任务（每 5 分钟）扫描本地消息表中的 “待发送” 消息，重新发送，确保消息不丢失；若库存扣减后支付超时，触发补偿事务（库存服务恢复库存，预约服务取消订单）。通过 Seata 框架实现 SAGA 事务的协调，本地消息表确保消息持久化，双重保障数据一致性。
时序数据的 “InfluxDB+Telegraf” 存储方案：客流监测数据（每 30 秒采集一次，包含景区 ID、实时人数、排队时长等）属于典型时序数据，采用 InfluxDB 存储：①数据模型设计：measurement=tourist_flow，tag=scenic_id（景区 ID），field=people_count（人数）、queue_time（排队时长），timestamp = 采集时间；②数据写入：部署 Telegraf Agent 在各景区采集设备，通过 MQTT 协议接收数据，自动写入 InfluxDB；③数据保留策略：设置 3 个保留策略 ——rp_7d（保留 7 天原始数据，采样间隔 10 秒）、rp_30d（保留 30 天数据，采样间隔 1 分钟）、rp_1y（保留 1 年数据，采样间隔 1 小时），通过连续查询（CQ）自动进行数据降采样，减少存储成本；④查询优化：创建 tag 索引（scenic_id），查询时指定景区 ID 和时间范围，避免全表扫描。
三、考点深度关联
本单元深化了 “分库分表的双维度分片策略”“分布式事务的双重保障机制”“时序数据的存储与降采样方案”，这些是综合知识和案例分析的高频考点。例如分库分表的绑定表、广播表配置，分布式事务的补偿逻辑，均是真题中 “数据库性能优化”“数据一致性保障” 场景的核心答案要点；而 InfluxDB 的使用也契合 “新兴技术架构” 的考察趋势。
