Как создавать и проверять распределенные системы?
Я работаю над проектом, который представляет собой комбинацию сервера приложений и базы данных объектов и в настоящее время работает на одиночный машина только. Некоторое время назад я читал статью, в которой описывается распределенная реляционная база данных, и получил некоторые идеи о том, как применять идеи в этой статье к моему проекту, так что я мог бы сделать версию с высокой степенью доступности, запущенную в кластере, используя общедоступную архитектуру.
Моя проблема в том, что у меня нет опыта проектирования распределенных систем и их протоколов - я не принимал продвинутые курсы CS о распределенных системах в университете. Поэтому я беспокоюсь о том, что могу разработать протокол, который не вызывает тупик, голод, разделить мозг и другие проблемы.
Вопрос: Где я могу найти хороший материал о проектировании распределенных систем? Какие существуют методы проверки правильности работы распределенного протокола? Рекомендуются рекомендации книг, академических статей и других.
Ответы
Ответ 1
Я многому научился, глядя на то, что опубликовано о действительно огромных веб-платформах, и особенно о том, как их системы эволюционировали со временем, чтобы удовлетворить их рост.
Вот несколько примеров, которые я нашел для понимания:
-
Архитектура eBay: Хорошая история их архитектуры и проблемы, которые у них были. Очевидно, что они не могут использовать много кеширования для аукционов и ставок, поэтому их история в этом отношении отличается от многих других. По состоянию на 2006 год они разворачивали 100 000 новых строк кода каждые две недели и могут откатывать текущее развертывание, если возникают проблемы.
-
Бумага в Файловой системе Google: Хороший анализ того, что им нужно, как они реализовали его и как он работает при производстве, Прочитав это, я счел менее страшным для того, чтобы самостоятельно построить части инфраструктуры, чтобы удовлетворить мои потребности, если это необходимо, и что такое решение может и, вероятно, должно быть довольно простым и прямым. В сети также есть много интересного (включая видео на YouTube) на BigTable и MapReduce, других важных частях архитектуры Google.
-
Внутри MySpace: Один из немногих действительно огромных сайтов построен на стеке Microsoft. Вы можете много узнать о том, что не делать с вашим уровнем данных.
Отличным началом для поиска гораздо больше ресурсов по этой теме является раздел Real Life Architectures на веб-сайте "Высокая масштабируемость". Например, они содержат хорошее резюме в архитектуре Amazons.
Ответ 2
Обучение распределенным вычислениям непросто. Его действительно очень обширная область, охватывающая области связи, безопасности, надежности, concurrency и т.д., Каждый из которых займет годы, чтобы освоить. Понимание, в конечном счете, придет через много чтения и практического опыта. Кажется, у вас есть сложный проект, поэтому у вас есть шанс:)
Две самые популярные книги по распределенным вычислениям, я считаю:
1) Распределенные системы: концепции и дизайн - Джордж Кулурис и др.
2) Распределенные системы: принципы и парадигмы - А. С. Таненбаум и М. Ван Стин
Обе эти книги дают очень хорошее представление о современных подходах (включая протоколы связи), которые используются для построения успешных распределенных систем. Я лично использовал последнее в основном, и я нашел его отличным текстом. Если вы считаете, что отзывы на Amazon не очень хорошие, то это потому, что большинство читателей сравнивают эту книгу с другими книгами, написанными A.S. Tanenbaum (кто ИМО является одним из лучших авторов в области компьютерных наук), которые откровенно лучше написаны.
PS: я действительно сомневаюсь в необходимости разработки и проверки нового протокола. Если вы работаете с серверами приложений и базами данных, то вам, вероятно, уже доступно.
Ответ 3
Мне понравилась книга Распределенные системы: принципы и парадигмы Эндрю С. Таненбаума и Маартен ван Стин.
Ответ 4
На более абстрактном и формальном уровне Коммуникационные и мобильные системы: Pi-Calculus Робин Милнер дает исчисление для проверки систем. Существуют варианты pi-исчисления для проверки протоколов, таких как SPI-calculus (страница википедии, которая исчезла с момента последнего просмотра), и implementations, некоторые из которых также являются инструментами проверки.
Ответ 5
Где я могу найти хороший материал о проектировании распределенных систем?
Я никогда не мог закончить знаменитую книгу из Нэнси Линч. Однако я считаю, что книгу из Sukumar Ghosh Распределенные системы: Алгоритмический подход гораздо легче читать, и при необходимости он указывает на оригинальные документы.
Тем не менее, правда, что я не читал книги из Gerard Tel и Никола Санторо. Возможно, их еще легче читать...
Какие существуют методы проверки правильности работы распределенного протокола?
Чтобы изучить возможности (а также, чтобы понять вопрос), я считаю, что полезно получить обзор возможных инструментов из книги Методы определения программного обеспечения.
Моим окончательным решением было узнать TLA+. Зачем? Даже если язык и инструменты выглядят лучше, я действительно решил попробовать TLA +, потому что парень позади него - Лесли Лампорт. То есть, не только видная фигура на распределенных системах, но и автор Latex!
Вы можете бесплатно получить книгу TLA + и несколько примеров.
Ответ 6
Одна хорошая книга - Birman Надежные распределенные системы, хотя у нее есть свои хулители.
Если вы хотите официально проверить свой протокол, вы можете посмотреть некоторые из методов в Lynch Distributed Algorithms.
Вероятно, какой-либо протокол, который вы пытаетесь реализовать, был разработан и проанализирован ранее. Я просто подключу свой блог, который охватывает, например, консенсусных алгоритмов.
Ответ 7
Есть много классических работ, написанных Лесли Лампортом:
(http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html) и Edsger Dijkstra
(http://www.cs.utexas.edu/users/EWD/)
для базы данных.
Основной поток - движение NoSQL, многие проекты появляются на рынке, включая CouchDb (couchdb.apache.org), MongoDB, Cassandra. Все они имеют обещание масштабируемости и управляемости (репликация, отказоустойчивость, высокая доступность).