Redis — индексы с истекшим сроком действия не удаляются

Я нашел следующий вопрос (Spring Redis - индексы не удаляются после основного entry expires) о проблеме с истечением срока действия индексов в Redis.

Проблема в том, что срок действия основных записей и записей :phantom истекает и они удаляются корректно, но соответствующие записи :idx остаются в Redis потерянными.

Одно из предложенных решений заключалось в том, чтобы включить KeyspaceEvents, чтобы Redis автоматически удалял индексы записей с истекшим сроком действия во время задания очистки.

К сожалению, это решение не будет работать для нашего приложения Spring Boot, поскольку мы используем Redis Enterprise в качестве предоставляемой услуги внутри облачной среды, что не позволяет нам вносить какие-либо изменения в конфигурацию (команда CONFIG отключена).

Вот что я пробовал:

@Configuration
@EnableRedisRepositories(enableKeyspaceEvents = RedisKeyValueAdapter.EnableKeyspaceEvents.ON_STARTUP)
public class RedisConfiguration {...}

Редактировать:
Я думал, что это работает для моего локального образа докера Redis, но я ошибался! А в предоставленном нами сервисе Redis (Enterprise) его даже нельзя настроить со следующим сообщением:
Caused by: redis.clients.jedis.exceptions.JedisDataException: ERR unknown command 'CONFIG'...

Может ли кто-нибудь дать мне подсказку о том, как удалить индексы?

В настоящее время у нас не так много записей :idx, но они должны быть удалены вместе с записью :phantom, чтобы избежать сохранения «осиротевших» записей.

Заранее спасибо.


person NanSil    schedule 22.01.2018    source источник
comment
Уведомления о пространстве ключей AFAIK поддерживаются в версии Enterprise. Было бы лучше, если бы вы направили этот вопрос по адресу [email protected] с подробной информацией о поставщике услуг и облачной среде, которую вы используете.   -  person Itamar Haber    schedule 22.01.2018
comment
Спасибо, обязательно напишу! Дело в том, что для включения KeyspaceEvents требуется, чтобы была включена команда CONFIG, что не относится к защищенным средам Redis... :-/   -  person NanSil    schedule 23.01.2018


Ответы (1)


Я смог найти решение для удаления ключей :phantom и :idx.

В классе конфигурации Redis следует поместить следующее:

@Configuration
@EnableRedisRepositories(enableKeyspaceEvents = EnableKeyspaceEvents.ON_STARTUP, basePackages = {
    "com.aaaaa.bbbbb.persistence.model.repository" }, keyspaceNotificationsConfigParameter = "")

Когда вы устанавливаете для атрибута keyspaceNotificationsConfigParameter пустую строку, команда CONFIG, которая не работает в AWS Redis, не выполняется, но таким образом создается экземпляр прослушивателя событий истечения срока действия.

Этот атрибут имеет значение по умолчанию (Ex), которое вызывает выполнение команды CONFIG.

Это происходит с помощью следующего кода весны:

public void init() {
    if (StringUtils.hasText(keyspaceNotificationsConfigParameter)) {
        RedisConnection connection = listenerContainer.getConnectionFactory().getConnection();

        try {
            Properties config = connection.getConfig("notify-keyspace-events");

            if (!StringUtils.hasText(config.getProperty("notify-keyspace-events"))) {
                connection.setConfig("notify-keyspace-events", keyspaceNotificationsConfigParameter);
            }

        } finally {
            connection.close();
        }
    }
    doRegister(listenerContainer);
}

Как это условие не выполняется

if (StringUtils.hasText(keyspaceNotificationsConfigParameter)) {

команда CONFIG не выполняется.

Я думаю, что Spring должен улучшить это, а не создавать поток, основанный на установке атрибута с пустой строкой.

Единственное, что также необходимо, это чтобы в AWS ElastiCache (Redis) было установлено значение параметра «notify-keyspace-events», например AKE, что означает, что все события будут уведомлены.

person Germán Kronberg    schedule 06.03.2020
comment
Я попробовал это. Я не получаю сообщение об ошибке во время запуска, но он не очищает индексы, созданные spring-data-redis. У вас есть идеи, как это исправить? - person Raashith; 05.09.2020