2010-01-13 3 views
1

Я ищу информацию о таких вещах, как ehcache и другие альтернативы memcached для проекта, который, вероятно, будет включать в себя 3-4 веб-сервера и что-то вроде 2-10 миллионов распределенных объектов, которые должны быть доступный для всех серверов.Распределенные системы кеширования и способы их распространения

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

Например, при рассмотрении документации на такие вещи, как ehcache, мне не ясно, если «распределенным» они означают стратегию, похожую на memcached, или нечто большее, чем «реплицированное/синхронизированное».

Редактировать: хотя ссылки на распределенные вычисления полезны, меня больше интересует, как ведут себя конкретные реализации. например буду ли я платить за накладные расходы синхронизации в некоторых системах?

+0

посмотреть: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem – jldupont

+1

немного таксономии: http://themindstorms.blogspot.com/2009/05/quick-reference-to-alternative-data.html – Tobu

ответ

3

Вы не очень точны в своем вопросе, хотя я могу видеть, куда вы хотите пойти, это довольно большое поле само по себе.

Вы можете начать здесь: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/

Кроме того, взглянув на Динамо, BigTable и все theoritical вопросы, связанные с этим (теорема CAP и выступление Вернер Vogels на это, что вы можете найти на InfoQ).

У вас есть все больше и больше информации об этом благодаря многочисленным видеороликам о встречах NoSQL.

Надеется, что это помогает,

Edit: о накладных расходах синхронизации, это действительно зависит от системы. каждая система имеет особые требования, например, Dynamo нацелена на систему высокой доступности, которая может быть не всегда полностью последовательной (возможная согласованность), поэтому она подразумевает (по дизайну и из-за ее требований) быть распределенными системами, в которых каждая запись должна быть принятым и быстрым. Другие системы могут вести себя по-другому,

+0

Спасибо за отличную ссылку. –

2

Я подозреваю, что вы после обсуждения на консистенции через «распределенные данные». Эта тема обширна, но имеется хорошая ссылка на компромиссы here.

Другими словами, это в значительной степени зависит от ваших требований (которые здесь не очень подробно описаны). Если я неправильно понял ваш вопрос, вы можете смело игнорировать мой вклад ;-)

1

Эта функция или свойство, которое вы, вероятно, ищете, - это архитектура «ничего общего». Memcached - пример, e. г. нет единой точки отказа, синхронизации или любого другого трафика между узлами, узлы даже не знают друг друга.

Итак, если это то, что вы хотите, и вы оцениваете продукт/проект, ищите термин «общий ничего». Если это не упоминается на первом экране, это, вероятно, не общая архитектура;)