Redis для .Net разработчиков

С 2014 года .net стал совсем другим (не тем, каким мы его знаем). Открытие части .net framework, новый компилятор C#, новый jit компилятор, .net native, активное использование нетипичных для windows технологий в Azure (из-за чего даже переименовали Windows Azure в Microsoft Azure), все большее движение Asp.net в сторону не только windows.

На DevCon в 2012 году мы (я) с непониманием, слушал доклады по использованию Redis в .net приложениях. В нынешнем 2015 году не обращать внимания на Redis невозможно, даже живя на другой планете.

Я для себя точкой смены вех вижу 7 октября 2014 года, когда Скотт Гаттри анонсировал общую доступность Redis Cache в Azure ^[1].

И последним ударом стало — Microsoft теперь официально рекомендует использовать Redis для кэша — «We recommend all new developments use Azure Redis Cache.»
Всю жизнь говорили SQL Server (либо распределенный AppFabric Caching), а теперь Redis.

В Asp.Net5 (до декабря 2014 — vnext) появятся возможности:

• Команда Entity Framework анонсировала поддержку NoSQL хранилищ в Entity Framework 7 (правда в первом релизе 7.0 будет по старинке только SQL Server). Моя статья ^[2] об этом.
• Xранить Session в Redis 1 ^[3] и 2 ^[4].
• И кэшировать ^[5] данные в Redis.
• Для SignalR можно использовать Redis в качестве scaleout backplane. Моя статья ^[6] и официальная ^[7]

А когда-то не так давно, во времена .net 4.0- 4.5, был только Output cache ^[8] и умельцы прикручивали Redis сами — автор на хабре недавно писал ^[9] про использование Redis вместе с CacheDependency.

Краткая справка про Redis для .net разработчиков, не следивших за Redis ранее

Изначально Redis писался под nix системы. Через какое-то время Microsoft занялся поддержкой Redis для Windows через Microsoft Open Technologies. И уже потом, от проекта под Windows, Azure форкнула свою версию.
Чтобы понимать разницу между проектами:

• antirez/redis ^[10] – 4836 комитов
• MSOpenTech/redis ^[11] – 4399 комитов
• Azure/redis ^[12] – 3813 комитов

Основную работу по поддержке Windows версии несет команда MS Open Technologies.

Она пишет Win32_Interop, для работы Redis под Windows,

сохраняя все интерфейсы/header файлы для совместимости с не windows версией; при этом ответственность на себя за windows версию берет только в Azure варианте. На локальном сервере/кластере – это на ваш страх и риск.
Команде Azure проще всего, т.к.

• Они не тащат кучу старых веток типа 2.2, 2.4. У них есть prod версия 2.8 и на этом все.
• Они не используют 32-битную версию сборки - только 64.

  
• Им не нужны инструкции инсталляции, т.к. в Azure ты просто берешь инстанс, а не занимаешься сам его настройкой.

Часто задаваемые вопросы

Коллеги, которые очень хорошо/плотно разбирались/ковырялись с SQL Server лет по 10, но вообще не ковырялись с Redis спрашивали:

А насколько он быстрый? А выдержит ли он нашу нагрузку, причем с запасом, мы ведь все-таки enterprise, а не детская площадка?

Простой ответ — Redis очень быстрый. На бытовом уровне я бы объяснил так:

• Использовать данные в памяти сильно быстрее, чем сначала читать их с диска.
• Внутри ^[13] себя Redis хранит данные в разных структурах данных в зависимости от типа. Быстрее чем поиск по hash таблице, тяжело что-то придумать (без углубления в вопросы распределения hash и качества hash функций) => если вы храните данные в ней, у вас все очень хорошо. Если храните данные в списках, то могут быть проблемы.
• Т.к. в Redis нет такого сложного конвейера обработки запроса, как в SQL, накладные расходы ниже (план запроса, к примеру, надо составить, если его нет. Он составляется на основе статистики, статистика может быть некорректной и т.д., и т.п.).

В документации есть статья ^[14] про производительность (очень рекомендую потратить время и прочесть), и сравнение производительности с memcache ^[15]/ вариант 2 ^[16]. На своих тестах Redis обошел Memcache, что очень хороший критерий производительности.

Если коротко, то 100 тысяч запросов в секунду на одном узле — это абсолютно нормальный результат, без какого-то фантастического железа или плясок с бубном при настройке. Мне нравится вот этот график,

который объясняет большую часть моментов, а именно: что при росте объема данных сеть становится узким местом, а не процессор или память. Сеть — это уже вопрос не к производительности самого Redis.

Второй вопрос был: кластерную конфигурацию поддерживает?

Ответ: да, причем из коробки, и кластер — это практически базовая конфигурация (design for cluster).
В этих статьях это описано подробно 1 ^[17] и 2 ^[18], и пусть Вас не смущает фразы про альфа/бета — тут как с gmail (которая была beta когда уже сотни миллионов ящиков на ней были по 5-6 лет в эксплуатации). Люди годами работают и не жалуются.
Кластеры поддерживают и распределение нагрузки, и отказоустойчивость. Master-узлы разделяют между собой нагрузку (диапазон ключей) + у каждого узла может быть любое число shard-ов (на которых хранится реплика мастера, готовая его заменить в случае недоступности.)

А какие хорошие библиотеки доступа из .net есть?

Года 2 назад, на devcon 2012, ребята показывали библиотеку, написанную на коленках за неделю. С тех пор мир изменился кардинально. Есть множество ^[19]библиотек, но для .net де факто стандартом стала stackexchane ^[20] (те, кто использовал другие библиотеки в своих проектах, все чаще выпиливают и заменяют на эту версию).
Чтобы начать пользоваться этой библиотекой, долго вникать в нее не нужно. Принцип ее работы можно разобрать, открыв всего 3 класса.

• github.com/StackExchange/StackExchange.Redis/blob/master/StackExchange.Redis/StackExchange/Redis/RedisCommand.cs ^[21]
• github.com/StackExchange/StackExchange.Redis/blob/master/StackExchange.Redis/StackExchange/Redis/ConnectionMultiplexer.cs ^[22]
• github.com/StackExchange/StackExchange.Redis/blob/master/StackExchange.Redis/StackExchange/Redis/RedisDatabase.cs ^[23]

Если данные хранятся в памяти, то как долговременно хранить их? Сервер же перегружается иногда!

В определении что такое Redis есть слово, которое всех сбивает с толку – InMemory, но оно не означает In Memory Only. В Redis есть механизм сброса данных на диск, точнее 2 механизма. Инкрементальный — это когда каждые n секунд (можно сделать каждые 5, 30, 600 секунд) идет сброс данных, и Полный — это когда сбрасывается все содержимое на диск. (Как с бэкапами баз данных — инкрементальный и полный бэкап). Эти варианты друг другу не противоречат, можно оба включить. Это не бесплатно в плане производительности, как и любая запись на диск.

Вместо заключения

.Net сильно меняется, и придется меняться .net разработчикам. Использование Redis – это очередной шаг эволюции платформы, и его надо принять. Это не страшно.

Ссылки

• redis ^[24]
• msdn.microsoft.com/en-us/library/azure/dn690523.aspx ^[25]
• Azure Redis ^[26]

Автор: SychevIgor

Источник ^[27]