Здравствуйте, Ватакуси, Вы писали:
В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
держать счётчик в памяти, какие ещё могут быть решения? Гарантировать сохранение в базу будет raid-массив и дизель-генератор. Вероятность выхода из строя raid-массива с дизель-генератором считать много меньшей вероятности банкротства компании.
Здравствуйте, Ватакуси, Вы писали:
В>Да. "Правильное решение" примерно так и должно выглядеть. В>Как это осуществить?
Ну для начала, надо бы побенчмаркать, на чем вообще можно сделать HTTP-сервер, способный держать миллион пустых запросов в секунду. Скажем, если запрос и ответ укладываются в 1 килобайт (а это довольно близкое приближение), то там чисто сетевого трафика набегает по 8 гигабит в каждую сторону. Одна писишка, боюсь, не потянет, а десяток писишек потянут с легкостью, на чем не пиши. Т.е. понадобится какой-нибудь load balancer и сетевое хранилище, скорострельность которого нам не очень важна, но оно должено обладать одним хитрым свойством, о котором чуть позже.
Далее, вопрос о своевременности чтения, как многие уже заметили, не стоит, но вопрос о монотонности счетчика все же стоит упомянуть. В последовательности read-inc-read второй read должен возвращать число, которое больше, чем вернул первый read. Ну, хотя бы для приличия. И никакие два клиента, даже сговорившись, не должны увидеть одинаковый ответ на read, если в промежутке проскочил инкремент.
Поскольку для конструкции из сети, load balancer'а и нескольких писишек, обслуживание запросов будет наверняка происходить не всегда в порядке поступления, часть забот о монотонности нам придется переложить на клиентов. А именно, мы возьмем с них обязательство, что они не будут посылать несколько запросов одновременно, иначе мы не гарантируем, что их запросы будут обслужены в правильном порядке.
Еще одна печальная новость заключается в том, что из-за необходимости изображать из себя монотонный счетчик, нам придется запросы на чтение ставить в общую очередь с запросами на запись. Хотя приятнее было бы обслужить их, чтобы не мешалось, мгновенно после поступления, глядя просто на счетчик в памяти.
А что до хранилища, нам от него понадобится один единственный запрос, но хитрый: он должен прибавлять к счетчику, что сказали, и возвращать старое значение. Назовем его read-increment.
Ну а дальше все относительно просто. Нам понадобится очередь запросов. Изначально очередь пустая. Первый поступивший запрос посылает хранилищу запрос read-increment(0), если это запрос на чтение, и read-incrememt(1), если это запрос на увеличение счетчика, и становится в очередь. Остальные просто становятся в очередь. Запрос в хранилище посылается асинхронно. И еще, мы запоминаем, сколько запросов было в очереди, когда мы послали запрос в хранилище.
Когда из хранилища придет ответ, мы выгребаем из очереди столько запросов, сколько было на момент обращения к хранилищу — не зря мы запомнили это число. У нас есть вся информация, чтобы их обслужить: актуальный счетчик из базы и сколько к нему прибавилось по мере продвижения по очереди. Если у нас после этого в очереди остались запросы, мы считаем, сколько из них инкременты, и посылаем очередной read-increment(), указав в качестве параметра количество оставшихся инкрементов. Ну и так далее.
Еще было бы не лишне поставить какое-то ограничение на максимальную длинну очереди. Если оно превышено, очередной запрос сразу получает HTTP 503, и в очередь не становится.
Здравствуйте, Ватакуси, Вы писали:
В>REST-сервис
В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>read — получить текущее глобальное значение
В>сервис на сервере, который пишет и читает из постгреса.
В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
В>Ваши предложения. В>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
Какая разбивка между reads and increments? Одинаковый rps или сильный перевес с одну сторону?
Какая точность нужна для read (если ожидаем latency < 50 ms, то насколько старое значение можно вернуть, т.к очевидно что "текущее" не имеет смысла в такой системе)
И самое главное — зачем postgres, если мы по сути имеем всего несколько байт данных (ну или скаляр по одному числу на линию кэша)?
Как только вы ответите себе на эти вопросы, остальное станет просто.
Для 100К огород вообще городить не надо, один 1-сокетный сервер справится без проблем. На миллион тоже можно поколдовать.
Здравствуйте, Ватакуси, Вы писали:
В>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
Тестовое задание чтоль делаешь ?
Тривиально. Получил событие inc n — положил в очередь. Другие потоки, а то и сервера — они вычитывают из очереди и уже атомарно инкрементят счетчик, который либо в памяти, либо это распределенный кеш. Операция read тривиальная, просто достать значение. 100к держать будет даже на одной машине навскидку. Если нужен постгрес, и он оказывается узким местом (нужно проверять) — периодически иожно сбрасывать значение текущего счетчика в базу. По идее задача адекватно решается даже на одном серваке без резервирования.
Здравствуйте, Sharov, Вы писали:
Pzz>> Т.е. понадобится какой-нибудь load balancer и сетевое хранилище, скорострельность которого нам не очень важна, но оно должено обладать одним хитрым свойством, о котором чуть позже.
S>А lb то каким должен быть, ибо все эти 8Гб через него же ходят?
Вот не знаю, честно. Возможно, у них внутри что-нибудь более легковесное, чем linux TCP/IP stack.
Pzz>>А что до хранилища, нам от него понадобится один единственный запрос, но хитрый: он должен прибавлять к счетчику, что сказали, и возвращать старое значение. Назовем его read-increment.
S>Я правильно понимаю, что чтение из хранилища надо в сл. нескольких машин, а не одной?
Я не понял вопрос.
Pzz>>Ну а дальше все относительно просто. Нам понадобится очередь запросов. Изначально очередь пустая. Первый поступивший запрос посылает хранилищу запрос read-increment(0), если это запрос на чтение, и read-incrememt(1), если это запрос на увеличение счетчика, и становится в очередь. Остальные просто становятся в очередь. Запрос в хранилище посылается асинхронно. И еще, мы запоминаем, сколько запросов было в очереди, когда мы послали запрос в хранилище.
S>Смысл асинхронно, что мы будем делать в этот момент? Мы даже чтение обслужить без результата запроса не можем.
Выгребать запросы из сокетов, парсить их, ставить в очередь, рассылать ответы.
У нас основная нагрузка — это именно HTTP. Затраты на содержательную обработку запросов очень низкие.
Здравствуйте, Ватакуси, Вы писали:
В>>>REST-сервис
В>>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>>read — получить текущее глобальное значение
В>>>сервис на сервере, который пишет и читает из постгреса. В>>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
G>>Что-то не очень точные входные данные.
G>>1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1. G>>2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится. То есть надо будет несколько серверов и писать надо будет в postgres. И тут быстродействие упирается в сам postgres, потому что он сам будет задыхаться даже от 1К запросов на изменение данных. Но по условию надо получить ответ от базы. Тут поможет только сервер пожирнее, потому что мастшабировать запись в одну ячейку без потери целостности невозможно.
В>Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся). В>Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь.
В>Но решение (типа) есть.
Объединять несколько inc n на дополнительных серверах, а на основной отправлять inc n1+n2+n3+...? Но это только на запись и не известно быстрей ли будет.
inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился.
read — получить текущее глобальное значение
сервис на сервере, который пишет и читает из постгреса.
Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
Ваши предложения.
Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Ватакуси, Вы писали:
В>>REST-сервис
В>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>read — получить текущее глобальное значение
В>>сервис на сервере, который пишет и читает из постгреса. В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
G>Что-то не очень точные входные данные.
G>1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1. G>2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится.
ну можно взять какую-нибудь быструю ПЗУ, типа Intel Optane,
и писать туда напрямую, а TCP/IP и Ethernet обрабатывать почти полностью
в user-space или наоборот все в kernel space включаю логику инкремента и записи optane,
тогда я думаю 100k должно выдавать без проблем, даже на относительно слабом железе.
Здравствуйте, Ватакуси, Вы писали:
В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
Очевидно, что никакая база тебе не даст "100к или даже миллион" записей в секунду. Однако требование на 50 мс на отклик внушает надежду — 20 записей в секунду можно потянуть, даже если хранить данные в текстовом файле, который каждый раз обновляется.
Значит, тебе надо собирать запросы в кучку, суммировать их эффект, сохранять их в базу одной записью на много запросов, и если она прошла уачно, всем везунчикам отвечать "200 ОК".
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
LK>Redis + Golang?
Не гарантирует сохранение в базу.
В>>Бюджет относительно небольшой
LK>Миллион rps на виртуальном серваке за 5 баксов? Что за проект-то? Счётчик экземпляров короновируса?
Речь о том, что нельзя брать Redis Enterprise (например), который стоит миллионы денег.
LK>>>Redis + Golang? В>>Не гарантирует сохранение в базу.
LK>Почему?
А если он упадёт?
В>>Речь о том, что нельзя брать Redis Enterprise (например), который стоит миллионы денег.
LK>Энтерпрайз на 100 гиг и 100k rps стоит 4k в месяц. Бюджета в 100k вполне хватит.
Где про это можно почитать? Меня уверяли совсем в других цифрах...
Для этого есть кластерная репликация. Также можно сделать отказоустойчивость на уровне REST-сервера (Golang).
LK>>Энтерпрайз на 100 гиг и 100k rps стоит 4k в месяц. Бюджета в 100k вполне хватит. В>Где про это можно почитать?
Здравствуйте, L.K., Вы писали:
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
LK>Redis + Golang?
Здравствуйте, Ватакуси, Вы писали:
В>REST-сервис
В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>read — получить текущее глобальное значение
В>сервис на сервере, который пишет и читает из постгреса. В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
Что-то не очень точные входные данные.
1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1.
2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится. То есть надо будет несколько серверов и писать надо будет в postgres. И тут быстродействие упирается в сам postgres, потому что он сам будет задыхаться даже от 1К запросов на изменение данных. Но по условию надо получить ответ от базы. Тут поможет только сервер пожирнее, потому что мастшабировать запись в одну ячейку без потери целостности невозможно.
Здравствуйте, Ватакуси, Вы писали:
В>REST-сервис
В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>read — получить текущее глобальное значение
Зачем n? В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик. В>Ваши предложения.
Ставишь Kafka/rabbit, складируешь запросы (гарантия что все будут обработаны), и раскидываешь их по обработчикам которые пишут в базу. Схема конечно тупая т.к. в базу будут ломиться все обработчики запросов и она будет узким местом, но если баз несколько, то можно наверное. Короче, я в этом не разбираюсь, написал как нафантазировал, возможно я бред несу .
В>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
амазон SQS, динамические инстансы под нагрузку, вопрос только к том, выдержит ли твоя БД 1кк update-ов в секунду.
LK>>>Энтерпрайз на 100 гиг и 100k rps стоит 4k в месяц. Бюджета в 100k вполне хватит. В>>Где про это можно почитать?
LK>На официальном сайте, разумеется:
LK>https://redislabs.com/redis-enterprise-cloud/pricing/
Я может тупой, но где там про 100k rps написано?
В>>REST-сервис
В>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>read — получить текущее глобальное значение
В>>сервис на сервере, который пишет и читает из постгреса. В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
G>Что-то не очень точные входные данные.
G>1) Предположим у нас есть бесконечно мощный веб-сервер, который сам по себе вывезет 1М rps. Тогда не нужен даже постгрес, просто пишем данные в файл на диск при inc с эксклюзивной блокировкой на запись и отдаем файл с диска при запросе read. Быстрее точно никак не получится. Это может даже для 100к сработать если соотношение чтении и записи 100:1. G>2) Но в реальности сервер не выдержит 1М rps, просто очередь переполнится. То есть надо будет несколько серверов и писать надо будет в postgres. И тут быстродействие упирается в сам postgres, потому что он сам будет задыхаться даже от 1К запросов на изменение данных. Но по условию надо получить ответ от базы. Тут поможет только сервер пожирнее, потому что мастшабировать запись в одну ячейку без потери целостности невозможно.
Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся).
Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь.
В>>REST-сервис
В>>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>>read — получить текущее глобальное значение K>Зачем n?
Хочешь на 1 увеличить или на 10, например.
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик. В>>Ваши предложения. K>Ставишь Kafka/rabbit, складируешь запросы (гарантия что все будут обработаны), и раскидываешь их по обработчикам которые пишут в базу. Схема конечно тупая т.к. в базу будут ломиться все обработчики запросов и она будет узким местом, но если баз несколько, то можно наверное. Короче, я в этом не разбираюсь, написал как нафантазировал, возможно я бред несу .
Да, всё упрётся в базу.
Но кафка (типа) часть решения, да.
В>>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся. K>амазон SQS, динамические инстансы под нагрузку, вопрос только к том, выдержит ли твоя БД 1кк update-ов в секунду.
Одной БД не сделать, это понятно.
Здравствуйте, Ватакуси, Вы писали:
В>Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся). В>Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь. В>Но решение (типа) есть.
Если мы предполагаем что количество запросов растет бесконечно, то есть заведомо больше чем любая жеезная конфигурация может выдержать, то нет решения без дополнительных условий.
Потому что CAP-теорему (будь она неладна) обмануть нельзя. Тут или согласованностью чтения надо жертвовать, или время ответа не жестко фиксировать.
Но в реальности нет такого, что количество запросов растет бесконечно. Более того, 90% проектов не преодолеют возможности одной машины.
Здравствуйте, Ватакуси, Вы писали:
В>Хочешь на 1 увеличить или на 10, например.
Мне не понятно зачем тебе счётчик такой нужен. В>Одной БД не сделать, это понятно.
можно амазоновускую заюзать, но $$$$ отвалишь .
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Ватакуси, Вы писали:
В>>read — получить текущее глобальное значение
L>А что такое "текущее" значение? Если у тебя дофига запросов на запись, то оно будет устаревать практически сразу после чтения.
В>>Именно в этом и заключается подвох задачи. Увеличивать мощность сервера приложений или даже сервера ДБ нельзя до бесконечности (да и деньги кончатся). В>>Поскольку все запросы inc будут биться за одну глобальную переменную, то они сразу станут в очередь. В>>Но решение (типа) есть.
G>Если мы предполагаем что количество запросов растет бесконечно, то есть заведомо больше чем любая жеезная конфигурация может выдержать, то нет решения без дополнительных условий. G>Потому что CAP-теорему (будь она неладна) обмануть нельзя. Тут или согласованностью чтения надо жертвовать, или время ответа не жестко фиксировать.
G>Но в реальности нет такого, что количество запросов растет бесконечно. Более того, 90% проектов не преодолеют возможности одной машины.
Не бесконечно, конечно же. Кол-во запросов просто большое.
В>>read — получить текущее глобальное значение
L>А что такое "текущее" значение? Если у тебя дофига запросов на запись, то оно будет устаревать практически сразу после чтения.
Согласен.
Но интуитивно, это значение, которое успело уже записаться.
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
МГ>держать счётчик в памяти, какие ещё могут быть решения? Гарантировать сохранение в базу будет raid-массив и дизель-генератор. Вероятность выхода из строя raid-массива с дизель-генератором считать много меньшей вероятности банкротства компании.
В>>Хочешь на 1 увеличить или на 10, например. K>Мне не понятно зачем тебе счётчик такой нужен.
Просто поболтать, это же не настоящая задача, ты понимашь.
В>>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
Pzz>Очевидно, что никакая база тебе не даст "100к или даже миллион" записей в секунду. Однако требование на 50 мс на отклик внушает надежду — 20 записей в секунду можно потянуть, даже если хранить данные в текстовом файле, который каждый раз обновляется.
Pzz>Значит, тебе надо собирать запросы в кучку, суммировать их эффект, сохранять их в базу одной записью на много запросов, и если она прошла уачно, всем везунчикам отвечать "200 ОК".
Да. "Правильное решение" примерно так и должно выглядеть.
Как это осуществить?
M>Какая разбивка между reads and increments? Одинаковый rps или сильный перевес с одну сторону? M>Какая точность нужна для read (если ожидаем latency < 50 ms, то насколько старое значение можно вернуть, т.к очевидно что "текущее" не имеет смысла в такой системе)
Это заранее неизвестно, скажем так. Т.е. может быть любое соотношение.
M>И самое главное — зачем postgres, если мы по сути имеем всего несколько байт данных (ну или скаляр по одному числу на линию кэша)?
Можно предлагать, что угодно. Можно и отказаться от него, если есть решение.
M>Как только вы ответите себе на эти вопросы, остальное станет просто. M>Для 100К огород вообще городить не надо, один 1-сокетный сервер справится без проблем. На миллион тоже можно поколдовать.
Очевидно, что узким местом тут является запись в глобальную переменную. Как это распарралелить?
Z>ну можно взять какую-нибудь быструю ПЗУ, типа Intel Optane, Z>и писать туда напрямую, а TCP/IP и Ethernet обрабатывать почти полностью Z>в user-space или наоборот все в kernel space включаю логику инкремента и записи optane, Z>тогда я думаю 100k должно выдавать без проблем, даже на относительно слабом железе.
Здравствуйте, Ватакуси, Вы писали:
В>>>read — получить текущее глобальное значение
L>>А что такое "текущее" значение? Если у тебя дофига запросов на запись, то оно будет устаревать практически сразу после чтения.
В>Согласен. В>Но интуитивно, это значение, которое успело уже записаться.
В смысле, с гарантией, что при повторном запросе нельзя получить ответ меньше, чем при первом запросе. Никакой другой гарантии особо не получится.
Здравствуйте, Ватакуси, Вы писали:
В>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", но тогда возможно придется увеличить количество экземпляров сервисов, да и лаги станут больше.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Ватакуси, Вы писали:
В>>Да. "Правильное решение" примерно так и должно выглядеть. В>>Как это осуществить?
Pzz> Т.е. понадобится какой-нибудь load balancer и сетевое хранилище, скорострельность которого нам не очень важна, но оно должено обладать одним хитрым свойством, о котором чуть позже.
А lb то каким должен быть, ибо все эти 8Гб через него же ходят?
Pzz>А что до хранилища, нам от него понадобится один единственный запрос, но хитрый: он должен прибавлять к счетчику, что сказали, и возвращать старое значение. Назовем его read-increment.
Я правильно понимаю, что чтение из хранилища надо в сл. нескольких машин, а не одной?
Pzz>Ну а дальше все относительно просто. Нам понадобится очередь запросов. Изначально очередь пустая. Первый поступивший запрос посылает хранилищу запрос read-increment(0), если это запрос на чтение, и read-incrememt(1), если это запрос на увеличение счетчика, и становится в очередь. Остальные просто становятся в очередь. Запрос в хранилище посылается асинхронно. И еще, мы запоминаем, сколько запросов было в очереди, когда мы послали запрос в хранилище.
Смысл асинхронно, что мы будем делать в этот момент? Мы даже чтение обслужить без результата запроса не можем.
Здравствуйте, Ватакуси, Вы писали:
В>REST-сервис
В>inc n — увеличить глобальное значение на n. После того как запись в базу сделана возвращается код 200. Это гарантия, что счётчик увеличился. В>read — получить текущее глобальное значение
В>сервис на сервере, который пишет и читает из постгреса.
В>Как сделать / спроектировать систему так, чтобы она работала на 100k или даже миллионе rps и не более 50 мс отклик.
В>Ваши предложения. В>Бюджет относительно небольшой, поэтому всякие супер-космические решения не годятся.
Надежность какая нужна? Судя по неидемпотентному API, абсолютная точность не требуется. Так что оптимально — синхронизированный счетчик в памяти, который периодически, каждые 10 мс, например, пишется в постгрес.
Для масштабирования разворачиваются несколько нод, каждая со своим собственным счетчиком. read читает данные всех счетчиков и суммирует.
Здравствуйте, Pzz, Вы писали:
Pzz>>>А что до хранилища, нам от него понадобится один единственный запрос, но хитрый: он должен прибавлять к счетчику, что сказали, и возвращать старое значение. Назовем его read-increment. S>>Я правильно понимаю, что чтение из хранилища надо в сл. нескольких машин, а не одной? Pzz>Я не понял вопрос.
В случае одной машины зачем в базу лезть? Т.е. писать надо, а отвечать можно по памяти.
