Есть ли клиент golang redis, который автоматически определяет новые шарды для pubsub?

[ОБНОВЛЕНИЕ]: текущий Redis отправляет каждое опубликованное сообщение на каждый узел во всем кластере:

/* -----------------------------------------------------------------------------
 * CLUSTER Pub/Sub support
 *
 * For now we do very little, just propagating PUBLISH messages across the whole
 * cluster. In the future we'll try to get smarter and avoiding propagating those
 * messages to hosts without receives for a given channel.
 * -------------------------------------------------------------------------- */
void clusterPropagatePublish(robj *channel, robj *message) {
    clusterSendPublish(NULL, channel, message);
}

Это оригинальный текст вопроса, который неверен:

Насколько я понимаю, мне необходимо:

  1. По заданному каналу найдите узел, которому принадлежит хэш-слот.

  2. Подпишитесь на этот узел, а также на слоты cluster: для обнаружения миграций.

  3. После миграции слота подпишитесь на канал на новом узле и оставьте старое соединение открытым.

  4. Пересылайте сообщения в приложение из старого соединения, пока оно не закроется, и запомните эти сообщения.

  5. Когда миграция завершена и старое соединение закрыто, пересылайте сообщения из нового соединения, удаляя запомненные сообщения из первого соединения.

Делает ли это какая-нибудь клиентская библиотека golang redis? Я просмотрел многих, и мне кажется, что мне нужно написать эту логику самостоятельно, постоянно опрашивая CLUSTER SLOTS или слушая эту информацию в pubsub, чтобы знать, когда сегменты увеличиваются или уменьшаются, и перемещать существующие сценарии pubsub с одного сервера на другой.

Т.е. существует множество библиотек golang, которые обрабатывают обычный ключ GET с кластером, даже если количество шардов изменяется. Но pubsub и cluster - это совсем другое, верно?


person Andrew Arrow    schedule 28.08.2018    source источник


Ответы (1)


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

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

Источник: Спецификация кластера Redis

person Itamar Haber    schedule 28.08.2018
comment
Итак, если я слушаю канал ABC123 на узле 1 в системе с 3 узлами, и мы увеличиваем количество узлов до 17, канал ABC123 все равно будет на том же компьютере, и исходное TCP-соединение не разорвется из-за события новых узлов. добавляется? - person Andrew Arrow; 28.08.2018
comment
Итак, если у меня есть 1000 подключенных TCP-подписчиков к 1000 различным каналам, и мы резко увеличиваем количество узлов и слотов, снова и снова, есть ли теперь куча накладных расходов на сопоставление этих старых подписчиков по сравнению с тем, если бы мы их закрыли? все выключено, перезагрузитесь с последним количеством слотов и подключите их заново? - person Andrew Arrow; 29.08.2018
comment
Теоретически это должно работать, но на практике я бы протестировал его, прежде чем поверить в то, что кто-то пишет на SO;) - person Itamar Haber; 30.08.2018
comment
Хорошо, я вижу, вы правы, сэр! Большое тебе спасибо. Я наконец нашел точную строку кода c в cluster.c с комментарием: «CLUSTER Pub / Sub support * * На данный момент мы делаем очень мало, просто распространяем сообщения PUBLISH по всему * кластеру. В будущем мы постараемся стать умнее и избегать распространения этих * сообщений на хосты без получения для данного канала ». - person Andrew Arrow; 30.08.2018
comment
Отлично - ничто не сравнится с глубоким погружением в (открытый) исходный код :) Пожалуйста, дайте нам знать (желательно через репозиторий проекта на GitHub), если у вас возникнут какие-либо трудности с этим (чтобы мы могли точно изучить и расставить приоритеты в будущей версии). - person Itamar Haber; 31.08.2018