Eider used for protocol and off-heap repositories¶
The sample will be using Eider generated commands, events and repositories. This allows the sample to focus on the Aeron Cluster aspects, and keep the code simple with limited noise from cluster objects and serialization. Additionally, Eider has some similarities to the solutions typically used in production Aeron Cluster environments, so provides a hint as to how this is structured. Eider provides:
- zero-copy when working with DirectBuffers (although interactions with repositories can lead to a copy)
- support for indexed repositories, and out the box support for snapshot reading and writing
- transactions, allowing simpler cluster failure handling
- CRC32 support, to support determinism checks across cluster nodes
Simple Binary Encoding has comparable performance, and a far richer feature set for messaging, but has no equivalent to Eider Repositories.
Logic in the Gateways¶
To keep cluster performance as high as possible, it is assumed that Gateway processes will include logic to customize outbound messages per user, as needed. See Gateway Distribution for more on this topic. This can be seen by the general principle of broadcasting state changes from the cluster, and replying when errors are raised.
The number of RFQs and RFQ responses supported by the system are fixed at process startup. Once the system hits capacity, RFQs and/or RFQ responses will be declined. This allows the process to allocate all memory needed at process startup, preventing any unnecessary buffer resizing and garbage collection during operation. This is typical in higher performance exchanges.
Users are fully managed within Gateways¶
The cluster design requires that users are managed within the gateways, and exist only as attributes coming into the cluster via commands. This reduces complexity of the cluster, and given that Gateways allow for some scale out, increases overall possible performance of the system.