Chained replication techniques for large-scale data streams
US-9639589-B1 · May 2, 2017 · US
US2016156502A1 · US · A1
| Field | Value |
|---|---|
| Publication number | US-2016156502-A1 |
| Application number | US-201514954731-A |
| Country | US |
| Kind code | A1 |
| Filing date | Nov 30, 2015 |
| Priority date | Dec 1, 2014 |
| Publication date | Jun 2, 2016 |
| Grant date | — |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A message broker computer includes a master broker, a plurality of slave message brokers and event stores. A client system sends messages for processing to the master broker. The master broker generates a message event in response to receiving such a message, and distributes the message event in parallel to the slave brokers and the event stores. Each of the event stores store the message event in persistent storage, and notifies the master broker that the message event has been persisted. The master broker considers the message stabilized n a quorum of the event stores. As the master broker does not take action until a messaging event is stabilized, in the event of failover, a new master broker is able to re-construct a broker state of the old master with no loss of data.
Opening claim text (preview).
1 . A method for a message broker computer system to process a message, the method comprising: a master broker computer system receiving a message from a client producer; the master broker computer system, responsive to receiving the message from the client producer, generating a message event, the message event uniquely identifying the message with an epoch value associated with the master broker computer system and a sequence number associated with the message, the message event further including a pointer to a last message stored by at least two of a plurality of event stores in associated persistent storage systems; the master broker computer system distributing the message event to a plurality of event stores and a plurality of slave broker computer systems, wherein each event store has an associated persistent storage system, and each slave broker computer system has an associated memory; each slave broker computer system holding the message event in its associated memory; each event store that received the message event from the master broker computer system storing the message event in its associated persistent storage system, wherein once the message event is stored, each event store sends a stabilization notification to the master broker computer system indicating that the message event has been stored in the event store; the master broker computer system, responsive to receiving stabilization notifications from at least two event stores, storing the message event in an associated persistent storage, and sending a notification to the client producer; the master broker computer system generating a second message event indicating that the message event has been stabilized; the master broker computer system distributing the second message event to the plurality of event stores and the plurality of slave broker computer systems; and each slave broker computer system, responsive to receiving the second message event, storing the message event from its memory to a respective persistent storage system. 2 . The method of claim 1 , further comprising a broker computer system state for each messaging broker computer system, wherein a broker computer system state is a representation of the message event stream that has been persisted at the broker computer system. 3 . The method of claim 2 , further comprising updating the broker computer system state of each messaging broker computer system on receiving a message event from the master broker computer system, wherein updating the broker computer system state includes performing at least one of removal of a message event from the persistent storage or overwriting the message event with a received message event from the master broker computer system. 4 . The method of claim 1 , further comprising the master broker computer system removing the message event from an internal memory of the master broker computer system once the message event is stabilized. 5 . The method of claim 1 , further comprising removing the message event from an internal memory of a slave broker computer system on receiving at least one of a second message event from the master broker computer system or a stability message event from the master broker computer system, wherein a stability message event includes information associated with a last known stable message event at the master broker computer system. 6 . The method of claim 1 , wherein a second message event includes a message event, a sequence number associated with the last stable message event, an epoch value associated with the master broker computer system that sent the last stable message event, a sequence number associated with the message event and an epoch value associated with the master broker computer system. 7 . The method of claim 1 , wherein the master broker computer system distributes the message event to the plurality of slave broker computer systems and the plurality of event stores in parallel. 8 . A method, in a messaging system comprising a master broker computer system, a plurality of slave broker computer systems, and a plurality of event stores, for a broker computer system to change its status from a slave broker computer system to a master broker computer system, the method comprising: storing in persistent storage a plurality of message events, each message event comprising a message received from a client producer and metadata, the metadata uniquely identifying the message with an epoch value associated with a prior master broker computer system and a sequence number associated with the message event, and including a back pointer to a last message having been stored by at least two of the plurality of event stores in associated persistent storage systems; receiving a notification to change status from a slave broker computer system to master broker computer system; identifying a base value for the plurality of message events, the base value being a highest one of the sequence numbers of the message events stored by the broker computer system; retrieving, from the plurality of event stores, sequence information describing the highest sequence numbers of message events which have been persisted on each of the plurality of event stores; determining a set of message events to retrieve based on the base value and the sequence information; retrieving the set of message events from one or more of the plurality of event stores; assembling a message event stream based in part on the retrieved set of message events; identifying a maximum contiguous message event (MCM) using the message event stream, wherein MCM is a message event with the highest sequence number that is observed before encountering a sequence number gap, a metadata of the MCM message event including a back pointer; identifying a synchronization point using the MCM, the synchronization point being a sequence number pointed to by a back pointer in the metadata associated with the MCM; republishing any message events with sequence numbers above that of a synchronization point with a new epoch number determined for the new master broker computer system, to each of the event stores and to a plurality of slave broker computer systems; and updating a broker computer system state in the new master broker computer system to correspond to the MCM, wherein the broker computer system state indicates a state of the old master broker computer system prior to failure including information associated with stabilized message events corresponding to the MCM. 9 . The method of claim 8 , further comprising incrementing an epoch number on updating status of a slave broker computer system to a master broker computer system, wherein incrementing the epoch number indicates that a new broker computer system epoch has been initiated. 10 . The method of claim 8 , further comprising determining a failure of a master broker computer system wherein a failure is detected in response to one or more slave broker computer systems not receiving a message from a master broker computer system for a predetermined threshold of time. 11 . The method of claim 8 , wherein identifying a MCM event further comprises: identifying a gap between sequence numbers of a retrieved set of stabilized message events; and determining a maximum contiguous message event (MCM), wherein MCM is the stabilized message event with the highest sequence number that a broker computer system can recover before encountering the gap in the sequence numbers. 12 . The method of claim 8 , wherein republishing any message events further comprises: regenerating the message events with sequence numbers above a synchronization point by using a new epoch number associa
for short real-time information, e.g. alarms, notifications, alerts, updates · CPC title
Hierarchical allocation of resources, e.g. involving a hierarchy of local and centralised entities · CPC title
by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure · CPC title
Interdomain routing, e.g. hierarchical routing · CPC title
Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.