Всем привет! у каждого джуна происходит переломный момент, когда наспех собранной мускул таблички перестаёт хватать, латенси падает, все рушится, и следующий проект нужно собирать уже максимально грамотно.
Допустим, мы разрабатываем клиент-серверное приложение, в котором все клиенты много пишут данных, но читают и вовсе в несколько раз больше. Чат/мессенджер/что-то подобное.
Я задался вопросом верной архитектуры бекенда для подобной задачи с точки зрения хранения данных, и накидал грубую схемку:
Я приблизительно понял, как распределить нагрузку по чтению, плюс не обязательно делать это именно по регионам, это я так, для примера их привел. Но, грубо говоря, балансировщик нагрузки должен отправлять клиента на ноду, близкую к нему, например, где он с меньшей задержкой получит свои сообщения.
Допустим, так же - с записью, только чтоб не происходило проблем с одновременной записью с разных источников - сделал очередь сообщений. т.е. сбор потоков сообщений в одну кучу, а далее в "однопоточном" режиме запись в master базу. Хреново как-то получается, нет? Выходит, точка отказа - мастер бд + сервис очередей, и общая пропускная способность и скорость всего и вся зависит от этих двух частей. В чем я не прав и как сделать лучше?
по хорошему, надо и писать сначала в slave чтоб не было так что юзер отправил сообщение, но увидел его же только через, условно, 20 минут, когда оно пройдет весь путь от записывателя до считывателя в том же регионе. НО как в таком случае тогда это должно все выглядеть - вообще не представляю.
Простой
Простой
