Альтернативные политики кэширования в кофеине

Question

В своем исследовании я прослеживаю и получаю доступ к кешу кофеина только для некоторых элементов в нем. Поэтому я собираю собственную статистику попаданий / промахов, которая отличается от встроенной статистики Caffeine. Это прекрасно работает с политикой Caffeine по умолчанию - Window-TinyLFU. Однако я бы хотел сделать то же самое с другими политиками кэширования.

Действительно, симулятор Caffeine предлагает множество политик кэширования, которые можно выбрать с помощью application.conf. файл. Тем не менее, AFAIK, симулятор ведет себя как черный ящик - запускает всю трассировку, создает собственную статистику и т. Д. c. Другими словами, хотя конструктор Caffeine позволяет определять некоторые параметры (например, максимальный размер кэша), я не нашел способа определить там политику кэширования.

Есть ли способ сделать это? Меня интересует только прием / выселение - (пока) я не использую политику истечения срока действия. Большое спасибо заранее.

Answer 1

Библиотека кэша кофеина и его симулятор должны обрабатываться независимо. Библиотека предназначена для разработчиков приложений, поэтому это черный ящик, который скрывает значительную сложность и делает выбор алгоритма c. Симулятор предназначен для исследований и представляет собой «белый ящик», который можно напрямую модифицировать.

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

Так как симулятор используют лишь немногие из нас, вы можете задавать вопросы, открыв выпуск Github или можете написать мне. Его структура довольно проста:

• Симулятор: организует процесс параллельного запуска политик
• Реестр: создает настроенные политики
• TraceReader: анализатор для трассировки format
• PolicyActor: запускает пакет событий против политики
• Policy: алгоритм замены, который отслеживает его статистику
• Reporter: довольно распечатанный результат симуляции.
• reference.conf: внешняя конфигурация

Простой пример - CaffeinePolicy , который адаптируется из кэша Caffeine к политике симулятора. Прямой алгоритм, такой как SegmentedLruPolicy , включает в себя необязательную политику допуска для использования со своей политикой выселения.