내가 건너 왔어요하지만 카프카 전에, 나는 최근 카프카가 아마도 (기초)을 사용할 수있다 실현 CQRS , eventstore .

Kafka가 지원하는 주요 요점 중 하나 :

• 물론 이벤트 캡처 / 저장, 모든 HA.
• 펍 / 서브 아키텍처
• 사실 이후에 새로운 가입자가 시스템에 등록 할 수있는 이벤트 로그 재생 기능.

분명히 나는 ​​100 % CQRS / 이벤트 소싱에 정통하지는 않지만 이벤트 스토어와 거의 비슷해 보입니다. 재미있는 것은 : 카프카가 이벤트 스토어로 사용되는 것에 대해 그다지 많은 것을 찾을 수 없으므로 아마도 뭔가 빠진 것입니다.

그렇다면 카프카에서 누락 된 것이 좋은 이벤트 저장소가 될 수 있을까요? 작동할까요? 그것을 사용하여 생산합니까? 통찰력, 링크 등에 관심이 있습니다.

기본적으로 시스템 상태는 일반적으로 수행되는 시스템의 현재 상태 / 스냅 샷을 저장하는 대신 시스템이 수신 한 트랜잭션 / 이벤트를 기반으로 저장됩니다. (회계의 총계정 원장이라고 생각하십시오. 모든 거래는 궁극적으로 최종 상태에 도달합니다) 이것은 모든 종류의 멋진 것을 허용하지만 제공된 링크를 읽으십시오.

Kafka는 이벤트 저장소와 많은 유사점을 가지고 있지만 소개 내용을 인용하는 메시징 시스템입니다.

Kafka 클러스터는 게시 된 모든 메시지 (소비 여부에 관계없이)를 구성 가능한 기간 동안 유지합니다 . 예를 들어 보존 기간이 2 일로 설정된 경우 메시지가 게시 된 후 2 일 동안 사용할 수 있으며 공간을 확보하기 위해 버려집니다. Kafka의 성능은 데이터 크기와 관련하여 사실상 일정하므로 많은 데이터를 유지하는 것은 문제가되지 않습니다.

따라서 메시지는 무한정 보유 될 수 있지만 메시지는 삭제 될 것으로 예상됩니다. 그렇다고 이벤트 스토어로 사용할 수는 없지만 다른 것을 사용하는 것이 좋습니다. 대안을 보려면 EventStore 를 살펴보십시오 .

최신 정보

카프카 문서 :

이벤트 소싱은 상태 변경이 시간 순서대로 기록 된 순서로 기록되는 응용 프로그램 디자인 스타일입니다. Kafka의 매우 큰 저장된 로그 데이터 지원은이 스타일로 구축 된 응용 프로그램을위한 훌륭한 백엔드입니다.

업데이트 2

이벤트 소싱에 Kafka를 사용할 때 고려해야 할 한 가지 사항은 필요한 주제 수입니다. 일반적으로 이벤트 소싱에는 엔터티 (예 : 사용자, 제품 등) 당 이벤트 스트림 (주제)이 있습니다. 이러한 방식으로 스트림의 모든 이벤트를 다시 적용하여 엔티티의 현재 상태를 재구성 할 수 있습니다. 각 Kafka 주제는 하나 이상의 파티션으로 구성되며 각 파티션은 파일 시스템에 디렉토리로 저장됩니다. znode 수가 증가함에 따라 ZooKeeper의 압력도 있습니다.

저는 Kafka의 원저자 중 한 사람입니다. Kafka는 이벤트 소싱을위한 로그로 매우 잘 작동합니다. 내결함성이 있으며 엄청난 데이터 크기로 확장되며 내장 된 파티셔닝 모델이 있습니다.

LinkedIn에서이 양식의 여러 유스 케이스에 사용합니다. 예를 들어 오픈 소스 스트림 처리 시스템 인 Apache Samza 는 이벤트 소싱 을 기본적으로 지원 합니다.

이벤트 소싱 용어가 주로 카프카가 가장 많이 사용되는 소비자 웹 공간에서 널리 퍼지지 않는 것 같기 때문에 이벤트 소싱에 Kafka를 사용하는 것에 대해 많이 듣지 못한다고 생각합니다.

나는 카프카의 사용이 스타일에 대해 조금 작성했습니다 여기에 .

