Помимо многопоточности в Redis 6.0, не забывайте об этой замечательной функции!

Новые функции Redis 6.0 также определяются в ходе пошаговых обсуждений и оптимизаций.

Многие функции были представлены в предыдущих версиях, таких как RC.

Но есть и новые изменения в официальной версии GA:

• SSL
• ACL: лучше, поддержка команд
• RESP3
• Кэширование на стороне клиента: редизайн
• Threaded I/O
• Diskless replication on replicas
• Cluster support in Redis-benchmark and improved redis-cli cluster support
• Disque в бета-версии как модуль Redis: начал вторгаться в область очереди сообщений
• Redis Cluster Proxy
• Поддержка RDB может быть удалена сразу после того, как она больше не используется, для сценариев, когда диск не будет удален.
• PSYNC2: оптимизированный протокол репликации
• Поддержка настройки тайм-аута более дружелюбна
• Более быстрая загрузка RDB, улучшение на 20–30 %
• STRALGO, новая строковая команда, в настоящее время только одна реализует LCS (самая длинная общая подпоследовательность)

@antirez упомянул, что это только самое крупное обновление версии в истории Redis, поэтому разумно рекомендуется протестировать и оценить больше приложений и пообещать, что версия 6.0.1 будет выпущена в срочном порядке, как только будет обнаружена серьезная ошибка. Как и ожидалось, на день позже вышла версия 6.0.1, в которой исправлена ​​ошибка аллокатора, которая была введена для оптимизации и теперь временно устранена.

I just released Redis 6.0.1. Unfortunately there was a bug in Redis 6.0.0 introduced just a few days before the release, that only happens when using the non-default allocator (libc malloc in this case triggers it). Optimization reverted, 6.0.1 released. Sorry for the issue.

Эта статья в основном посвященаClient side caching(Кэширование на стороне клиента) Эта функция.

smallnest/RESP3 — это библиотека синтаксического анализа для протокола Redis RESP3. Вы можете использовать ее для связи с базовым Redis или обернуть ее для реализации новой версии клиентской библиотеки Redis или сервера Redis.

Год назад, после того как @antirez посетил конференцию Redis в Нью-Йорке, он проснулся в отеле в 5:30, глядя на красивые пейзажи улиц Манхэттена, думая о будущем Redis в толпе. В том числе кэширование на стороне клиента.

Фактически, на функцию кэширования на стороне клиента повлиял Бен Малек из Redis Conf 2018, который внезапно открыл идею @antirez. Мы знаем, что многие компании используют Redis в качестве системы кэширования, что значительно повышает производительность доступа к данным, однако для дальнейшей работы с горячими данными многие компании по-прежнему кэшируют некоторые горячие данные на стороне клиента Redis, чтобы справиться с поеданием дыни. Мероприятия. Например, на Weibo мы часто сталкиваемся с крушением знаменитостей, разделением и воссоединением звезд, чрезвычайными ситуациями и т. д. Каждый год происходит несколько чрезвычайных ситуаций.В дополнение к использованию Redis в качестве кеша, чтобы избежать прямого доступа к базе данных, Weibo также добавит больше кеша. слои впереди, такие какL1 cacheи т. д., используя такие продукты, как memcached, в качестве кеша горячих данных. Тогда возникает вопрос, как синхронизировать данные этих кешей и редисов по времени? Бен предложил очень интересные идеи.

Стоя на улицах Манхэттена, @antirez впал в созерцание, а позже вернулся в отель, где занялся внедрением кэша первой версии клиента. Конечно, окончательная реализация Redis 6.0 сильно отличается от реализации этой начальной версии, но ясно, что мы все еще можем видеть компромисс этой функции @antirez с развитием клиента. В этой статье мы не будем вдаваться в подробности этой истории, поскольку мы больше сосредоточены на том, как в конечном итоге выглядит эта функция.

Redis реализует серверный клиентский кеш, называемыйtracking. Команда для кэширования на стороне клиента:

CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]

когдаtrackingЕсли этот параметр включен, Redis «запомнит» ключ, запрошенный каждым клиентом, и отправит клиенту сообщение о недействительности при изменении значения ключа. Информация о недействительности может быть отправлена ​​запрашивающему клиенту по протоколу RESP3 или перенаправлена ​​на другое соединение (поддерживает RESP2+ Pub/Sub). При включенном режиме вещания (трансляции) участвуйте вtrackingКлиент будет получать уведомления о ключе, на который он подписан через префикс, даже если он не запрашивал соответствующий ключ. Также предоставляетOPTIN,OPTOUTи т.п. режим.

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

