Есть ли хорошее решение для переменной магазина?
Я хочу сохранить переменную, отправленную из внешнего интерфейса (ReactJs) в мой внутренний интерфейс (ядро asp.net), например этот URL-адрес: http://localhost:3000/?inviteCode=TRIAL, я хочу сохранить значение TRIAL в любом месте (бэкэнд имеет более высокий приоритет), чтобы использовать его позже.
Эти вещи привели меня в замешательство, когда я выбирал, как их хранить. Я не хочу хранить его в хранилище InMemory (memcache), потому что я использовал его во многих местах, и это может привести к нехватке памяти на виртуальной машине хоста (я так думаю). Хранить его в базе данных — не лучшая идея хранить такую небольшую ценность.
Хранить его в файлах cookie внешнего интерфейса или в локальном хранилище — хорошее решение, но мой приоритет — хранить его во внутреннем хранилище.
Итак, есть ли какие-нибудь решения для хранения этого значения?
Хранилище InMemory очищается при перезапуске, что может быть не тем, что вам нужно.
Ответы 2
Похоже, что единственный оставшийся путь — это другая база данных на том же физическом сервере, что и сервер приложений (я предполагаю, что ваша текущая база данных является удаленной). SQLite может быть самым простым вариантом.
Но в целом это значение вам наверняка понадобится в будущем, и в этом случае лучше сразу сохранить его в базу данных.
Если нет, то подумайте еще раз, действительно ли этих запросов будет так много, чтобы постоянно переполнять ВМ (однократное переполнение не страшно, операционная система с этим справится). И можно ли увеличить виртуальную машину по мере необходимости?
В качестве компромисса вы можете разместить кэш памяти на отдельном сервере.
Да, мое приложение использует облачный сервис, физически ничего не размещается, поэтому меня беспокоят деньги — это бюджет. Итак, создание отдельного сервера — это одно из моих предложений в премьер-министре, но оно еще не одобрено.
сохранить переменную, отправленную из внешнего интерфейса (ReactJs) в мой внутренний интерфейс.... У меня есть использовал его во многих местах, и это могло привести к нехватке памяти
Теперь у нас есть клиентское приложение + веб-API в качестве бэкэнда, данные отправляются от клиента на бэкэнд API, и я уверен, что данные будут часто использоваться в API, поэтому вы предпочитаете хранить их на бэкэнде.
Как мы знаем, веб-API не имеет состояния, поэтому мы не можем хранить данные в сеансе (каждое http-соединение создает новый сеанс). Чтобы получить доступ к данным более эффективно, нам нужно отличаться от каждого сценария. Если мы хотим получить доступ к данным в приложении реагирования, то лучшим вариантом будет сохранение их в локальном хранилище, или, другими словами, мы должны хранить данные в браузере, чтобы код js мог читать их локально без какого-либо ввода-вывода или удаленного подключения. .
Если мы хотим получить доступ к данным в API, поскольку в текущем сценарии у нас нет встроенного сеанса, нам нужно найти места для хранения данных -> у нас есть память и диск.
Если мы храним данные на диске, нам нужен ввод-вывод. В этом сценарии мы можем использовать базу данных, если у нас много таких данных и данные не будут часто меняться, хранить данные в базе данных как словарь, даже если это приведет к затратам на ввод-вывод, а мы должны это сделать, это может привести к проблемам с производительностью, но поскольку данные невелики, запрос должен быть быстрым. Если у нас не так много данных для хранения, мы также можем записать данные в файл json или текстовый файл (зависит от формата данных), но данные все равно будут храниться на диске. SSD поможет улучшить производительность.
Если мы храним данные в памяти, мы можем использовать базу данных памяти, например Redis. База данных памяти принесет пользу, когда данные будут часто меняться, но их необходимо часто использовать. Поскольку данные хранятся в памяти, нам не нужен дисковый ввод-вывод, получить их будет гораздо быстрее, чем обращаться к обычной базе данных.
Вопрос, основанный на мнении