Ответ 1
Лемм выдвинул несколько основных терминов, прежде чем ответить:
EventHubs - это высокопроизводительный конвейер приема долговременных событий. Проще говоря - это надежный поток событий в облаке.
Смещение на EventData (одно событие в потоке) буквально является курсором в потоке. Наличие этого курсора - включит такие операции, как - возобновить чтение с этого курсора (он же Offset) - включительно или эксклюзивно.
Библиотека EventProcessor - это фреймворк, созданный командой EventHubs поверх пакета ServiceBus SDK для создания "приемника событийного гу" - выглядеть проще. ZooKeeper для Kafka <-> EPH для Event Hub. Он удостоверится, что процесс, запускающий EventProcessor на определенном разделе, умирает/падает - он будет возобновлен с последнего смещения Checkpointed - в другом доступном экземпляре EventProcessorHost.
CheckPoint: на сегодняшний день - EventHubs поддерживает только проверку на стороне клиента. Когда вы звоните в Checkpoint с вашего кода клиента:
await context.CheckpointAsync();
- он преобразуется в вызов хранилища (напрямую от клиента), который будет хранить текущее смещение в предоставленной вами учетной записи хранения. Сервис EventHubs не будет связываться с хранилищем для проверки чека.
ОТВЕТ
EventProcessor Framework предназначен для достижения именно того, что вы ищете.
Контрольные точки не сохраняются через сервер (он же EVENTHUBS Service). Это чисто на стороне клиента. Вы разговариваете с хранилищем Azure. По этой причине библиотека EventProcessor вносит новую дополнительную зависимость - AzureStorageClient. Вы можете подключиться к учетной записи хранения и к контейнеру, в который записаны контрольные точки - мы сохраняем информацию о владельце - экземпляры (имена) EPH к разделам концентраторов EventHub, которыми они владеют, и к какой контрольной точке они в настоящее время считываются/обрабатываются до тех пор.
В соответствии с шаблоном проверки контрольных точек на основе таймера - у вас изначально было - если Процесс остановится - вы будете заново делать события в последнем 5-минутном окне. Это здоровый образец, как:
- фундаментальное предположение состоит в том, что неисправности являются редкими событиями, поэтому вы будете иметь дело с дублирующимися событиями
- в конечном итоге вы будете делать меньше звонков в службу хранилища (что вы можете легко переполнить, часто проверяя). Я бы сделал еще один шаг и фактически произвел бы вызов контрольной точки асинхронно. OnProcessEvents не нужно проваливать, если контрольная точка терпит неудачу!
если вы хотите, чтобы абсолютно без событий повторялись - вам нужно будет построить эту логику дедупликации в нисходящем конвейере.
- каждый раз, когда запускается EventProcessorImpl - запрашивать у вашего нисходящего потока последнюю последовательность нет. он получил и продолжает отбрасывать события до текущей последовательности нет.