Как избежать перекоса доступа и искажения данных в кластере redis

Автор оригинала: David Wong.

[TOC]

Большинство методов развертывания кластера redis используют способ развертывания twemproxy, подобный развертыванию. То есть, ключ redis разделяется с помощью tweetproxy, ключ redis разделяется и выделяется одному из нескольких экземпляров redis. Структура twemproxy выглядит следующим образом:

Поскольку несколько экземпляров redis, стоящих за tweetproxy, согласованы в конфигурации памяти и конфигурации процессора, как только возникает перекос в объеме доступа или объеме данных, это может привести к тому, что экземпляр redis достигнет узкого места в производительности, так что весь кластер достигнет узкого места в производительности.

Появление горячей клавиши вызывает наклон трафика кластера

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

1. Содержание горячих новостей в новостном приложении;
2. Конфигурация действия действия, в котором пользователь не может участвовать;
3. В системе seckill торгового центра именно информация о товарах привлекает наибольшее внимание пользователей и имеет самые высокие показатели затрат;

……

Решение

1. Используйте локальный кэш

Использование локального кэша на стороне клиента уменьшает доступ кластера redis к горячему ключу, но это также приводит к двум проблемам: 1. Если локальный кэш используется для всех ключей, которые могут стать горячими ключами, будет ли локальный кэш слишком большим, это повлияет на накладные расходы на кэш, требуемые самим приложением. 2. Как обеспечить согласованность между сроком действия локального кэша и данными кластера redis. Ввиду этих двух проблем мы не будем сначала говорить о втором решении.

2. Использование характеристик алгоритма сегментирования для взлома ключа

Мы знаем, что причина, по которой горячий ключ является горячим ключом, заключается в том, что он имеет только один ключ и попадает в один экземпляр. Таким образом, мы можем добавить префикс или суффикс к горячей клавише, изменить количество горячих клавиш на несколько M от числа экземпляров redis, чтобы перейти от доступа к ключу redis к доступу к n * m ключам redis. N * m ключей redis распределяются по разным экземплярам с помощью сегментирования, и трафик равномерно распределяется по всем экземплярам.

Код выглядит следующим образом:

//Number of redis instances
const M = 16

//Number of redis instances倍数(按需设计,2^n倍,n一般为1到4的整数)
const N = 2

func main() {
//Get redis instance 
    c, err := redis.Dial("tcp", "127.0.0.1:6379")
    if err != nil {
        fmt.Println("Connect to redis error", err)
        return
    }
    defer c.Close()

    hotKey := "hotKey:abc"
    // random number
    randNum := GenerateRangeNum(1, N*M)
    //Get the key to break up the hot key
    tmpHotKey := hotKey + "_" + strconv.Itoa(randNum)
    
    //Hot key expiration time
    expireTime := 50
    
    //A random value of time for smoothing expiration time
    randExpireTime := GenerateRangeNum(0, 5)

    data, err := redis.String(c.Do("GET", tmpHotKey))
    if err != nil {
        data, err = redis.String(c.Do("GET", hotKey))
        if err != nil {
            data = GetDataFromDb()
            c.Do("SET", "hotKey", data, expireTime)
            c.Do("SET", tmpHotKey, data, expireTime + randExpireTime)
        } else {
            c.Do("SET", tmpHotKey, data, expireTime + randExpireTime)
        }
    }
}

В этом коде с помощью случайного числа, большего или равного 1 и меньшего m * n, получается ключ TMP. Программа сначала получит доступ к ключу TMP, а затем к исходному горячему ключу, когда данные недоступны, и запишет содержимое горячего ключа обратно в ключ TMP. Стоит отметить, что время истечения срока действия ключа TMP-это время истечения срока действия горячего ключа плюс небольшое случайное положительное целое число, гарантирующее, что по истечении срока действия горячего ключа все ключи TMP не истечут одновременно и не вызовут лавину кэша. Это способ избежать схода лавины по просроченному склону. В то же время атомные часы можно использовать для записи данных, чтобы сделать их более совершенными и снизить давление БД.

Еще одна вещь, о которой стоит упомянуть. По умолчанию при создании ключа TMP мы будем использовать случайное число в качестве суффикса горячего ключа, что соответствует пространству имен redis и облегчает сбор и управление ключом. Но есть экстремальная ситуация, то есть длина горячей клавиши очень велика, в это время случайное число нельзя добавить в качестве суффикса, потому что в процессе расчета алгоритма сегментации tweetproxy, чем выше вес символа спереди, тем ниже вес символа после теста. То есть, для имени ключа, чем больше разница между символами перед ним, тем больше разница между вычисляемыми значениями разделов и тем более вероятно, что оно будет присвоено разным экземплярам (конкретный алгоритм здесь не будет расширен). Поэтому для горячей клавиши с длинным именем ключа случайное число должно быть аккуратно помещено, например, перед последним пробелом команды (например: из оригинала

Большой ключ приводит к увеличению объема данных в кластере

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

1. Крупномасштабные и долгосрочные строительные мероприятия на Форуме;
2. Список сообщений популярных чатов в системе чатов;

……

Решение

Разделенный большой ключ

Разделите данные, хранящиеся в большом ключе, на значения 1, 2 и 3,

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

// deposit
mset key1, vlaue1, key2, vlaue2 ... keyN, valueN
// take
mget key1, key2 ... keyN

1. Если большое значение-это большой список, вы можете разделить его на, list_2, список 3, список
2. То же самое верно и для других типов данных.

Как большой ключ, так и горячий ключ

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

Другой

Как найти горячий ключ, большой ключ

1. Предварительное судебное решение

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

2. В процессе – мониторинг и автоматическая обработка

Монитор

1. На стороне приложения каждый раз собирайте и сообщайте о запрошенных операциях redis; это не рекомендуется, но это можно рассмотреть в случае нехватки ресурсов O & M. Разработка может обходить эксплуатацию и техническое обслуживание);
2. На уровне прокси каждый запрос redis собирается и сообщается (рекомендуется, с небольшими изменениями и простым обслуживанием).;
3. Используйте команду monitor для подсчета горячих клавиш экземпляра redis (не рекомендуется, при условии высокого параллелизма может возникнуть скрытая опасность разрыва памяти redis).;
4. На машинном уровне клиент redis использует протокол TCP для взаимодействия с сервером, а протокол связи использует соотв. С точки зрения машины, вы можете завершить статистику ключей горячих точек, захватив TCP-пакеты всех портов redis на машине (не рекомендуется, на каждой машине компании есть много основных компонентов, так что не создавайте больше путаницы).;

Автоматическая обработка

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

3. после этого

Постарайся не говорить об этом потом. Все дело в крови и слезах. Не говори об этом.

Спасибо за чтение и добро пожаловать на обмен.