이 품질 관리로 계속 돌아옵니다. 그리고 나는 기존의 답변이 충분히 미묘한 것을 찾지 못했기 때문에 이것을 추가하고 있습니다.

TL; DR. 이벤트 소싱 사용량에 따라 예 또는 아니요.

내가 알고있는 두 가지 주요 이벤트 소스 시스템이 있습니다.

다운 스트림 이벤트 프로세서 = 예

이런 종류의 시스템에서 이벤트는 실제 세계에서 발생하며 사실로 기록됩니다. 제품 팔레트를 추적하는 창고 시스템과 같은. 기본적으로 충돌하는 이벤트가 없습니다. 잘못 되었더라도 모든 일이 이미 일어났습니다 (즉, 팔레트 123456은 트럭 A에 장착되었지만 트럭 B에 예약되었습니다.) 그런 다음,보고 메커니즘을 통해 예외를 확인합니다. Kafka는 이러한 종류의 다운 스트림 이벤트 처리 응용 프로그램에 적합합니다.

이러한 맥락에서 Kafka 직원이이를 이벤트 소싱 솔루션으로 옹호하는 이유를 이해할 수 있습니다. 예를 들어 클릭 스트림과 같이 이미 사용 된 방식과 매우 유사하기 때문입니다. 그러나 이벤트 소싱 (스트림 처리와 반대)이라는 용어를 사용하는 사람들은 두 번째 사용법을 참조 할 가능성이 높습니다.

응용 프로그램 제어 진실 소스 = 아니오

이러한 종류의 응용 프로그램은 사용자 요청이 비즈니스 로직을 통과 한 결과로 자체 이벤트를 선언합니다. 이 경우 Kafka는 두 가지 주요 이유로 제대로 작동하지 않습니다.

엔터티 격리 부족

이 시나리오에는 특정 엔티티에 대한 이벤트 스트림을로드하는 기능이 필요합니다. 일반적인 이유는 비즈니스 로직이 요청을 처리하는 데 사용할 임시 쓰기 모델을 빌드하기 때문입니다. 이 작업은 Kafka에서 비실용적입니다. 엔터티 당 주제를 사용하면 수천 또는 수백만 엔터티가있을 수있는 스타터가 아닌 것을 제외하고는이를 허용 할 수 있습니다. 이것은 Kafka / Zookeeper의 기술적 한계 때문입니다.

이러한 방식으로 임시 쓰기 모델을 사용하는 주된 이유 중 하나는 비즈니스 논리 변경을 저렴하고 쉽게 배포 할 수 있도록하기위한 것입니다.

Kafka 대신 유형별 주제를 사용하는 것이 좋지만 단일 엔터티에 대한 이벤트를 가져 오려면 해당 유형의 모든 엔터티 에 대한 이벤트를로드해야합니다 . 어떤 이벤트가 어떤 엔티티에 속하는지 로그 위치로 알 수 없기 때문입니다. 알려진 로그 위치에서 시작하기 위해 스냅 샷 을 사용 하더라도이 이벤트는 상당히 많은 이벤트가 될 수 있습니다.

충돌 감지 부족

