问题
We have a requirement to run Active-Active instances of an order manager application for elasticity. Within our team, Hazelcast is the preferred distributed cache for sharing state across elastic instances.
Within the application I am using single-writer pattern along with LMAX disruptor lib. So basically I have a single busy spinning main thread which reads incoming order events from the disruptor (ring buffer) and quickly processes it without involving any blocking operation.
Now the only issue is that, as soon as my main thread receives an event, it first performs a lookup in a Hazelcast distributed map (to fetch current order’s state), and hazelcast lookup is relatively a slow operation (~5-10 millis). I wanted to understand:
1) if this is still an acceptable thing I.e. reading from a distributed map when using LMAX disruptor
2) plus since Hazelcast calls are thread safe involving distributed locks and LMAX guys suggest avoiding thread related locks in the main business thread so that CPU optimized code caches remain hot, does making a call to hazelcast an anti-pattern from LMAX Disruptor’s main processing thread?
Could someone add their 2 cents on this?
回答1:
I would say it's not acceptable, of course. IMap is not only blocking for indefinite time, it also doing network calls.
I think a way to go is to
- either split off the IMap access into another thread and communicate with it using async events in separate ring buffers
- or subscribe to IMap entry listener and store data in the memory (if it fits).
来源：https://stackoverflow.com/questions/59579079/using-hazelcast-map-with-lmax-disruptor-performance-impact