MQTT Broker Message Ordering With Master-Follower Counters
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing MQTT broker systems face challenges in efficiently managing and maintaining consistent ordering of messages, especially in distributed environments with limited bandwidth and high latency, leading to potential message loss and delivery issues.
Innovation Solution
A method involving a master node in a broker cluster that generates a key for each message using a client identifier and sequence number, stored as a key-value pair, with replication to follower nodes, ensuring message ordering and fault tolerance through consistent hashing and failover mechanisms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If a distributed broker cluster is used to handle large volumes of messages, then the system's message handling capacity is improved, but maintaining consistent message ordering across multiple nodes becomes more complex
Solution Approach 1:
The patent segments the broker cluster into master nodes and follower nodes, with each node maintaining separate counters for message sequencing. This segmentation allows the system to handle large volumes of messages across multiple nodes while maintaining ordering consistency within each node's responsibility scope.
Solution Approach 2:
The patent implements preliminary action by having follower nodes pre-synchronize their counters with master nodes before potential failover events. This ensures that when a master node fails, the follower node can immediately take over message ordering without disruption, maintaining consistent ordering across the distributed system.
2Reliability
If message replication to follower nodes is implemented for fault tolerance, then system reliability is improved, but the overhead of synchronizing counters and messages increases system complexity
Solution Approach 1:
The patent uses copying by replicating message data and counter state from master nodes to follower nodes. This allows follower nodes to serve as backups for fault tolerance while keeping the synchronization mechanism relatively simple - followers receive and store copies of master node state without requiring complex bidirectional coordination.
Solution Approach 2:
The patent introduces an intermediary mechanism where master nodes act as mediators that push counter and message state to follower nodes. This intermediary approach simplifies the system by having a single direction of synchronization (master to follower) rather than requiring complex peer-to-peer synchronization protocols between all nodes.
3Manufacturing precision
If strict monotonic counter incrementing is enforced to ensure message ordering, then message ordering precision is improved, but the system's flexibility in handling node failures and reconnections is reduced
Solution Approach 1:
The patent applies preliminary action by pre-synchronizing follower node counters with master node counters before failover events occur. This ensures that when a master node fails, the follower can immediately resume strict monotonic incrementing from the correct sequence point, maintaining ordering precision without requiring complex recovery negotiations that would reduce flexibility.
Solution Approach 2:
The patent implements feedback mechanisms where follower nodes monitor and compare their counter values with master node counters. This feedback allows the system to detect and correct any drift in counter values while maintaining strict monotonic incrementing, providing both ordering precision and adaptability to node failures through automatic synchronization.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
There is provided a method for managing messages in a broker cluster. The broker cluster comprises a plurality of nodes each of which maintains a separate counter. The master node of the plurality of nodes in the broker cluster receives a request containing a payload for a message to be stored at the master node. The master node generates a key for the message, wherein the key comprises at least: a client identifier of a client to receive the message, and a sequence number from the counter of the master node. The master node stores a message formed based on the key and the payload as a key-value pair at the master node.