Исходя из того, какая информация имеется в вопросе и комментариях, выясняется, что основной вопрос: В многосерверной архитектуре без сохранения состояния, как наилучшим образом предотвратить дублирование данных , здесь данные "был ли этот возврат обработан?"
Это квалифицируется как "в основном основанное на мнении".Есть несколько способов сделать это, и ни один из них не является лучшим.Вы можете сделать это с MySQL, и вы можете сделать это с Zookeeper.
Теперь приходит чистое мнение и предположение:
Чтобы обработать возврат, где-то должна быть какая-то база данных?Почему бы просто не проверить это?Сценарий с дублирующимся запросом, против которого вы готовитесь, кажется редким явлением - такого не будет сто раз в секунду.Если это так, то этот сценарий не гарантирует высокую производительность реализации.Просто поиск в базе данных должен быть в порядке.
Ваша рабочая нагрузка, похоже, равна 1:1 read:write.Каждый раз, когда возмещение обрабатывается, вы проверяете, обработано ли оно уже или нет, а если не обработано, обрабатываете его и делаете запись для него.Теперь сам Zookeeper говорит, что лучше всего работает для чего-то вроде 10:1 коэффициент read:write.Хотя для MySQL такой метрики не существует, нет необходимости * в определенных * гарантиях, которые zookeeper делает для операций записи.Следовательно, я надеюсь, что это должно быть лучше для чистой интенсивной записи. (* Гарантии, такие как последовательность, широковещание, консенсус и т. Д.)
Просто ничтожество, но ваши данные представляют собой линейный список из сотен (тысяч? Миллионов?) Идентификаторов транзакций.Это точно , для чего построен MySQL (или любая база данных) и его первичный ключ.Zookeeper создан для более сложных / мощных иерархических данных.Это вам не нужно.