둘째, 사용자는 동일한 엔터티에 대한 동시 요청으로 인해 경쟁 조건을 만들 수 있습니다. 충돌 이벤트를 저장하고 사실 후에 해결하는 것은 바람직하지 않습니다. 따라서 충돌하는 이벤트를 방지 할 수 있어야합니다. 요청로드를 확장하기 위해 조건부 쓰기를 사용하여 쓰기 충돌을 방지하면서 상태 비 저장 서비스를 사용하는 것이 일반적입니다 (마지막 엔터티 이벤트가 #x 인 경우에만 쓰기). 일명 낙관적 동시성. Kafka는 낙관적 동시성을 지원하지 않습니다. 주제 수준에서 지원하더라도 효과적이려면 엔티티 수준까지 내려 가야합니다. Kafka를 사용하고 충돌하는 이벤트를 방지하려면 응용 프로그램 수준에서 상태 저장 직렬화 기록기를 사용해야합니다. 이것은 중요한 아키텍처 요구 사항 / 제한 사항입니다.

추가 정보

댓글 당 업데이트

댓글이 삭제되었지만 질문은 다음과 같습니다. 사람들이 이벤트 저장에 사용하는 것은 무엇입니까?

대부분의 사람들은 기존 데이터베이스를 기반으로 자체 이벤트 스토리지 구현을 수행하는 것으로 보입니다. 내부 백엔드 또는 독립형 제품과 같은 비 분산 시나리오의 경우 SQL 기반 이벤트 저장소를 작성하는 방법 이 잘 문서화 되어 있습니다. 그리고 다양한 종류의 데이터베이스 위에 사용 가능한 라이브러리가 있습니다. 이 목적을 위해 만들어진 EventStore 도 있습니다 .

분산 시나리오에서 몇 가지 다른 구현을 보았습니다. Jet의 Panther 프로젝트는 피드 변경 기능과 함께 Azure CosmosDB 를 사용하여 리스너에게 알립니다. AWS에서 들었던 또 다른 유사한 구현은 DynamoDB를 Streams 기능과 함께 사용하여 리스너에게 알리는 것입니다. 파티션 키는 아마도 최상의 데이터 분배를위한 스트림 ID 여야합니다 (과잉 프로비저닝 양을 줄이려면). 그러나 Dynamo의 스트림에서 전체 재생은 비용이 많이 듭니다 (읽기 및 비용 기준). 따라서이 impl은 Dynamo Streams가 이벤트를 S3에 덤프하도록 설정되었습니다. 새 리스너가 온라인 상태가되거나 기존 리스너가 전체 재생을 원하면 S3을 먼저 읽습니다.

현재 프로젝트는 다중 테넌트 시나리오이며 Postgres를 기반으로 프로젝트를 진행했습니다. Citus와 같은 것은 텐 턴트 + 스트림에 의한 파티션, 확장성에 적합한 것으로 보입니다.

Kafka는 여전히 분산 시나리오에서 매우 유용합니다. 각 서비스의 이벤트를 다른 서비스에 노출시키는 것은 사소한 문제가 아닙니다. 이벤트 저장소는 일반적으로 그러한 용도로 구축되지는 않지만 Kafka가 잘하는 것입니다. 각 서비스에는 자체 내부 소스가 있으며 (이벤트 저장 또는 기타 일 수 있음) "외부"에서 발생하는 상황을 파악하기 위해 Kafka를 경청합니다. 이 서비스는 Kafka에 이벤트를 게시하여 "외부"에 서비스가 수행 한 흥미로운 작업을 알릴 수 있습니다.

Kafka를 이벤트 저장소로 사용할 수 있지만 좋은 선택처럼 보이지만 권장하지는 않습니다.

• Kafka는 최소한 한 번만 제공하며 이벤트 저장소에 제거 할 수없는 사본이 있습니다. 업데이트 : Kafka가 왜 그렇게 어려운지 그리고 최종적 으로이 행동을 얻는 방법에 대한 최신 뉴스를 읽을 수 있습니다 : https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-does-it /
• 불변성으로 인해 응용 프로그램이 발전하고 이벤트를 변환해야 할 때 이벤트 저장소를 조작 할 수있는 방법이 없습니다 (물론 업 캐스팅과 같은 방법이 있지만 ...). 일단 이벤트를 변환 할 필요는 없지만 올바른 가정이 아니라고하면 원래 백업을 수행하지만 최신 버전으로 업그레이드하는 상황이있을 수 있습니다. 이는 이벤트 중심 아키텍처에서 유효한 요구 사항입니다.
• 엔티티 / 집계 및 재생의 스냅 샷을 유지할 장소가 더 느리고 느려집니다. 스냅 샷 작성은 장기적인 관점에서 이벤트 저장소의 기능이어야합니다.
• 주어진 Kafka 파티션은 분산되어 있으며 데이터베이스와 비교하여 관리 및 백업하기가 어렵습니다. 데이터베이스는 간단합니다 :-)

따라서 선택하기 전에 두 번 생각하십시오. 응용 프로그램 계층 인터페이스 (모니터링 및 관리), SQL / NoSQL 저장소 및 브로커 인 Kafka를 결합한 이벤트 저장소는 Kafka가 두 기능을 모두 처리하여 완전한 기능을 갖춘 완전한 솔루션을 만드는 것보다 더 나은 선택입니다.

이벤트 저장소는 이벤트 소싱 아키텍처에 이벤트 소싱, CQRS, Sagas 및 기타 패턴을 적용하고 성능을 유지하는 데 심각한 문제가있는 경우 Kafka가 제공 할 수있는 것보다 더 많은 서비스를 요구하는 복잡한 서비스입니다.

