Нет, не совсем так. Конечно, те ключи, которые были на пропавшем сервере, пропадут. Но есть существенная разница.
Пусть у нас было 4 сервера с одинаковым весом. И один из них сломался, мы его удалили из пула. После этого стандартное распределение будет остаток от деления на 3 вместо остатка от деления на 4, очевидно, что ключи переместятся на всех серверах. То есть и на тех, которые не пострадали, то есть для нашего кода это будет выглядеть как потеря значительно больше чем 25% ключей.
В случае консистентного хэширования ключи, которые были на 3 серверах, которые остались в рабочем состоянии, на них же и останутся. А ключи с 4-го сервера равномерно распределяться по 3-м оставшимся, мы потеряли ровно 25% ключей — возможный минимум.
Соединение может пропасть когда угодно, это правда. Но интерфейс клиента прозрачный.
failure_callback не для пересоединения, конечно! Там есть таймауты на новую попытку коннекта и всё остальное. Надо искать причину рассоединения — их не должно быть по-хорошему.
Коннект ко всем серверам — это нормально, если они перзистенты. Какая разница? Потом всё равно с высокой вероятностью все понадобятся.
Понимаю Вас ;) Но здесь не нужно хранить новых паролей — по сути доступом к MDC-серверу является доступ к учетной записи протокола, например, ICQ. Так что никаких новых паролей, всё прозрачно. Покуда есть доступ к ICQ, например, будет доступ и к истории.
Если не заботится об атомарности изменений — любой объект разумного размера можно положить в memcached просто через сериализацию.
Когда требуется атомарное изменение, списка, например, это уже становится довольно сложной задачей: можно использовать аналог блокировок (об этом будет позже в цикле статей) или другими подходами.
Если будет конкретный вопрос, постараюсь ответить.
Я написал выше, текущее состояние кода. Сейчас стыдно еще и смысла нет. Доведем/доработаем, подумаем и сделаем. В исходном коде нет тайны, наоборот были бы рады сторонним патчам.
Я думаю, определения для большинства читателей будут полезны. Потому что термины должны быть у всех одинаковы. Я привел классические и широко используемые определения этих терминов и пояснил, почему не бывает «разделяемый распределенный».
В остальном согласен — когда нужна исключительно разделямая память и повышенная производительность, memcached не нужен. Пример такой задачи — разделямая память в сервере PostgreSQL/Oracle, которые работают в многопроцессном режиме.
Да, скорее всего, мы собирали на 4.3/4.4, тут версия стандартной библиотеки C++ изменилась. Будем билдить для разных дистров, постараемся охватить и gentoo, которая не спешит за последней модой ;)
Если gcc 3-й, то лучше даже не пытаться — надо обновлять всю систему (у них с 4-м ABI несовместимы). А дальнейшее зависит от Вашего дистрибутива (если дело только в Qt). Какие-то уже обновились, кто-то обновится скоро, а кто-то, может, через год.
Если быть более точным, то shared memory — это память, к которой прямой доступ имеют несколько процессов, находящихся на одном физическом сервере.
Distributed memory — это память, которая распределена на нескольких физических хостах, и к ней имеют прозрачный доступ процессы с разных хостов.
Что такое 'distributed' 'shared', я не знаю.
Memcached не является 'memory' в точном смысле этого слова, т. к. доступ не прямой к памяти, а через некоторый API. Это типичный сетевой сервис, на самом деле, который можно рассматривать как 'distributed memory'.
Если несколько языков программирования, например, даже в рамках одного физического сервера, ваять «свою» разделяемую память смысла нет, лучше сразу использовать то, для чего есть биндинги — например, memcached.
Пусть у нас было 4 сервера с одинаковым весом. И один из них сломался, мы его удалили из пула. После этого стандартное распределение будет остаток от деления на 3 вместо остатка от деления на 4, очевидно, что ключи переместятся на всех серверах. То есть и на тех, которые не пострадали, то есть для нашего кода это будет выглядеть как потеря значительно больше чем 25% ключей.
В случае консистентного хэширования ключи, которые были на 3 серверах, которые остались в рабочем состоянии, на них же и останутся. А ключи с 4-го сервера равномерно распределяться по 3-м оставшимся, мы потеряли ровно 25% ключей — возможный минимум.
Если есть что-то кроме этого, есть простая функция вида:
getCachedResult($func, $arguments, $cache_name, $cache_timeout)
Которая либо делает $func($arguments) (если еще нет кэша), либо отдает результат из кэша.
На самом деле чуть сложнее, но суть эта. Включается/выключается кэш, конечно, централизованно, как и управляется политика доступа к нему.
Хранилище кэша (memcached, файлы, eAccelerator) отделено от логики кэширования интерфейсами.
failure_callback не для пересоединения, конечно! Там есть таймауты на новую попытку коннекта и всё остальное. Надо искать причину рассоединения — их не должно быть по-хорошему.
Коннект ко всем серверам — это нормально, если они перзистенты. Какая разница? Потом всё равно с высокой вероятностью все понадобятся.
Если не заботится об атомарности изменений — любой объект разумного размера можно положить в memcached просто через сериализацию.
Когда требуется атомарное изменение, списка, например, это уже становится довольно сложной задачей: можно использовать аналог блокировок (об этом будет позже в цикле статей) или другими подходами.
Если будет конкретный вопрос, постараюсь ответить.
Я написал выше, текущее состояние кода. Сейчас стыдно еще и смысла нет. Доведем/доработаем, подумаем и сделаем. В исходном коде нет тайны, наоборот были бы рады сторонним патчам.
В остальном согласен — когда нужна исключительно разделямая память и повышенная производительность, memcached не нужен. Пример такой задачи — разделямая память в сервере PostgreSQL/Oracle, которые работают в многопроцессном режиме.
Но статья про memcached, и он для случая вылезания из рамок одного сервера.
Distributed memory — это память, которая распределена на нескольких физических хостах, и к ней имеют прозрачный доступ процессы с разных хостов.
Что такое 'distributed' 'shared', я не знаю.
Memcached не является 'memory' в точном смысле этого слова, т. к. доступ не прямой к памяти, а через некоторый API. Это типичный сетевой сервис, на самом деле, который можно рассматривать как 'distributed memory'.
Писал определения по памяти из классических университетских курсов, но, на всякий случай, дополню себя ссылками: en.wikipedia.org/wiki/Distributed_memory и en.wikipedia.org/wiki/Shared_memory.