Чому база даних як черга така погана? [зачинено]

Я щойно прочитав цю статтю , і я розгублений.

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

О, я сказав "ділитися" .. але про що попереджає стаття? :

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

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

Продовжимо: webapp обробляє HTTP-запити клієнта і може в будь-який час оновити деякі агрегати (термін DDD), генеруючи відповідні події домену.
Метою працівника було б обробляти ці події в домені, обробляючи необхідні завдання.

Справа в тому:

Як слід передавати працівникові дані про події?

Першим рішенням, як пропагує прочитана стаття, було б використовувати RabbitMQ, будучи чудовим програмним забезпеченням, орієнтованим на повідомлення.

Робочий процес буде простим:

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

Приклад: Можливо, подія була опублікована без успіху сукупного оновлення ... в результаті чого подія представляла помилкове представлення доменної моделі.
Ви можете стверджувати, що глобальна XA (двофазна комісія) існує, але це не рішення, яке відповідає всім базам даних або середнім.

Отже, що може бути хорошим рішенням для забезпечення цієї негайної послідовності? :
IMO, зберігання події в базі даних, в тій же локальній транзакції, що і сукупне оновлення.
Простий асинхронний планувальник створив би і відповідав за запит поточних неопублікованих подій з бази даних та надсилає їх у RabbitMQ, який, у свою чергу, заповнює працівника.

Але навіщо потрібен додатковий планувальник на стороні webapp і до речі: навіщо потрібен RabbitMQ в цьому випадку?

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

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

Витяг із статті:

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

І негайна послідовність, ігнорована?

Підводячи підсумок, насправді здається, що в будь-якому випадку, значить, база даних спільна чи ні, нам потрібно опитування бази даних .

Я пропустив якісь критичні поняття?

Спасибі

Якщо ви будуєте просту програму з низьким трафіком, можна щось сказати про те, щоб уникнути іншого компонента у вашій системі. Ймовірно, що не використання шини повідомлень є правильною відповіддю для вас. Однак я б запропонував побудувати вашу систему таким чином, щоб ви могли поміняти систему черг на базі даних для рішення проміжного програмного забезпечення. Я погоджуюся зі статтею. База даних не є правильним інструментом для системи, що базується на черзі, але вона може бути достатньою для вас.

Система, що базується на черзі, як RabbitMq, побудована в масштабному розмірі на помірному обладнання. Їх архітектура здатна досягти цього, уникаючи процесів, які роблять систему сумісних баз даних ACID повільною за своєю природою. Оскільки шині повідомлень потрібно лише забезпечити збереження та успішну обробку повідомлення, йому не потрібно займатись блокуванням та записом журналів транзакцій. Обидві ці концепції абсолютно необхідні для системи кислотних кислот, але часто є причиною суперечок.

Виконання продуктивності зводиться до: у вас є SQL-таблиця. Багато читає і багато пише. Обидва вимагають певного блокування для оновлення рядків, сторінок та індексів. Ваш механізм опитування постійно блокує індекс, щоб робити його пошуки. Це перешкоджає написанню записів; в кращому випадку вони стоять у черзі. Код, який виконує обробку, також блокується для оновлення стану в черзі, коли вони завершуються або виходять з ладу. Так, ви можете зробити оптимізацію запитів після оптимізації, щоб змусити це працювати, або ви можете використовувати систему, спеціально розроблену для робочого навантаження, про яке ви запитуєте. RabbitMq з’їдає цей вид робочого навантаження, навіть не порушуючи поту; Крім того, ви можете зберегти свою базу даних від завантаженого навантаження, даючи їй більше місця для масштабування інших дій.

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

Редагування: Додавання випадку використання.

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