Cегодня мы поговорим о компонентах для высокопроизводительной и масштабируемой архитектуре на основе сервера memcached, а именно — распределённой базе для хранения данных MemcacheDB и системы очередей сообщений MemcacheQ.
![](http://abrdev.com/wp-content/uploads/2008/10/intro.png)
Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.
Memcached давно известен как сервер кеширования данных, который используется на многих высоконагруженных проектах, включая Wikipedia и LiveJournal, и позволяет кешировать в памяти любые данные и быстро ими оперировать, при этом поддерживаются только самые простые операции, это уж явно не полноценная база данных. А использование в качестве хранилища данных памяти идеально для случая кеширования данных, но если речь заходит про надёжность или устойчивость к сбоям — здесь работа переложена на сам сервер и оборудование.
Вот для решения всех этих вопросов, для совмещения высокой скорости, простого интерфейса и принципов работы memcached, и надёжности обычных баз данных, и был разработан MemcacheDB. Это система распределённого хранения данных в виде пар ключ-значение, которая совместима с API memcached, а значит любой клиент прозрачно может работать как с кешем, так и с хранилищем данных, даже не замечая этого. Но, в отличии от кеша, данные в memcacheDB хранятся на диске — в качестве бекенда используется встраиваемая промышленная база BerkeleyDB и используются все возможности для обеспечения эффективности и надёжности хранения, в частности, транзакционность и реплицирование.
![](http://abrdev.com/wp-content/uploads/2008/10/berkeleydb.png)
По скорости доступа к данным memcacheDB стоит на уровне того же memcache и сравнимо с специализированными базами данных, например, CouchDB, а в цифрах это составляет десятки тысяч операций записи и чтения в секунду (а вот и бенчмарк, а также сравнение с CouchDB). Сами разработчики предупреждают, что memcacheDB никак не кеш, поэтому не стоит использовать его везде как замену для самого memcached, он просто реализует другую стратегию хранения данных с совместимым доступом, аналогично memcached.
Несмотря на самые простые операции с данными — запись, чтение, обновление и удаление, такого функционала очень часто хватает для большинства задач, где мы привыкли использовать обычные базы данных. Но если перенести часть операций на специализированные решения, это позволит существенно разгрузить основную базу для операций, где требуются уже серьёзные средства работы с данными. Например, поддерживается команда инкремента/декремента переменных, что позволит реализовать различные счётчики и статистику без обращения к базе, при этом система сможет обслуживать тысячи клиентов в реальном времени.
![](http://abrdev.com/wp-content/uploads/2008/10/img_1.png)
Развёртывается memcacheDB просто — устанавливаете и компилируете с исходников, устанавливаете базу данных (она не требует администрирования) и все. Настройте просто параметры доступа для клиентов — порт и несколько других параметров, влияющих на производительность, например, размер буфера данных, каталог для хранения базы данных, размер кеша в памяти. Не думайте, что все операции чтения идут с диска, раз система использует базу данных в виде файла на диске, конечно используется и кеширование, что позволяет сравниваться в скорости с оригинальным memcached, при этом обеспечивая ещё и надёжность хранения.
Самым интересным свойством memcacheDB является возможность работы на нескольких серверах, используя реплицирование для обмена данными и синхронизации баз данных. При этом memcacheDB может использовать несколько стратегий реплицирования, в зависимости от ваших потребностей, гарантирующих целостность данных или обеспечивающих скорость работы. Основная модель распределённой инфраструктуры, поддерживаемая системой — один мастер-сервер и несколько подчинённых slave-серверов, которые используются только для чтения данных.
В случае нескольких серверов, система может использовать следующие стратегии репликации:
![](http://abrdev.com/wp-content/uploads/2008/10/replica.png)
Пока необходимо, чтобы все сервера в группе использовали одну и ту же стратегию реплицирования, но я не уверен, что это касается именно сложных систем, где много групп — в конце концов можно настроить так, что запрос будет распределятся сначала по одной группе серверов с одной стратегией, а потом данные распределяются по другому алгоритму, при этом корневой сервер даже не подозревает об этом.
Отдельно поддерживается логгирование и бекап самих файлов базы данных, в том числе и горячий бекап, но это отдельный разговор и конкретика инсталляции и использования.
И так, у нас есть возможность организовать… такой себе сервис Amazone S3, при этом как угодно распределённый, быстрый и надёжный, с простым и понятным универсальным API. Применения такой системе есть множество, практически в каждом высоконагруженном проекте можно часть логики перенести с базы данных на такую систему хранения и получить высокую отказоустойчивость и обеспечить снятие нагрузки по множеству простых запросов с основной базы данных.
Второй проект, также основанный на коде memcached — memcacheQ. Это система очередей сообщений, которая имеет ещё более простой API и поддерживает только две команды, запись и чтение. Очередь сообщений это некоторый именованый стек, куда можно записать сообщения, а клиент, указывая имя очереди, в любой другой момент времени может получить все сообщения из очереди. Максимальный размер сообщения равен 64Кб, а сами данные хранятся в той самой базе данных BerkeleyDB, а значит обеспечивается те же условия сохранности данных, реплицирование и другие возможности. Такую систему можно использовать для построения систем общения между пользователей в рамках проекта, почтовых систем, чата и других аналогичных, где требуется такой функционал, умноженный на большую скорость и надёжность.
Эти два проекта, MemcacheDB и MemcacheQ являются достаточно простыми в плане внешнего интерфейса и, казалось бы, ограниченные в возможностях, но вместе с этим позволяют строить на своей основе очень мощные и высоконагруженные проекты, если вы будете учитывать их возможности ещё на этапе проектирования. Для многих проектов это позволит отказаться или сократить нагрузку на дорогие ресурсы в виде базы данных и обеспечить высокую отказоустойчивость и гибкость.
![](http://abrdev.com/wp-content/uploads/2008/10/intro.png)
Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.
Memcached давно известен как сервер кеширования данных, который используется на многих высоконагруженных проектах, включая Wikipedia и LiveJournal, и позволяет кешировать в памяти любые данные и быстро ими оперировать, при этом поддерживаются только самые простые операции, это уж явно не полноценная база данных. А использование в качестве хранилища данных памяти идеально для случая кеширования данных, но если речь заходит про надёжность или устойчивость к сбоям — здесь работа переложена на сам сервер и оборудование.
Вот для решения всех этих вопросов, для совмещения высокой скорости, простого интерфейса и принципов работы memcached, и надёжности обычных баз данных, и был разработан MemcacheDB. Это система распределённого хранения данных в виде пар ключ-значение, которая совместима с API memcached, а значит любой клиент прозрачно может работать как с кешем, так и с хранилищем данных, даже не замечая этого. Но, в отличии от кеша, данные в memcacheDB хранятся на диске — в качестве бекенда используется встраиваемая промышленная база BerkeleyDB и используются все возможности для обеспечения эффективности и надёжности хранения, в частности, транзакционность и реплицирование.
![](http://abrdev.com/wp-content/uploads/2008/10/berkeleydb.png)
По скорости доступа к данным memcacheDB стоит на уровне того же memcache и сравнимо с специализированными базами данных, например, CouchDB, а в цифрах это составляет десятки тысяч операций записи и чтения в секунду (а вот и бенчмарк, а также сравнение с CouchDB). Сами разработчики предупреждают, что memcacheDB никак не кеш, поэтому не стоит использовать его везде как замену для самого memcached, он просто реализует другую стратегию хранения данных с совместимым доступом, аналогично memcached.
Несмотря на самые простые операции с данными — запись, чтение, обновление и удаление, такого функционала очень часто хватает для большинства задач, где мы привыкли использовать обычные базы данных. Но если перенести часть операций на специализированные решения, это позволит существенно разгрузить основную базу для операций, где требуются уже серьёзные средства работы с данными. Например, поддерживается команда инкремента/декремента переменных, что позволит реализовать различные счётчики и статистику без обращения к базе, при этом система сможет обслуживать тысячи клиентов в реальном времени.
![](http://abrdev.com/wp-content/uploads/2008/10/img_1.png)
Развёртывается memcacheDB просто — устанавливаете и компилируете с исходников, устанавливаете базу данных (она не требует администрирования) и все. Настройте просто параметры доступа для клиентов — порт и несколько других параметров, влияющих на производительность, например, размер буфера данных, каталог для хранения базы данных, размер кеша в памяти. Не думайте, что все операции чтения идут с диска, раз система использует базу данных в виде файла на диске, конечно используется и кеширование, что позволяет сравниваться в скорости с оригинальным memcached, при этом обеспечивая ещё и надёжность хранения.
Самым интересным свойством memcacheDB является возможность работы на нескольких серверах, используя реплицирование для обмена данными и синхронизации баз данных. При этом memcacheDB может использовать несколько стратегий реплицирования, в зависимости от ваших потребностей, гарантирующих целостность данных или обеспечивающих скорость работы. Основная модель распределённой инфраструктуры, поддерживаемая системой — один мастер-сервер и несколько подчинённых slave-серверов, которые используются только для чтения данных.
В случае нескольких серверов, система может использовать следующие стратегии репликации:
- DB_REPMGR_ACKS_ALL — мастер-сервер ожидает подтверждения о успешной записи данных от всех остальных серверов;
- DB_REPMGR_ACKS_ALL_PEERS — мастер ожидает ответа от всех slave-серверов, которые являются, в свою очередь, мастер-серверами для своих групп (многоуровневая система);
- DB_REPMGR_ACKS_NONE — не ожидаем никаких подтверждений от других серверов. Самая большая скорость, но нет гарантий, что копии данных есть на других серверах, кроме мастера.
- DB_REPMGR_ACKS_ONE — ожидаем подтверждения хоть бы одного из серверов;
- DB_REPMGR_ACKS_ONE_PEER — так же, как в предыдущем случае, но подтверждение ожидается от сервера, который в свою очередь, является мастер-сервером для своей группы.
- DB_REPMGR_ACKS_QUORUM — ожидаем подтверждения от некоторого минимального числа серверов, которые гарантируют целостность данных и являются также мастер-серверами для своих групп. Эта стратегия используется по умолчанию.
![](http://abrdev.com/wp-content/uploads/2008/10/replica.png)
Пока необходимо, чтобы все сервера в группе использовали одну и ту же стратегию реплицирования, но я не уверен, что это касается именно сложных систем, где много групп — в конце концов можно настроить так, что запрос будет распределятся сначала по одной группе серверов с одной стратегией, а потом данные распределяются по другому алгоритму, при этом корневой сервер даже не подозревает об этом.
Отдельно поддерживается логгирование и бекап самих файлов базы данных, в том числе и горячий бекап, но это отдельный разговор и конкретика инсталляции и использования.
И так, у нас есть возможность организовать… такой себе сервис Amazone S3, при этом как угодно распределённый, быстрый и надёжный, с простым и понятным универсальным API. Применения такой системе есть множество, практически в каждом высоконагруженном проекте можно часть логики перенести с базы данных на такую систему хранения и получить высокую отказоустойчивость и обеспечить снятие нагрузки по множеству простых запросов с основной базы данных.
Второй проект, также основанный на коде memcached — memcacheQ. Это система очередей сообщений, которая имеет ещё более простой API и поддерживает только две команды, запись и чтение. Очередь сообщений это некоторый именованый стек, куда можно записать сообщения, а клиент, указывая имя очереди, в любой другой момент времени может получить все сообщения из очереди. Максимальный размер сообщения равен 64Кб, а сами данные хранятся в той самой базе данных BerkeleyDB, а значит обеспечивается те же условия сохранности данных, реплицирование и другие возможности. Такую систему можно использовать для построения систем общения между пользователей в рамках проекта, почтовых систем, чата и других аналогичных, где требуется такой функционал, умноженный на большую скорость и надёжность.
Эти два проекта, MemcacheDB и MemcacheQ являются достаточно простыми в плане внешнего интерфейса и, казалось бы, ограниченные в возможностях, но вместе с этим позволяют строить на своей основе очень мощные и высоконагруженные проекты, если вы будете учитывать их возможности ещё на этапе проектирования. Для многих проектов это позволит отказаться или сократить нагрузку на дорогие ресурсы в виде базы данных и обеспечить высокую отказоустойчивость и гибкость.