Навіщо нам потрібні брокери повідомлень на зразок RabbitMQ через таку базу даних, як PostgreSQL?

Я новачок у брокерах повідомлень, таких як RabbitMQ, які ми можемо використовувати для створення завдань / черг повідомлень для такої системи планування, як Celery .

Тепер ось питання:

• Я можу створити таблицю в PostgreSQL, яку можна доповнити новими завданнями та споживати споживчою програмою, на зразок Celery.

• Чому на землі я б хотів налаштувати цілу нову технологію для такого типу RabbitMQ?

Тепер я вважаю, що масштабування не може бути відповіддю, оскільки наша база даних, як PostgreSQL, може працювати в розподіленому середовищі.

Я поглянув на те, які проблеми створює база даних для конкретної проблеми, і виявив:

• опитування зберігає базу даних зайнятою та низькопродуктивною
• блокування столу -> знову малоефективне
• мільйони рядків завдань -> знову ж таки, опитування малоефективне

Тепер, як RabbitMQ або будь-який інший подібний брокер вирішує ці проблеми?

Також я з’ясував, що AMQPпротокол - це те, що випливає. Що в цьому чудового?

Чи може Redis також використовуватися в якості брокера повідомлень? Я вважаю його аналогічним Memcached, ніж RabbitMQ.

Будь ласка, пролийте трохи світла на це!

Черги кроликів залишаються в пам'яті, і тому будуть набагато швидшими, ніж реалізація цього в базі даних. (Хороша) виділена черга повідомлень також повинна забезпечувати важливі функції, пов’язані з чергою, такі як регулювання дроселювання / потоку та можливість вибору різних алгоритмів маршрутизації, щоб назвати пару (кролик надає ці та багато іншого). Залежно від розміру вашого проекту, ви можете також захотіти, щоб компонент, що передає повідомлення, був окремим від вашої бази даних, так що якщо один компонент зазнає великого навантаження, він не повинен перешкоджати роботі іншого.

Щодо згаданих вами проблем:

• опитування по підтримці бази даних Buzy і низькі виконавський : Використання RabbitMQ, виробники можуть підштовхнути поновлення для споживачів , які набагато більш продуктивними , ніж опитування. Дані просто надсилаються споживачеві, коли це потрібно, усуваючи необхідність в марних чеках.

• блокування таблиці -> знову малоефективне: немає таблиці для блокування: P

• мільйони рядків завдання -> повторне опитування малоефективне: Як було сказано вище, Rabbitmq працюватиме швидше, коли знаходиться в ОЗУ, і забезпечує контроль потоку. Якщо потрібно, він також може використовувати диск для тимчасового зберігання повідомлень, якщо у нього закінчується оперативна пам’ять. Після 2.0, Rabbit значно покращився у використанні оперативної пам'яті. Також доступні варіанти кластеризації.

Що стосується AMQP, я б сказав, що дійсно класною особливістю є "обмін" та можливість його переходу на інші біржі. Це дає вам більшу гнучкість та дає змогу створити широкий набір складних типологій маршрутизації, які можуть стати дуже зручними при масштабуванні. Для хорошого прикладу дивіться:

_{(джерело: springsource.com )}

і: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

Нарешті, що стосується redis, так, він може бути використаний як брокер повідомлень, і може робити добре. Однак Rabbitmq має більше функцій черги повідомлень, ніж redis, оскільки rabbitmq був побудований з нуля, щоб він був повнофункціональною спеціальною чергою повідомлень на рівні підприємства. Redis, з іншого боку, був створений в першу чергу для зберігання ключових значень пам'яті (хоча це робить набагато більше, ніж зараз; його навіть називають ножем швейцарської армії). Тим не менш, я читав / чув, що багато людей досягають хороших результатів із Redis для менших розмірів проектів, але не чули багато про це у великих програмах.

Ось приклад того, як Redis використовується у чаті для довгого опитування: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

PostgreSQL 9.5

PostgreSQL 9.5 включає SELECT ... FOR UPDATE ... SKIP LOCKED. Це робить впровадження робочих систем черги набагато простішими та легшими. Вам більше не потрібна система зовнішньої черги, оскільки тепер легко отримати "n" рядки, які не заблокували жоден інший сеанс, і тримати їх заблокованими, поки ви не підтвердите, що робота виконана. Він навіть працює з двофазними транзакціями, коли потрібна зовнішня координація.

Зовнішні чергові системи залишаються корисними, забезпечуючи функціональність консервів, перевірену продуктивність, інтеграцію з іншими системами, варіанти горизонтального масштабування та федерації тощо. Тим не менш, для простих випадків вони вам вже не потрібні.

Старіші версії

Вам не потрібні такі інструменти, але використання цього може полегшити життя. Робити чергу в базі даних виглядає просто, але ви на практиці виявите, що високопродуктивні, надійні паралельні черги справді важко зробити в реляційній базі даних.

Ось чому такі інструменти, як PGQ, існують.

Ви можете позбутися опитування в PostgreSQL, використовуючи LISTENі NOTIFY, але це не вирішить проблему надійної передачі записів з верхньої частини черги точно одному споживачеві, зберігаючи при цьому дуже одночасну роботу та не блокуючи вставки. Усі прості та очевидні рішення, які, на вашу думку, вирішать цю проблему, насправді не є в реальному світі, і, як правило, перероджуються в менш ефективні версії отримання черги з одним працівником.

Якщо вам не потрібні дуже одночасні вибори черги з кількома працівниками, то використання єдиної таблиці черг у PostgreSQL цілком розумно.