Последние сообщения

Хотелось бы по подробней узнать, зачем использовать паттерн MVC в DST Platform? Какие вообще преимущества и минусы MVC. Также было здорово понять MVC в реальной веб-разработке: как работает контроллер?

Денис Наумов

Ну если просто то MVC помогает грамотно организовать собственный код — по функциям каждого конкретного блока. Это повышает его читаемость. Вам будет проще к нему возвращаться и дорабатывать, а другим разработчикам — легче его понять.

Спасибо всем за ответы. Просто у нас переходов на сайт много, а обращений нет, как с этим быть?

Agrarium

Расскажу один интересный эксперимент, который проводил мой коллега. Был у него клиент юрист. Думали вместе, какой сделать сайт. Это было достаточно давно, тогда еще не было каких-то явных элементов, повышающих конверсию.

Решили поэкспериментировать и заказали сайт у трех разных разработчиков. Юристы вполне могут себе это позволить. Разработчики трех разных уровней: профессиональный опытный специалист, с небольшим опытом и студент. Кстати, третий согласился сделать бесплатно в качестве тренировки и наглядного материала для дипломной работы.

Первый сайт получился красивый, яркий, с акцентами. Смотришь, глаз не нарадуется. Второй сайт средний, как у всех, но тоже неплохой. А третий внешне вообще не привлекательный, чем-то похож на сайт гос.структры.

Запустили рекламу на все сайты одновременно. И что вы думаете – третий «убогонький» сайт побил все рекорды У него конверсия оказалась в 15% Это в 3 раза выше нормы. А все потому, что он вызывал доверие у посетителей сайта. В умах людей юрист – это дорого, если сильно роскошный сайт, значит этот юрист берет много денег.

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

Поэтому если, у вашего сайта нет или мало обращений, нужно что-то менять. Анализируйте входящий трафик, работайте с отказами, вебвизором, страницами входа и выхода, визуалом, юзабилити. Это все вам поможет довести сайт до нужной конверсии, и вы начнете получать обращения.

Спасибо всем за ответы. Просто у нас переходов на сайт много, а обращений нет, как с этим быть?

Кстати на CR влияет много факторов, так что не стоит считать его главной метрикой в маркетинге, которая отражает эффективность рекламы. CR — важный элемент общей картины, но вписывать его туда нужно осмысленно. В следующих статьях мы поговорим о том, на какие ещё показатели стоит обращать внимание. Учитывайте все каналы, по которым может прийти пользователь: не только заказы с сайта, но и звонки, офлайн-конверсии. Тогда вы точно оцените, сколько людей совершили целевое действие.

Конверсия — это процент посетителей сайта, которые совершили определённое действие, например зарегистрировали профиль или заказали товар. В маркетинге для этого показателя используют обозначение CR, или conversion rate.

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

Как вычислить коэффициент конверсии

Конверсия в Директе — это количество целевых визитов.

Целевое действие — то, ради чего проводится рекламная кампания. Оно может быть таким:

— Покупка → самое частое целевое действие
— Посещение разделов «Контакты», «Каталог», «Прайс» → для интернет⁠-⁠магазина, продающего сайта
— Заявка с просьбой предоставить информацию, вопрос → для сайта юридических услуг
— Регистрация на форуме или сайте → для информационного или игрового портала

Коэффициент конверсии (conversion rate, CR) — маркетинговый показатель, который помогает определить, как количество целевых действий соотносится с общим количеством посещений сайта или приложения. Например, цель кампании — собрать контакты потенциальных клиентов. Тогда каждое заполнение формы обратной связи будет увеличивать показатель CR.

Как посчитать конверсию в процентах:

CR = (Количество целевых визитов ÷ Общее количество посещений) × 100

Количество конверсий — это абсолютный показатель, а CR — относительный.

Чем CR отличается от CTR

С метрикой CR связан ещё один показатель конверсии.

Коэффициент кликабельности (click through rate, CTR) — отношение количества кликов к общему числу показов объявления или рекламного баннера.

Рассчитывается он по формуле, похожей на расчёт CR:

CTR = (Количество кликов ÷ Количество показов) × 100

При запуске кампании сначала обращают внимание на CTR:
он показывает процент пользователей, которые увидели рекламное объявление или баннер и перешли на сайт.

Дальше оценивают уже CR-конверсию — процент посетителей сайта, которые совершили целевое действие.

От чего зависит количество конверсий

— Рекламная кампания: релевантные ключевые запросы с минус-словами, тексты и посадочные страницы.
— Удобство сайта: навигация, простая форма заказа, быстродействие.
— Качество трафика: насколько клиент подготовлен и заинтересован в товарах и услугах. Например, человеку с идеальным зрением не нужны очки, даже самый продающий текст вам не поможет.
— Качественная работа с теми, кто совершил целевое действие. Надо быстро отправлять заказы и отвечать на письма, проводить грамотные консультации. Если это заявка — доведите человека до покупки, если заказ — превратите клиента в постоянного.
— Остальные причины, которые от вас не зависят: день недели, время суток, сезон, распродажи, праздники.

Как связаны конверсия и эффективность рекламы

С помощью коэффициента конверсии можно анализировать эффективность рекламной кампании. Но всегда ли высокий CR означает высокую эффективность?

Предположим, у нас есть два сайта.

Сайт 1: 5 000 посещений, 200 продаж. CR = 4%.
Сайт 2: 1 000 посещений, 100 продаж. CR = 10%.

CR второго более чем в два раза выше первого. Однако по посещаемости первый сайт в пять раз превосходит второй. При прочих равных условиях с точки зрения охвата аудитории первый случай тоже можно считать эффективным. Всё зависит от цели кампании, от цены привлечённого заказа и от того, окупились ли вложения в рекламу.

На что лучше ориентироваться, измеряя эффективность: CR или количество конверсий?

Представьте ситуацию: вы добавили в кампанию ключевые запросы, которые увеличили охват рекламы и количество кликов. Посетителей стало в три раза больше, но количество заказов не выросло. Таким образом, количество конверсий осталось прежним, а CR упал втрое.

