Черга повідомлень База даних проти виділених MQ

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

Початкова пропозиція полягала в тому, щоб просто використовувати екземпляр SQL Server і обробляти повідомлення з цього приводу. Все, що я прочитав в Інтернеті, говорить про те, що використання бази даних для черги повідомлень не є масштабним рішенням. З цієї причини була запропонована ідея використання RabbitMQ або якоїсь іншої сторони MQ.

Інша річ, яку слід врахувати, - це те, що вимога до "обробки робіт" не буде нижчою за 30 секунд, тому процес, який виконує завдання, опитуватиме базу даних кожні 30 секунд. Мені це не здається поганим, і, ймовірно, спрацює нормально, не додаючи великого навантаження до Бази даних.

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

Інший варіант, який я розглядав, дозволяв користувачам обирати один із них. Якщо вони маленькі користувачі, тоді рішення сервера Sql буде нормальним, але якщо вони більші користувачі, ми дозволяємо їм налаштувати сторонне рішення MQ.

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

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

Дійсність, яку часто ігнорують " не використовувати X, оскільки вона не масштабує " (посилання містить мову, де деякі можуть виявитись протилежною) натовп, це те, що шкала не завжди важлива. Я б пішов так далеко, щоб сказати, що якщо дивитися на кожен додаток на обличчі планети в сукупності, масштаб рідко важливий.

Ваш коментар посилається на швидкість 20 000 повідомлень щодня, що означає, що вам потрібно буде підтримувати середню швидкість 0,23 повідомлення в секунду (кожне 4,3 секунди). Якщо ваш проект виявиться на два порядки більш успішним, ніж ви очікували, ваші вимоги переходять до обробки 23 повідомлень в секунду, що є завданням, яке мені буде дуже зручно давати моєму чотирирічному мобільному телефону або Малині Пі. Це все ще не є масштабним додатком, навіть якщо ви дотримуєтесь ще декількох порядків величини.

Я спостерігав (на щастя, в кулуарах), що проекти закінчуються погано, тому що вони або витратили занадто багато часу занадто рано, одержимі масштабом, що не відбудеться, або часу на нього взагалі не було, і розчавилися від масштабу, який врешті-решт і зробив. Як і все інше, є щасливий засіб. Якщо ви вважаєте, що масштабне масштабування вашої програми є реалістичною можливістю, не може бути складно зробити бізнес-справу для того, щоб виконати невелику кількість зайвих робіт, щоб створити достатню абстракцію навколо не масштабованих частин, які недорого розгортати зараз . Це означає, що пізніше , якщо виникне потреба в масштабі, у вас є спосіб (і, можливо, дохід) зробити оптову заміну цих частин без необхідності переосмислювати всю систему.

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

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

Якщо у вас просто є одна "черга роботи" з речей, які ви хочете обробити "офлайн", тоді таблиця SQL буде добре.

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

Як інші згадані масштаби, мабуть, тут не важливі. Проблема використання двох різних механізмів зберігання даних - транзакційна цілісність.

Якщо ви збираєтесь із виділеною чергою повідомлень, вам потрібно вибрати одне з наступних у разі відмови.

1. Дозволити, що дані можуть бути на mb, але не в db
2. Дозволити, що дані можуть бути в db, але не в mb
3. Установіть двофазну фіксацію або розподіл транзакцій між db a mq, що може бути складним

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

Для практичності основними причинами використання черги повідомлень є:

• Мені не довелося винаходити колесо. Проектування навіть найпростішої черги повідомлень за допомогою бази даних вимагає принаймні пару годин роздумів, декілька годин кодування тощо. Порівняно з реалізацією черги повідомлень час, необхідний для налаштування та / або автоматизації конфігурації, є тривіальним
• Черги з повідомленнями мають приємний та зрозумілий інтерфейс для виробника та споживача. Це, мабуть, найважливіше в написанні заявки. Без інтерфейсу черги з повідомленнями - це лише сукупність даних
• Черги повідомлень надають більше функцій, які можуть знадобитися в майбутньому

Що стосується дозволу користувачам вибору, це дійсно детальна інформація про впровадження, про яку користувачі не повинні піклуватися. Користувачі повинні отримувати один і той же інтерфейс, і для користувачів не повинно бути різниці, якщо використовується база даних чи черга повідомлень. Після встановлення єдиного дизайну можливим вибором користувачів є те, скільки вузлів потрібно розгорнути для задоволення їх потреб.

Я створив рішення з черги повідомлень Mssql, яке може обробляти 20k операцій в секунду, відповідно до тесту на продуктивність, і нам потрібно 10 / сек більшу частину часу. Я думаю, що те, що ви можете насправді мати вбудований пріоритет - це особливість, якої не вистачає виділеної черги повідомлень. І це було головною вимогою в моєму випадку.