如何设计可处理百万级请求的Elasticsearch抓取与gRPC调用系统

核心架构思路 #

采用分层异步分布式架构，把整个流程拆分为数据抽取、规则处理、gRPC调用、结果落库四个独立模块，依托流处理与分布式调度框架，支撑百万级任务的水平扩展与高性能执行。

模块详细设计 #

1. Elasticsearch 数据抽取模块 #

• 用ES Scroll API + 分片并行拉取：避免全量查询内存溢出，按ES集群的分片维度分配拉取任务，每个工作节点负责1~N个分片的数据扫描，提升拉取效率
• 增量拉取优化：维护全局last_processed_ts标记，仅拉取上次处理完成后新增的请求数据，减少重复计算
• 流量控制：动态调整Scroll的size参数和工作节点并发数，避免对ES集群造成过大压力

2. 自定义规则处理模块 #

• 轻量可扩展规则引擎：基于Groovy表达式或自定义QL实现用户规则，规则存储在配置中心，支持热更新，无需重启服务
• 分布式规则执行：将编译后的规则片段分发到各个工作节点并行执行，过滤不符合规则的请求并按要求修改请求结构，避免单点瓶颈
• 规则预校验：用户提交规则时自动做语法校验和模拟执行，确保规则合法且不会引发性能问题

3. gRPC服务调用模块 #

• 连接池化与多路复用：基于Netty实现gRPC连接池，复用TCP连接减少握手开销，每个工作节点维护独立的连接池，按需扩容
• 异步批量调用：将过滤后的请求按gRPC接口分组，批量发起异步调用，提升吞吐量
• 重试与熔断：采用指数退避策略处理调用失败的请求；配置熔断阈值，当服务不可用时自动降级，将失败请求暂存到消息队列待后续重试

4. Hadoop 结果落库模块 #

• 批量Parquet写入：将gRPC响应结果按时间窗口聚合，以Parquet格式批量写入HDFS，减少小文件数量，提升后续Hive/Spark查询效率
• 分布式写入协调：通过YARN调度写入任务，每个工作节点负责对应批次的结果写入，完成后同步Hive元数据
• 一致性保障：写入前将结果暂存本地磁盘，写入成功后删除缓存；写入失败则触发重试，避免数据丢失

可扩展性与性能保障 #

• 水平扩展：所有工作节点（数据抽取、规则处理、gRPC调用、结果写入）均可通过K8s或YARN动态扩容，根据任务负载自动调整节点数量
• 流处理框架支撑：基于Flink或Spark Streaming实现端到端流式处理，将整个流程转化为流式任务，支持动态扩展与故障容错
• 全局状态管理：用Redis或ZooKeeper维护全局处理状态（如last_processed_ts、失败任务队列），确保集群节点状态一致
• 监控告警：采集各节点的QPS、延迟、错误率等指标，通过Prometheus+Grafana监控；配置告警规则，负载过高或服务异常时及时通知

容错与可靠性 #

• 任务幂等性：为每个请求生成唯一ID，处理前先校验该ID是否已处理，避免重复执行
• 失败任务重试：将调用或写入失败的任务存入Kafka队列，启动独立的重试节点异步处理，重试次数可配置
• 数据备份：ES请求数据、HDFS结果数据均开启副本机制，确保数据不丢失

内容的提问来源于stack exchange，提问作者Rishav Jayswal