방해자 패턴 을 이해하려고합니다 . InfoQ 비디오를보고 논문을 읽으려고했습니다. 캐시 버퍼를 활용하기 위해 매우 큰 배열로 초기화되어 새 메모리 할당이 필요 없다는 링 버퍼가 있음을 이해합니다.
위치를 추적하는 하나 이상의 원자 정수가있는 것처럼 들립니다. 각 '이벤트'는 고유 ID를 갖는 것으로 보이며 링의 위치 등은 링의 크기 등에 대한 계수를 찾아서 찾을 수 있습니다.
불행히도, 나는 그것이 어떻게 작동하는지 직관적으로 이해하지 못합니다. 나는 많은 거래 응용 프로그램을 수행하고 배우 모델을 연구하고 SEDA 등을 조사했습니다.
그들은 프레젠테이션에서이 패턴이 기본적으로 라우터의 작동 방식이라고 언급했습니다. 그러나 라우터가 어떻게 작동하는지에 대한 좋은 설명을 찾지 못했습니다.
더 나은 설명에 대한 좋은 조언이 있습니까?
답변:
Google 코드 프로젝트는 링 버퍼 구현에 대한 기술 문서 를 참조 하지만 작동 방법을 배우려는 사람에게는 약간 건조하고 학문적이며 힘든 작업입니다. 그러나 좀 더 읽기 쉬운 방식으로 내부를 설명하기 시작한 일부 블로그 게시물이 있습니다. 가 링 버퍼의 설명 교란 패턴의 코어 A는 소비자 장벽 설명 합니다 (교란로부터 판독 관련된 부분) 및 일부 여러 생산자에 대한 정보를 처리 가능.
Disruptor에 대한 가장 간단한 설명은 다음과 같습니다. 가능한 가장 효율적인 방식으로 스레드간에 메시지를 보내는 방법입니다. 큐의 대안으로 사용될 수 있지만 SEDA 및 액터와 많은 기능을 공유합니다.
대기열과 비교 :
Disruptor는 메시지를 다른 스레드로 전달하여 필요한 경우 깨우는 기능을 제공합니다 (BlockingQueue와 유사). 그러나 3 가지 차이점이 있습니다.
배우와 비교
액터 모델은 다른 BatchConsumer / BatchHandler 클래스를 사용하는 경우 대부분의 다른 프로그래밍 모델보다 Disruptor에 더 가깝습니다. 이 클래스는 소비 된 시퀀스 번호를 유지 관리하는 모든 복잡성을 숨기고 중요한 이벤트가 발생할 때 간단한 콜백 세트를 제공합니다. 그러나 몇 가지 미묘한 차이점이 있습니다.
onEndOfBatch()합니다. 이를 통해 처리량을 향상시키기 위해 이벤트를 일괄 처리하기 위해 I / O를 수행하는 소비자가 느려질 수 있습니다. 다른 액터 프레임 워크에서 일괄 처리를 수행 할 수 있지만 거의 모든 다른 프레임 워크가 일괄 처리 끝에 콜백을 제공하지 않으므로 일괄 처리 종료를 결정하기 위해 시간 초과를 사용해야하는 대기 시간이 줄어 듭니다.SEDA와 비교
LMAX는 SEDA 기반 접근법을 대체하기 위해 Disruptor 패턴을 구축했습니다.
메모리 배리어와 비교
그것에 대해 생각하는 또 다른 방법은 체계적이고 체계적인 메모리 장벽입니다. 생산자 장벽이 쓰기 장벽을 형성하고 소비자 장벽이 읽기 장벽입니다.
먼저 우리는 그것이 제공하는 프로그래밍 모델을 이해하고 싶습니다.
하나 이상의 작가가 있습니다. 하나 이상의 독자가 있습니다. 오래된 것부터 새로운 것까지 순서대로 정렬 된 항목이 있습니다 (왼쪽에서 오른쪽으로 그림). 작가는 오른쪽 끝에 새 항목을 추가 할 수 있습니다. 모든 독자는 왼쪽에서 오른쪽으로 순차적으로 항목을 읽습니다. 독자들은 분명히 과거의 작가들을 읽을 수 없습니다.
항목 삭제 개념이 없습니다. 항목 소비 이미지를 피하기 위해 "소비자"대신 "리더"를 사용합니다. 그러나 우리는 마지막 독자의 왼쪽에있는 항목이 쓸모 없다는 것을 이해합니다.
일반적으로 독자는 동시에 독립적으로 읽을 수 있습니다. 그러나 독자들 사이에 의존성을 선언 할 수 있습니다. 판독기 종속성은 임의의 비 주기적 그래프 일 수 있습니다. 판독기 B가 판독기 A에 의존하는 경우 판독기 B는 판독기 A를 지나칠 수 없습니다.
독자 A는 항목에 주석을 달 수 있고 독자 B는 해당 주석에 의존하기 때문에 독자 종속성이 발생합니다. 예를 들어 A는 항목을 계산하고 항목의 결과를 항목에 저장합니다 a. A는 계속 진행하면 B는 항목과 aA 의 값을 읽을 수 있습니다 . 판독기 C가 A에 의존하지 않으면 C는 읽지 않아야합니다 a.
이것은 실제로 흥미로운 프로그래밍 모델입니다. 성능에 관계없이 모델만으로도 많은 응용 분야에 혜택을 줄 수 있습니다.
물론 LMAX의 주요 목표는 성능입니다. 사전 할당 된 항목의 링을 사용합니다. 링은 충분히 크지 만 시스템이 설계 용량을 초과하여로드되지 않도록 제한되어 있습니다. 링이 가득 찬 경우 작가는 가장 느린 독자가 진행할 때까지 기다렸다가 공간을 만듭니다.
가비지 수집 비용을 줄이기 위해 항목 개체가 사전 할당되어 영구적으로 유지됩니다. 새 항목 개체를 삽입하거나 이전 항목 개체를 삭제하는 대신 작성자가 기존 항목을 요청하고 해당 필드를 채우고 독자에게 알립니다. 이 명백한 2 단계 동작은 실제로 단순한 원자 동작입니다.
setNewEntry(EntryPopulator);
interface EntryPopulator{ void populate(Entry existingEntry); }
사전 할당 항목은 인접 메모리 셀에있는 인접 항목 (매우 가능성이 있음)을 의미하며, 독자가 항목을 순차적으로 읽으므로 CPU 캐시를 활용하는 것이 중요합니다.
그리고 잠금, CAS, 심지어 메모리 장벽을 피하기 위해 많은 노력을 기울입니다 (예 : 작성자가 하나 뿐인 경우 비 휘발성 시퀀스 변수 사용)
독자 개발자 : 쓰기 경합을 피하기 위해 다른 주석 독자는 다른 필드에 작성해야합니다. (실제로 다른 캐시 라인에 기록해야합니다.) 주석이 달린 판독기는 다른 비 독립 판독기가 읽을 수있는 내용을 건드리지 않아야합니다. 이것이 독자들이 항목을 수정하는 대신 항목에 주석을달라고 말하는 이유 입니다.
마틴 파울러 (Martin Fowler)는 LMAX와 장애자 패턴 인 LMAX Architecture 에 관한 기사를 작성했으며 ,이를 자세히 설명 할 수 있습니다.
나는 실제로 호기심에서 실제 소스를 연구하는 데 시간이 걸렸으며 그 뒤에있는 아이디어는 매우 간단합니다. 이 글을 쓸 당시의 최신 버전은 3.2.1입니다.
소비자가 읽을 수 있도록 데이터를 보유 할 사전 할당 된 이벤트를 저장하는 버퍼가 있습니다.
버퍼는 버퍼 슬롯의 가용성을 설명하는 길이의 플래그 배열 (정수 배열)로 백업됩니다 (자세한 내용은 추가 참조). 배열은 java # AtomicIntegerArray처럼 액세스되므로이 설명을 위해 배열을 하나라고 가정 할 수 있습니다.
여러 개의 생산자가있을 수 있습니다. 생산자가 버퍼에 쓰려고 할 때 AtomicLong # getAndIncrement 호출과 같이 긴 숫자가 생성됩니다. Disruptor는 실제로 자체 구현을 사용하지만 동일한 방식으로 작동합니다. 이것을 길게 생성자 (producerCallId)라고하자. 비슷한 방식으로 consumerCallId는 소비자 ENDS가 버퍼에서 슬롯을 읽을 때 생성됩니다. 가장 최근의 consumerCallId에 액세스합니다.
(소비자가 많은 경우 ID가 가장 낮은 통화가 선택됩니다.)
그런 다음이 ID를 비교하고 둘 사이의 차이가 버퍼 쪽보다 작 으면 생산자가 쓸 수 있습니다.
(producerCallId가 최근 consumerCallId + bufferSize보다 큰 경우 버퍼가 가득 차서 스팟을 사용할 수있을 때까지 생산자가 버스 대기하도록 강제합니다.)
그런 다음 생산자는 자신의 callId (prducerCallId modulo bufferSize)를 기준으로 버퍼의 슬롯이 할당되지만 bufferSize는 항상 2의 제곱 (버퍼 생성시 제한)이므로 실제로 사용되는 작업은 producerCallId & (bufferSize-1)입니다. )). 그런 다음 해당 슬롯에서 이벤트를 자유롭게 수정할 수 있습니다.
(실제 알고리즘은 최적화를 위해 별도의 원자 참조로 최근 consumerId를 캐싱하는 것을 포함하여 조금 더 복잡합니다.)
이벤트가 수정되면 변경이 "게시"됩니다. 플래그 배열에서 각 슬롯을 게시하면 업데이트 된 플래그로 채워집니다. 플래그 값은 루프 수 (producerCallId를 bufferSize로 나눈 값입니다 (bufferSize는 2의 거듭 제곱이므로 실제 작업은 올바른 시프트 임).
유사한 방식으로 임의의 수의 소비자가있을 수 있습니다. 소비자가 버퍼에 액세스하려고 할 때마다 consumerCallId가 생성됩니다 (소비자에 소비자가 추가 된 방식에 따라 id 생성에 사용 된 원자가 각각에 대해 공유되거나 분리 될 수 있음). 그런 다음이 consumerCallId를 가장 최근의 producentCallId와 비교하고 둘 중 작은 값이면 독자가 진행할 수 있습니다.
(producerCallId가 consumerCallId의 경우에도 마찬가지입니다. 이는 버퍼가 비어 있고 소비자가 기다려야 함을 의미합니다. 대기 방식은 방해 요소 작성 중 WaitStrategy에 의해 정의됩니다.)
개별 소비자 (자체 아이디 생성기가있는 소비자)의 경우 다음으로 확인해야 할 것은 배치 소비 능력입니다. 버퍼의 슬롯은 각각 consumerCallId (인덱스는 생산자와 동일한 방식으로 결정됨)에서 최근의 producerCallId에 이르는 슬롯까지 순서대로 검사됩니다.
이들은 플래그 배열에 작성된 플래그 값을 consumerCallId에 대해 생성 된 플래그 값과 비교하여 루프에서 검사됩니다. 플래그가 일치하면 슬롯을 채우는 생산자가 변경 사항을 커밋했음을 의미합니다. 그렇지 않으면 루프가 끊어지고 커밋 된 가장 높은 changeId가 반환됩니다. ConsumerCallId에서 changeId로 수신 된 슬롯은 일괄 적으로 소비 될 수 있습니다.
소비자 그룹이 함께 공유하는 경우 (공유 ID 생성기가있는 그룹), 각 그룹은 단일 callId 만 가져 오며 해당 단일 callId의 슬롯 만 확인하여 리턴합니다.
에서 이 문서 :
중단 자 패턴은 메모리 장벽을 사용하여 시퀀스를 통해 생산자와 소비자를 동기화하는 사전 할당 된 전송 객체로 채워진 순환 배열 (즉, 링 버퍼)로 백업되는 배치 대기열입니다.
메모리 장벽은 설명하기가 어렵고 Trisha의 블로그는이 게시물에 대해 제 의견으로는 최선의 시도를했습니다 : http://mechanitis.blogspot.com/2011/08/dissecting-disruptor-why-its-so-fast. html
그러나 하위 수준의 세부 정보를보고 싶지 않다면 Java의 메모리 장벽이 volatile키워드 또는을 통해 구현된다는 것을 알 수 있습니다 java.util.concurrent.AtomicLong. 방해자 패턴 시퀀스는 AtomicLong로크 대신 메모리 배리어를 통해 생산자와 소비자 사이에서주고받습니다.
코드를 통해 개념을 이해하는 것이 더 쉽다는 것을 알기 때문에 아래 코드는 CoralQueue 의 간단한 helloworld 입니다 . 이는 CoralBlocks 에서 수행 한 방해 요소 패턴 구현입니다. 아래 코드에서 방해 요소 패턴이 일괄 처리를 구현하는 방법과 링 버퍼 (예 : 원형 배열)가 두 스레드간에 가비지없는 통신을 허용하는 방법을 확인할 수 있습니다.
package com.coralblocks.coralqueue.sample.queue;
import com.coralblocks.coralqueue.AtomicQueue;
import com.coralblocks.coralqueue.Queue;
import com.coralblocks.coralqueue.util.MutableLong;
public class Sample {
public static void main(String[] args) throws InterruptedException {
final Queue<MutableLong> queue = new AtomicQueue<MutableLong>(1024, MutableLong.class);
Thread consumer = new Thread() {
@Override
public void run() {
boolean running = true;
while(running) {
long avail;
while((avail = queue.availableToPoll()) == 0); // busy spin
for(int i = 0; i < avail; i++) {
MutableLong ml = queue.poll();
if (ml.get() == -1) {
running = false;
} else {
System.out.println(ml.get());
}
}
queue.donePolling();
}
}
};
consumer.start();
MutableLong ml;
for(int i = 0; i < 10; i++) {
while((ml = queue.nextToDispatch()) == null); // busy spin
ml.set(System.nanoTime());
queue.flush();
}
// send a message to stop consumer...
while((ml = queue.nextToDispatch()) == null); // busy spin
ml.set(-1);
queue.flush();
consumer.join(); // wait for the consumer thread to die...
}
}