Здравствуйте, Ватакуси, Вы писали:

В>REST-сервис

В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился.
В>read — получить текущее глобальное значение

В>сервис на сервере, который пишет и читает из постгреса.

В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.

В>Ваши предложения.
В>Бюджет относительно небольшой, поэтому всякие супер-космхраниические решения не годятся.

Абстрактная проблема — абстрактное решение.

Несколько серверов с сервисами для обслуживания запросов "inc n".
Каждый сервер со своим экземпляром СУБД(PostgreSQL по условию задачи), на локальном диске/дисковом массиве(никаких внешних СХД). В каждом экземпляре PostgreSQL собственный счетчик-накопитель. Сервисы обрабатывающие запросы "inc n" кешируют текущее значение счетчика-накопителя в памяти(изменение кеша после успешного изменения в БД), и периодически отправляют(push) его сервису-агрегатору(собственный протокол поверх UDP, или даже RDMA).
Балансировка, например посредством DNS. Получаем практически неограниченное горизонтальное масштабирование по запросу "inc n".

Сервис-агрегатор периодически суммирует push-и от вышеописанных сервисов и отправляет(push) результат множеству сервисов "read"(собственный протокол поверх multicast UDP, или RDMA, если RDMA умеет multicast). Сервис-агрегатор не нуждается в хранилище данных.

Несколько сервисов "read" котрые отправляют суммарное значение счетчиков-накопителей клиентам по запросу. Получаем практически неограниченное горизонтальное масштабирование по запросу "read". Сервис "read" не нуждается в хранилище данных.

Потенциальное узкое место — сервис-агрегатор. Но он только суммирует числа и отправляет результаты(причем не персонально каждому сервису получателю, а сразу всем, и без установки соединения). В крайнем случае можно применить каскадирование агрегаторов, и тогда агрегация станет горизонтально масштабируемой.

Стоимость реализации сравнительно не высока, так как специальнго оборудования не требуется. Сервисам-агрегаторам и сервисам "read" даже HDD после старта не нужен. Для сервисов "inc n" важны только накопители с низкой задержкой.

Недостаток только в том, что актуальное значение глобального счетчика для поттребителя доступно с небольшой задержкой. Но суммарная сетевая задержка запроса и ответа, для потребителя может быть даже больше, чем лаг внутри системы сервисов.

Здравствуйте, Ватакуси, Вы писали:

В>REST-сервис

В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился.
В>read — получить текущее глобальное значение

В>сервис на сервере, который пишет и читает из постгреса.

В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.

В>Ваши предложения.
В>Бюджет относительно небольшой, поэтому всякие супер-космхраниические решения не годятся.

Абстрактная проблема — абстрактное решение.

Несколько серверов с сервисами для обслуживания запросов "inc n".
Каждый сервер со своим экземпляром СУБД(PostgreSQL по условию задачи), на локальном диске/дисковом массиве(никаких внешних СХД). В каждом экземпляре PostgreSQL собственный счетчик-накопитель. Сервисы обрабатывающие запросы "inc n" кешируют текущее значение счетчика-накопителя в памяти(изменение кеша после успешного изменения в БД), и периодически отправляют(push) его сервису-агрегатору(собственный протокол поверх UDP, или даже RDMA).
Балансировка, например посредством DNS. Получаем практически неограниченное горизонтальное масштабирование по запросу "inc n".

Сервис-агрегатор периодически суммирует push-и от вышеописанных сервисов и отправляет(push) результат множеству сервисов "read"(собственный протокол поверх multicast UDP, или RDMA, если RDMA умеет multicast). Сервис-агрегатор не нуждается в хранилище данных.

Несколько сервисов "read" котрые отправляют суммарное значение счетчиков-накопителей клиентам по запросу. Получаем практически неограниченное горизонтальное масштабирование по запросу "read". Сервис "read" не нуждается в хранилище данных.

Потенциальное узкое место — сервис-агрегатор. Но он только суммирует числа и отправляет результаты(причем не персонально каждому сервису получателю, а сразу всем, и без установки соединения). В крайнем случае можно применить каскадирование агрегаторов, и тогда агрегация станет горизонтально масштабируемой.

Стоимость реализации сравнительно не высока, так как специальнго оборудования не требуется. Сервисам-агрегаторам и сервисам "read" даже HDD после старта не нужен. Для сервисов "inc n" важны только накопители с низкой задержкой.

Недостаток только в том, что актуальное значение глобального счетчика для поттребителя доступно с небольшой задержкой. Но суммарная сетевая задержка запроса и ответа, для потребителя может быть даже больше, чем лаг внутри системы сервисов.

Можно обойтись и без "собственный протокол поверх UDP, или даже RDMA", но тогда возможно придется увеличить количество экземпляров сервисов, да и лаги станут больше.