Можно ли получить набор кандидатов из выселенных ключей в кофеине? - PullRequest
0 голосов
/ 08 июня 2018

Я пытаюсь использовать кэш для ведения списка маршрутизируемых серверов в зависимости от типа запроса.

LoadingCache<Request, ActorRef> serversByRequestType = Caffeine.newBuilder()
  .writer(new CacheWriter<RequestType, ActorRef>() {

    @Override public void write(RequestType req, ActorRef server) {
      // We need to handle this type of request now.
      //
      server.tell(StartUp(req))
    }

    @Override public void delete(RequestType req, ActorRef server, RemovalCause cause) {
      // This req type can no longer be handled, so remove from
      // routable servers.
      //
      server.tell(ShutDown(req))
    }

  })
  .build();

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

В приведенном выше коде нет способа сделать это без блокировки.

В идеальном случае удаление должно происходить перед добавлением в кэш, чтобы я мог асинхронно завершить работу сервера и ждатьдля события ShutdownServer ... но нет способа получить этот сигнал из метода write, который обязательно должен знать, когда начинать.Другими словами, я хотел бы отправить SwitchServerTraffic(from: RequestType, to: RequestType) на server, где from будет удаленным ключом, а to будет добавленным ключом.

Если у меня был доступ кнабор кандидатов на выселение: когда поступает запрос, если его тип отсутствует в кеше, а кэш заполнен, я могу выбрать элемент из набора для выселения и закрыть его сервер, а затем синхронно добавить тип запроса в кэшà la Akka.

Есть ли способ получить доступ к списку кандидатов на выселение в кофеине?Если нет, есть ли другой способ обойти эту проблему, которая устраняет ее?

1 Ответ

0 голосов
/ 08 июня 2018

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

Map<K, V> coldest = cache.policy().eviction().get().coldest(count);

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

По умолчанию выселение выполняется асинхронно с вызовами, обращенными к пользователю, поэтому большинство вызовов CacheWriter#delete будутскрытый.Однако, если этот вызов дорогой, он задерживает выселение следующего предмета.

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

...