Хорошо это или плохо — зависит от цели кампании. Если требовалось увеличить охват, то у вас всё получилось. А если повысить продажи — снижение CR говорит, что цели вы не достигли.

Важно разделять понятия «коэффициент конверсии» и «количество конверсий». Мы рекомендуем ориентироваться на CR: именно он характеризует качество трафика и в конечном счёте эффективность рекламной кампании.

Как повысить конверсию

Первый этап — исследование

Изучаем причины низкой конверсии (анализируем кампанию, сайт, работу с клиентами). Ищем способы, как устранить их. Собираем аналитику и формулируем гипотезу.

Если нужно увеличить CR, в первую очередь изучаем качество трафика и посадочные страницы; если количество конверсий — оцениваем ещё и количество трафика.

Второй этап — эксперимент

Устраняем причины низкой конверсии: оптимизируем кампанию, изменяем сайт. Например:

— Работаем с запросами — минус-слова, вложенные и нецелевые запросы, дубли, пересечения
— Пишем релевантные тексты
— Добавляем точные посадочные страницы
— Анализируем сайт, смотрим на него глазами потенциального покупателя
— Подбираем таргетинги: настраиваем рекламу на целевую аудиторию (ретаргетинг, сегменты аудитории)

Какая конверсия сайта считается хорошей или должна быть

Но какую конверсию сайта можно посчитать хорошей? В среднем этот показатель колеблется от 0,5% до 14%. Однако, стоит говорить о том, что для одного сайта мало, для другого нормально. Например, первый ресурс выдает конверсию в 9%, а второй – 3%. Но, у второго сайта получается средний чек больше, а значит и прибыли будет больше. Получается, что второй ресурс со своими 3% выигрывает.

Поэтому говорить о конкретной цифре хорошей конверсии сайта для любого ресурса практически невозможно. Следует рассматривать этот показатель для конкретного сайта. Так, хорошая конверсия сайта – эта та, которая перекрывает траты владельца на рекламу, зарплату работникам, аренду помещения и другое.

Чтобы достигнуть такой конверсии, не следует забывать о таком определении, как воронка продаж, ведь клиент должен пройти все ее этапы, прежде чем купит вашу продукцию (товар/услугу). Вам нужно сначала привлечь внимание посетителя, потом заинтересовать его в продукции.

Следующим шагом станет сделать так, чтобы пользователь изъявил желание купить или добавить в корзину продукцию. И, наконец, сделал покупку.

Виды конверсии сайта

Теперь давайте поговорим о видах конверсии сайта. Их существует два. Это макроконверсия и микроконверсия. Остановимся на каждом из них для большего понимания этого показателя успешности интернет-продвижения.

Основой макроконверсии являются продажи, а именно целевые действия пользователей к соотношению общего числа аудитории сайта. Увеличить этот процент старается каждый предприниматель, ведь основными правилами бизнеса являются его развитие, постоянная прибыль, учитывание перспектив и другое.

А вот микроконверсия строится на шагах, которые совершает посетитель перед покупкой. Он тесно связан с воронкой продаж. От этого вида конверсии зависят результаты первого. Это, своего рода, промежуточный показатель, но при этом также очень важный. Анализируя его, можно выявить недостатки того, почему так мало посетителей совершают действие, и исправить недочет.

Конверсия сайта: какие факторы влияют

Не маловажным будет знать о том, какие факторы влияют на конверсию сайта. Зная их, можно понять, как на них повлиять и что улучшить на веб-ресурсе, ведь от этого зависит региональное продвижение сайтов агентством или самостоятельно. Они делятся на внешние и внутренние факторы.

И так, внешние факторы подразумевают действия аудитории до ее перехода на веб-ресурс. Во-первых, на них влияет реклама. Если о сайте аудитория не знает, то она не сложит мнение о веб-ресурсе, а значит не будет и заинтересованности в нем, как и дальнейших действий.

Во-вторых, на конверсию ресурса влияет его место в списке поисковых систем. Здесь говориться о SEO-продвижении по позициям с попаданием веб-ресурса в ТОП-10. Чем выше сайт в выдаче, тем больше вероятность того, что аудитория перейдет на него.

Внутренние факторы – это ваш ресурс. На них повлиять легче, ведь вы сами можете улучшить его, чтобы аудитория проводила на нем как можно больше времени.

Внутренние факторы, влияющие на конверсию сайта:

— Дизайн сайта. Он должен привлекать посетителей, а не отталкивать. Пренебрегать им не следует, так как это первое, что видит аудитория.

— Контент сайта. Он должен быть уникальным и информативным для аудитории чтобы они нашли всю интересующую их информацию.

— Юзабилити сайта. Веб-ресурс должен быть удобным в использовании, чтобы аудитория не запуталась при поиске ответов на свои вопросы.

— Техническое состояние веб-ресурса. Он дожжен быстро загружаться, быть без каких-либо ошибок (например, ошибка 404), без лишних страниц и многое другое.

— Семантическое ядро веб-ресурса. Оно должно быть грамотно и правильно составлено. Иначе это снизить вашу конверсию.

Повышение конверсии сайта: как улучшить

Теперь мы знаем о факторах, влияющих на конверсию сайта, поэтому сейчас расскажем вам о повышении конверсии. Эти советы помогут владельцам веб-ресурсов правильно построить работу по улучшению этого показателя.

Способы по повышению конверсии:

— Постоянно просматривайте различные браузеры для выхода в интернет. Это нужно для того, чтобы ваш сайт правильно показывался в них.

— Контактная информация должна быть исчерпывающей. Предоставьте пользователям все контакты для связи, ведь будущий клиент может передумать сделать покупку из-за разных мобильных операторов.

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

— На сайте должен быть раздел с информацией о компании: чем занимается, история, награды и т.д.

— Отзывы также должны быть. Они помогут потенциальному клиенту принять решение: покупать или нет.

— Покупка продукции должна быть простой и удобной. Постарайтесь убрать лишние действия.

