#wso2 #wso2-am #hazelcast #wso2carbon
#wso2-api-менеджер #hazelcast #wso2 #wso2-api-manager
Вопрос:
Мы используем многопользовательский кластер WSO2-AM 2.6, который имеет два типа узлов
- Узел полного профиля (издатель, хранилище, KM и т.д.)
- Рабочие узлы шлюза
Обмен информацией между издателем и шлюзами осуществляется с использованием EFS.
До сих пор мы работали с включенным Hazelcast, но мы предпочитаем отключить Hazelcast, поскольку это доставляет нам много хлопот при производстве, и мы понимаем, что в WSO2 2.x его включение не обязательно.
Мы протестировали нашу систему со следующими настройками:
<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="false">
Все работало нормально, за исключением одного замеченного нами побочного эффекта: требуется много времени (может быть даже 15 минут), пока деактивация или повторная активация клиента не будет заполнена на рабочем узле.
При создании совершенно новой организации с недавно созданным API можно практически мгновенно запустить API на рабочем компьютере. Но если вы отключите организацию, API все равно будет работать. Пройдет много времени, прежде чем worker сообщит, что клиент больше не активен.
То же самое для повторной активации клиента. Потребуется много времени, пока worker перестанет жаловаться на неактивную организацию и разрешит запустить API.
Есть ли какие-то настройки конфигурации, которые нам нужно изменить? Или это ожидаемое поведение? Кто должен сообщать работникам об изменениях в организации в отсутствие Hazelcast?
Ответ №1:
Существует кэш клиента [1], который содержит информацию о клиенте. По умолчанию TTL кэша (и любого другого кэша) составляет 15 минут. При деактивации клиента этот распределенный кэш очищается с помощью hazelcast. Вот почему вы видите выше, когда отключаете кластеризацию hazelcast.
Как правило, в производственной среде маловероятно, что вам потребуется очень часто активировать и деактивировать арендаторов. Поэтому я не думаю, что задержка в 15 минут является серьезной проблемой.
Однако, если это действительно так, вы должны поддерживать кластеризацию Hazelcast включенной. Когда вы сказали, что столкнулись с большой болью из-за Hazelcast, я полагаю, что это из-за распределенного характера этих кэшей. В качестве решения вы можете включить локальный кэш в отличие от распределенного кэша. Здесь кластеризация Hazelcast используется только для вызовов аннулирования кэша. Это может сработать для вас. (Отказ от ответственности: я еще не пробовал это.)
Для этого вам нужно установить ForceLocalCache в true в carbon.xml
<Cache>
<!-- Default cache timeout in minutes -->
<DefaultCacheTimeout>15</DefaultCacheTimeout>
<!-- Force all caches to act as local -->
<ForceLocalCache>true</ForceLocalCache>
</Cache>
Ответ №2:
Честно говоря, я думаю, вам следует подробнее изучить, как настроить Hazelcast. Hazelcast встроен во множество очень часто используемых стеков проектов (JHipster, Atlassian, Apache Camel, SunGard и т.д.) Он очень удобен для выполнения того, что вы хотите здесь, но он также легко настраивается, так что вы, вероятно, захотите настроить его в соответствии с вашими потребностями. Если вы просто отключите это, вы удалите всю кластеризованную масштабируемость, которую это приносит. Конфигурация представляет собой всего лишь XML-файл, и вы можете найти всю документацию здесь:
https://docs.hazelcast.org/docs/3.11.2/manual/html-single/index.html#understanding-configuration
Это легко понять и определенно стоит вашего времени.