Destroyer: Logging Example

I was curious about the most common (or recommended) implementations of the destroyer about the logging step. And my most common questions are:

  • How is it actually implemented (using an example)?
  • Can I use JPA?
  • Which database is commonly used (by a community that is already implementing projects with a destroyer)?
  • Is it possible to use intermediate handlers (EventProcessors), so that the state of each message is preserved, and not before and after the business logic process?

By the way, I know that this is not related to the logging step), which is the correct way to delete a message from RingBuffer during the eventHandler process (provided that the message is dead / expired and should be deleted by the whole procedure). I was wondering, something similar to the Dead Letter Channel template.

Hooray!

+7
source share
1 answer

Disruptor is typically used for processing with low latency and high throughput. For example. millions of messages with a typical delay of hundreds of microseconds. Since very few databases can handle this update rate with fairly limited delays, logging is often done for a raw file with replication to the second (or third) system.

For reporting purposes, the system reads this file or listens to messages and updates the database as quickly as it can, but this is taken out of the critical path.

Write dead in the ring buffer when the handler of each event processed it.


The slot that uses the message is unavailable until each event handler processes it and the entire message in front of it. Removing a message would be too expensive, both in terms of performance and design impact.

Each event processor sees each message. Since this happens at the same time, there is little cost involved, but it is normal for event processors to ignore messages. (perhaps most posts)

+5
source

All Articles