— Не забывайте о правильной и четкой навигации. Она должна помогать найти ответ, а не запутывать еще больше.

Как узнать конверсию сайта?

Ответ на вопрос «Как узнать конверсию сайта?» также важен. В этом вам помогут сервисы для ее измерения. В основном, это Яндекс. Метрика и Google Analytics. Ранее мы писали о Яндекс.Метрике, а также говорили, что это такое Google Analytics и как работает. Эти сервисы бесплатны.

В Яндекс Метрике для начала следует поместить счетчик для определения числа пользователей и их действий. После этого следует задать цели, по которым сервис будет считать действия аудитории. В Метрике их четыре типа: число просмотренных страниц аудиторией веб-ресурса; число просмотров конкретной страницы сайта; событие, как удачный показатель для владельца веб-ресурса; постепенные шаги для совершения действия на веб-ресурсе.

Для счетчиков есть ограничение, а именно 100 целей. Поэтому в Метрике разработали и внедрили колонку с показателем отложенной конверсии. Она помогает узнать те переходы, которые пользователь совершил напрямую с адресной строки браузера.

В Google Analytics также присутствуют цели. Это переход аудитории на заданную страницу, нахождение на сайте аудитории какое-то время, просмотр заданного числа страниц веб-ресурса аудиторией и совершение ею действия. Для упрощения работы в сервисе есть шаблоны, что убыстряет работу.

Подводя итог, можно сказать, что конверсия сайта – один из наиважнейших показателей в интернет-продвижении. Если владелец веб-ресурса знает о проценте этого показателя, то он может поднять интерес аудитории к сайту, что приведет и к поднятию действий с ее стороны. Получается, что у компании повысится прибыль. Чего и добивается каждый бизнесмен.

Я хочу использовать Redis в качестве базы данных на DST Platform, а не кэша. Насколько я (ограниченно) понимаю, Redis — это хранилище данных в оперативной памяти. Каковы риски при использовании Redis и как их можно снизить?

Евгений Абрамов

Поскольку Redis — это хранилище в оперативной памяти, вы не можете хранить большие объёмы данных, которые не помещаются в память вашего компьютера. Обычно Redis работает очень плохо, если объём хранимых данных превышает 1/3 объёма оперативной памяти. Таким образом, это серьёзное ограничение при использовании Redis в качестве базы данных.

Конечно, вы можете распределить большие данные по нескольким экземплярам Redis, но вам придётся делать это вручную. Обычно эта операция выполняется следующим образом (при условии, что изначально у вас есть только один экземпляр):

— Используйте механизм «ведущий-ведомый» для репликации данных на второй компьютер. Теперь у вас есть две копии одних и тех же данных.

— Оборвите соединение между ведущим и ведомым устройством.

— Удалите первую половину (разделенную с помощью хеширования и т. д.) данных на первом компьютере и удалите вторую половину данных на втором компьютере.

— Скажите всем клиентам (PHP, C и т. д.) работать на первом компьютере, если указанные ключи находятся на этом компьютере, в противном случае работайте на втором компьютере.

Именно так масштабируется Redis! Вам также нужно остановить свой сервис, чтобы предотвратить запись данных во время миграции.

Исходя из нашего опыта, мы пришли к следующему выводу о Redis: Redis не подходит для хранения более 30 ГБ данных, Redis не масштабируется, Redis вполне подходит для разработки прототипов.

Позже мы нашли альтернативу Redis — SSDB(github.com/ideawu/ssdb), сервер уровня БД, который поддерживает почти все API-интерфейсы Redis и подходит для хранения более 1 ТБ данных, что зависит только от размера вашего жёсткого диска.

Я хотел бы поделиться некоторыми вещами, которые мы узнали, используя Redis в качестве основной базы данных в нашем сервисе на базе DST Platform. Мы выбрали Redis, потому что у нас были данные, которые нельзя было разделить на разделы. Мы хотели добиться максимальной производительности от одного сервера

Плюсы:

— Redis был непревзойденным по производительности. Мы получали 10 000 транзакций в секунду «из коробки» (обратите внимание, что одна транзакция включала в себя несколько команд Redis). После нескольких оптимизаций и использования скриптов LUA мы смогли достичь скорости 25 000+ транзакций в секунду. Таким образом, когда дело касается производительности на один сервер, Redis не имеет себе равных.

— Redis очень прост в настройке и имеет очень небольшую кривую обучения по сравнению с другими хранилищами данных SQL и NoSQL.

Минусы:

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

— Самая большая проблема, с которой мы столкнулись при работе с Redis, — это отсутствие гибкости. Как только вы определяете структуру своих данных, любые изменения в требованиях к хранилищу или шаблонах доступа практически требуют переосмысления всего решения. Не уверен, что это относится ко всем хранилищам данных NoSQL (я слышал, что MongoDB более гибкая, но сам её не использовал).

— Поскольку Redis работает в однопоточном режиме, загрузка процессора очень низкая. Вы не можете разместить несколько экземпляров Redis на одном компьютере, чтобы повысить загрузку процессора, так как они будут конкурировать за один и тот же диск, что приведёт к его перегрузке.

— Отсутствие горизонтальной масштабируемости — это проблема, о которой упоминалось в других ответах.

Redis — это хранилище в оперативной памяти, которое также может записывать данные обратно на диск. Вы можете указать, сколько раз выполнять fsync, чтобы сделать Redis более безопасным (но и более медленным => компромисс).

Но все же я не уверен, что redis еще не в состоянии действительно хранить в нем критически важные данные (пока?). Если, например, это не большая проблема, когда появляется еще 1 твит (twitter.com ) или что-то подобное приведет к потерям, тогда я бы обязательно использовал redis. Также много информации о постоянстве доступно на собственном веб-сайте redis.

Вам также следует знать о некоторых проблемах с сохранением данных, которые могут возникнуть при чтении статьи в блоге antirez (разработчиков Redis). Вам стоит почитать его блог, потому что у него есть несколько интересных статей.

Вы можете использовать Redis в качестве авторитетного хранилища несколькими способами:

