EventStore частичное упорядочение событий и других функций

Question

Я пытаюсь оценить EventStore как в надежном механизме организации очередей, встроенном в серверное программное обеспечение.

MSMQ не удается в качестве альтернативы, потому что он не может поддерживать частичное упорядочение, упорядоченные сообщения в «разговорах».сообщений.И из-за его ограничения размера сообщения 4 МБ (который может быть преодолен с частичным упорядочением).Компонент SQL Service Broker поддерживает частичное упорядочение, но при настройке и управлении программными средствами это очень сложно.

Поскольку документация по EventStore, по общему признанию, скудна, может кто-нибудь, имеющий опыт работы с EventStore, помочь в следующем?

• Поддерживает ли EventStore транзакционную обработку событий - то есть, если обработка не удалась, можно ли откатить очередь назад?
• При наличии нескольких считывателей в различных потоках, процессах или машинах, обеспечивает ли EventStore, чтокаждое событие отправляется (?) только одному считывателю (за один раз, возможно, во время транзакции)
• При условии, что вышеизложенное возможно, могут ли события в разных «разговорах» считываться одновременно в любом порядке,в то время как сообщения в одном и том же разговоре читаются по отдельности и по порядку?
• Я читал, что EventStore в основном "по крайней мере один раз".Можно ли с помощью определенных поставщиков услуг хранения обеспечить доставку «точно один раз»?
• Как обрабатываются «ядовитые» события?События, которые выдают ошибку при обработке.Возможно, ошибка носит временный характер и может быть повторена.Возможно, он носит постоянный характер и требует административного вмешательства.
• Можно ли при необходимости управлять хранилищем EventStore вручную?Можно ли это сделать, пока другие читатели продолжают читать?

(я читал, что транзакции в хранилище не требуются, но я все еще использую язык транзакций для обозначения того, что заменяет транзакции в EventStore).Если у вас есть важные функциональные последствия при переходе от транзакций к чему-либо, пожалуйста, прокомментируйте их. Мне не нужно сразу понимать каждый аспект, просто нужно надежда , чтобы выиграть больше времени для экспериментов.)

Answer 1

Некоторые мысли, даже если вы, кажется, довольны первым ответом:

• Частичное упорядочение - это то, что происходит, если вы отслеживаете причинность сообщений.Есть способы сделать это.Наивный способ сделать это - просто сохранить список всех узлов в распределенной сети, которые было просмотрено данным сообщением, и добавить его в этот список, когда вы перемещаете сообщение.Я говорю сообщение, но я действительно ссылаюсь на сообщения в этом разговоре.

  Теперь, это может хорошо работать с простыми системами, но когда вы начинаете получать более сложные системы, вы можете захотеть, чтобы Saga отслеживала какое сообщениеозначает именно то, что.

  Тем не менее, вам может потребоваться частичное упорядочение на одном узле-получателе - и тогда sagas, если вы будете использовать шаблон «хаб-и-спик» в отношении потока сообщений, вам не помогут,Тогда, возможно, вам действительно нужно добавить некоторую логику в транспорт, который вы используете.

  Один алгоритм называется векторными часами , другой подобный называется векторами версий .Вот пример реализации векторных часов в Go - если вы хотите провести пару часов в паре, я работаю над крошечной векторной библиотекой часов для F # - потому что алгоритм действительно очень прост.Если вы действительно хотите прочитать что-то, что имеет смысл, я рекомендую эту книгу - Элементы распределенных систем .Хороши главы 2-3, 5.

  Затем вы получаете частичное упорядочение ваших разговоров в распределенной системе.Причина, по которой вы не можете получить это с помощью очереди, состоит в том, что между вашей очередью и вашим узлом имеется пропасть сети, и если узел или процесс на том же узле, что и очередь, отключается, поскольку у него есть сообщениев пути это сообщение будет поставлено в очередь и переупорядочено.То же самое, если вы NACK сообщение.Вы можете обойти эту проблему переупорядочения, используя 2PC для очереди и потребляющего клиента, или вы можете отсортировать сообщения по их векторным часам, или вы можете отсортировать их по идентификатору последовательности, который был задан в приложении публикации / отправки, или выМожно отсортировать их по некоторым данным, так как это имеет смысл с точки зрения вашего потребителя.Выбор за вами.

• Что касается других требований, таких как ядовитые сообщения, вы должны посмотреть, что дает вам служебная шина.Я лично использую MassTransit, и он хорошо обрабатывает сообщения о ядах.Вот некоторые режимы сбоя при приеме сообщений:

  • Ошибка сериализации - вы допустили ошибку программирования.Исправьте процесс разработки, потому что этого не должно быть.Если они все-таки произошли, просто переместите их в очередь ядовитых сообщений - эти сообщения, вероятно, повреждены.
  • Необработанное исключение из вашего кода - вы допустили ошибку в программировании.Опять же, ваш процесс разработки готов к проверке.Если вы не выбросите его, чтобы среда выполнения служебной шины переместила сообщение в очередь отравления.
  • У вас могут возникнуть проблемы с записью в базу данных вашего локального потребителя - это проблема операций, которая не должна возникать в коде.Убейте свой процесс, потому что вы сейчас ничего не можете сделать из кода.Naigos или какой-либо другой монитор процессов должен сообщить вашим операционным сотрудникам, что что-то не работает и что его нужно срочно исправить - потому что если вы не можете записать в свою модель чтения, то, вероятно, ваша модель чтения не сможет обслуживать запросы, предназначенные для этого.Puppet или какой-либо другой монитор процессов, вероятно, через некоторое время перезапустят ваш процесс, и затем вы сможете выполнить те же шаги, предполагая, что все в порядке, но на этот раз не начинайте расходовать свою очередь, пока у вас не будет подключения к базе данных.(это то, что NHibernate делает со своей статической инициализацией, когда он запускается, например) - и реализует политику повторных попыток, такую ​​как автоматический выключатель, поверх этой логики повторных попыток.

• Большие события - убедитесь, что ваши API очереди слишком длинны в байтовом массиве. ZeroMQ имеет многочастные сообщения. AMQP / RabbitMQ этого не сделал, так что вам, конечно, придется разбивать их на части, заставляя переупорядочивать их снова. Или вы можете просто дать указатель на двоичный двоичный объект где-нибудь, откуда вы можете прочитать его обратно, как и все мы.

Answer 2

Хотя EventStore потенциально можно использовать для создания полноценной очереди, он никогда не был разработан с учетом этого.Это означает, что существует много взвешенных решений, которые вошли в создание библиотеки, которые идут вразрез с требованиями, предъявляемыми вашим вопросом.

Например, концепция доставки «точно один раз» - это то, что системы сообщений не делаютдействительно поддерживаю.Другие вещи, упомянутые выше, например, ядовитые сообщения, на самом деле не проблема, потому что EventStore таким образом не подключен к конвейеру сообщений.

Кажется, проблема, которую вы пытаетесь решить, небыть тем, где EventStore может помочь вам.Поэтому я бы порекомендовал оценить полноценную очередь сообщений, такую ​​как RabbitMQ.

Кроме того, что у вас есть в ваших сообщениях, что делает их больше 4 МБ?Если вы перемещаетесь по файлам или большим двоичным потокам, почему бы не отправить их в какое-то высокодоступное «глобальное» хранилище (например, Amazon S3), а затем указать указатель на них в сообщении?