- PVSM.RU - https://www.pvsm.ru -
В мире опен сорс есть огромное количество технологий, подходов, паттернов, тулзов и аппов, которые юзает очень много компаний. Как превратить используемое ПО или технологию в конкурентное преимущество? Предлагаю рассмотреть на примере Redis Cluster — как мы прокладывали наш путь.
Стоит начать с того, что Redis — это, по сути, очень удобная штука. В двух словах, Redis — это персистентное key-value хранилище в памяти, со своим блэкджеком и куртизантками. Чаще всего его сравнивают с устаревшим Memcached, который не умеет делать почти ничего из того, что умеет делать Redis.
Преимущества Redis:
Получается, что Redis — это такая «серебряная пуля», абсолютно для всех кейсов, подходов и практик? Ну, такое. Скорее нет, чем да.
Например, проблемы, которые очень очень мешают жить:
Вывод очевиден — Redis ускоряет продукт, ускоряет разработку, и его однозначно, нужно использовать, но… есть проблемы.
Там же есть Redis Cluster! Скажете Вы, но я бы попросил не спешить. На самом деле, у Redis есть 2 типа кластеризации:
Redis Sentinel — это очень примитивная штука, которая выстраивает древовидную структуру из Ваших стенделон редисок, и называет это кластером. Никакого шардинга, балансировки, ничего. И тем более, это работает для старых версий Redis, если не ошибаюсь, ниже 3.0.
Redis Cluster — это штука повеселее, тут уже есть шардинг, репликация, отказоустойчивость, мастера-слейвы, разные там штуки прикольные и все такое. Это уже однозначно похоже на нормальный кластер, но все равно юзать это таким, как оно есть — не получится.
Для того, чтобы понять почему это не работает, нужно понять, как это работает внутри.
Во первых, сам процесс создания Redis Cluster из стенделон нод — это дикость и унижение, в том виде, в котором это есть сейчас. В нашем 2017 году все привыкли к дискаверингу, провижинингу и репорту типа «я все сделал, тут уже кластер, все ок!» — но реалии таковы, что в сорсах Redis есть скрипт, написанный на рубях, который занимается тем, что принимает как аргументы инстансы редиски, и потом соединяет их в кластер. Доверяете ли вы подобным штукам? Думаю да, доверяли, лет 100500 назад.
Окей, у нас есть кластер. Теперь немного теории: внутри кластера есть такие штуки, как hash slots. По сути, слот — это число, которое подразумевает набор данных, за которые ответственна конкретная нода кластера. Всего существует 16384 слота, которые равномерно делятся между всеми мастерами.
Кстати, о мастерах. По умолчанию Redis Cluster может состоять не менее чем из трех нод, и все это будут мастера. Соответсвенно, они поделят слоты между собой.
Второй нюанс использования кластера — это невероятная хрупкость. Например, у нас из кластера с 3 нодами отвалилась одна нода. Логичным решением было бы продолжить работать — у нас же есть 66,6% данных, но все совсем не радужно. В дефолтной конфигурации будет ответ 'CLUSTER IS DOWN' по запросу любого, даже живого ключа.
Если рассматривать кластер побольше, например из 6 нод (3 мастера и 3 слейва) — ситуация повторяется. Пока происходит автоматический промоутинг слейва в мастера после падения, ответ аналогичен — 'CLUSTER IS DOWN'. А это — секунды, хотя эта задержка зависит от количества данных в кластере.
Третья проблема — это клиенты. Точнее, коннекторы в апликейшнах. Если взять предыдущий кейс, когда у нас идет промоутинг кластера — все клиенты отвалятся с socket error, или connection timeout, или с чем-то похожим, потому что держат коннект ко всем мастерам в кластере. Это тоже нужно доделывать.
Четвертый, и один из самых неприятных, нюанс — это изменение набора команд. Стандартные команды, которые работают по вайлдкардам — не работают, и это не удивительно. Это нужно переделывать по всему проекту, учить апликейшн работать как со стенделоном так и с кластером. По факту — это самая длинная и затратная часть имплементации Redis Cluster.
Первый нюанс с провижинингом мы исправить не в состоянии, разве что сделать LWRP для Chef, и провижинить это как-то более нормально. По сути, примерно так мы и сделали.
А вот второй и третий — это уже наша компетенция!
Исправить 'CLUSTER IS DOWN' при отсутствии части слотов очень легко и просто — достаточно добавить параметр конфигурации:
cluster-require-full-coverage no
Проблему с клиентами, которые отваливаются можно решить, потратив немного времени. В нашем проекте используется 2 языка — PHP и Java, поэтому нам нужно было делать два раза одну и ту же работу. Общий алгоритм сводится к таким степам:
Изменение слотмапы будет означать, что кластер перешел в рабочее состояние, и наши данные уже похвалит какой-то слейв, и он готов с ними работать.
Ни для кого не будет секретом, если я скажу, что в кластере с 6+ нод, смысла флашить данные на диск нет никакого. Соответственно, если отключить персистентность — все будет работать очень и очень быстро.
Что же получилось в результате?
Вот такой интересный путь у нас получился.
А как Вы используете общедоступные инструменты?
Автор: mukolaich
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/238854
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/320902/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox
Нажмите здесь для печати.