转载

浅谈Disruptor

Disruptor是一个低延迟(low-latency),高吞吐量(high-throughput)的事件发布订阅框架。通过Disruptor,可以在一个JVM中发布事件,和订阅事件。相对于Java中的阻塞队列(ArrayBlockingQueue,LinkedBlockingQueue),Disruptor的优点是性能更高。它采用了一种无锁的数据结构设计,利用环形数组(RingBuffer)来存放事件,通过对象复用减少垃圾回收进一步提高性能。

从"慢日志"说起

线上有一个接口最近频繁报警(tp99变高),通过监控报警系统定位到问题主要出现在日志打印环节。接口方法入参和出参都会打印"info"日志,我们采用的日志是logback。它默认的是同步打印日志,在日志报文过大时,磁盘IO耗时会变得更加明显。某个慢请求90%的处理时间都消耗在日志打印中。于是我们决定采用异步的方式打印日志。sl4j2日志框架支持异步的日志打印,改成异步日志打印之后接口性能报警消失。而sl4j2高性能的秘密就在于Disruptor。

Disruptor解决的问题

设想一下,在一个JVM中当我们有多个消息的生产者线程,一个消费者线程时,他们之间如何进行高并发、线程安全的协调?很简单,用一个阻塞队列。 当我们有多个消息的生产者线程,多个消费者线程,并且每一条消息需要被所有的消费者都消费一次(这就不是一般队列,只消费一次的语义了),该怎么做? 这时仍然需要一个队列。但是:

  1. 每个消费者需要自己维护一个指针,知道自己消费了队列中多少数据。这样同一条消息,可以被多个人独立消费。
  2. 队列需要一个全局指针,指向最后一条被所有生产者加入的消息。消费者在消费数据时,不能消费到这个全局指针之后的位置——因为这个全局指针,已经是代表队列中最后一条可以被消费的消息了。
  3. 需要协调所有消费者,在消费完所有队列中的消息后,阻塞等待。
  4. 如果消费者之间有依赖关系,即对同一条消息的消费顺序,在业务上有固定的要求,那么还需要处理谁先消费,谁后消费同一条消息的问题。

总而言之,如果有多个生产者,多个消费者,并且同一条消息要给到所有的消费者都去处理一下,需要做到以上4点。这是不容易的。 LMAX Disruptor,正是这种场景下,满足以上4点要求的单机跨线程消息传递、分发的开源、高性能实现。

原文  https://juejin.im/post/5c728d7c518825625c272e3f
正文到此结束
Loading...