— Включите AOF (хранилище файлов только для добавления) см. документацию по AOF. Это позволит вести журнал всех команд Redis, выполняемых с вашим набором данных, в режиме реального времени.

— Запускайте Redis с помощью репликации Master-Slave см. документацию по репликации. Это позволит обеспечить высокую доступность в случае сбоя одного из ваших экземпляров.

— Если вы используете что-то вроде EC2, вы можете использовать EBS для резервного копирования раздела Redis, чтобы обеспечить дополнительный уровень защиты от сбоев инстанса.

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

Используем keydb как для кеша, так и хранения горячих данных

В кеше одно ядро, в среднем, обрабатывает 2,5 млн команд в минуту, в среднем, количество обрабатываемых команд колеблется от 2 до 10 млн хз, как redis с таким наплывом справится.

Сколько читаю подобные статьи, никто не пишет то, что висит в воздухе:

— если используется хранение данных, то, при перезагрузке редиса/кейдб, ему надо время, чтобы загрузить данные в память и чем больше данных, тем дольше редис отбрасывает коннекты к базе, например, rdb-файл размером 30Гб, будет грузится около 15 минут и все это время редис работать НЕ БУДЕТ, имейте это ввиду, чтобы потом не оказалось, что у вас сайт на 15 минут упал, потому, что кто-то решил редис дернуть.

— касаемо aof помните, это файл ЖУРНАЛА, т.е. туда пишется КАЖДАЯ команда и если вы не включили перезапись файла, то будьте готовы к тому, что у вас закончится место на диске спустя очень короткое время, если будет большая активность.

— если используете хранение данных, следите за местом. вам надо иметь запас минимум x2 от текущего размера данных в памяти иначе, в момент форка (неважно rdb или aof) у вас закончится место на диске, потому как в этот момент создается temp файл, куда скидываются данные и только после этого удаляется старый файл.

Почему бы не использовать и RDB, и AOF? А также что насчет создания форков?

Евгений Абрамов

Можно скомбинировать AOF и RDB в одном и том же экземпляре Redis. Если надёжность хранения данных в обмен на некоторое снижение скорости вас устраивает — можно так и поступить. Полагаю, что это — приемлемый способ использования Redis. Но при этом, если система будет перезагружена, помните о том, что для восстановления данных Redis будет использовать AOF, так как в этом хранилище находится более полная версия данных.

Создание форков процессов Redis

Теперь, когда мы разобрались с механизмами организации постоянного хранения данных в Redis, поговорим о том, как это делается в однопоточном приложении наподобие Redis.

Создание форка процесса Redis. Снепшот содержит данные, актуальные на определённый момент времени. После создания форка данные копируются на диск.

Полагаю, что самое приятное в Redis — это то, как тут используется создание форков и копирование при записи для реализации высокопроизводительного копирования данных в постоянное хранилище.

Форк — это когда операционная система, по команде, вызванной неким процессом, создаёт новый процесс, копируя родительский процесс. В результате в нашем распоряжении оказывается новый ID процесса и ещё некоторые полезные сведения. При этом только что созданный форк процесса (процесс-потомок) может взаимодействовать с процессом-родителем.

А вот теперь начинается самое интересное. Redis — это процесс, которому выделено огромное количество памяти. Как скопировать такой процесс и не столкнуться с нехваткой памяти?

Когда создают форк процесса — процесс-родитель и процесс-потомок используют память совместно. Redis начинает процесс создания снепшота в процессе-потомке. Это возможно благодаря технике совместного использования памяти, называемой «копирование при записи». При этом во время создания форка память не выделяется, используются ссылки на уже выделенную память. Если, во время сброса данных дочерним процессом на диск, ничего в памяти не менялось, новая память выделяться не будет.

В том случае, если изменения были, происходит следующее. Ядро операционной системы отслеживает ссылки на каждую страницу памяти. Если на некую страницу имеется больше одной ссылки — изменения записываются в новые страницы. Процесс-потомок ничего не знает об изменениях, в его распоряжении имеется стабильный снимок памяти. В результате для создания форка процесса используется лишь небольшой объём памяти. Мы можем быстро и эффективно создавать снепшоты, отражающие состояние хранилища на некий момент времени, размеры которых могут достигать многих гигабайтов.

Итоги

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

А для чего собственно нужен Redis, можно по подробней, желательно из практики

Fresh Sound

Redis (Remote Dictionary Service) — это опенсорсный сервер баз данных типа ключ-значение.

Точнее всего описать Redis можно, сказав, что это — сервер структур данных. Уникальные особенности сервера Redis стали основной причиной его популярности и того, что он применяется во множестве реальных проектов.

Вместо того чтобы работать со строками базы данных, перебирать, сортировать, упорядочивать их, что если информация с самого начала будет находиться в структурах данных, которые нужны программисту? Первое время Redis использовали практически так же, как Memcached. Но, по мере развития Redis, эта система управления базами данных (СУБД) нашла применение и во многих других ситуациях. В частности — в реализациях механизма издатель/подписчик, в задачах потоковой обработки данных, в системах, где нужно работать с очередями.

Вот какие типы данных поддерживает Redis:

— Строка (String)

— Битовый массив (Bitmap)

— Битовое поле (Bitfield)

— Хеш-таблица (Hash)

— Список (List)

— Множество (Set)

— Упорядоченное множество (Sorted set)

— Геопространственные данные (Geospatial)

— Структура HyperLogLog (HyperLogLog)

— Поток (Stream)

Redis — это база данных, размещаемая в памяти, которая используется, в основном, в роли кеша, находящегося перед другой, «настоящей» базой данных, вроде MySQL или PostgreSQL. Кеш, основанный на Redis, помогает улучшить производительность приложений. Он эффективно использует скорость работы с данными, характерную для памяти, и смягчает нагрузку центральной базы данных приложения, связанную с обработкой следующих данных:

— Данные, которые редко меняются, к которым часто обращается приложение.

— Данные, не относящиеся к критически важным, которые часто меняются.

