Глава 12. Экосистема Redis

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

Клиент Redisson является неким Java клиентом Redis с расширенной функциональностью. Он снижает нагрузку разработчиков при реализации распределённых объектов и служб применяя Redis в качестве серверной основы хранения.

Разработанный Twitter Twemproxy является неким посредником (прокси), который поддерживает как протокол Redis, так и протокол memcached. Он часто применяется в качестве некоторого решения фрагментации данных Redis, которое также способно снижать общее число подключений к самим Серверам Redis базовой структуры.

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

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

Несмотря на то, что стоимость физической памяти снизилась в последнее время драматическим образом, имеется возможность сбережения средств с помощью применения твердотельных устройств хранения в качестве базовой основы хранения данных Redis. Проект Pika от Qihoo 360 является некоторой совместимой с интерфейсом Redis службой хранения, которая реализует эту идею.

Redisson является неким расширенным клиентом Java Redis, который предоставляет более простой и более удобный способ работы с Redis. Redisson предлагает некую последовательность распределённых объектов и служб, которые упрощают проектирование и реализацию больших распределённых систем в Redis.

Приводимая ниже схемы отображает некую выборку функций Redis:

Reddisson основывается на инфраструктуре Netty в Java NIO. Он может применяться не только для расширения клиента Redis на уровне драйвера базы данных, но также предоставляет и множество дополнительных свойств. Естественные типы данных Redis, такие как hash, list, set, string, Geo и HyperLogLog вкладываются в простые в использовании структуры данных или объекты Java (Map, List, Set, Object Bucket, Geospatial Bucket и HyperLogLog).

Кроме того, Redisson содержит распределённые типы данных, такие как Multimap, LocalCachedMap и SortedSet. Соответствующие объекты Distributed lock, MultiLock, ReadWriteLock, FairLock, RedLock, Semaphore и CountDownLatch также реализованы в библиотеке Redisson. Если кратко, Redisson является полезной библиотекой при построении распределённых систем с Redis.

Обладая инструментарием распределённой среды внутри своей библиотеки Redidisson, Redidisson также предоставляет для различных вариантов применения такие распределённые службы как Remote Service, Executor Service и Scheduler Service.

Redisson также может рассматриваться как некая ячеистая структура данных в оперативной памяти. Узел Redisson, который является неким узлом обработки независимой задачи может запускаться как некая системная служба и автоматически вливаться в некий Кластер Redisson.

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

Для получения дополнительных сведений о Redisson вы можете пользоваться справочными материалами на на его странице GitHub.

Таблица соответствия команд Redis для Redisson доступна по ссылке https://github.com/redisson/redisson/wiki/11.-Redis-commands-mapping.

Twemproxy, также известный в качестве nutcracker является быстрым посредником Redis с малым весом, разработанным Twitter. Основная цель данного проекта состоит в предоставлении некоторого посредника и решения фрагментации данных для Redis, а также снижения общего числа подключений клиентов к самим Серверам основы Redis.

Выступая в качестве посредника (прокси), Twemproxy поддерживает два протокола, и Redis, и Memcached. Вы можете позади Twemproxy установить множество серверов Redis. Клиенты общаются только с самим посредником и им нет нужды знать подробности экземпляров Redis, составляющих основу.

Приводимая далее схема отображает базовую архитектуру того, как Twemproxy работает со средой из множества экземпляров Redis:

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

Twemproxy также можно настроить на отключение узлов основы в случае отказов и их восстановления через некоторое время.

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

Twemproxy на практике имеет ограничения. Он не поддерживает все команды Redis. К примеру, команды PUB/SUB и транзакций не сопровождаются. Кроме того, добавление и удаление узлов Redis, составляющих основу, для Twemproxy не является удобным. Во- первых, имеющиеся настройки не вступят в действие без перезагрузки Twemproxy. Во- вторых, хотя согласованное кэщирование и поддерживается Twemproxy, данные не осуществляют автоматическую повторную балансировку после добавления или удаления узлов Redis.

Для получения дополнительной информации о Twemproxy вы можете воспользоваться справочными материалами на его странице GitHub.

Относительно справочной информации по поддерживаемым в Twemproxy командам Redis рекомендуем следующую страницу.

