如何设计面向订单反欺诈的高写入量分布式存储架构（无商用组件）

核心设计前提对齐 #

先明确所有约束条件：

• 禁止使用任何开源/商用现成存储组件，仅用普通服务器的内存、磁盘资源
• 支持水平扩展，日写入量10M次，单订单大小为1-10KB
• 需支持三个API：/insertOrder、/getLongestNOrdersByDuration、/getShortestNOrdersByDuration

整体架构分层 #

整套系统分为三层，所有逻辑均自主实现，无第三方组件依赖：

• 无状态协调节点：承接所有API请求，做请求路由、结果聚合，可无限水平扩展
• 轻量元数据集群：由3个节点组成，自主实现Raft共识算法保证元数据一致性，存储「时间分片范围→对应存储节点列表」的映射关系，元数据总量极小，性能无瓶颈
• 分片存储节点：负责实际的订单数据存储、索引构建，节点数量可随数据量增长随时扩容

分片规则设计 #

所有订单按beginTime字段做时间分片，单分片覆盖时间范围可配置（默认按天分片，单日数据量最大为100GB，普通服务器完全可承载）：

• 写入时直接按订单的beginTime匹配对应分片，路由到对应存储节点
• 查询时按输入的startTime、endTime定位所有覆盖的分片，并行查询后聚合结果

核心流程设计 #

/insertOrder写入流程 #

1. 协调节点接收订单参数，提取beginTime字段查询元数据集群，拿到对应分片的主存储节点
2. 主存储节点将订单数据以追加写方式写入本地块文件，同步将写入请求转发给2个从副本节点
3. 只要有1个从节点返回写入成功，主节点立即给协调节点返回写入成功响应，异步更新本地索引

写入全程为顺序IO，单节点可支持每秒数千次写入，远高于10M日写入的115QPS平均要求，性能完全冗余

Top N查询流程（最长/最短逻辑一致） #

1. 协调节点解析查询的时间范围，查询元数据拿到所有涉及的分片列表，给每个分片的存储节点下发查询请求
2. 每个存储节点本地遍历对应排序的索引，过滤出beginTime符合时间范围的前N条订单ID返回给协调节点
3. 协调节点将所有分片返回的结果做全局归并排序，取出全局Top N的订单ID，再到对应存储节点拉取完整订单Blob返回

存储节点本地结构设计 #

原始订单存储 #

• 订单数据写入固定大小（默认1GB）的块文件，写满就生成新块，全程顺序写无随机IO
• 本地维护orderId到「块文件ID、偏移量、长度」的哈希索引，可毫秒级定位单条订单数据

本地索引结构 #

每个分片自主维护三个内存+磁盘混合存储的跳表索引，热点索引全部放内存，冷索引自动刷盘：

1. beginTime排序跳表：key为beginTime，value为对应时间的订单ID列表，用于快速过滤时间范围
2. 时长升序跳表：key为「订单时长、beginTime」，value为订单ID，用于最短N条查询，直接从表头遍历即可拿到最短订单
3. 时长降序跳表：key为「负的订单时长、beginTime」，value为订单ID，用于最长N条查询，直接从表头遍历即可拿到最长订单

水平扩展与容错方案 #

水平扩展 #

当存储节点容量不足时，直接新增服务器，将历史无写入的冷分片迁移到新节点，更新元数据映射即可，全程不影响线上写入，存储容量随节点数量线性增长。

容错设计 #

• 每个分片默认存3副本，主节点负责写入，从节点负责承接读请求分摊压力
• 单节点故障时，元数据集群自动将对应分片的主节点切换为健康的从节点，故障切换耗时在秒级，不影响服务可用性

内容的提问来源于stack exchange，提问作者Andriy Shevchenko