Примеры таких данных могут включать в себя сессионные кеши или кеши данных, а так же содержимое панелей управления — вроде списков лидеров и отчётов, включающих в себя данные, агрегированные из разных источников.

Традиционный подход к использованию Redis выглядит следующим образом: клиент обращается к приложению, а оно получает необходимые для выполнения его запроса данные. Сначала (пункт 1 на рисунке) приложение обращается к кешу Redis представленному главной базой данных (Main). Если данные в кеше есть, произошло попадание кеша, выполняется обычный возврат данных. Если произошёл промах кеша (пункт 2), система обращается к постоянному хранилищу (в данном случае — базе данных MySQL). Данные из него (пункт 3) загружаются в кеш, после чего ими сможет воспользоваться приложение. 

Но во многих случаях Redis гарантирует достаточно высокий уровень сохранности данных, что позволяет использовать эту СУБД в роли настоящей основной базы данных. А добавление в систему плагинов Redis и различных конфигураций высокой доступности (High Availability, HA) делает базу данных Redis крайне интересной для определённых сценариев использования и рабочих нагрузок.

Ещё одна важная особенность Redis заключается в том, что эта СУБД размывает границы между кешем и хранилищем данных. Тут важно понять то, что чтение данных из памяти и работа с данными, находящимися в памяти, гораздо быстрее чем те же операции, выполняемые традиционными СУБД, использующими обычные жёсткие диски (HDD) или твердотельные накопители (SSD).

Временные характеристики задержек и пропускной способности систем, о которых стоит знать каждому программисту. 

Изначально Redis чаще всего сравнивали с Memcached, с системой, в которой тогда не было и намёка на долговременное хранение данных.

Хранилище Memcached создал в 2003 году Брэд Фицпатрик. Оно появилось на 6 лет раньше Redis. Сначала это был Perl-проект, а позже его переписали на C. В своё время Memcached был стандартным инструментом кеширования. Главные различия между ним и Redis заключаются в том, что в Memcached имеется меньше типов данных, и в ограничениях, связанных с политикой вытеснения ключей. Memcached поддерживает лишь политику LRU (Least Recently Used), когда первыми вытесняются данные, которые не использовались дольше всех.

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

В наши дни Redis поддерживает настройку того, как именно данные сохраняются на диск. А в самом начале эта система использовала снепшоты, когда асинхронные копии данных, находящихся в памяти, отправляли на диск для долговременного хранения. К сожалению, у этого механизма имеется недостаток, выражающийся в возможной потере данных, изменённых или добавленных в хранилище на временных интервалах между снепшотами.

Хранилище Redis, с момента его появления в 2009 году, серьёзно развилось. Мы рассмотрим большую часть архитектурных и топологических решений, характерных для Redis, что позволит вам, изучив эту систему, включить её в состав своего арсенала систем хранения данных.

Архитектура Redis

Прежде чем мы начнём разговор о внутренних механизмах Redis — рассмотрим различные варианты развёртывания этого хранилища и обсудим компромиссы, на которые приходится идти тем, кто выбирает тот или иной вариант.

Мы, в основном, уделим внимание следующим конфигурациям:

— Единственный экземпляр Redis.

— Redis HA.

— Redis Sentinel.

— Redis Cluster.

Вы можете выбрать ту или иную конфигурацию в зависимости от особенностей вашего проекта и его масштабов.

Единственный экземпляр Redis

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

Если дать экземпляру Redis достаточно памяти и серверных ресурсов, этот экземпляр может оказаться довольно-таки мощной сущностью. Такой подход, в основном, используется для кеширования, позволяет, потратив минимум сил и времени на настройку системы, получить серьёзный рост производительности проекта. При наличии достаточных серверных ресурсов развернуть подобный сервис Redis можно на той же машине, на которой работает основное приложение.

Для обеспечения успешной работы с Redis важно понимать некоторые концепции этой системы, связанные с управлением данными. Запросы, поступающие к базе данных Redis, обрабатываются путём работы с данными, хранящимися в памяти. Если используемый экземпляр Redis предусматривает применение постоянного хранения данных, в системе будет форк процесса. Он использует RDB (Redis Database, база данных Redis) для организации постоянного хранения снепшотов (снимков) данных. Это — весьма компактное представление данных Redis на определённый момент времени. Вместо RDB могут использоваться файлы, предназначенные только для добавления данных (Append-Only File, AOF).

Эти два механизма позволяют Redis иметь долговременное хранилище данных, поддерживать различные стратегии репликации, помогают реализовывать на базе Redis более сложные топологии. Если сервер Redis не настроен на постоянное хранение данных, то, при перезагрузке или сбое системы, данные теряются. Если же постоянное хранение включено, то при перезагрузке системы осуществляется загрузка в память данных из снепшота RDB или из AOF. После этого экземпляр Redis сможет обрабатывать запросы клиентов.

Учитывая вышесказанное — рассмотрим конфигурации Redis, которые характеризуются, так сказать, большей распределённостью, чем рассмотренная.

Redis HA

Конфигурация высокой доступности. В состав системы входят главная база данных (Main), ведущий узел, и второстепенная база данных (Secondary) — подчинённый узел. Состояние узлов синхронизируется посредством репликации. 

Ещё одна популярная конфигурация Redis представляет собой систему, состоящую из ведущего и подчинённого узлов, состояние которых синхронизируется посредством репликации. По мере того, как данные записываются в ведущем экземпляре Redis, копии соответствующих команд отправляются в выходной буфер для подчинённых узлов, что обеспечивает выполнение репликации данных. В состав подчинённых узлов может входить один или большее количество экземпляров Redis. Эти экземпляры способны помочь в масштабировании операций чтения данных или обеспечить отказоустойчивость системы при потере связи с ведущим узлом.

«Высокая доступность» (HA, High Availability) — это характеристика системы, которая нацелена на обеспечение согласованного уровня показателей её деятельности (обычно — времени безотказной работы системы) на временных интервалах, превышающих средние.