내 대답에 자유롭게 도전하십시오! 겹치는 기능이 많은 즐겨 사용하는 브로커에 대해 내가 말한 것을 좋아하지 않을 수도 있지만 Kafka는 이벤트 저장소로 설계되지 않았지만 동시에 빠른 생산자 대 느린 소비자 시나리오를 처리하기 위해 고성능 브로커 및 버퍼 이상으로 설계되었습니다. 예를 들어.

잠재적 인 문제에 대한 자세한 내용은 eventuate.io 마이크로 서비스 오픈 소스 프레임 워크를 참조하십시오 : http://eventuate.io/

2018 년 2 월 8 일자로 업데이트

의견의 새로운 정보를 통합하지는 않지만 그 측면 중 일부에 동의합니다. 이 업데이트는 마이크로 서비스 이벤트 중심 플랫폼에 대한 일부 권장 사항에 대한 것입니다. 마이크로 서비스의 견고한 디자인과 최고의 성능에 대해 진지한 경우, 몇 가지 힌트를 제공 할 것입니다.

1. Spring을 사용하지 마십시오-훌륭하지만 (나 자신을 많이 사용하지만) 동시에 무겁고 느립니다. 그리고 이것은 마이크로 서비스 플랫폼이 아닙니다. 하나만 구현하는 데 도움이되는 프레임 워크입니다. 다른 프레임 워크는 "그냥"경량 REST 또는 JPA 또는 다르게 초점을 맞춘 프레임 워크입니다. 순수한 Java 루트로 돌아가는 동급 최강의 오픈 소스 완전한 마이크로 서비스 플랫폼을 사용하는 것이 좋습니다. https://github.com/networknt

성능이 궁금하다면 기존 벤치 마크 제품군과 비교해보십시오. https://github.com/networknt/microservices-framework-benchmark

2. Kafka를 전혀 사용하지 마십시오 :-)) 반 농담입니다. 카프카는 훌륭하지만 또 다른 브로커 중심 시스템입니다. 미래는 브로커리스 메시징 시스템에 있다고 생각합니다. 놀랍지 만 Kafka 시스템보다 빠릅니다 :-), 물론 더 낮은 수준으로 내려 가야합니다. 연대기를보십시오.

3. 이벤트 저장소의 경우 대용량의 고성능 시계열 데이터 처리 (이벤트는 시계열)에 중점을 둔 TimescaleDB라는 우수한 Postgresql 확장을 권장합니다. 물론 CQRS, 이벤트 소싱 (재생 등의 기능)은 Postgres를 낮은 스토리지로 사용하는 기본적으로 light4j 프레임 워크에 내장되어 있습니다.

4. 메시징을 위해 Chronicle Queue, Map, Engine, Network를보십시오. 이 구식 중개인 중심 솔루션을 제거 하고 마이크로 메시징 시스템 (내장 된 시스템)을 사용합니다. 크로니클 큐는 실제로 카프카보다 훨씬 빠릅니다. 그러나 나는 그것이 하나의 솔루션에 전부는 아니라는 것을 동의합니다. 그렇지 않으면 개발을해야합니다. 그렇지 않으면 엔터프라이즈 버전 (유료)을 구입하십시오. 결국 Chronicle에서 구축하려는 노력은 Kafka 클러스터 유지 관리 부담을 제거하여 자체 메시징 계층에 비용을 지불하게됩니다.

예, Kafka를 이벤트 저장소로 사용할 수 있습니다. 특히 Kafka Streams를 도입하면 잘 작동 합니다.이 기능은 이벤트를 쿼리 할 수있는 누적 상태 로 처리하는 Kafka 네이티브 방식을 제공 합니다. .

에 관해서:

사실 이후에 새로운 가입자가 시스템에 등록 할 수있는 이벤트 로그 재생 기능.

까다로울 수 있습니다. https://stackoverflow.com/a/48482974/741970 에서 자세히 다루었습니다.

예, Kafka는 특히 CQRS 이벤트 소싱 모델에서 잘 작동하지만 주제에 대한 TTL을 설정하는 동안주의를 기울여야하며 Kafka는이 모델을 위해 설계된 것이 아니라는 점을 항상 명심하십시오.

Kafka에 대한 지원과 함께 axon framework을 봐야한다고 생각합니다.