#java #memcached #ehcache #shared-memory #distributed-caching
#java #memcached #ehcache #разделяемая память #распределенное кэширование
Вопрос:
В документации MemCached упоминается, что данные распределяются по узлам. Это их определение распределенного кэша. Если узлу A нужны данные, которые находятся на узле B, данные передаются из B в A. Если A выходит из строя, все данные, хранящиеся на A, больше не доступны для B.
Однако EhCache имеет другое определение распределенного кэширования. По сути, это больше похоже на общую память, чем на распределенный кэш. Если узел A изменяет некоторые данные, узел B увидит это изменение. В случае сбоя любые данные A, хранящиеся в общей памяти, остаются доступными для узла B.
Это приводит меня к двум вопросам:
-
Если у меня есть 3 узла A, B, C, каждый из которых имеет 1 ГБ памяти, кажется, что MemCached добавит память и сделает ее похожей на 3 ГБ памяти для узлов. Однако, похоже, что EhCache не добавляет 3 ГБ, а скорее разрешает не более 1 ГБ общей памяти между каждым узлом. Правильно ли это?
-
Если ответ на 1. «да», то правильно ли делать вывод, что EhCache и MemCached на самом деле дополняют друг друга, а не конкурируют?
Ответ №1:
Говоря о том, что делает Ehcache, поскольку я не эксперт по Memcache.
Ehcache — это «многоуровневый кэш». Это позволяет вам увеличивать и уменьшать масштаб на каждом уровне. Если бы у вас было 3 серверных узла Ehcache (на самом деле серверный уровень — это массив серверов TSA, Terracotta), каждый из этих серверных узлов имел бы уникальные данные, поэтому, не включая то, что можно поменять местами на диск, у вас было бы 3 гигабайта. TSA может быть настроен на использование сохраняемости диска для HA и / или активного пассивного переключения. Подключив BigMemory, вы можете увеличить любой из этих уровней до сотен гигабайт оперативной памяти, не опасаясь проблем с GC.
Итак, почему многоуровневый кэш — это круто? Это то, как он использует память в вашем клиенте. Вы можете иметь согласованные данные объемом до сотен гигабайт, обрабатываемые всего за микросекунды на локальных уровнях кучи и кучи вне кучи или за миллисекунды на удаленном уровне. И все данные могут быть HA.
Вы можете прочитать больше о некоторых из этих материалов здесь:
http://scaleaholic.blogspot.com/2010/09/little-bit-about-bigmemory-for-ehcache.html
и здесь:
http://scaleaholic.blogspot.com/2011/08/what-is-terracotta.html
и, конечно же: ehcache.org и terracotta.org
Комментарии:
1. Итак, вы хотите сказать, что если бы у узла TSA был 1 ГБ, узлы EhCache все еще могли бы хранить 1 ГБ своих собственных данных, а узел TSA сохранял бы 1 ГБ в памяти этих данных и разливал оставшиеся 2 ГБ на диске (более или менее)?
Ответ №2:
У меня есть некоторый опыт работы с обоими.
Я бы сказал «да» на оба ваших вопроса.
Я использую ehcache вместе с гибернацией. Он кэширует данные, найденные в центральной базе данных, в памяти на нескольких серверных узлах кластера. Причина, конечно, в том, чтобы иметь меньше обращений к базе данных. Если кэшированное значение записывается одним узлом, то это значение должно быть признано недействительным на других узлах, чтобы заставить их повторно прочитать значение из базы данных и повторно кэшировать его.
Memcached я использовал в качестве источника данных. Это простая база данных ключ = значение. На каждом сервисном узле вы определяете список узлов memcached, которые он может использовать. Затем он будет записывать на какой-либо узел (я думаю, с помощью циклического перебора). Ключ содержит информацию о том, на каком узле memcached хранится значение.
Итак, по моему опыту, memcached — это часто распределенная база данных (не реляционная, но все же база данных), в то время как ehcache — это скорее традиционный кэш.