Как правильно организовать работу бекэнда у мобильного приложения?

Question

[defin]

Есть мобильное приложение (вернее разрабатывается), мы отправляем на него сообщение, приложение сообщает серверу, что оно прочитано (когда оно прочитается). Нужно на бекенде обработать это обращение от приложения и сохранить в базу. Приложения сообщают id сообщения и id приложения. На сервере нужно в базе сделать два запроса:
UPDATE messages SET read = read+1 WHERE id = id приложения;
INSERT INTO log (id_mes, id_pril, date) VALUES (id сообщения, id приложения, NOW());
и отдать в ответ условный OK. Приложение ждет ответа 10 секунд в фоновом режиме.

В пиковые моменты может приходить до 10 000 таких вот обращений в секунду (проектируемая нагрузка). Но волнами, т.е. отправили мы, условно, 100 000 сообщений, их начали читать и посыпались оповещения о прочтении на сервер. По идее все приложения ждут ответа в течение 10 секунд, т.е. ответ можно не прям вот срочно отдавать, возможно некое ожидание. Нужно всё это корректно обрабатывать и сохранять.

Как всё это правильно построить? Несколько серверов под обработку, один под базу? Балансировку нагрузки делать? если да, то в какую сторону смотреть? Какие конфиги серверов?

А может вообще пересмотреть сохранение в базе? Т.е. допустим только вставки, а потом какой-нибудь бот обрабатывает отдельно и делает апдейты...

Answer 1

[thingInSelf]

В пиковые моменты может приходить до 10 000 таких вот обращений в секунду (проектируемая нагрузка). Но волнами, т.е. отправили мы, условно, 100 000 сообщений, их начали читать и посыпались оповещения о прочтении на сервер.

Буквально сейчас тестирую высокие нагрузки.
Сетевой стек Linux - говно-говном. Чтобы получать 30 000 в секунду (на виртуалке) нужно отдать ему целиком 1 ядро процессора на 100%. И это не считая того, что нужно еще обработать информацию и отдать ответ. Отдача тоже грузит ядро почти на полную, но чуть-чуть поменьше все же, чем прием.

На реальном железе не на виртуальном - народ утверждает, что можно получать примерно в 10 раз больше. Но это dedicated.

Так что 100 000 в секунду - это будет очень не просто.

Если нагрузка рваная - то специальное облако, автомасштабируемое - вас спасет.
Иначе - придется серьезно разбираться как оптимизировать, как распараллелить.

Answer 2

[Александр Трахимёнок]

Посмотрите в сторону облачных решений.

Например Google AppEngine Datastore - может масштабироваться практически безгранично. К тому же очереди бесплатно. Можно класть сообщение о прочтении в очередь и обновлять базу пачкой. Клиенту будет ответ в течении 100-500 миллисекунд. 100 000 сообщений можно будет обработать за пару секунд-минуту в зависимости от того какой лимит по количеству инстансов будет.

Я использую AppEngine Go standard environment для своего приложения по учёту долгов https://DebtsTracker.io/ и очень доволен.

Go выбрал чтобы инстансы стартовали очень быстро.

Standard, а не Flexible чтобы не управлять самому масштабированием. Хотя сейчас уже и flexible может автоматически масштабироваться.

Comments

[thingInSelf]

Например Google AppEngine Datastore

Ага.
Очень забавная штука. Пока нагрузка небольшая - бесплатно. Когда нагрузка возрастает - цена взлетает до небес.
Знаем, плавали. Точнее - прямо сейчас используем его. Мечтаем слезть.
Из безусловных бонусов - нулевое администрирование, это очень круто.

Answer 3

[Igor Kalashnikov]

Можно писать не в базу, а в какой-нибудь redis и например раз в минуту запускать балковые квери. Сэкономим время на rountrip-ах.
Update можно переписать, чтобы он высчитывал количество read из Log таблицы.

И вообще лучше всего запилить пару PoC, взять какой-нибудь JMeter и померить.