В этой главе мы уже представили Twemproxy, некоторое решение фрагментации на основе посредника, разработанное Twitter. Для решения имеющихся ограничений горизонтального масштабирования и отсутствия соответствующей инструментальной панели администрирования, CodisLabs предложила иной посредник (прокси) фрагментации Redis с названием Codis. Имеющиеся в Codis производительность, Высокая доступность и удобство применения намного превосходят Twemproxy. В то же время он полностью совместим с Twemproxy. Кроме того, помимо его посредника предоставляется удобный инструментарий с названием redis-port для выполнения миграции из имеющегося Redis/Twemproxy в Codis.

На приводимой ниже схеме представлена архитектура Codis.

Имеющийся codis-server представляет особый экземпляр redis на базе пакета redis-3.2.8. Для его связанных со слотами операций и миграции данных добавлены дополнительные структуры данных и инструкции. В предыдущей схеме у нас имеются три сервера codis, один хозяин и два подчинённых.

Понятие codis-group представляет некую группу серверов codis, работающих как фрагмент набора данных.

В некотором Кластере Codis имеющийся набор данных подразделяется на 1024 слота при помощи алгоритма CRC32. Codis вводит понятие codis-group. Каждая группа содержит какого- то хозяина и по крайней мере одного подчинённого. Для имеющегося codis-server отработкой отказов управляет Sentinel Redis.

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

Входящий в состав codis-dashboard является инструментом управления, при помощи которого можно добавлять или удалять codis-codisserver и codis-group.

jodis-client является интеллектуальным клиентом, который наблюдается Zookeeper для получения доступных в реальном масштабе времени посредников и отправления команд неким карусельным (round-robin) образом.

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

Таблица 12-1.

Функция	Продукт
	Codis	TwemProxy	Кластер Redis
повторная фрагментация без перезапуска кластера	Да	Нет	Да
Конвейеризация	Да	Да	Нет
Хэширование тегов для операций со множеством ключей	Да	Да	Да
Операции со множеством ключей в процессе повторной фрагментации	Да	Нет	Нет
Поддержка клиентов Redis	Любые клиенты	Любые клиенты	Клиенты должны поддерживать протокол кластера

Для получения дополнительных подробностей относительно Codis вы можете обратиться к справочной информации на его странице GitHub.

Подробности об инструментарии миграции Redis вы можете найти в их справочной информации на его странице GitHub.

Развёртывание большого числа экземпляров Redid и управление ими является обременительным и требующим времени. В данном разделе мы представим некий проект с открытым исходным кодом, CaheCloud, разрабатываемый Sohu (NASDAQ: SOHU) TV и предназначенный для решения такого рода проблем.

CacheCloud является платформой централизованного управления Redis для предоставления службы Redis, мониторинга производительности и отыскания неполадок. Она поддерживает различные архитектуры Redis, включая обособленный Redis, Redis Sentinel и Кластер Redis.

Собственно архитектура CacheCloud отображена на приводимой ниже схеме:

В CacheCloud предоставляются следующие фантастические возможности:

Для получения дополнительных подробностей о CacheCloud вы можете обращаться к его справочным материалам на странице GitHub.

Сама домашняя страница CacheCloud доступна по ссылке https://cachecloud.github.io/.

В своём приведённом ранее введении мы уяснили, что если размер набора данных некоторого экземпляра Redis слишком велик, скорее всего, это будет серьёзной проблемой для его репликации и удержания. В особенности, всегда требуется значительный промежуток времени для восстановления определённого набора данных из какого- то файла удержания если такой набор данных какого- то экземпляра Reis является большим. Кроме того, чем большим является рассматриваемый набор данных Reids, тем больше займёт его ветвление при включении удержания. А хуже всего то, что если хозяин Redis имеет некий большой набор данных и при этом владеет множеством подчинённых, его полная синхронизация выливается в некое бедствие. С точки зрения стоимости хранения, Оперативная память намного более затратна чем Твердотельные устройства (SSD, Solid State Drive).

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

Полная архитектура Pika показана на следующей схеме:

В Pika имеются четыре следующих основных компонентов:

Для получения дополнительных подробностей о CacheCloud вы можете обращаться к его справочным материалам на странице GitHub.