不要用DRPC批量处理大数据：设计初衷决定了适用边界

Storm的DRPC提供了应用程序和Topology之间同步交互的接口，让外部程序可以直接调用Storm的并发处理能力去处理数据，处理完再把结果同步返回给调用方——这种方式在数据量不大的场景下通常没什么问题，但一旦被用来批量处理大数据，问题会变得明显：一是Topology处理这批数据可能来不及在调用方设定的超时时间内返回结果，导致调用直接超时失败；二是批量处理大数据会让整个集群的负载短时间内剧烈升高，处理完之后又迅速降回来，负载曲线极不平滑，这种脉冲式的负载模式对集群资源规划和稳定性都不友好。这两个问题的根源不是DRPC实现得不够好，而是DRPC这种同步调用、等待返回的交互模式，从设计初衷上就不是为批量处理大数据这类场景准备的——Storm整体的设计取舍是在”时效性”和”批量处理能力”之间更看重前者，它擅长的是持续、细粒度地处理无限数据流，而不是一次性吞下一大批数据再同步返回结果。如果业务真正的需求是准实时地处理大批量数据，更合适的选择是Spark Streaming这类专门针对批量和准实时场景设计的框架。这个案例给出了一条技术选型的重要提醒：一项技术组件提供的某个具体接口（这里是DRPC）能不能用在某个场景，不能只看这个接口”技术上能不能调通”，还要审视这个接口所属的整个技术体系在设计之初真正针对的是什么场景——把一个为”持续流式处理、追求时效性”设计的系统，硬用在”批量、同步等待”这种和它设计初衷相悖的场景上，即使短期内能跑通，也很容易在真实规模下暴露出超时和负载不均这类深层次的不适配问题，而这类问题往往不是靠调参数就能根治的，需要回到”这个场景本该用什么类型的工具”这个更基础的问题上重新选型。