目前有个服务 A 有 N 个节点,现需要从某个服务 B rpc 广播到 A 的各节点去获取数据,数据是内存数据(有状态),目前感觉广播 rpc 太费,而且如果某个节点 timeout,或者崩了没回来怎么办,因为从 B 发出去请求要等所有数据返回,只要有一个节点 timeout 没回来,B 就要等到这个 timeout 。 想过 A 服务各节点主动上报数据状态到某个新服务 C,但我们想要的是全量数据,不是摘要数据,所以 B 的完整数据都要推到 C(属于 C 里暂存 B 的副本),如果 C 里暂存的数据太多了怎么办,也分 N 个节点么,那么问题又回到了原点。暂时的做法是把数据推到 redis,但数据多了,频繁修改上报,怕 redis 也扛不住(redis 这块没做过详细的压力测试,此场景下不敢滥用),大家有没有什么好的想法?
1
soulzz 2020-05-27 16:04:43 +08:00
kafka 它不香吗
A 的各个节点按照分区取模发 B 再来消费,实时性很强 代码的复杂度一下子就降低了 |
2
soulzz 2020-05-27 16:05:32 +08:00
B 处理完发到另一个 topic
C 监听这个 topic |
3
LennieChoi OP @soulzz 其实不是一个消费的场景。举个例子,A 的 a 节点存放北京的某货源情况,b 节点存放上海的某货源情况,以此类推,现我要给客户展示全国的货源情况,数据如果太大,每个城市的数据可以截取一部分,是个实时抓取数据的场景
|