-
메시지 브로커는 보통 메시지를 적어도 한 번 이상 전달한다. 클라이언트나 네트워크, 혹은 브로커 자신에 이상이 있는 경우 같은 메시지를 여러번 전달할 수도 있다.
-
하지만 이때 메시지를 여러번 전달함으로 인해 중복 메세지가 발생하여 멱등하지 않은 시스템에 지장을 주거나, 메시지 순서가 꼬여 잘못 처리될 수도 있다. 이를 해결하기 위해 ID를 기록하여 검사하거나 DB 폴링 방식을 사용하기도 한다.
-
이때 사용할 수 있는 정교하고 성능이 꽤 좋은 방식중 하나로는, 트랜잭션 로그 테일링 패턴이 있다.
-
말 그대로 메시지 릴레이를 통해 DB 트랜잭션 로그(커밋 로그)를 tailing하는 방법이다. 애플리케이션에서 커밋된 업데이트를 각 DB의 트랜잭션 로그 항목(log entry)으로 남긴다.
-
그리고 그 후에 트랜잭션 로그 마이너(transaction log miner)로 트랜잭션 로그를 읽어 변경분을 하나씩 메시지로 메시지 브로커에 발행하는 절차로 수행된다.
-
Debezium: DB 변경분을 아파치 카프카 메시지 브로커에 발행하는 오픈 소스 프로젝트
-
LinkedIn Databus: 오라클 트랜잭션 로그를 마이닝하여 변경분을 이벤트로 발행하는 오픈 소스 프로젝트. 링크드인에서는 데이터버스를 이용하여 다양한 파생 데이터 저장소를 레코드 체계와 동기화한다.
-
DynamoDB streams: DynamoDB 스트림즈는 최근 24시간 동안 DynamoDB 테이블 아이템에 적용된 변경분(생성, 수정, 삭제)을 시간 순으로 정렬하여 가고 있으면, 애플리케이션은 스트림에서 변경분을 읽어 이벤트로 발행할 수 있다.
-
Eventuate Tram: 오픈 소스 트랜잭션 메시징 라이브러리. MYSQL 빈로그(binlog) 프로토콜, Postgres(포스트그레스) WAL(Write-Ahead Logging), 폴링을 응용해서 OUTBOX 테이블의 변경분을 읽어 아파치 카프카로 발행한다.