Как спроектировать работника без состояния для обработки сообщения только один раз с помощью Uber Cadence

Question

Пожалуйста , помогите нам принять каденцию:D

Вот текущий дизайн. Некоторые работники без состояния извлекают сообщения из централизованной очереди для их обработки. Сложная бизнес-логика задействована как в рабочей, так и в функциональной возможности Deduper, которая использует отдельный кластер Redis в качестве удаленного распределенного кэша (строгая согласованность с использованием консенсуса). В этом кэше хранятся только идентификаторы сообщений и их статусы: "выполняется", "завершено" и "не запущено". Очевидно, что работник должен обрабатывать незавершенное сообщение.

Лично я хотел бы переосмыслить все возможные решения. Модель рабочего процесса приходит мне на ум, потому что у меня приятный опыт работы с AWS SWF. Поскольку все наши сервисы написаны на ходу и работают в нашем собственном центре обработки данных, я хотел бы попробовать Uber Cadence (с открытым исходным кодом SWF).

Я посмотрел много видео от пользователей Uber, и я думаю, что первым шагом является создание одного действия в новом рабочем процессе в качестве начала, а затем разбить его на несколько действий или, возможно, позднее на AWS lambda, когда мы перенесем его в AWS.

Поэтому я перечисляю все требования здесь

1. Избегайте обработки сообщения дважды несколькими работниками.
2. 50 тыс. Запросов / с, поэтому необходимо масштабируемое решение
3. низкая задержка на p99, надеюсь < 300 мс

Пока что только первое требование - это головная боль, поскольку кэш Redis - это удаленный кластер. Есть некоторые проблемы с подключением в prod, и мы действительно хотим избавиться от них, чтобы избежать сложности и дополнительных сетевых скачков.

Вопросов:

1. Вот и мне интересно, как спроектировать дедупер при переходе на каденцию?

Читая документ, Cadence предоставляет функцию уникальности идентификатора рабочего процесса внутри домена. Может быть, я могу использовать идентификатор сообщения как часть идентификатора рабочего процесса, например, WF-00001, чтобы гарантировать отсутствие дубликатов внутри домена. Там не будет никаких проблем, пока я использую только один домен. Тогда я не знаю ограничения этого подхода. например, количество рабочих процессов, разрешенных внутри домена. у нас скорость обработки сообщений 50k / с (пик)

Я не уверен, что это правильный подход. Больше идей приветствуются.

2. Есть ли веб-страница с перечнем всех ограничений Cadence? нам нужно это, чтобы оценить Каденс.

Спасибо

SWF Step Function Uber Cadence

Answer 1

На высоком уровне Cadence хорошо подходит для вашего случая использования.

1. Дедупер довольно прост. Рабочий процесс хранит карту последних идентификаторов запросов (или всех запросов, которые принадлежат данному рабочему идентификатору, если их число ограничено) и выполняет проверку на дублирование.

2. Большинство ограничений Cadence являются специфичными для развертывания и настраиваются. Давайте обсудим ваш конкретный вариант использования в Slack.