目前有个服务 A 有 N 个节点，现需要从某个服务 B rpc 广播到 A 的各节点去获取数据，数据是内存数据(有状态)，目前感觉广播 rpc 太费，而且如果某个节点 timeout，或者崩了没回来怎么办，因为从 B 发出去请求要等所有数据返回，只要有一个节点 timeout 没回来，B 就要等到这个 timeout 。 想过 A 服务各节点主动上报数据状态到某个新服务 C，但我们想要的是全量数据，不是摘要数据，所以 B 的完整数据都要推到 C(属于 C 里暂存 B 的副本)，如果 C 里暂存的数据太大带宽服务器多了怎么办，也分 N 个节点么，那么问题又回到了原点。暂时的做法是把数据推到 redis，但数据多了，频繁修改上报，怕 redis 也扛不住(redis 这块没做过详细的压力测试，此场景下不敢滥用)，大家有没有什么好的想法？

kafka 它不香吗
A 的各个节点按照分区取模发
B 再来消费，实时性很强
代码的复杂度一下子就降低了

B 处理完发到另一个 topic
C 监听这个 topic

其实不是一个消费的场景。举个例子，A 的 a 节点存放北京的某货源情况，b 节点存放上海的某货源情况，以此类推，现我要给客户展示全国的货源情况，数据如果太大，每个城市的数据可以截取一部分，是个实时抓取数据的场景