Size: a a a

Архитектура ИТ-решений

2020 October 05

GK

Gennadiy Kruglov in Архитектура ИТ-решений
При работе на экстремальных нагрузках у вас богатого выбора нет. Это почти всегда - асинхрон, а потом ещё и пакетная обработка.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Но 100 одновременных юзеров - это как бы очень скромно. Десятки тысяч, вот тут уже стоит думать.
источник

G

George in Архитектура ИТ-решений
Можно из одной таблицы сделать сотню, использовать партиционирование. И разным запросам выдавать разные таблицы для блокировки.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Хм. Ок. Спасибо.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Нужно уходить от модели request-response. Принимаете запрос, ставите его в обработку (конвейер/поток), возращаете результат (пуш)
источник

BI

Boris Ibulaev in Архитектура ИТ-решений
Не знаю как будет на практике, но мне нравится идея с буфером)

Двумерная коллекция, где элемент коллекции:
Тип товара -> 100 свободных айдишников.

При пустом буфере первый пользователь подождёт заполнение буфера, последующие 99 будут быстро получать незанятый айдишник для данного товара, 101-ый пользователь ждёт сброс буфера в базу и заполнение нового буфера.

Допустим 10000 типов товаров, по 100 айдишников на каждый - 8 мегабайт памяти)
upd: Если uid используется для айдишников, то 16 МБ*
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Окей, рассмотрю этот вариант, спасибо.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Хм.. а вот этих выигрышных билетов разве их не штук 10 всего?
Почему бы их просто не держать в памяти веб-сервера в статике?
Или это был гипотетический пример?
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Сервис не различает выигрышные и не выигрышные билеты.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Это вот такой вариант: сделать чтобы различал. Какой смысл хранить невыигрышные билеты?
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Отдать их пользователю.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Зачем их хранить в БД, чтобы отдавать? Можно хэш сделать и так проверять законность билета.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Законность?
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Сервис не знает про то, выигрышные билеты или нет.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Ему надо просто отдать.
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Законность: это к тому, чтобы проверить что билет настоящий.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Т.е. все билеты в оперативке держать?
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Только выигрышные.
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Нет информации о том, выигрышные билеты или нет.
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Peter Tugolukov
Т.е. все билеты в оперативке держать?
не внимательно читал переписку, но имхо - фильтр блума вам поможет
источник