2017-04-16 3 views
0

현재 Azure Event Hubs는 메시지를 백그라운드 프로세서로 보내주기위한 메커니즘으로보고 있습니다. 현재 대기열 기반 시스템이 사용되고 있습니다.Azure 이벤트 허브 - SQL 검사 점이있는 사용자 정의

대부분의 프로세서는 SQL Server 데이터베이스에 데이터를 쓰고 있으며 쓰기 작업은 트랜잭션으로 래핑됩니다.

이벤트 허브는 최소 한 번만 통신 채널로 배치되므로 중복 메시지가 예상됩니다. EventProcessorHost은 Azure Blob Storage를 사용하여 임대 관리 및 검사 점을 자동화하는 읽기 측면에서 권장되는 API입니다.

그러나 우리는 가장 중요한 일부 프로세서의 경우 동일한 데이터베이스 내에서 SQL Server 테이블을 사용하여 자체 검사 점을 구현하고 프로세서의 동일한 트랜잭션 내에 검사 점을 작성한다는 아이디어가 있습니다. 이렇게하면 필요할 때 정확히 한 번 배송 할 수 있다는 강력한 보장이 제공됩니다.

지금 임대 관리를 무시하고 (파티션 당 1 프로세서 만 실행 함) SQL 기반 체크 포인트가 좋은 생각입니까? API의 수준을 낮추고 체크 포인트를 다룰 필요성을 제외하고는 다른 단점이 있습니까?

답변

1

Azure 저장소는 기본 제공되는 솔루션이지만 이에 국한되지 않습니다. 대부분의 프로세서가 SQL Server 데이터베이스에 데이터를 쓰고 있고 EventProcessorHost에 Azure Storage (저장소 계정이 필요함)에 체크 포인트를 저장하고 싶지 않다면 SQL 데이터베이스에 체크 포인트를 저장하면 쉽게 만들 수 있습니다 프로세스 이벤트를 처리하고 체크 포인트를 트랜잭션 방식으로 관리한다면 좋은 해결책이 될 것입니다.

ICheckpointManager interface을 사용하여 자신의 체크 포인트 관리자를 작성하여 SQL 데이터베이스에 체크 포인트를 저장할 수 있습니다.

+0

감사합니다. 프레드. 이 인터페이스를 구현하면 EventProcessorHost의 다른 부분을 다시 사용할 수 있습니까? 또는 사용자 정의 코드와 비교하면 어떤 이점이 있습니까? 모든 관련 샘플을 온라인으로 제공합니까? – Mikhail

0

Fred의 조언에 따라 SQL Server의 테이블을 기반으로 자체 Checkpoint Manager를 구현했습니다. 코드 샘플 here을 찾을 수 있습니다.

이 구현은 EventProcessorHost에 잘 꽂습니다. 또한 기본 구현에서 많이 결합 되었기 때문에 ILeaseManager을 구현해야했습니다.

my blog post에서 저는 SQL 기반 구현과 전반적인 솔루션에 대한 높은 수준의 관점에 대한 동기를 설명했습니다.