Logic Behind Client Information Sync #79
-
|
While reading other discussions and a code ( Mochi-broker modified code ), From my understanding,
Is my understanding correct @wind-c? Also, I further want to know what the logic behind |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Each node saves the subscription tree of other nodes (only the subscription not the client, which reduces memory footprint) and generates the corresponding routing table (map[subscription]nodes), subscription data is synchronized between nodes via raft. The logical flow is publish -> local subscription tree -> local subscription tree of the other nodes -> routing table -> grpc to node. The same logic applies to shared subscriptions. The difference is that the shared subscription takes precedence on the local node, and if the local node does not have this shared subscription, it will randomly select the node with the shared subscription to send the message. A non-shared subscription is sent to all nodes that have the subscription. Have I explained myself clearly? If you have any questions please leave a message! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, got it! |
Beta Was this translation helpful? Give feedback.
Each node saves the subscription tree of other nodes (only the subscription not the client, which reduces memory footprint) and generates the corresponding routing table (map[subscription]nodes), subscription data is synchronized between nodes via raft. The logical flow is publish -> local subscription tree -> local subscription tree of the other nodes -> routing table -> grpc to node. The same logic applies to shared subscriptions. The difference is that the shared subscription takes precedence on the local node, and if the local node does not have this shared subscription, it will randomly select the node with the shared subscription to send the message. A non-shared subscription is sen…