В системах высокой доступности важно отсутствие единой точки отказа. Это позволяет им корректно и быстро восстанавливать нормальную работу после сбоев. Конфигурации высокой доступности предусматривают наличие надёжных линий связи, что исключает потерю данных при их передаче от ведущего узла к подчинённому. Кроме того, в таких системах осуществляется автоматическое обнаружение сбоев и восстановление после них.

Так как теперь мы перешли к распределённым системам, с которыми связано множество заблуждений, нам нужно ознакомиться с несколькими новыми понятиями. То, что раньше было простым и ясным, теперь становится сложнее.

Репликация данных в Redis

Каждый ведущий узел Redis имеет идентификатор (ID) и смещение репликации. Эти два показателя чрезвычайно важны для того, чтобы выяснить момент времени, когда подчинённый узел может продолжать процесс репликации, или чтобы определить, что необходимо выполнить полную синхронизацию данных. Смещение инкрементируется при выполнении любого действия, которое происходит в ведущем узле Redis.

Если описать это более конкретно, то окажется, что когда подчинённый узел Redis отстаёт лишь на несколько шагов смещения от ведущего узла, он получает оставшиеся необработанными команды от ведущего узла, эти команды применяются к данным, так происходит до момента синхронизации узлов. Если два экземпляра не могут договориться об ID репликации, или ведущий узел не имеет сведений о смещении, подчинённый узел запрашивает полную синхронизацию данных. Сюда входит создание ведущим узлом нового снепшота RDB и отправка его подчинённому узлу. В процессе передачи этих данных ведущий узел буферизует промежуточные обновления данных, произошедшие между моментом создания снепшота и текущим моментом. Эти обновления будут отправлены подчинённому узлу после того, как он синхронизируется со снепшотом. После завершения этого процесса репликация может продолжаться в обычном режиме.

Если у разных экземпляров Redis имеются одинаковые ID и смещение, это значит, что они хранят в точности одни и те же данные. Тут может появиться вопрос о том, почему в Redis используется ID репликации. Дело в том, что когда уровень экземпляра Redis повышается до ведущего узла, или если экземпляр сразу запускается как ведущий, ему назначается новый ID репликации. Он используется для выяснения того, какой экземпляр Redis был до этого ведущим. А именно, выясняется то, из какого экземпляра раньше копировал данные узел, уровень которого был только что повышен. Это даёт возможность выполнения частичной синхронизации (с другими подчинёнными узлами), так как новый ведущий узел помнит свой старый ID репликации.

Например, два экземпляра Redis, ведущий и подчинённый, имеют один и тот же ID репликации, а их смещения отличаются на несколько сотен команд. То есть — если на «отстающем» экземпляре воспроизвести соответствующие команды, в распоряжении обоих экземпляров будет идентичный набор данных. Предположим, что ID репликации экземпляров различаются и нам неизвестен предыдущий ID (у экземпляров нет общего предка) узла, уровень которого недавно понижен до подчинённого (он подключён к ведущему узлу). В такой ситуации нужно выполнить ресурсозатратную операцию полной синхронизации данных.

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

Redis Sentinel

Развёртывание системы с использованием Redis Sentinel. В состав такого развёртывания входят Sentinel-узлы, ведущий узел и подчинённые узлы. 

Redis Sentinel — это сервис, обеспечивающий создание распределённых систем. И, как и в случае со всеми распределёнными системами, у Sentinel имеются и сильные, и слабые стороны. В основе Sentinel лежит кластер Sentinel-процессов, работающих совместно. Они координируют состояние системы, реализуя конфигурацию высокой доступности Redis. Sentinel — это сервис, защищающий хранилище Redis от сбоев. Поэтому логично то, чтобы этот сервис не имел бы единой точки отказа.

Сервис Sentinel решает несколько задач. Во-первых — он обеспечивает работоспособность и доступность текущих ведущих и подчинённых узлов. Благодаря этому текущий Sentinel-процесс (вместе с другими подобными процессами) может отреагировать на ситуацию, когда теряется связь с ведущими и/или подчинёнными узлами. Во-вторых — он играет определённую роль в деле обнаружения сервисов. Похожим образом в других системах работают Zookeeper и Consul. То есть — когда новый клиент пытается что-то записать в хранилище Redis, Sentinel сообщит клиенту о том, какой экземпляр Redis в этот момент является ведущим.

Получается, что узлы Sentinel постоянно мониторят доступность экземпляров Redis и отправляют сведения о них клиентам, что позволяет клиентам предпринимать определённые действия в тех случаях, когда хранилище даёт сбой.

Вот какие функции выполняют узлы Sentinel:

— Мониторинг. Обеспечение того, что ведущие и подчинённые узлы работают так, как ожидается.

— Отправка уведомлений администраторам. Система отправляет администраторам уведомления о происшествиях в экземплярах Redis.

— Управление восстановлением системы после отказа. Узлы Sentinel могут запустить процесс восстановления системы после сбоя в том случае, если ведущий экземпляр Redis недоступен и достаточное количество (кворум) узлов согласно с тем, что это так.

— Управление конфигурацией. Узлы Sentinel, кроме того, играют роль системы, позволяющей обнаруживать текущий ведущий экземпляр Redis.

Использование Redis Sentinel для решения вышеописанных задач позволяет обнаруживать сбои Redis. Процедура обнаружения сбоя включает в себя получение согласия нескольких узлов Sentinel с тем, что текущий ведущий экземпляр Redis недоступен. Процесс получения такого согласия называют кворумом (quorum). Это позволяет повысить надёжность системы, защититься от ситуаций, когда один из процессов ведёт себя неправильно и не может подключиться к ведущему узлу Redis.

Кворум — это минимальное число голосов, которое нужно получить распределённой системе для того, чтобы ей было бы позволено выполнять определённые операции, наподобие восстановления после сбоя. Это число поддаётся настройке, но оно должно отражать количество узлов в рассматриваемой распределённой системе. Размеры большинства распределённых систем равняются трём или пяти узлам, в них, соответственно, кворум равен двум или трём голосам. Нечётные количества узлов предпочтительны в случаях, когда системе необходимо разрешать неоднозначности.

