Как мне напомнили в комментариях - история развивается по спирали.
Очереди (очереди не равно топики Kafka) есть в Oracle https://docs.oracle.com/en/database/oracle/oracle-database/19/adque/aq-introduction.html
И они поддерживают общие транзакции с таблицами.
Также у Oracle есть шлюз для связывания внутренних и внешних очередей https://docs.oracle.com/en/database/oracle/oracle-database/21/adque/messaging_gateway.html
Аналогично для MSSQL https://learn.microsoft.com/ru-ru/sql/database-engine/service-broker/benefits-of-programming-with-service-broker?view=sql-server-ver16
Спасибо @AViIgnatov
#rdbms #mq #transactions
Очереди (очереди не равно топики Kafka) есть в Oracle https://docs.oracle.com/en/database/oracle/oracle-database/19/adque/aq-introduction.html
И они поддерживают общие транзакции с таблицами.
Также у Oracle есть шлюз для связывания внутренних и внешних очередей https://docs.oracle.com/en/database/oracle/oracle-database/21/adque/messaging_gateway.html
Аналогично для MSSQL https://learn.microsoft.com/ru-ru/sql/database-engine/service-broker/benefits-of-programming-with-service-broker?view=sql-server-ver16
Спасибо @AViIgnatov
#rdbms #mq #transactions
Oracle Help Center
Advanced Queuing User's Guide
Advanced Queuing (AQ) is a robust and feature-rich message queuing system integrated with Oracle Database. These topics discuss Oracle Database Advanced Queuing (AQ) and the requirements for complex information handling in an integrated environment.
Зачем нужен MQ?
По работе передо мной периодически встает данный вопрос - зачем нужен MQ? Нужен ли он?
Поясню. Мы давно и успешно перешли с ESB поверх IBM WebSphere MQ на Kafka. Стало сильно лучше. В первую очередь за счет того, что получить топик Kafka, выпустить сертификаты и настроить ACL сильно проще, чем заказать доработку для на ESB. Да, это проблемы ESB, а не MQ, но их исчезновение все сразу заметили) Второй плюс: появились persistence и возможность повторной вычитки сообщения в случае сбоя - и сильно увеличилась надежность решения. И конечно же Kafka быстрее.
Как итог - Kafka используется везде и всегда. При этом есть понимание, что кроме Kafka есть другие инструменты, реализующие паттерн очередь (queue). Долгое время не мог сформулировать - в каких кейсах нужны очереди?
Ведь паттерн publisher-subscriber, реализованный в Kafka, является более общим, чем очередь. И т.об. очереди - асинхронное взаимодействие с одним producer и одним consumer - вроде бы можно делать в и Kafka. А возможность везде использовать один инструмент - это плюс.
Но если подумать - суть не в реализуемом паттерне. Ключевые отличия у Kafka и RabbitMQ (взял самую известную реализацию очередей для конкретики) другие. Покажу их на примере того, чего Kafka не умеет:
1) Kafka не удаляет сообщение после вычитки. Удаляет позднее, по TTL, вместе с партицией, но это другой алгоритм и другой use case. Т.е. первая потенциальная причина выбора очередей - необходимость гарантировать, что вычитанное одним потребителем, никогда не вычитает другой. Не скажу, что это частый кейс - возможно, требования безопасности.
2) Kafka имеет достаточно ограниченные возможности по маршрутизации. По сути на клиенте можно выбрать топик и партицию по определенному ключу. Вот и вся маршрутизация. Причем это было сделано сознательно, для достижения высокой производительности. Если нужна более сложная маршрутизация - это критерий для выбора очереди вместо Kafka. Тоже кейс не частый, и есть альтернатива в виде реализации маршрутизации на клиенте.
3) невозможно организовать конкурентную вычитку сообщений на consumer - конкуренция ограничена числом партицией. Меня число партицией после создания топика можно, но не нужно, т.к. это приводит к ребалансировке и плохо прогнозируемому падению производительности
4) у Kafka свой протокол. Поэтому если нужна поддержка существующего решения, где используется AMPQ или JMS - это не к Kafka. Особый случай, но упомянуть его надо.
Вот пожалуй и все варианты, когда Kafka не подходит.
P.S. Если знаете еще кейсы - напишите, плиз, в комментариях.
#mq #kafka
По работе передо мной периодически встает данный вопрос - зачем нужен MQ? Нужен ли он?
Поясню. Мы давно и успешно перешли с ESB поверх IBM WebSphere MQ на Kafka. Стало сильно лучше. В первую очередь за счет того, что получить топик Kafka, выпустить сертификаты и настроить ACL сильно проще, чем заказать доработку для на ESB. Да, это проблемы ESB, а не MQ, но их исчезновение все сразу заметили) Второй плюс: появились persistence и возможность повторной вычитки сообщения в случае сбоя - и сильно увеличилась надежность решения. И конечно же Kafka быстрее.
Как итог - Kafka используется везде и всегда. При этом есть понимание, что кроме Kafka есть другие инструменты, реализующие паттерн очередь (queue). Долгое время не мог сформулировать - в каких кейсах нужны очереди?
Ведь паттерн publisher-subscriber, реализованный в Kafka, является более общим, чем очередь. И т.об. очереди - асинхронное взаимодействие с одним producer и одним consumer - вроде бы можно делать в и Kafka. А возможность везде использовать один инструмент - это плюс.
Но если подумать - суть не в реализуемом паттерне. Ключевые отличия у Kafka и RabbitMQ (взял самую известную реализацию очередей для конкретики) другие. Покажу их на примере того, чего Kafka не умеет:
1) Kafka не удаляет сообщение после вычитки. Удаляет позднее, по TTL, вместе с партицией, но это другой алгоритм и другой use case. Т.е. первая потенциальная причина выбора очередей - необходимость гарантировать, что вычитанное одним потребителем, никогда не вычитает другой. Не скажу, что это частый кейс - возможно, требования безопасности.
2) Kafka имеет достаточно ограниченные возможности по маршрутизации. По сути на клиенте можно выбрать топик и партицию по определенному ключу. Вот и вся маршрутизация. Причем это было сделано сознательно, для достижения высокой производительности. Если нужна более сложная маршрутизация - это критерий для выбора очереди вместо Kafka. Тоже кейс не частый, и есть альтернатива в виде реализации маршрутизации на клиенте.
3) невозможно организовать конкурентную вычитку сообщений на consumer - конкуренция ограничена числом партицией. Меня число партицией после создания топика можно, но не нужно, т.к. это приводит к ребалансировке и плохо прогнозируемому падению производительности
4) у Kafka свой протокол. Поэтому если нужна поддержка существующего решения, где используется AMPQ или JMS - это не к Kafka. Особый случай, но упомянуть его надо.
Вот пожалуй и все варианты, когда Kafka не подходит.
P.S. Если знаете еще кейсы - напишите, плиз, в комментариях.
#mq #kafka