This is the third day of my participation in the August Text Challenge.More challenges in August
Series of articles:
Disruptor For High Performance — Introduction & Introduction
Disruptor For High Performance — False Sharing
Disruptor High-performance — Lock-free Implementation (CAS)
Disruptor High-performance — Memory barriers (Volatile)
Disruptor – The principle of AvailableBuffer
directory
One, foreword
Disruptor what is Disruptor
Three, the last
Four, practice
One, foreword
While looking at Jraft from Ant Financial recently, I came across several uses of a single component called Disruptor. Out of curiosity, I went to Baidu to see what it was. Really don’t see don’t know, a look startled. As I got to know it, IT turned out to be an awesome concurrency framework. I think its outstanding performance is not only its outstanding concurrency performance, but in order to achieve such outstanding performance, almost all the means that we usually call high concurrency to improve performance have been applied to its code implementation, such as: False Sharing, lock-free implementation (lock-free for high concurrency resource contention), Volatile(memory barriers), CAS application. So out of awe of such excellent code implementation, but also through its implementation to learn the practical application of various means of high concurrency enhancement. So the building Lord decided to go to the source.
Therefore, in the following chapters of this series, I will explore how Disruptor achieves such exceptional performance by applying various optimization and enhancement techniques.
Before sharing the implementation of Disruptor, this introductory article intends to provide a basic literacy overview of Disruptor.
Further articles in this series will cover the use of each of these enhancements and will not cover the detailed use or code implementation of Disruptor (there are plenty of these online). Read subsequent articles in this series with a basic understanding of the use of Disruptor and basic code implementation.
Disruptor what is Disruptor
Disruptor is an open source concurrency framework that won the 2011 Duke’s Application Framework Innovation Award for Queue concurrency (from the network) without locking.
Disruptor Disruptor Disruptor Disruptor Disruptor Disruptor Disruptor Disruptor Disruptor Disruptor So let’s take a look at the following scenario:
We often have a requirement in business development that our code has one or more producers that can generate many messages. These messages need to be processed by other consumers (one or more) on the machine (for example, in a business publishing scenario, a series of follow-up operations, such as synchronizing third-party systems and updating relevant business status, need to be performed after a business is published).
I think everyone can offer specific solutions to this business scenario. The usual solution is to use a BlockingQueue. Producers then add offers to it, and consumers pull messages from it to poll. The flow chart of this method is as follows.
Putting performance aside for the moment, from a business perspective, if we need to implement the following business scenarios, how do we implement them?
Business process as above:
- A message is consumed by consumer group 1, then consumed by consumer group 2, and then consumed by consumer group 3
- A message needs to be consumed by all consumers in consumer group 1
- A message can be sent by only one consumer message in consumer groups 2 and 3
To implement this business logic, it seems more complicated. Of course, we can do it ourselves by using our brains. So what’s the problem with implementing the business yourself?
If you are familiar with BlockingQueue first, you will know that Offer and Poll collide with each other via lock. Everyone should know that Lock is a heavyweight operation and is definitely not recommended or used sparingly in high concurrency and high performance scenarios. From this we know that the first problem with our implementation is poor performance.
The other problem I’m not going to mention is that you should know that coding yourself is too complicated and error-prone. So in this case, do we have a simple implementation and meet the performance of the framework can be used? Disruptor of course, yes, it’s our lead Disruptor. It provides excellent (already beeped) performance in this producer-consumer mode, which can be 7-8 times better than BlocingQueue, or even an order of magnitude better (10 times +). You can go to the Internet to search a lot of friends have done the pressure test.
Disruptor also enables us to implement the second business scenario we listed above in very simple code with excellent performance. Do your own research on how to achieve these business scenarios through Disruptor.
Three, the last
Do those of you who have not read about Disruptor feel the urge to learn about it? If so, check out the official website. Have you ever wondered why Disruptor performance is so high if you’ve used it before? If so, stay tuned for the rest of this series.
If the students say no, then I can only say “excuse me, excuse me! “Ha ha ha ha ha…
Stay tuned for the next post on Disruptor High Performance: False Sharing!
Four, practice
If you have any questions or comments about this article, please add an official account to discuss it. (Add an official account to get 10GB video and graphic materials on “Java Advanced Architecture”.)