Какой лучший распределенный кеш-память Erlang в памяти?

Мне нужно какое-то предложение для системы кэширования в памяти erlang.

  1. Элемент кэша представляет собой хранилище на основе ключей и значений. ключ обычно представляет собой строку ASCII; value - это типы erlang, включая число/список/кортеж/и т. д.
  2. Элемент кэша может быть установлен любым узлом.
  3. Элемент кэша может быть получен любым узлом.
  4. Элемент кеша является общим для всех узлов, даже на разных серверах.
  5. грязное чтение разрешено, я не хочу, чтобы какая-либо блокировка или транзакция снижали производительность.
  6. Полностью распределенная, без централизованной машины или службы.
  7. Хорошее выступление
  8. Простота установки и развертывания, настройки и обслуживания

Первый вариант мне кажется mnesia, но у меня нет опыта в этом. Соответствует ли это моему требованию? Какую производительность я могу ожидать?

Другой вариант - memcached -- Но я боюсь, что производительность ниже, чем у mnesia, потому что дополнительная сериализация/десериализация выполняются как демон memcached из другого процесса ОС.


erlang ets
person Mr.Wang from Next Door    schedule 24.05.2013    source источник

Ответы (1)


arrow_upward
12
arrow_downward

Спасибо за ваше подробное предложение. Я предпочитаю какое-то локальное решение для кэширования в памяти вместо централизованной системы кэширования. Централизованная система кэширования означает задержку сетевого взаимодействия и дополнительные затраты на сериализацию/десериализацию объекта из/в сохраненный двоичный файл или строку. В моей ситуации у меня много мелких элементов кеша, и в одном HTTP-запросе я могу запросить до 100 элементов, но не в пакетном режиме. В таком случае централизованная система кэширования мне не подходит. Есть ли у Mnesia какой-то локальный кеш, чтобы не всегда запрашивать кеш с других машин?

person Muzaaya Joshua    schedule 24.05.2013
comment
да. Если на каждом узле есть копия mnesia одной и той же базы данных, согласованность будет распространяться на весь кластер. Всегда. в любой момент то, что вы читаете с любого узла кластера, будет таким же, как и везде. Но это предполагает доступность сети и доступность мнезии на всех узлах, участвующих в распределенной системе. - person Mr.Wang from Next Door; 24.05.2013
comment
да. _1_ соответствует вашим требованиям. Однако, как вы сказали, инструмент хорош, когда тот, кто его использует, глубоко в нем разбирается. Мы использовали mnesia на _2_ и до сих пор не испытывали никаких проблем. Когда mnesia используется в качестве кеша, это лучше, чем memcached, по одной причине: «Memcached не может гарантировать, что то, что вы пишете, вы можете прочитать в любое время из-за проблем с подкачкой памяти и прочего» (следуйте здесь).

Однако это означает, что ваша распределенная система будет построена на Erlang. Действительно, mnesia в вашем случае превосходит большинство решений для кэширования NoSQL, потому что их системы _3_. Mnesia непротиворечива до тех пор, пока в кластере может быть обеспечена доступность сети. В системе с распределенным кэшем вам не нужна ситуация, когда вы читаете разные значения для одного и того же ключа с разных узлов, поэтому здесь пригодится согласованность мнезии.

Вам следует подумать о том, что это возможно. иметь централизованный кэш памяти для распределенной системы. Это работает следующим образом: у вас есть сервер _4_, работающий и доступный для клиентов AMQP на каждом узле кластера. Системы взаимодействуют через интерфейс AMQP. Поскольку кеш является централизованным, согласованность обеспечивается процессом/системой, ответственной за запись и чтение из кеша. Другие системы просто помещают запрос ключа в _5_, а система, отвечающая за кеширование, получает это сообщение и отвечает на него значением.

Мы использовали _6_ для недавней системы, которая включала интеграцию с банковские системы, ERP-система и Публичный онлайн-сервис. То, что мы построили, отвечало за объединение всего этого, и мы рады, что использовали _7_. Деталей много, но мы придумали формат сообщения и механизм идентификации системы. Все системы должны иметь клиент RABBITMQ для записи и чтения из шины сообщений. Затем вы должны создать _8_ чтения для каждой системы, чтобы другие системы записывали свои запросы в эту очередь, чье имя внутри RABBITMQ совпадает с именем системы, которой она принадлежит. Затем, позже, вы должны зашифровать сообщения, проходящие по шине. В конце концов, у вас есть системы, связанные вместе на большом расстоянии/между штатами, но с эффективной сетью вы не поверите, как быстро RABBITMQ связывает эти системы. В любом случае, RABBITMQ также может быть кластеризован, и я должен сказать вам, что именно _9_ поддерживает RABBITMQ (это говорит вам, насколько хорошей может быть мнезия).

Другое дело в том, что вам следует немного почитать и написать много программ, пока вы не освоитесь с этим. - person Muzaaya Joshua; 24.05.2013