#c# #.net #redis #stackexchange.redis
#c# #.net #redis #stackexchange.redis
Вопрос:
Я пытаюсь изменить поставщика Redis StackExchange с помощью Azure и просто задаюсь вопросом о наилучшей настройке.
Учитывая следующий код
private static ConnectionMultiplexer connection = ConnectionMultiplexer.Connect(...);
public string Get(string key)
{
IDatabase cache = connection.GetDatabase();
return cache.StringGet(key);
}
Будет ли получение базы данных снижать производительность, вызывая ее каждый раз при вызове кэша?
Следует ли управлять им каким-либо другим способом?
Должен ли он создаваться только для жизненного цикла объекта, но не статично?
Какова наилучшая практика управления базой данных идентификаторов?
Ответ №1:
Будет ли получение базы данных снижать производительность, вызывая ее каждый раз при вызове кэша?
Не заметно; как описано здесь:
Объект, возвращаемый из
GetDatabase
, является дешевым сквозным объектом, и его не нужно хранить.
Конечно, вы можете сохранить его, если пожелаете. Как бы то ни было, мы это делаем — но это просто потому, что мы используем разные номера баз данных (для разных сайтов), и хранить an так же удобно IDatabase
, как и хранить int
, представляющее номер базы данных.
Однако, помимо этого, вам не нужно слишком беспокоиться — если вы выделяете по требованию, сбор по-прежнему будет очень дешевым и т. Д.
Единственное, что еще стоит сказать, это то, что, возможно, стоит кэшировать в памяти перед касанием redis: вызов redis выполняется быстро, но вызов redis, который вы не выполняете, выполняется быстрее.
Комментарии:
1. «Единственное, что еще стоит сказать, это то, что, возможно, стоит кэшировать в памяти, прежде чем вы коснетесь redis: вызов redis выполняется быстро, но вызов redis, который вы не выполняете, выполняется быстрее». Я предполагаю, что под этим вы подразумеваете, что после того, как вы выполните вызов кэша, сохраните значение в памяти, возможно, только на время выполнения запроса, но это может иметь значение. В противном случае, как вы справляетесь с признанием недействительным содержимого в памяти на разных серверах?
2. @Craig в идеале, дольше, чем запрос; когда имеет значение недействительность: pub / sub; на самом деле, последние версии redis необязательно включают уведомления об изменении пространства ключей, но это должно быть включено на сервере; мы просто используем обычный явный pub / sub, когда нам нужна недействительность (наш метод «set value» имеет
bool broadcastInvalidation = false
, если вы понимаете, что я имею в виду)3. Неплохо. Есть ли у вас какие-либо примеры вашей реализации broadcastInvalidation?