У Redis Sentinel есть и недостатки. Поэтому мы рассмотрим несколько рекомендаций и практических советов, касающихся этого сервиса.

Redis Sentinel можно развернуть несколькими способами. Честно говоря, чтобы дать какие-то адекватные рекомендации, мне нужны подробности о той системе, в составе которой планируется использовать Redis Sentinel. В качестве общего правила я посоветовал бы запускать узел Sentinel вместе с каждым из серверов приложения (если это возможно). Это позволит не обращать внимания на различия, связанные с сетевыми подключениями узлов Sentinel и клиентов, которые используют Redis.

Sentinel можно запустить и на тех же машинах, на которых работают экземпляры Redis, или даже в виде независимых узлов, но это, в различных формах, усложняет ситуацию. Рекомендую применять как минимум три узла с кворумом, как минимум, из двух. Вот простая таблица, в которой описано количество серверов в кластере, даны сведения о кворуме и о количестве допустимых отказов.

Подобные показатели будут, от системы к системе, различаться, но общая идея остаётся подобной той, что выражена в таблице.

Подумаем о том, что может пойти не так в системе, в которой используется Sentinel. Если такая система будет работать достаточно долго — можно столкнуться со всеми этими проблемами.

— Что если узлы Sentinel выйдут из состава кворума?

— Что если сеть разделится и старый ведущий экземпляр Redis окажется в меньшей группе узлов Sentinel? Что произойдёт с данными, записанными в этот экземпляр Redis? (Подсказка: эти данные, после полного восстановления системы, будут утеряны.)

— Что произойдёт, если сетевые топологии узлов Sentinel и клиентских узлов (узлов приложения) окажутся несогласованными?

У нас нет гарантий устойчивости системы, особенно учитывая то, что операции по сохранению данных на диск (об этом — ниже) выполняются асинхронно. Тут ещё имеется неприятная проблема, связанная с тем, когда именно клиенты узнают о появлении новых ведущих узлов. Сколько команд записи данных уйдут в никуда, будучи отправленными в ситуации, когда новый ведущий узел неизвестен? Разработчики Redis рекомендуют запрашивать сведения о новом ведущем узле при установлении новых соединений. Это, что зависит от конфигурации системы, может приводить к серьёзным потерям данных.

Есть несколько способов уменьшить масштабы потерь данных в том случае, если принудить ведущий экземпляр Redis к репликации операций записи на как минимум один подчинённый экземпляр. Помните о том, что репликация в Redis выполняется асинхронно, и что у неё есть свои недостатки. Поэтому понадобится независимо отслеживать подтверждения получения данных, а если не удастся получить подтверждение от хотя бы одного подчинённого узла, главный узел должен прекратить принимать запросы на запись данных.

Redis Cluster

Кластер Redis. Клиенты выполняют операции чтения/записи, взаимодействуя с ведущими (M1, M2, M3) узлами Redis. Между ведущими и подчинёнными (S1, S2, S3) выполняется репликация данных. Другие клиенты, обращаясь к подчинённым узлам, выполняют операции чтения данных. Для определения общего состояния кластера используется протокол Gossip. 

Уверен, что многие размышляют о том, как быть в том случае, если не получится хранить все необходимые данные в памяти на одной машине. В наши дни максимальный объём оперативной памяти, доступный на одном сервере, составляет 24 ТиБ, такие конфигурации есть в AWS. Понятно, что это много, но некоторым системам этого не хватит даже для организации кеша.

Redis Cluster позволяет горизонтально масштабировать хранилища Redis.

По мере роста некоей системы её владелец может выбрать один из следующих трёх вариантов действий:

— Меньше работать (никто так не поступает, потому что мы — ненасытные монстры).

— Повышать мощность отдельных компьютеров.

— Распределять нагрузку на большее количество небольших компьютеров.

Серьёзно мы отнесёмся лишь к двум последним пунктам этого списка. Они, соответственно, известны как вертикальное и горизонтальное масштабирование. При вертикальном масштабировании для ускорения работы системы используют более продвинутые компьютеры, надеясь, что возросшая вычислительная мощность позволит успешно справляться с растущей нагрузкой. Но, даже если на первых порах ожидания и оправдаются, в итоге тот, кто пользуется вертикальным масштабированием, столкнётся с ограничениями аппаратного обеспечения.

После того, как вертикальное масштабирование себя исчерпало (а скорее всего, хочется надеяться, задолго до этого), нужно будет обратиться к горизонтальному масштабированию. Это — распределение нагрузки по множеству небольших машин, ответственных за решение небольших подзадач одной большой задачи.

Разберёмся с терминологией. После того, как мы решили использовать Redis Cluster, это будет значить, что мы решили распределить хранимые нами данные по множеству машин. Это называют шардингом. В результате каждый экземпляр Redis, входящий в состав кластера, считается хранилищем шарда, или фрагмента, всех данных.

Такой подход вызывает к жизни новую проблему. Если отправить в кластер данные — как узнать о том, какой именно экземпляр Redis (шард) хранит эти данные? Есть несколько способов это сделать. Redis Cluster использует алгоритмический шардинг.

Для того чтобы найти шард для заданного ключа, мы хешируем ключ, а результат делим по модулю на количество шардов. Затем, используя детерминистическую хеш-функцию (благодаря этому конкретный ключ всегда будет соответствовать одному и тому же шарду), мы, когда нужно будет прочитать соответствующие данные, сможем узнать о том, где именно они хранятся.

Что произойдёт, если через некоторое время в систему будет добавлен новый шард? А произойдёт то, что называют решардингом.

Исходя из предположения о том, что ключ foo был назначен шарду 0, он, после решардинга, может быть назначен шарду 5. Но перемещение данных ради того, чтобы их размещение соответствовало бы новой конфигурации шардов, окажется медленной и нереалистичной задачей в том случае, если мы хотим, чтобы операции по увеличению хранилища выполнялись бы быстро. Такое перемещение данных, кроме того, окажет негативное влияние на доступность Redis Cluster.