• REDIRECT: переслать сообщение об аннулировании другому клиенту. Когда мы не используем RESP3, а используем старый RESP2 для связи с Redis, сам клиент не поддерживает обработку сообщений об аннулировании, поэтому мы можем включить клиент Pub/Sub для обработки сообщений об аннулировании. Конечно, если клиент поддерживает RESP3, он также может переслать сообщение об аннулировании другому клиенту. Мы поместили этот случай в финальное демо.
• BCAST: начать использовать режим трансляцииtracking. В этом режиме клиенту необходимо установить префикс ключа дорожки, и сообщение об аннулировании этих ключей будет транслироваться всем участвующим клиентам, независимо от того, запрашивают/кешируют ли эти клиенты эти ключи. Если не в широковещательном режиме, Redis будет отслеживать только ключи, запрошенные командами только для чтения, и только один раз сообщит об аннулировании.
• PREFIX: Применяется только широковещательный режим и регистрируется префикс ключа. Сообщение об аннулировании будет отправлено, когда будут изменены все ключи, начинающиеся с этого префикса. Можно зарегистрировать несколько префиксов. Если префикс не установлен, режим трансляции будет отслеживать каждую клавишу.
• OPTIN: Нормально, когда режим вещания не активированНе будуотслеживать командные клавиши только для чтения, если только они неCLIENT CACHING yesназывается после.
• OPTOUT: Нормально, когда режим вещания не активированМогуотслеживать командные клавиши только для чтения, если только они неCLIENT CACHING offназывается после.
• NOLOOP: Не отправлять ключ, модифицированный самим клиентом.

Давайте рассмотрим каждый вариант один за другим.

Настройка тестовой среды

Сначала давайте представим параметры, связанные с протоколом RESP3,REDIRECT <id>Представлен в конце.

Прежде чем пытаться, вам сначала нужно установить версию Redis 6.x, в настоящее время 6.0.1. На официальном сайте есть загрузка исходников, компиляция и установка тоже очень простые:

make distclean
make
make test
sudo make install

Я думаю, что скомпилированный бинарный пакет скоро будет доступен для скачивания.

Запустите сервер, он запустит службу на порту 6379:

redis-server

использоватьredis-cliДоступ, доступ по умолчанию к экземпляру 6379 этой машины:

redis-cli

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

Иногда, чтобы лучше наблюдать за возвращаемыми результатами redis, мы используемtelnetвместоredis-cliПодключайтесь к Redis в качестве клиента, потому что Redis-Cli обрабатывает результаты, особенно сообщения об ошибках, которые вы можете не заметить.

Режим вещания BCAST (отслеживание клиентов включено)

Запускаем Redis-сервер:

Запустите Redis-Cli:

Конечно, мы используем telnet для тестирования, что удобно для наблюдения за возвращаемыми результатами redis.Только сейчас redis-cli использовался для обновления значения ключа, чтобы помочь тесту. Отправлено после подключенияhello 3Включить протокол RESP3:

➜  ~ telnet localhost 6379
Trying ::1...
Connected to localhost.
Escape character is '^]'.
hello 3
%7
$6
server
$5
redis
$7
version
$5
6.0.1
......

Потом попробуй включитьtrackingи читатьaЗначение:

client tracking on
+OK
set a 1
+OK
get a
$1
1

В настоящее время, если вы используете redis-cli в качестве другого клиента для обновленияa, клиент telnet должен иметь возможность получать уведомления:

127.0.0.1:6379> set a 2
OK

Наблюдая за телнетом, он получил сообщение об ошибке:

>2
$10
invalidate
*1
$1
a

Обратите внимание, что он принимает тип PUSH в RESP3 (>).

Если это использует вас, используйте redis-cli для обновленияaзначение, telnet больше не будет получать сообщения об аннулировании. если клиент telnet неget aсноваtrackingзначение а.

Можно отменить в любое времяtracking:

client tracking off

ключ отслеживания для определенного префикса (отслеживание клиента включено)

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

Используйте клиент telnet, чтобы установить префикс и включить отслеживание:

hello 3
.......
client tracking on prefix a bcast
+OK
client tracking on prefix user bcast
+OK

Мы отслеживаем два префикса, начиная сaВсе ключи, начинающиеся с и начинающиеся сuserВсе ключи в начале, всеaВсе ключи, начинающиеся с и начинающиеся сuserВсе ключи в начале (включаяaа такжеuser) должен получать сообщение при каждом изменении ключа ).

Затем мы используем redis-cli для обновления трех ключей:abc,user:32432723213а такжеfeed:6532343243432:

127.0.0.1:6379> set abc 100
OK
127.0.0.1:6379> set user:32432723213 good
OK
127.0.0.1:6379> set feed:6532343243432 abc
OK

