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

2015-01-13 в 6:23, admin, рубрики: .net, Microsoft Azure, nosql

С 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.

И последним ударом стало — 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). Моя статья об этом.
Xранить Session в Redis 1 и 2.
И кэшировать данные в Redis.
Для SignalR можно использовать Redis в качестве scaleout backplane. Моя статья и официальная

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

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

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

antirez/redis – 4836 комитов
MSOpenTech/redis – 4399 комитов
Azure/redis – 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 очень быстрый. На бытовом уровне я бы объяснил так:

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

Автор: SychevIgor

Источник

Информация

Обсуждаемое

Рекомендуем