The next in the series of understanding the Disruptor pattern developed at LMAX.
After the last post we all understand ring buffers and how awesome they are. Unfortunately for you, I have not said anything about how to actually populate them or read from them when you’re using the Disruptor.
ConsumerBarriers and Consumers
I’m going to approach this slightly backwards, because it’s probably easier to understand in the long run. Assuming that some magic has populated it: how do you read something from the ring buffer?
(OK, I’m starting to regret using Paint/Gimp. Although it’s an excellent excuse to purchase a graphics tablet if I do continue down this road. Also UML gurus are probably cursing my name right now.)
Your Consumer is the thread that wants to get something off the buffer. It has access to aConsumerBarrier, which is created by the RingBuffer and interacts with it on behalf of theConsumer. While the ring buffer obviously needs a sequence number to figure out what the next available slot is, the consumer also needs to know which sequence number it’s up to – each consumer needs to be able to figure out which sequence number it’s expecting to see next. So in the case above, the consumer has dealt with everything in the ring buffer up to and including 8, so it’s expecting to see 9 next.
The consumer calls waitFor on the ConsumerBarrier with the sequence number it wants next
final long availableSeq = consumerBarrier.waitFor(nextSequence);
and the ConsumerBarrier returns the highest sequence number available in the ring buffer – in the example above, 12. The ConsumerBarrier has a WaitStrategy which it uses to decide how to wait for this sequence number – I won’t go into details of that right now, the code has comments in outlining the advantages and disadvantages of each.
Now what?
So the consumer has been hanging around waiting for more stuff to get written to the ring buffer, and it’s been told what has been written – entries 9, 10, 11 and 12. Now they’re there, the consumer can ask the ConsumerBarrier to fetch them.
As it’s fetching them, the Consumer is updating its own cursor.
You should start to get a feel for how this helps to smooth latency spikes – instead of asking “Can I have the next one yet? How about now? Now?” for every individual item, the Consumer simply says “Let me know when you’ve got more than this number”, and is told in return how many more entries it can grab. Because these new entries have definitely been written (the ring buffer’s sequence has been updated), and because the only things trying to get to these entries can only read them and not write to them, this can be done without locks. Which is nice. Not only is it safer and easier to code against, it’s much faster not to use a lock.
And the added bonus – you can have multiple Consumers reading off the same RingBuffer, with no need for locks and no need for additional queues to coordinate between the different threads. So you can really run your processing in parallel with the Disruptor coordinating the effort.
The BatchConsumer is an example of consumer code, and if you implement the BatchHandler you can get the BatchConsumer to do the heavy lifting I’ve outlined above. Then it’s easy to deal with the whole batch of entries processed (e.g. from 9-12 above) without having to fetch each one individually.
EDIT: Note that version 2.0 of the Disruptor uses different names to the ones in this article. Please see my summary of the changes if you are confused about class names.
文章转自 并发编程网-ifeve.com
