Что такое распределенный кэш?
меня смущает концепция распределенного кэша. Я знаю, что это такое из поиска google. Распределенный кэш может охватывать несколько серверов, так что он может увеличиваться в размере и транзакционной емкости. Однако я действительно не понимаю, как это работает или как он распределяет данные.
например, предположим, что у нас есть сведения 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 и 2 сервера кэша A и B. Если мы используем распределенный кэш, то один из возможных решение состоит в том, что данные 1, 3, 5, 7, 9 хранятся на сервере кэша A, а 2, 4, 6, 8, 10-на сервере кэша B.
Так это правильно или я неправильно понял?
второй вопрос в том, что я обычно слышал слово сервер. Что это? В приведенном выше примере сервер-это сервер, верно?
третий вопрос, если сервер (скажем, сервер A) идет вниз, что мы можем сделать с этим? Я имею в виду, если мой пример выше верен, мы не можем получите данные 1, 3, 5, 7, 9 из кэша, когда сервер a не работает, тогда что может сделать сервер кэша в этом случае?
2 ответов
да, половина данных на сервере a и половина на сервере b будут распределенным кэшем. Существует много способов распространения данных, хотя наиболее популярным кажется какое-то хеширование ключей.
термины сервер и узлов взаимозаменяемы. Узел, как правило, является единицей некоторой коллекции, часто называемой кластером. Сервер-это, как правило, единое аппаратное обеспечение. В erlang можно запустить несколько экземпляров Erlang runtime на одном сервере, и, таким образом, у вас будет несколько узлов erlang... но обычно вы хотите иметь один узел на сервер для более оптимального планирования. (Для не-распределенных языков и платформ вы должны управлять процессами на основе ваших потребностей.)
если сервер идет вниз, и это сервер кэша, то данные должны были бы исходить из его исходного источника. Например: кэш обычно представляет собой базу данных на основе памяти, предназначенную для быстрого извлечения. Данные в кэш остается только до тех пор, пока он используется регулярно, и в конечном итоге будет очищен. Но для распределенных систем, где вам нужно постоянство, общий метод должен иметь несколько копий. Например: у вас есть серверы A, B, C, D, E и F. Для данных 1 Вы бы поместили его на A, а затем копию на B и C. Couchbase и Riak делают это. Для данных 2 это может быть на B, а затем копии на C и D. Таким образом, если какой-либо один сервер идет вниз, у вас все еще есть две копии.
Я уже довольно давно использую решения распределенного кэширования (NCache , AppFabric и т. д.), и я собираюсь ответить на все три вопроса, основанные на моем опыте с распределенным кэшированием.
1: Решение распределенного кэширования позволяет хранить данные на всех серверах путем создания кластера кэша. Допустим, у вас есть 2 сервера кэш(серверные узлы) и вы добавили 10 элементов в кэше. В идеале 5 элементов должны присутствовать на обоих узлах сервера с момента загрузки данных получает распределение между количеством серверов в кластере кэша. Обычно это достигается с помощью алгоритмов хэширования и интеллектуального распределения данных. В результате нагрузка на запрос данных также разделяется между всеми серверами кэша и достигается линейный рост транснациональной емкости по мере увеличения количества серверов в кластере кэша.
2: кластер кэша может содержать много серверных машин, которые также называются серверными узлами. Да, сервер это сервер или сервер в вашем примере.
3: обычно распределенная система кэширования очень надежна с помощью поддержки репликации. Если один или несколько серверов идут вниз, и у вас была включена репликация, то не будет потери данных или простоя. NCache имеет различные типологии для решения этой проблемы, такие как реплицированная топология и раздел топологии реплики, где данные каждого сервера реплицируются на другой сервер. В случае, если один сервер выходит из строя, реплицированные данные этого сервера автоматически доступно с выжившего узла сервера.
в вашем примере, данные серверу(1, 3, 5, 7, 9) реплицируется на сервер B(2, 4, 6, 8, 10) и наоборот. Если сервер A отключится, данные сервера A, присутствующие на сервере B, будут доступны и использованы оттуда, чтобы не произошло потери данных. Поэтому, если сервер A отключается и приложение запрашивает данные (1), эти данные будут получены с сервера B, поскольку сервер B содержит резервную копию всех данных сервера A. Это бесшовные для ваших приложений и управляется автоматически системой кэширования.