В рамках Redis Cluster создан механизм, направленный на решение этой проблемы. Это — так называемые «хеш-слоты», в которые и отправляют данные. Имеется около 16 тысяч таких слотов. Это даёт нам адекватный способ распределения данных по кластеру, а при добавлении новых шардов нужно просто переместить в системе хеш-слоты. Поступая так, нам нужно лишь перемещать хеш-слоты из шарда в шард и упростить процесс добавления новых ведущих экземпляров Redis в кластер.

Сделать это можно без простоев системы и с минимальным воздействием на её производительность. Рассмотрим пример.

Узел M1 содержит хеш-слоты с 0 по 8191.

Узел M2 содержит хеш-слоты с 8192 по 16383.

Назначая хеш-слот ключу foo, мы вычисляем детерминистический хеш от ключа (foo) и делим по модулю на количество хеш-слотов (16383). В результате данные, соответствующие этому ключу, попадают на узел M2. Теперь, предположим, мы добавляем в систему новый узел — M3. Новое соответствие узлов и хеш-слотов будет таким:

Узел M1 содержит хеш-слоты с 0 по 5460.

Узел M2 содержит хеш-слоты с 5461 по 10922.

Узел M3 содержит хеш-слоты с 10923 по 16383.

Все ключи, которые попали в хеш-слоты узла M1, теперь принадлежащие узлу M2, понадобилось бы перенести. Но соответствие отдельных ключей и хеш-слотов сохраняется, так как ключи уже распределены по хеш-слотам. Таким образом данный механизм решает проблему решардинга при использовании алгоритмического шардинга.

Протокол Gossip

Redis Cluster использует протокол Gossip для определения общего состояния кластера. На вышеприведённой иллюстрации имеется 3 ведущих (M) узла и 3 подчинённых (S) узла. Все эти узлы постоянно обмениваются друг с другом информацией для того чтобы знать о том, какие шарды доступны и готовы обрабатывать запросы. Если достаточное количество шардов согласно с тем, что узел M1 не отвечает на запросы, они могут решить повысить S1 — подчинённый узел узла M1, до уровня ведущего узла, чтобы поддержать кластер в работоспособном состоянии. Количество узлов, необходимое для запуска подобной процедуры, поддаётся настройке. Очень важно правильно выполнить подобную настройку. Если сделать что-то не так, можно оказаться в ситуации, когда кластер окажется разделённым на части в том случае, если он не сможет разрешить неоднозначную ситуацию, когда «за» и «против» голосует одинаковое количество систем. Этот феномен называют «split brain» (разделение вычислительных мощностей). Поэтому, в качестве общего правила, важно, чтобы в кластере было бы нечётное количество ведущих узлов, у каждого из которых имеется два подчинённых узла. Это послужит хорошей основой для построения надёжной системы.

Модели постоянного хранения данных в Redis

Если в Redis планируется размещать какие-либо данные в расчёте на их надёжное постоянное хранение, важно понимать то, как именно это организовано в Redis. Существует множество ситуаций, когда потеря данных, хранящихся в Redis — это не такая уж и катастрофа. Например — использование Redis в роли кеша, или в ситуациях, когда в Redis хранятся данные некоей аналитической системы реального времени.

В других случаях разработчикам нужны некие гарантии относительно постоянного хранения данных и возможности их восстановления.

Redis — быстрое хранилище, а все гарантии относительно целостности данных второстепенны в сравнении со скоростью. Это, вероятно, спорная тема, но, на самом деле, так оно и есть.

Модели постоянного хранения данных в Redis. Данные из памяти копируются либо в RDB, в виде снепшотов, либо в AOF. Если экземпляр Redis отказал, но данные этого экземпляра были помещены в постоянное хранилище, эти данные загружаются в новый экземпляр Redis. 

Постоянное хранение данных не используется

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

RDB-файлы

Постоянное хранение данных в файлах RDB подразумевает создание снепшотов, содержащих данные, актуальные на определённые моменты времени. Снепшоты создаются с заданными временными интервалами.

Главный минус этого механизма заключается в том, что данные, поступившие в хранилище между моментами создания снепшотов, будут, при сбое Redis, утеряны. Кроме того, этот механизм хранения данных полагается на создание форка главного процесса. При работе с большими наборами данных это может привести к кратковременным задержкам в обработке запросов. Но, при этом, RDB-файлы загружаются в память гораздо быстрее, чем AOF.

AOF

Механизм постоянного хранения данных, основанный на AOF, осуществляет журналирование каждой операции записи, запрос на выполнение которой получает сервер. Эти операции будут воспроизведены при запуске сервера, что приведёт к воссозданию исходного набора данных.

Такой подход к постоянному хранению данных гораздо надёжнее RDB. Ведь речь идёт не о снимках состояния хранилища, а о файлах, рассчитанных только на присоединение к ним данных. Когда происходят операции, их буферизуют в журнале, но они не оказываются сразу после этого размещёнными в постоянном хранилище. В журнале содержатся реальные команды, которые, если нужно восстановить данные, запускают в том порядке, в котором они выполнялись.

Затем, когда это возможно, журнал сбрасывают на диск с помощью fsync (то, когда именно запускается этот процесс, поддаётся настройке). После этого данные оказываются в постоянном хранилище. Минус этого подхода в том, что такой формат хранения данных не является компактным, он требует больше места на диске, чем RDB-файлы.

Вызов fsync() переносит («сбрасывает») все модифицированные данные из памяти (то есть — модифицированные страницы файлового буфера), имеющие отношение к файлу, представленному файловым дескриптором fd, на дисковое устройство (или на другое устройство для постоянного хранения информации). В результате вся изменённая информация может быть восстановлена даже после серьёзного сбоя или перезагрузки системы.

По разным причинам изменения, которые вносят в открытый файл, сначала попадают в кеш, а вызов fsync() гарантирует то, что они будут физически сохранены на диск, то есть — позже их можно будет с диска прочитать.

А для чего собственно нужен Redis, можно по подробней, желательно из практики