Когерентность ближнего кэша с распределенной обратной схемой и локальными настройками
Я использую Coherence 12.1.2.0.0
Топология моей системы: три узла с приложением (кеш-клиенты) и отдельный кеш-сервер с большим объемом памяти.
Моя цель - создать систему кеширования, которая не полностью зависит от сервера кеша и в то же время потребляет строгую память на серверах приложений. Поэтому я хочу сохранить все значения, которые когда-либо были помещены в кэш на сервере кеша. Но если сервер кеша не работает, приложения могут работать со своими небольшими локальными кешами.
Я думал, что Ближний кеш - это то, что мне нужно. Он состоит из локальной схемы в качестве передней и распределенной кэш-памяти в качестве задней схемы. Но когда я устанавливаю для локального хранилища значение false в распределенном разделе на клиентах, я не могу работать даже с фронтальным локальным кешем, поскольку я получаю сообщение об ошибке "Нет локального хранилища с включенным узлом" для каждой операции put. Если я установлю для local-storage значение true и ограничу локальную память, например, 1 единицей, кеш-сервер не получит размещенные значения со стороны клиента. Точнее, он получает некоторые из них, но не все. Например, если я делаю "положить 1 1" и получаю его несколько раз, а после этого пытаюсь "положить 2 2" и "положить 4 4", я никогда не получу "2 2" и "4 4" вместе на сервере кеша. В этом случае сервер кэша содержит "1 1" и может иметь одно из значений "2 2" или "4 4", но не все три пары одновременно.
Я попробовал схему заднего плана с прямой локальной схемой и схему чтения-записи-заднего плана с локальной схемой во внутреннем разделе. Результат тот же. Это мой примерный тестовый конфиг:
<near-scheme>
<scheme-name>near</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>local</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<distributed-scheme>
<scheme-ref>distributed</scheme-ref>
</distributed-scheme>
</back-scheme>
<invalidation-strategy>all</invalidation-strategy>
</near-scheme>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>DistributedCache</service-name>
<local-storage>false</local-storage>
<backing-map-scheme>
<local-scheme>
<scheme-ref>local-binary</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<local-scheme>
<scheme-name>local</scheme-name>
<eviction-policy>HYBRID</eviction-policy>
<high-units>1</high-units>
<unit-calculator>FIXED</unit-calculator>
<expiry-delay>{expiry 1h}</expiry-delay>
</local-scheme>
<local-scheme>
<scheme-name>local-binary</scheme-name>
<eviction-policy>HYBRID</eviction-policy>
<high-units>300</high-units>
<unit-calculator>BINARY</unit-calculator>
<expiry-delay>{expiry 1h}</expiry-delay>
</local-scheme>
Какой набор схем мне нужен?
2 ответа
Функция, которую вы пытаетесь использовать, не существует. Oracle Coherence позволяет вам определять ближний кеш на стороне вашего приложения, но он должен поддерживаться сервером удаленного кеша. Без этого вы ничего не сможете спасти. Клиентская сторона рядом с кешем требует от нее серверной части для взаимодействия в качестве большой БД для загрузки и обновления данных, полученных из приложения. Трюк, который вы пытаетесь использовать только для набора 1, также неверен. Каждая клиентская сторона пытается обновить значения самостоятельно. Проблема здесь в том, что когда клиентская сторона "A" отправляет обновление, а "B" также отправляет, один из них получен ранее (вы не знаете, какой), а другой помечен как недействительный. И затем, если у вас есть в кеше 1 1, "A" отправляет 2 2 и "B" 3 3, один из них (т.е. 3 3) останется, а 2 2 будет помечен как недействительный, поскольку 1 1 был в гипотетической стороне 'C'. Вы злоупотребляете возможностями ближайшего кеша - он не предназначен для этого. Coherence - это надежный кеш, и если серверная часть не работает, ваше приложение также не будет работать. Если вам нужно, чтобы рядом с кэшами иногда обновлялись удаленные серверы (звучит так), подумайте об использовании другого решения. Надеюсь, я тебе помог.
Потерял ваш актуальный вопрос. Но если вы хотите выделить / ограничить разный объем памяти для разных узлов в одном и том же кластере, то вы можете установить для калькулятора единиц значение Binary, а затем указать настраиваемый максимальный размер памяти через параметр JVM при запуске узла кластера. Проверьте, как рассчитать размер объекта в кеше.