телнет-клиент получилabcа такжеuser:32432723213сообщение об аннулировании без полученияfeed:6532343243432Сообщение об аннулировании:

>2
$10
invalidate
*1
$3
abc
>2
$10
invalidate
*1
$16
user:32432723213

ты можешь пройтиclient tracking offОстановить кэширование на стороне клиента. В настоящее время кажется, что невозможно остановить только один префиксtracking. даже если вы используетеclient tracking off prefix userтакже отменяется для всех ключейtracking.

......
} else if (!strcasecmp(c->argv[2]->ptr,"off")) {
    disableTracking(c);
} else {
......

выбрать в

При использованииOPTIN, который можно выборочно включитьtracking. только ты посылаешьclient caching yesКлюч следующей команды только для чтения после этого будетtracking, иначеКлючи в других командах только для чтения не отслеживаются.

Сначала мы начинаемoptin, прочитайте палец а. В это время используйте клиент redis-cli, чтобы изменить значение а на 1000, но мы его не получили.aсообщение об ошибке.

client tracking on optin
+OK
get a
$1
2

Далее мы отправляемclient caching yes, а затем получите значение а. Если вы измените значение а в это время, вы можете получить сообщение об ошибке для а:

client caching yes
+OK
get a
$4
1000
>2
$10
invalidate
*1
$1
a

должны сопровождатьсяclient caching yesДа, например, отправка следующей команды будет толькоtrackingб вместо а:

client caching yes
+OK
get b
_
get a
$4
2000

отказаться

При использованииOPTOUT, вы также можете отказатьсяtracking. только ты посылаешьclient caching offКлавиша следующей команды только для чтения после этого остановитсяtracking, иначеКлючи в других командах только для чтения будут отслеживаться.

можно увидеть иOPTINНапротив, вы можете выбрать в соответствии с вашей сценой.

Например, в следующем примере включитеOPTOUTПосле этого изменения любого ключа получат сообщение о недействительности:

client tracking on optout
+OK
get a
$4
3000
>2
$10
invalidate
*1
$1
a

В настоящее время, если мы хотим исключитьbЭтот ключ можно задать только для него:

client caching no
+OK
get b
$1
3

Последующие изменения в b не получат сообщение о недействительности b.

Уведомление: OPTINа такжеOPTOUTОн нацелен на не-BCAST-сценарии, то есть только после того, как вы отправите команду только для чтения для ключа, соответствующий ключ будет отслеживаться. Широковещательный режим заключается в том, что независимо от того, отправили ли вы команду только для чтения для ключа, пока redis изменяет ключ, он отправит сообщение о недействительности соответствующего ключа (или ключа, соответствующего префиксу).

NOLOOP

Если установлено нормально, сообщение об аннулировании отправляется всем участвующим клиентам, но если установленоNOLOOP, он не будет отправлен клиенту, который обновляет ключ.

client tracking on bcast noloop
+OK
set a 1
+OK
client tracking off
+OK
client tracking on bcast
+OK
set a 1
+OK
>2
$10
invalidate
*1
$1
a

Обратите внимание, что для отмены отслеживания просто позвонитеclient tracking offВот и все.

REDIRECT

Наконец, давайте посмотрим на обработку переадресованных сообщений. Это должно быть совместимо с методом обработки протокола RESP2, который пересылает сообщение о недействительности другому клиенту.

Сначала мы смотрим на идентификатор клиента redis-cli:

127.0.0.1:6379> client list
id=4 addr=127.0.0.1:61017 fd=8 name= age=33103 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client user=default

Используйте telnet для подключения к Redis и просмотра идентификатора клиента:

client id
:12

Клиент telnet открывает сообщение об аннулировании подписки:

SUBSCRIBE __redis__:invalidate
*3
$9
subscribe
$20
__redis__:invalidate
:1

Затем мы можем переслать сообщение об ошибке redis-cli клиенту telnet:

client tracking on bcast redirect 12
127.0.0.1:6379> set a 1000
OK

Вы можете видеть, что клиент telnet получил сообщение об аннулировании:

*3
$7
message
$20
__redis__:invalidate
*1
$1
a

Если целевой клиент, которого вы хотите перенаправить, включил протокол RESP3, вам не нужен RESP3 Pub/Sub, поскольку RESP3 изначально поддерживает Push-сообщения.

Код реализации функции отслеживания Redis находится в файле: tracking.c.

Обратите внимание на публичный аккаунт WeChat: Songhua сказал, становитесь более захватывающим!

Адрес блога:www.liangsonghua.com

Введение в общедоступную учетную запись: делитесь техническими знаниями о работе на JD.com, а также технологиями JAVA и лучшими отраслевыми практиками, большинство из которых являются прагматичными, понятными и воспроизводимыми.