Использование Hazelcast/Redis для требования к кеш-памяти резервного копирования

Question

Я разрабатываю распределенное приложение Java, которое должно проверять список пользовательских элементов черного списка по каждому запросу.

Если запрос не удовлетворяет некоторым правилам приемлемости, система должна добавить идентификатор пользователя (параметр запроса) в черный список.

Я пытаюсь найти правильное решение для кеширования для реализации черного списка. Мои требования;

• запрашивая черный список должен быть очень быстрым
• черный список Технология живучесть должна быть масштабируемой
• все данные из черного списка должны быть сохранены на РСУБД также для обеспечения отказоустойчивости/перезагрузки цели.

Это два возможных решения;

Вариант 1: Я могу использовать redis для хранения данных черного списка. Всякий раз, когда запрос терпит неудачу в правилах приемлемости, я могу добавить userid для кратного кеширования. - преимущества: чрезвычайно быстрый запрос, прост в реализации - недостатки: доверяя постоянству redis, хотя он работает, это решение для кеша по дизайну, а не на уровне стойкости.

Вариант 2: Я могу использовать redis для хранения данных черного списка, тем временем я могу поддерживать таблицы db на РСУБД для черного списка. Всякий раз, когда запрос терпит неудачу в правилах приемлемости, я могу добавить идентификатор пользователя в таблицу redis cache и rdbms. - преимущества: чрезвычайно быстрый запрос, возможность (возможность) перезагрузить redis cache из db - недостатки: существует проблема согласованности между таблицей redis и db.

Вариант 3: Я могу использовать hazelcast в качестве кэша L2 для гибернации, и когда я добавляю какой-либо идентификатор пользователя в черный список, он добавляется в кеш и db.

У меня есть вопросы по поводу варианта 3

• ли hazelcast кэш L2 подходит для сохранения такого черного списка пользователей?
• Поддерживает ли hibernate проблему согласованности между кешем и db?
• Когда приложение перезагрузилось, как перезагружается L2-кеш?

и последний вопрос - Есть ли у вас какие-либо другие предложения для такого прецедента?

Edit:

• Там будет 100m записи в черный список, и у меня есть пара smilar черный список.

• Мое чтение играет важную роль. Мне нужно запросить наличие ключа в черный список ~ 100мс

Answer 1

Ygok,

Все еще ждут разъяснений от требований запроса, но я могу предположить, что это поиск по ключу (так как вы упоминаете Redis и Redis не имеют языка запросов. Hazelcast действительно есть Distributed Query/Predicate API) , Поиск по ключевому слову - чрезвычайно быстрая операция с Hazelcast.

В опции вам необходимо поддерживать согласованность данных между вашей РСУБД и кешем Redis. Используя Hazelcast MapLoader/MapStore, вы можете реализовать write-through -/read-through - концепции кеша. Все, что вам нужно сделать, это поместить запись в кеш, и Hazelcast сохраняет ее немедленно или с установленной задержкой (с пакетной загрузкой) в РСУБД.

С точки зрения производительности, пожалуйста, ознакомьтесь с недавними Hazelcast/Redis benchmark.

Дайте мне знать, если возникнут какие-либо вопросы.

Answer 2

У меня был подобный вопрос раньше, в первую очередь, сколько данных вы хотите хранить и тратить, как много памяти? насколько быстрый запрос в секунду вам нужен? что такое структура данных, только userId как ключ?

• Запрос на Hazelcast не очень быстрый при тестировании (вы можете сделать это для себя), но он может хранить большие данные памяти. Hazelcast с использованием Java сериализации по умолчанию, это дороговато много памяти и ввода-вывода.

• Hazelcast обеспечивает спящий режим кэша L2, кэш-хранилище данных на Hazelcast (только кэш запросов), поэтому перезапустить приложение не влияет кэша.

• Redis обеспечивает постоянство данных памяти (DUMP и AOF), может быть, бит данных будет потерян, когда сервер будет разбит, но он очень быстрый.

• Если вы хотите, чтобы не потерять какие-либо данные, хранить на нескольких MySQL сервера (расщепленные данные по USERID на другой сервер, но вы должны рассмотреть проблемы, когда добавить новый сервер), в то же время, вы можете добавьте локальный кеш (например, Ehcache или google CacheBuilder) и установите время истечения срока действия , это может способствовать повышению производительности.

Answer 3

Возможно сохранение согласованности между кешем Redis и РСУБД с использованием рамки Redisson. Он предоставляет стратегии write-through и read-through для объекта Map с использованием MapWriter и MapLoader объектов, которые необходимо использовать в вашем случае.

Пожалуйста, прочтите этот documentation section