Redis .Net розробників

image image


З 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). Моя стаття про це.
  • Зберігати 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 форкнула свою версію.
Щоб розуміти різницю між проектами:
Основну роботу з підтримки Windows версії несе команда MS Open Technologies.
Вона пише Win32_Interop, для роботи Redis під Windows,image зберігаючи всі інтерфейси/header файли для сумісності з windows версією; при цьому відповідальність на себе за версію windows бере тільки в Azure варіанті. На локальному сервері/кластері — це на ваш страх та ризик.
Команді Azure простіше всього, т. к.
  • Вони не тягнуть купу старих гілок типу 2.2, 2.4. У них є prod версія 2.8 і на цьому все.
  • Вони не використовують 32-бітну версію збірки — лише 64.image
  • Їм не потрібні інструкції інсталяції, т. к. в Azure ти просто береш інстанси, а не займаєшся сам його налаштуванням.


часті питання

Колеги, які дуже добре/щільно розбиралися/колупалися з SQL Server років за 10, але взагалі не колупалися з Redis запитували:

А наскільки він швидкий? А чи витримає він нашу навантаження, причому з запасом, адже ми все-таки enterprise, а не дитячий майданчик?
Проста відповідь — Redis дуже швидкий. На побутовому рівні я б пояснив так:
  • Використовувати дані в пам'яті значно швидше, ніж спочатку читати їх з диска.
  • себе Redis зберігає дані в різних структурах даних в залежності від типу. Швидше ніж пошук по hash таблиці, важко щось придумати (без заглиблення у питання розподілу hash і якості hash функцій) => якщо ви зберігаєте дані в ній, у вас все дуже добре. Якщо зберігайте дані у списках, то можуть бути проблеми.
  • Т. к. в Redis немає такого складного конвеєра обробки запиту, як SQL, накладні витрати нижче (план запиту, наприклад, треба скласти, якщо його немає. Він складається на основі статистики, статистика може бути некоректною і т. д. і т. п.).
В документації є стаття про продуктивність (дуже рекомендую витратити час і прочитати), і порівняння продуктивності з memcache/ вариант 2. На своїх тестах Redis обійшов Memcache, що дуже хороший критерій продуктивності.

Якщо коротко, то 100 тисяч запитів в секунду на одному сайті — це абсолютно нормальний результат, без якогось фантастичного заліза або танців з бубном при налаштуванні. Мені подобається ось цей графік,
image
який пояснює більшу частину моментів, а саме: що при зростанні обсягу даних мережа стає вузьким місцем, а не процесор або пам'ять. Мережа — це вже питання не до продуктивності самого 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 — це черговий крок еволюції платформи, і його треба прийняти. Це не страшно.

Посилання



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.