1

Currently i'm in the process of assessing Aeron for our High-frequency trading use case. As i see from the documentationm Aeron is basically the transport. Is that some higher level implementation like competing consumer, fair dispatch or pattern similiar with RabbitMQ ?

Thanks

James
  • 388
  • 3
  • 7
Welly Tambunan
  • 160
  • 2
  • 10
  • With the competing consumer pattern are you looking at consumers in the same process, multiple processes but same host, or consumers distributed across hosts? – Michael Barker Aug 21 '20 at 20:29
  • @MichaelBarker is that 3 case very different? i would love to know it all, as i need to test a single process, same host and across node. – Welly Tambunan Aug 21 '20 at 21:40
  • 1
    Those 3 cases are very different and range in complexity from straight forward from the same process to difficult for multiple hosts. The complexity would also be dependent on what level of guarantee that you wanted to provide that each message is delivered only once. I'll post an answer with my thoughts. – Michael Barker Aug 22 '20 at 07:57

2 Answers2

3

The short answer is no.

The longer and more complicated answer is that you could build something on top of Aeron to implement competing consumer/fair dispatch. The primary challenge is that you need some mechanism to manage co-ordination between consumers. This gets more complex the more widely distributed the consumers are.

Single Process (multiple threads)

A single producer, multiple consumer queue would probably be sufficient for this case. With one thread reading from Aeron, copying and en-queuing the message and the consumers reading from the queue. The Agrona library (that ships with Aeron) has some fast queue implementations.

Single host

Similar to single process, you would need something similar to a queue, but implemented using shared memory or similar. There isn't anything out of the box that I'm aware of to do this.

Multiple hosts

To manage this there needs to be some sort of central broker to manage work distribution, acknowledgements, re-delivery, etc. This service would need to be redundant in order to ensure that processing can continue if the broker itself failed. You could conceivably build something like this on top of Aeron Archive and Cluster, but I wouldn't recommend it. There are other solutions that require less co-ordination overhead, e.g. partitioning by business key.

Michael Barker
  • 14,153
  • 4
  • 48
  • 55
  • Previously, I thought that Aeron in the same level as ZeroMQ as transport. So it lower level than ZeroMQ right? We need to build that capability ourself. So it's possible to do threading inside the process that communicate to Media Driver? Or i have to do single thread lilke ZeroMQ does. – Welly Tambunan Aug 22 '20 at 11:06
  • I've not used ZeroMQ enough to make a comparison. However with Aeron you can have multiple threads, with restrictions. The Docs for the various classes will mention the thread safety behaviours. E.g. `Publication`s can be shared among threads, `Subscription`s and `ExclusivePublication`s must have an instance per thread. – Michael Barker Aug 22 '20 at 20:23
  • thanks a lot for very clear explanation. will check more detail on the documentation – Welly Tambunan Aug 23 '20 at 00:30
1

No. Competing consumer is not applicable to trading applications. Actually, I have seen many trading applications trying to adapt similar patterns (i.e. SEDA framework), it does not scale and worse riddle with concurrency problems.

In order for competing consumer to work, tasks are independent and can run in parallel. In trading application, you cannot do this since an order can only process one event at single point in time. We usually invert the problem - having thread affinity to specific orders and making sure each event is processed by the same thread - so you achieve sequential processing.

IMO - Aeron, 24West LBM gives is a fast and sequenced/ordered event delivery. You want to run on reliable mode ( LBM - UME and Aeron cluster ) so you won't lose any trades. Multicast is really efficient - write once and consume everywhere. This pattern is applicable in trading system since you can offload non-critical processes. You can achieve this with 'shared-memory' but you are bounded by a single physical server. You can think 'aeron' has replication of shared-memory in real-time.

Furthermore, you will run into the physical boundary - so often you have to use 'load-balacer' to direct your orders to specific severs - the same pattern as thread-affinity within the server. For a concrete example, options market data volume is very high - so you want to limit market data process/consumption. So you want the orders of related symbols to be processed by the same physical server.

mjlee
  • 3,374
  • 4
  • 27
  • 22
  • Ah right, so we just use the network level to do the stuff and not reinventing the wheel by creating more layer of abstraction that cost us the performance right? – Welly Tambunan Aug 25 '20 at 02:02
  • Aeron is a messaging protocol. What do you mean by abstraction layer? Network, application, etc. – mjlee Aug 25 '20 at 14:29
  • i mean the use of multicast features directly from the network devices. usually we will use message broker like to achieve that one with pub/sub features on the broker like rmq, zeromq or kafka. – Welly Tambunan Aug 25 '20 at 20:41
  • if i were to use aeron to listen to multiple multicast channels, would it be one thread per subscription? If it was high throughput wouldnt this be an issue since i would only be able to have at most 8 threads if CPU usage per thread is 100%? – chunkynuggy Apr 25 '23 at 14:37