Производительность кэша Redis StackExchange

#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?