AOSA 💃 bookköd

Welcome to the aosabook wiki!

https://barionleg.github.io/aosabook/src/v1/web/fr/riak.html

  | Архитектураприложений с открытым исходным кодомЭми Браун и Грег Уилсон (ред.)ISBN 978-1-257-63801-7Лицензия / Купить / Новости / Внести вклад / Часто задаваемые вопросы -- | --

Глава 15. Риак и Эрланг/OTP

Франческо Чезарини , Энди Гросс и Джастин Шихи

Riak — это распределенная отказоустойчивая база данных с открытым исходным кодом, которая демонстрирует, как создавать высоконагруженные системы с использованием Erlang/OTP. Во многом благодаря возможностям Erlang для массово масштабируемых систем, Riak предлагает функции, не характерные для баз данных, такие как высокая доступность с линейной масштабируемостью, как с точки зрения емкости, так и пропускной способности.

Пара Erlang/OTP обеспечивает идеальную платформу для разработки таких систем, как Riak, поскольку она изначально обеспечивает распределенную связь между узлами, очереди сообщений, детекторы ошибок и абстракцию систем клиент-сервер. Кроме того, наиболее часто используемые шаблоны в Erlang реализованы в библиотеках, обычно называемых «OTP Behaviors». Они содержат общий код для управления параллелизмом и обработки ошибок, что упрощает параллельное программирование и предотвращает попадание разработчика в ловушки, присущие этому типу программирования. «Поведения» отслеживаются супервизорами, которые сами по себе являются «Поведениями», сгруппированными в деревьях надзора. Дерево контроля упаковывается в приложение и затем является блоком программы Erlang.

Полная система Erlang, такая как Riak, представляет собой набор слабосвязанных приложений, которые взаимодействуют друг с другом. Некоторые приложения написаны разработчиком, некоторые входят в стандартную комплектацию Erlang/OTP, а другие могут быть компонентами с открытым исходным кодом. Они загружаются последовательно и запускаются сценарием запуска, созданным на основе списка приложений и их версий.

Что различается между системами, так это запускаемые приложения, интегрированные в выпуск. В стандартном дистрибутиве Erlang файлы запуска запускают приложения Kernel и StdLib (стандартная библиотека). После установки также запускается приложение SASL (Библиотека поддержки системной архитектуры). SASL содержит инструменты выпуска и обновления, а также функции ведения журналов. Riak ведет себя следующим образом, запуская специфичные для Riak приложения и их зависимости, в том числе Kernel , StdLib и SASL . Полная, готовая к использованию сборка Riak использует эти стандартные элементы дистрибутива Erlang/OTP и запускает их одновременно при riak startвызове команды в командной строке. Riak состоит из нескольких сложных приложений, и эту главу не следует рассматривать как полное руководство. Но в качестве введения в OTP, где используются примеры из исходного кода Riak. Рисунки и примеры упрощены для целей демонстрации.

15.1. Краткое введение в Erlang

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

-модуль(факториал). 
-экспорт([фак/1]). 
факт(0) -> 1; 
fac(N), когда N>0 -> 
   Prev = fac(N-1), 
   N*Prev.

В этом примере первое предложение определяет факториал 0, второе — факториал положительных чисел. Тело каждого предложения представляет собой последовательность выражений, а последнее выражение является результатом этого предложения. Вызов этой функции с отрицательным числом приведет к ошибке во время выполнения, поскольку ни одно предложение не соответствует. Необработка этого случая является примером «незащитного» программирования, практика, поощряемая в Erlang.

В модуле функции вызываются обычным способом; В противном случае имя модуля должно иметь префикс, например factorial:fac(3). Можно определить функции с тем же именем, но с разным количеством аргументов, называемым arity . В директиве экспорта модуля factorialфункция facарности 1 объявлена ​​как fac/1.

Erlang поддерживает кортежи (также называемые «типами продуктов») и списки. Кортежи также заключаются в фигурные скобки {ok,37}. Доступ к элементам кортежей осуществляется по их позиции. Записи — это еще один тип данных; они позволяют нам хранить фиксированное количество элементов, к которым осуществляется доступ и манипулирование ими по имени. Мы определяем запись следующим образом: -record(state, {id, msg_list=[]}). чтобы создать ее экземпляр, мы используем выражение Var = #state{id=1}и извлекаем его содержимое, используя: Var#state.id. Для переменного количества элементов мы используем списки, определенные в квадратных скобках: {[}23,34{]}. Обозначение {[}X|Xs{]}указывает на непустой список с началом («головой») Xи концом («хвостом») хвостом Xs. Идентификаторы, начинающиеся со строчной буквы, обозначают атомы , которые не имеют значения; Элемент okв кортеже {ok,37}является примером атома. Атомы часто используются для дифференциации результатов функции: как и результаты ok, могут быть результаты формы {error, "Error String"}.

Процессы в системах Erlang выполняются одновременно в выделенном пространстве памяти и взаимодействуют друг с другом посредством передачи сообщений. Процессы можно использовать для самых разных приложений: от шлюзов баз данных до обработчиков протоколов и управления трассировками журналов других процессов. Хотя эти процессы обрабатывают разные типы запросов, в способах обработки этих запросов есть сходства.

Поскольку процессы существуют только внутри виртуальной машины (ВМ), одна виртуальная машина может одновременно запускать миллионы процессов, и эту возможность широко использует Riak. Например, каждый запрос к базе данных — чтение, запись и удаление — моделируется как отдельный процесс, и такой подход был бы невозможен в большинстве реализаций потоков на уровне ОС.

Процессы идентифицируются идентификаторами процессов, называемыми PID, но их также можно зарегистрировать под псевдонимом; псевдонимы следует использовать только для долгоживущих «статических» процессов. Регистрация процесса под собственным псевдонимом позволяет другим процессам передавать ему сообщения, даже не зная его PID. Процессы создаются с помощью встроенной функции (BIF) spawn(Module, Function, Arguments). BIF — это функции, интегрированные в виртуальную машину для достижения того, что было бы невозможно или слишком медленно выполнить в «чистом Эрланге». BIF spawn/3принимает в качестве параметров a Module, a Functionи список Arguments. Этот вызов возвращает PID только что созданного процесса («порожденного») и в качестве побочного эффекта создает новый процесс, который начинается с выполнения этой функции модуля с аргументами, описанными выше.

Сообщение Msgотправляется PID-процессу: Pid с помощью Pid ! Msg. Процесс может определить свой собственный PID, вызвав BIF self, а затем передать его другим процессам, чтобы они могли с ним взаимодействовать. Предположим, процесс ожидает получения сообщений вида {ok, N}и {error, Reason}. Для их обработки он использует следующий код:

получить 
   {ок, N} -> 
      N+1; 
   {ошибка, _} -> 
      0 
конец

Результатом является число, определяемое предложением сопоставления с образцом. Если значение переменной не требуется для сопоставления с образцом, в качестве подстановочного знака можно использовать символ подчеркивания, как показано выше.

Передача сообщений между процессами является асинхронной, и сообщения, полученные процессом, помещаются в почтовый ящик процесса в порядке поступления. Теперь предположим, что приведенное receiveвыше выражение выполнено: если первый элемент в почтовом ящике равен {ok, N}, {error, Reason}будет возвращен соответствующий результат. Если первое сообщение в почтовом ящике не в этой форме, оно будет храниться в почтовом ящике, а второе будет обработано таким же образом. Если ни одно сообщение не соответствует, блок приема будет ждать, пока не будет получено подходящее сообщение.

Процессы завершаются по двум причинам. Если больше нет кода для выполнения, говорят, что они завершаются по обычной причине . Если процесс обнаруживает ошибку во время выполнения, считается, что он завершился по ненормальной причине . Завершающий процесс не повлияет на другие процессы, если они не связаны друг с другом. Процессы могут связываться друг с другом, вызывая функцию BIF link(Pid)или вызывая spawn_link(Module, Function, Arguments). Если процесс завершается, он отправляет сигнал EXIT процессам, связанным с ним. Если причина завершения ненормальная, процесс завершается сам, распространяя сигнал EXIT. Вызывая функцию BIF process_flag(trap_exit, true), процессы могут получать сигналы EXIT в виде сообщений Erlang в свой почтовый ящик и обрабатывать их вместо завершения.

Riak использует сигналы EXIT для мониторинга работоспособности процессов, выполняющих некритическую работу, инициированную конечными автоматами, обрабатывающими запросы. Когда эти процессы завершаются ненормально, сигнал EXIT позволяет либо игнорировать ошибку, либо перезапустить процесс.

15.2. Скелеты процессов

Ранее мы представили идею о том, что процессы следуют общему шаблону независимо от цели, для которой они созданы. Для начала процесс должен быть «порожден» и, при необходимости, зарегистрирован его псевдоним. Первым действием вновь созданного процесса является инициализация данных цикла процесса. Эти данные часто являются результатом аргументов, передаваемых функции BIF spawn во время инициализации процесса. Его данные хранятся в переменной, которая считается состоянием процесса. Состояние, часто хранящееся в записи, передается функции приема-оценки, запускающей цикл, который принимает сообщение, обрабатывает его, обновляет состояние и возвращает его в качестве аргумента — «хвостовой рекурсивный» вызов. Если одно из обрабатываемых им сообщений является сообщением «стоп», процесс выполнит соответствующую очистку и завершится.

Это повторяющаяся тема процессов, независимо от поставленной перед ними задачи. Имея это в виду, давайте посмотрим на различия между процессами, которые соответствуют этому шаблону:

• Аргументы, передаваемые функции BIF, spawnбудут отличаться от одного процесса к другому.
• Вам необходимо решить, следует ли регистрировать процесс под псевдонимом, и если да, то какой псевдоним использовать.
• В функции инициализации состояния процесса предпринимаемые действия будут различаться в зависимости от задач, которые будет выполнять процесс.
• Состояние системы в каждом случае представлено данными цикла, однако содержимое данных будет различаться в зависимости от процесса.
• При выполнении цикла получения-оценки процессы будут получать разные сообщения и обрабатывать их по-разному.
• Наконец, когда процесс выключен, очистка будет варьироваться от одного процесса к другому.

Таким образом, даже если существует скелет родовых действий, эти действия дополняются конкретными, непосредственно связанными с задачами, поставленными перед каждым процессом. Используя этот скелет в качестве шаблона, программисты могут создавать процессы Erlang, которые действуют как серверы, конечные автоматы, обработчики событий и супервизоры. Но вместо того, чтобы каждый раз переопределять эти шаблоны, они были разработаны как модули и названы «поведениями». Они являются частью промежуточной платформы OTP.

15.3. Поведение OTP: «Поведение»

Основная команда разработчиков Riak разбросана примерно по дюжине географических регионов. Без очень тонкой координации и шаблонов для работы результат будет состоять из различных реализаций клиент/сервер, не обрабатывающих крайние особые случаи и связанные с ними ошибки конкуренции. Вероятно, не будет единого способа обработки инцидентов на клиенте и сервере или обеспечения того, чтобы ответ на запрос действительно был ответом, а не просто сообщением, соответствующим внутренним сообщениям протокола.

OTP — это набор библиотек Erlang и принципов проектирования, предоставляющий готовые к использованию инструменты для разработки надежных систем. Большинство этих шаблонов и библиотек предоставляются в форме «поведений».

Поведение OTP решает эти проблемы, предоставляя модули, реализующие наиболее распространенные шаблоны параллелизма. Под прикрытием, без ведома программиста, модули обеспечивают надежную обработку ошибок и особых случаев. В результате поведение OTP обеспечивает набор стандартизированных блоков для проектирования и построения промышленных систем качества.

15.3.1. Введение

Поведения OTP предоставляются в виде модулей в приложении, stdlib которое является частью дистрибутива Erlang/OTP. Конкретный код, написанный программистом, помещается в отдельный модуль и вызывается с помощью набора предопределенных функций обратного вызова для каждого из вариантов поведения. Этот «модуль обратного вызова» будет содержать весь конкретный код, необходимый для достижения желаемой функциональности.

Поведение OTP включает в себя рабочие процессы, которые фактически выполняют вычисления, и супервизоры, чья задача — контролировать работников и других супервизоров. Поведение работников, часто схематически изображаемое в виде кружков, включает в себя серверы, обработчики событий и конечные автоматы. Руководители, представленные в виде прямоугольников, контролируют своих детей, как рабочих, так и руководителей, создавая дерево надзора.

Рисунок 15.1: Дерево надзора OTP Riak

Деревья контроля сгруппированы в поведение, называемое приложением. Приложения OTP — это не только фундаментальные блоки систем Erlang, но и способ упаковки повторно используемых компонентов. Системы промышленного уровня, такие как Riak, состоят из набора слабосвязанных и потенциально распределенных приложений. Некоторые из этих приложений являются частью стандартного дистрибутива Erlang, а другие — частями, специально реализующими функциональные возможности Riak.

Примеры приложений OTP включают Corba ORB или агент простого протокола сетевого управления (SNMP). Приложение OTP — это повторно используемый компонент, который группирует модули с супервизорами и рабочими процессами. С этого момента, когда будет использоваться термин «приложение», он будет означать приложение OTP.

Модули поведения содержат весь общий код для каждого типа поведения. Хотя можно реализовать свой собственный модуль поведения, это требуется делать очень редко, поскольку те, которые предоставляются дистрибутивом Erlang/OTP, будут соответствовать большинству шаблонов, которые вы будете использовать в своем коде. Общая функциональность, предоставляемая в модуле поведения, включает следующие операции:

• создание и при необходимости запись процесса;
• отправка и получение клиентских сообщений посредством синхронных или асинхронных вызовов, включая определение внутреннего протокола сообщений;
• хранение данных цикла и управление циклом процесса; И
• остановка процесса.

Данные цикла — это переменная, которая будет содержать данные, которые потребуются поведению между вызовами. После вызова возвращается обновленная версия данных. Эти обновленные данные, часто называемые новыми данными в цикле, будут переданы в качестве аргумента при следующем вызове. Данные в цикле часто называют состоянием поведения.

Функциональность, которая должна быть включена в модуль общего приложения серверного типа для реализации конкретного поведения, включает в себя:

• инициализация данных цикла процесса и, если процесс зарегистрирован, имя процесса.
• конкретное управление клиентскими запросами и, если синхронно, ответ, отправляемый обратно клиенту.
• управление и обновление данных в цикле процесса между различными запросами.
• очистка данных цикла перед завершением процесса.

15.3.2. Общие серверы

Общие серверы, реализующие поведение клиент/сервер, определяются в поведении, gen_serverкоторое является частью приложения stdlib(Стандартная библиотека). Для объяснения универсальных серверов мы будем использовать модуль riak_core_node_watcher.erlприложения riak_core. Это сервер, который отслеживает и сообщает о доступности подсервисов и узлов в кластере Riak. Заголовки и директивы модулей следующие:

-модуль(riak_core_node_watcher). 
-поведение (gen_server). 
%% API 
-export([start_link/0,service_up/2,service_down/1,node_up/0,node_down/0,services/0, 
         Services/1,nodes/1,avsn/0]). 
%% обратных вызовов gen_server 
-export([init/1,handle_call/3,handle_cast/2,handle_info/2,terminate/2, code_change/3]). 

-record(state, {status=up, Services=[], Peers=[], avsn=0, bcast_tref, 
                bcast_mod={gen_server, abcast}}).

Общий сервер можно легко распознать по директиве. -behavior(gen_server). Эта директива используется компилятором для обеспечения правильного экспорта всех функций обратного вызова. Запись «state» будет использоваться для данных цикла сервера.

15.3.3. Запуск сервера

В поведении gen_serverвместо использования BIF spawnи функций spawn_linkвы будете использовать функции gen_server:startи gen_server:start_link. Основное различие между spawnи startзаключается в синхронном характере их вызова. Использование startвместо spawnделает запуск рабочего процесса более детерминированным и позволяет избежать непредвиденных условий гонки, поскольку вызов не вернет PID рабочего процесса до тех пор, пока он не будет инициализирован. Вы можете вызвать эту функцию, используя одну из следующих сигнатур:

gen_server:start_link(ServerName, CallbackModule, Arguments, Options) 
gen_server:start_link(CallbackModule, Arguments, Options)

ServerName— это кортеж в форме {local, Name}или {global, Name}, затем указывается, что Nameэто глобальный или локальный псевдоним процесса, если он должен быть зарегистрирован. Глобальные имена обеспечивают прозрачный доступ к серверам в кластере распределенных узлов Erlang. Если вы не хотите регистрировать процесс и вместо этого ссылаетесь на него, используя его PID, вам следует опустить аргумент match, используя вместо этого функцию start_link/3или start/3. CallbackModule— это имя модуля, в котором размещены определенные функции обратного вызова, Argumentsявляется действительным «термином» Erlang, который передается функции обратного вызова init/1, а также Optionsявляется списком, который позволяет вам указать параметры управления памятью, такие как fullsweep_afterи heapsize, а также трассировку и параметры отладки.

В нашем примере мы вызываем start_link/4, регистрируя процесс с тем же именем, что и модуль обратного вызова, с помощью макроса ?MODULE. Этот макрос транслируется в имя модуля препроцессором при компиляции кода. Всегда полезно называть свое поведение псевдонимом, совпадающим с именем модуля, в котором оно реализовано. Мы не передаем аргументы, просто предоставляя пустой список. Список опций также пуст:

start_link() -> 
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

Очевидная разница между функциями start_linkи startзаключается в том, что start_linkпроцесс связывается с его родителем, чаще всего с супервизором, а start это не так. Это заслуживает указания, поскольку ответственность за привязку к супервизору лежит на поведении OTP. Функции startчасто используются при тестировании поведения оболочки, поэтому ошибка ввода, вызывающая сбой процесса оболочки, не повлияет на поведение. Все формы функций startи start_linkвозвратов {ok, Pid}.

Функции startи start_linkсоздадут новый процесс, который вызовет функцию обратного вызова init(Arguments)с предоставленными CallbackModuleпараметрами Arguments. Функция initдолжна инициализировать LoopDataсервер и должна вернуть кортеж в форме {ok, LoopData}. LoopData содержит первый экземпляр данных цикла, которые будут передаваться между функциями обратного вызова. Если вы хотите сохранить некоторые аргументы, которые вы передали функции init, вы можете сделать это в переменной LoopData. LoopDataв сервере мониторинга узлов Riak — это результат вызова функции schedule_broadcast/1с записью типа, stateполя которой имеют значения по умолчанию:

init([]) -> 

    %% Следите за событиями включения/выключения узла 
    net_kernel:monitor_nodes(true), 

    %% Настройка таблицы ETS для отслеживания состояния узла 
    ets:new(?MODULE, [protected,named_table]), 

    {ok, Schedule_broadcast (#состояние{})}.

Хотя процесс-супервизор может вызвать функцию start_link/4, функцию вызывает другой процесс init/1 : тот, который только что был создан. Поскольку целью этого сервера является обнаружение, запись и сообщение о доступности подсервисов Riak, инициализация запрашивает среду выполнения Erlang уведомлять ее о таких событиях и состоит из таблицы для хранения этой информации. Это необходимо сделать при инициализации, поскольку вызовы к серверу завершится неудачно, если эта структура еще не существует. Делайте только то, что необходимо, и минимизируйте операции в вашей функции init, поскольку вызов initвыполняется синхронно, что предотвращает запуск всех других процессов до тех пор, пока функция не вернет свой результат.

15.3.4. Передача сообщений

Если вы хотите отправить синхронное сообщение на свой сервер, вы будете использовать функцию gen_server:call/2. Асинхронные вызовы выполняются с помощью функции gen_server:cast/2. Давайте возьмем две функции из Service API Riak; остальную часть кода мы предоставим позже. Они вызываются клиентскими процессами и приводят к отправке синхронного сообщения серверному процессу, зарегистрированному с тем же именем, что и модуль. Обратите внимание, что проверка данных, отправляемых на сервер, должна выполняться на стороне клиента. Если клиент отправит неверную информацию, сервер отключится.

service_up(Id, Pid) -> 
    gen_server:call(?MODULE, {service_up, Id, Pid}). 

service_down(Id) -> 
    gen_server:call(?MODULE, {service_down, Id}).

Как только сообщения получены, процесс gen_serverвызывает функцию обратного вызова, handle_call/3обрабатывающую сообщения в том же порядке, в котором они были отправлены:

handle_call({service_up, Id, Pid}, _From, State) -> 
    %% Обновить набор активных сервисов локально 
    Services = ordsets:add_element(Id, State#state.services), 
    S2 = State#state { Services = Services } , 

    %% Удалите все существующие mrefs для этой службы 
    delete_service_mref(Id), 

    %% Настройте монитор для Pid, ​​представляющего эту службу 
    Mref = erlang:monitor(process, Pid), 
    erlang:put(Mref, Id), 
    erlang:put( Id, Mref), 

    %% Обновите нашу локальную таблицу ETS и транслируйте 
    S3 = local_update(S2), 
    {reply, ok, update_avsn(S3)}; 

handle_call({service_down, Id}, _From, State) -> 
    %% Обновить набор активных сервисов локально 
    Services = ordsets:del_element(Id, State#state.services), 
    S2 = State#state { Services = Services }, 

    % % Удалить все существующие mrefs для этой службы 
    delete_service_mref(Id), 

    %% Обновить локальную таблицу ETS и транслировать 
    S3 = local_update(S2), 
    {reply, ok, update_avsn(S3)};

Обратите внимание на возвращаемое значение функции обратного вызова. Кортеж содержит управляющий атом reply, сообщающий универсальному коду, что gen_serverвторой элемент кортежа (который в обоих случаях является атомом ok) является ответом, возвращаемым клиенту. Третий элемент кортежа — new State, который в новой итерации сервера передается в качестве третьего аргумента функции handle_call/3; в обоих случаях состояние обновляется, чтобы отразить новый набор доступных услуг. Аргумент _From представляет собой кортеж, содержащий уникальную ссылку на сообщение и PID клиентского процесса. Весь кортеж используется в библиотечных функциях, которые мы не будем обсуждать в этой главе. В большинстве случаев вам это не понадобится.

Модуль gen_serverсодержит собственные механизмы и ограждения, которые проходят под поверхностью. Если ваш клиент отправляет синхронное сообщение на ваш сервер, а вы не получаете ответа в течение пяти секунд, процесс выполнения функции call/2завершается. Вы можете переопределить это, используя gen_server:call(Name, Message, Timeout)значение Timeoutв миллисекундах или атом infinity.

Первоначально механизм тайм-аута был введен для защиты от взаимоблокировок, гарантируя, что серверы, которые случайно звонят друг другу, по умолчанию завершаются после тайм-аута. Затем отслеживается отчет о сбое, что позволяет отладить и исправить эту ошибку. Большинство приложений будут нормально работать с пятисекундным таймаутом, но при очень больших нагрузках вам может потребоваться более тонкая настройка этого значения и, возможно, даже его использование infinity; этот выбор зависит от приложения. Весь критический код в Erlang/OTP использует infinity. В коде Riak, в зависимости от местоположения, для таймаута используются разные значения: infinityчасто используется между связанными внутренними компонентами, а значение Timeout, заданное пользовательским параметром, используется в тех случаях, когда клиентское приложение, взаимодействующее с Riak, указало, что операция имеет тайм-аут.

При использовании функции gen_server:call/2другие меры защиты обрабатывают случай, когда сообщение отправляется на несуществующий сервер, и случай, когда сервер выходит из строя перед отправкой обратно своего ответа. В обоих случаях вызывающий процесс остановится. В «чистом» Эрланге отправка сообщения, которое никогда не обрабатывается (сопоставление с образцом) в предложении приема, является ошибкой, которая может вызвать утечку памяти. Чтобы преодолеть эту проблему, Riak использует две разные стратегии, каждая из которых использует «объемные» предложения сопоставления. В местах, где сообщение может быть отправлено пользователем, нераспознанное сообщение может быть незаметно забыто. Если такое сообщение может прийти только от внутренних компонентов Riak, этот случай считается ошибкой, которая затем вызывает внутренний отчет о сбое, предупреждающий об ошибке, и перезагрузку рабочего процесса, который его получил.

Передача асинхронных сообщений работает таким же образом. Сообщения отправляются асинхронно на общий сервер и обрабатываются функцией обратного вызова handle_cast/2. Функция должна возвращать кортеж вида {reply, NewState}. Асинхронные вызовы используются, когда ответ сервера не требуется и существует небольшой риск создания большего количества сообщений, чем сервер может обработать. В тех случаях, когда ответ не обязателен, но мы хотим дождаться обработки сообщения, прежде чем повторно передавать новый запрос, мы будем использовать функцию gen_server:call/2, которая возвращает атом okобратно. Представьте себе процесс, который генерирует записи базы данных с большей скоростью, чем может потреблять Riak. Используя асинхронные вызовы, мы рискуем заполнить почтовый ящик процесса и, следовательно, использовать всю память узла Erlang. Для регулирования нагрузки Riak использует свойства сериализации сообщений синхронных вызовов gen_server, которые обрабатывают следующий запрос только после полной обработки предыдущего. Этот подход позволяет избежать добавления кода управления перегрузкой: помимо обеспечения параллелизма, процессы gen_serverмогут использоваться для введения точек сериализации.

15.3.5. Выключение сервера

Как остановить сервер? В функциях обратного вызова handle_call/3и handle_cast/2вместо возврата {reply, Reply, NewState}или {noreply, NewState}можно вернуть {stop, Reason, Reply, NewState}или соответственно {stop, Reason, NewState}. Что-то должно вызвать это возвращаемое значение, часто это сообщение о завершении работы, отправленное на сервер. Как только кортеж остановки, содержащий Reasonи получен State, общий код выполняет функцию обратного вызова terminate(Reason, State).

Эта функция terminate— лучшее место для вставки кода очистки сервера State и любых других постоянных данных, используемых системой. В нашем примере мы отправляем финальное сообщение нашим узлам, чтобы они знали, что этот монитор узла теперь остановлен. В этом примере переменная Stateсодержит запись с полями statusи peers :

завершения(_Reason, State) -> 
    %% Сообщите нашим узлам, что мы отключаем 
    широковещательную рассылку(State#state.peers, State#state {status = down }).

Использование функций обратного вызова поведения в качестве библиотечных функций и вызов их из других мест программы — очень плохая практика. Например, никогда не следует вызывать riak_core_node_watcher:init(Args)из другого модуля, чтобы получить исходное состояние данных цикла. Это необходимо сделать посредством синхронного вызова сервера. Вызовы функций обратного вызова должны исходить только из модулей библиотеки поведения, вызовы, возникающие в результате события в системе, и никогда непосредственно от пользователя.

15.4. Другое «поведение работников»

Большое количество других «поведений работников» может быть реализовано и реализовано на основе тех же идей.

15.4.1. Конечные автоматы

Конечные автоматы (FSM), реализованные в модуле поведения gen_fsm, являются важнейшим компонентом при реализации стеков протоколов в телекоммуникационных системах (область, для которой был изобретен Erlang). Состояния определяются как функции обратного вызова, названные в честь состояния и возвращающие кортеж, содержащий следующие Stateи обновленные данные цикла. Вы можете отправлять события в эти состояния синхронно или асинхронно. Модуль обратного вызова конечного автомата также должен экспортировать стандартные функции обратного вызова, а именно init, terminateи handle_info.

Очевидно, что конечные автоматы не являются специфичными для телекоммуникаций. В Riak они используются в обработчиках запросов. Когда клиент отправляет запрос типа get, putили delete, процесс, слушающий этот запрос, создаст новый процесс, реализующий gen_fsmсоответствующее поведение. Например, riak_kv_get_fsmотвечает за обработку запроса get, получение данных и возврат их клиентскому процессу. Процесс FSM проходит через разные состояния в зависимости от того, определяет ли он, у каких узлов запрашивать данные, отправляет ли он сообщения этим узлам и получает ли он данные в ответ.

15.4.2. Менеджеры мероприятий

Обработчики событий — это еще одно поведение, реализованное в модуле gen_event. Идея состоит в том, чтобы создать центральную точку, принимающую события определенного типа. События могут отправляться синхронно или асинхронно, и при их получении применяется заранее определенный набор действий. При получении события мы можем, например, отследить его в файле, отправить сигнал тревоги в виде SMS или объединить его в статистику. Каждое из этих действий определяется в отдельном модуле обратного вызова со своими собственными данными цикла, сохраняемыми между вызовами. Обработчики можно добавлять, удалять или обновлять для каждого обработчика событий. Итак, на практике для каждого обработчика событий может быть несколько модулей обратного вызова, и в разных обработчиках могут существовать разные экземпляры этих модулей. К обработчикам относятся процессы, получающие сигналы тревоги, отслеживаемые данные в реальном времени, события, связанные с событиями, или простые журналы.

В Riak одно из применений поведения gen_event — управление подписками на «кольцевые события», т. е. изменения членства в узлах или назначения разделов в кластере Riak. Процессы на узле Riak могут зарегистрировать функцию в экземпляре riak_core_ring_events, которая реализует данное поведение gen_event. Когда центральный процесс, управляющий кольцом этого узла, изменяет запись о членстве для всего кластера, он запускает событие, которое заставляет каждый модуль обратного вызова вызывать зарегистрированную функцию. Таким образом, различным частям Riak будет проще реагировать на изменения в любой из центральных структур данных Riak, не усложняя центральный менеджер этой структуры данных.

Наиболее распространенные модели конкуренции и общения управляются одним из трех основных типов поведения, которые мы только что представили: gen_server, gen_fsmи gen_event. Однако в больших системах со временем могут возникнуть шаблоны, специфичные для приложения, и потребовать создания нового поведения. Riak включает такое поведение, riak_core_vnodeкоторое формализует способ реализации виртуального узла. Виртуальные узлы — это основная абстракция хранилища в Riak, предоставляющая единый интерфейс от хранилища «ключ-значение» к соответствующим автоматам. Интерфейс модуля обратного вызова определяется с помощью функции behavior_info/1следующим образом:

Behavior_info(обратные вызовы) -> 
    [{init,1}, 
     {handle_command,3}, 
     {handoff_starting,2}, 
     {handoff_cancelled,1}, 
     {handoff_finished,2}, 
     {handle_handoff_command,3}, 
     {handle_handoff_data,2}, 
     { encode_handoff_item,2}, 
     {is_empty,1}, 
     {terminate,2}, 
     {delete,1}];

В этом примере показана behavior_info/1функция riak_core_vnode. Список кортежей {CallbackFunction, Arity} определяет контракт, который должен соблюдать модуль обратного вызова. Конкретные реализации виртуальных узлов должны экспортировать эти функции, иначе компилятор выдаст предупреждение. Реализовать собственное поведение OTP относительно просто. Помимо определения ваших функций обратного вызова, используя модули proc_libи sys модули, вы должны запускать их с определенными функциями, управлять системными сообщениями и отслеживать родительский процесс на случай, если он завершится.

15.5. Руководители

Задача супервизора поведения — следить за своими дочерними процессами и по заранее настроенным правилам выполнять необходимые действия при их завершении. Дети могут быть как другими руководителями, так и работниками процесса. Это позволяет коду Riak сосредоточиться на правильном случае, что позволяет супервизору обрабатывать ошибки программного обеспечения, поврежденные данные или системные ошибки единообразно во всей системе. В мире Erlang этот незащищенный подход к программированию часто называют стратегией «пусть произойдет сбой». Дочерние процессы, составляющие дерево контроля, могут включать как супервизоры, так и рабочие процессы. Рабочие процессы — это поведение OTP, включая gen_fsm, gen_serverи gen_event. Команда Риака, которой не нужно заниматься маргинальными делами, может работать с меньшей базой кода. Эту базу кода благодаря использованию поведений проще понять, поскольку она имеет дело только с конкретным кодом. Riak имеет супервизор высокого уровня, как и в большинстве приложений Erlang, а также супервизоры более низкого уровня для управления группами процессов по функциональности, такие как виртуальные узлы Riak, прослушиватели сокетов TCP и обработчики запросов-ответов.

15.5.1. Функции обратного вызова супервизора

Чтобы продемонстрировать, как реализован супервизор поведения, мы воспользуемся модулем riak_core_sup.erl. Этот основной супервизор является супервизором самого высокого уровня основного приложения Riak. Он запускает статический набор рабочих и супервизоров, а также динамическое количество рабочих, управляющих соединениями HTTP и HTTPS RESTful API узла, число, определенное в файлах конфигурации, специфичных для приложения узла. Подобно gen_servers, все модули обратного вызова супервизора должны включать директиву  -behavior(supervisor).. Они запускаются с помощью функций startили start_linkпринимают в качестве необязательных аргументов ServerName, the CallBackModuleи a Argument, которые будут переданы в функцию обратного вызова init/1.

Глядя на первые строки кода модуля riak_core_sup.erl, помимо директивы поведения и макроса, который мы опишем позже, мы можем увидеть функцию start_link/3:

-модуль(riak_core_sup). 
-поведение (руководитель). 
%% API 
-export([start_link/0]). 
%% Обратные вызовы супервизора 
-export([init/1]). 
-define(CHILD(I, Type), {I, {I, start_link, []}, постоянный, 5000, Тип, [I]}). 
start_link() -> 
    супервизор:start_link({local, ?MODULE}, ?MODULE, []).

Запуск супервизора вызовет создание («порождение») нового процесса и вызов функции обратного вызова init/1модуля обратного вызова riak_core_sup.erl. Это ServerNameкортеж в форме {local, Name}или {global, Name}, где Name— зарегистрированное имя супервизора. В нашем примере и зарегистрированное имя, и модуль — это атом riak_core_sup, взятый из макроса ?MODULE. Мы передаем пустой список в качестве аргумента init/1, который будет рассматриваться как нулевое значение. Эта функция initявляется единственной функцией обратного вызова супервизора. Он должен вернуть кортеж в формате:

{ок, {SupervisorSpecification, ChildSpecificationList}}

где SupervisorSpecification— кортеж из трех элементов {RestartStrategy, AllowedRestarts, MaxSeconds}, содержащий информацию о том, как обрабатывать сбои и перезапуски процессов. RestartStrategy— это один из трех параметров конфигурации, указывающий, как повлияют на «родственные» процессы в случае нештатного завершения работы:

• one_for_one: ни один из других процессов в дереве надзора не затрагивается.
• rest_for_one: Процессы, запущенные после завершения процесса, останавливаются и перезапускаются.
• one_for_all: Все процессы остановлены и перезапущены.

AllowedRestartsуказывает, сколько раз дочерние элементы супервизора могут завершить работу в интервале, MaxSeconds прежде чем супервизор завершит себя (и его дочерние элементы). Когда процесс завершается, он отправляет сигнал EXIT своему супервизору, который, в зависимости от стратегии перезапуска, соответствующим образом обрабатывает завершение работы. Супервизор завершает работу после достижения максимально разрешенного количества перезапусков и гарантирует, что циклические перезапуски и другие проблемы, не решенные на его уровне, позже перейдут на следующий уровень. Скорее всего, проблема в процессе в другом поддереве, что позволяет супервизору более высокого уровня закрыть контролирующее поддерево и переделать его.

Глядя на последнюю строку функции обратного вызова init/1модуля riak_core_sup.erl, мы можем заметить, что этот конкретный монитор имеет стратегию «один к одному», что означает, что процессы независимы друг от друга. Супервизор допустит максимум десять перезапусков, чтобы перезапустить себя.

ChildSpecificationListуказывает, каких дочерних элементов супервизор должен запускать и отслеживать, а также информацию о том, как его остановить и перезапустить. Он представлен списком кортежей в следующем виде:

{Id, {Модуль, Функция, Аргументы}, Перезапуск, Завершение работы, Тип, Список модулей}

Id— уникальный идентификатор данного супервизора. Кортеж Module, Functionи Argumentsпредставляет собой экспортированную функцию, которая запускает вызов start_linkфункции поведения, которая возвращает кортеж в форме {ok, Pid}. Стратегия Restartописывает, что должно произойти в зависимости от типа остановки процесса, который может быть:

• процессы transient, которые никогда не перезапускаются;
• процессы temporary, которые перезапускаются только в случае аварийного завершения работы; И
• процессы permanent, которые всегда перезапускаются независимо от того, является ли причина их остановки нормальной или ненормальной.

Shutdown— значение в миллисекундах, указывающее время, по истечении которого поведению разрешено выполнять функцию, terminateесли оно останавливается из-за перезапуска или завершения работы. Атом infinityтакже можно использовать, но для поведения, отличного от супервизоров, это настоятельно не рекомендуется. Typeявляется либо атомом workerв отношении универсальных серверов, обработчиков событий и конечных автоматов, либо атомом supervisor. Связанные со ModuleListсписком модулей, реализующих это поведение, они используются для управления и приостановки процессов во время процедур горячего обновления программного обеспечения. Только существующие или реализованные пользователем варианты поведения могут быть частью этого списка и, следовательно, включены в дерево контроля.

К настоящему моменту мы должны быть в состоянии описать стратегию перезагрузки, определяющую межпроцессные зависимости, пороги устойчивости к сбоям и процедуры эскалации на основе общей архитектуры. Мы также должны уметь понимать, что происходит в init/1примере функции модуля riak_core_sup.erl. Для начала давайте изучим макрос CHILD. Он создает спецификацию для одного дочернего процесса, используя имя модуля обратного вызова как Id, делая его постоянным и определяя 5-секундное время завершения. Потоки могут быть рабочими или супервайзерами. Давайте посмотрим на пример и посмотрим, что мы можем из него извлечь:

-define(CHILD(I, Type), {I, {I, start_link, []}, постоянный, 5000, Тип, [I]}). 

init([]) -> 
    RiakWebs = списки регистров: Flatten(riak_core_web:bindings(http), 
                                  riak_core_web:bindings(https)) of 
                   [] -> 
                       %% проверка старых настроек, если app.config 
                       %% не был обновлен 
                       riak_core_web:old_binding(); 
                   Привязка -> Конец 
                       привязки 
               , 

    Children = 
                 [?CHILD(riak_core_vnode_sup, супервизор), 
                  ?CHILD(riak_core_handoff_manager, рабочий), 
                  ?CHILD(riak_core_handoff_listener, рабочий), 
                  ?CHILD(riak_core_ring_events, рабочий), 
                  ?CHILD(riak_core_ring_manager, рабочий), ?CHILD(riak_core_ring_manager, рабочий), 
                  ? CHILD(riak_core_node_watcher_events, рабочий), 
                  ?CHILD(riak_core_node_watcher, рабочий), 
                  ?CHILD(riak_core_gossip, рабочий) | 
                  RiakWebs 
                 ], 
    {ok, {{one_for_one, 10, 10}, Дети}}.

Большинство из Childrenзапущенных этим супервизором статически определенных рабочих (или, в случае с vnode_supсупервизором). Исключением является часть RiakWebs, определение которой является динамическим и зависит от HTTP-части файла конфигурации Riak.

За исключением приложений библиотечного типа, все приложения OTP, включая приложения Riak, будут иметь собственное дерево контроля. В Riak в узле Erlang выполняются несколько приложений высокого уровня, например, riak_coreдля алгоритмов распределенных систем riak_kvдля семантики хранения ключей/значений, webmachineдля HTTP и многих других. Ниже мы видели расширенное дерево, riak_coreпредставляющее многоуровневый надзор, которым управляет Riak. Одним из основных преимуществ этой структуры является то, что работа подсистемы может быть прервана (из-за ошибки, проблемы окружающей среды или преднамеренного действия), а затем первоначально будет остановлено только это поддерево.

Супервизор перезапустит необходимые процессы, и вся система не будет затронута. На практике мы обнаружили, что эта операция корректна для Riak. Пользователь может придумать, как выключить виртуальный узел, но супервизор перезапустит его riak_core_vnode_sup. Если они успешно прервут последнее, супервизор riak_core перезапустит его, передав сообщение об отключении супервизору более высокого уровня. Этот механизм изоляции и восстановления инцидентов позволяет разработчикам Riak (и Erlang) довольно просто создавать отказоустойчивые системы.

Ценность этой модели мониторинга была продемонстрирована, когда промышленный пользователь создал экстремальную среду, чтобы определить, где произойдет сбой нескольких систем баз данных. Эта среда порождала гигантские пики нагрузки и условия, благоприятные для инцидентов. Они были сбиты с толку, обнаружив, что Риак просто не остановится даже в самых худших условиях. Точнее, конечно, они могли прерывать процессы или подсистемы по отдельности и разными способами, но супервайзеры очищали и перезапускали все необходимое для восстановления всей системы в рабочем состоянии.

15.5.2. Приложения

Поведение, applicationкоторое мы представили ранее, используется для упаковки модулей или ресурсов Erlang в повторно используемые компоненты. В OTP есть два типа приложений. Наиболее распространенная форма, называемая обычными приложениями, запускает управляющее дерево и все необходимые статические рабочие процессы. «Библиотечные» приложения, такие как «Стандартная библиотека», интегрированные в дистрибутив Erlang, содержат «библиотечные» модули, но не запускают дерево управления. Это не означает, что код не содержит процессов или деревьев супервизии. Это всего лишь означает, что они будут запущены как часть дерева, принадлежащего другому приложению.

Система Erlang будет состоять из набора слабо связанных приложений. Некоторые из них написаны разработчиками, другие доступны с открытым исходным кодом, а третьи являются неотъемлемой частью дистрибутива Erlang/OTP. Система времени выполнения Erlang и ее инструменты одинаково обрабатывают все приложения, независимо от того, являются ли они частью дистрибутива Erlang или нет.

15.6. Репликация и связь в Riak

Riak был разработан для обеспечения исключительной надежности и доступности в больших масштабах и был вдохновлен системой хранения данных Dynamo от Amazon [ DHJ+07 ]. Архитектуры Dynamo и Riak сочетают в себе аспекты как распределенных хеш-таблиц (DHT), так и традиционных баз данных. Два ключевых метода, которые используют Riak и Dynamo, — это последовательное хеширование для размещения реплик и протокол сплетен для обмена общим состоянием.

Согласованное хеширование требует, чтобы все узлы в системе знали друг о друге и знали, какими разделами владеет каждый узел. Эти данные о назначении можно хранить в файле конфигурации с централизованным управлением, но в больших конфигурациях это становится чрезвычайно сложно. Другой альтернативой является использование центрального сервера конфигурации, но это создает единую точку отказа в системе. Вместо этого Riak использует протокол сплетен для распространения данных о членстве в кластере и владельце разделов по всей системе.

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

При запуске кластера Riak все узлы должны быть настроены с одинаковым количеством разделов. Затем кольцо согласованного хеширования делится на количество разделов, и каждый интервал сохраняется локально как {HashRange, Owner}пара. Первый узел кластера просто заявляет права на все разделы. Когда новый узел присоединяется к кластеру, он обращается к существующему узлу за списком {HashRange, Owner} одноранговых узлов. Затем он запрашивает пары (количество разделов)/(количество узлов), обновляя свое локальное состояние, чтобы отразить новое владение. Обновленная информация о владельце затем передается одноранговому узлу. Это обновленное состояние затем распространилось по всему кластеру с использованием описанного выше алгоритма.

Используя протокол сплетен, Riak избегает создания единой точки отказа в виде централизованного сервера конфигурации, освобождая системных операторов от необходимости поддерживать критические данные конфигурации кластера. Любой узел может затем использовать полученные данные о назначении разделов в системе для маршрутизации запросов. При совместном использовании протокол Gossip и последовательное хеширование позволяют Riak функционировать как действительно децентрализованная система, что имеет важные последствия для развертывания и эксплуатации крупномасштабных систем.

15.7. Выводы и извлеченные уроки

Большинство программистов считают, что меньшие и простые базы кода не только легче поддерживать, но и часто содержат меньше ошибок. Используя базовые примитивы распределения Erlang для связи в кластере, Riak может начать с фундаментально надежного уровня асинхронного обмена сообщениями и построить свои собственные протоколы, не беспокоясь об этой базовой реализации. По мере того, как Riak становился зрелой системой, некоторые аспекты ее сетевого взаимодействия отошли от использования встроенного дистрибутива Erlang (к прямому манипулированию TCP-сокетами), в то время как другие оставались хорошо подходящими для включенных примитивов. Начав с встроенной передачи сообщений Erlang для всего, команда Riak смогла очень быстро построить всю систему. Эти примитивы достаточно чисты и понятны, чтобы потом было легко заменить те немногие места, где они оказались не лучшим образом подходящими для производства.

Кроме того, благодаря характеру обмена сообщениями Erlang и легкому ядру виртуальной машины Erlang пользователь может с легкостью запускать 12 узлов на 1 машине или 12 узлов на 12 машинах. Это значительно упрощает разработку и тестирование по сравнению с более тяжелыми механизмами обмена сообщениями и кластеризации. Это было особенно ценно из-за фундаментально распределенной природы Riak. Исторически сложилось так, что большинство распределенных систем очень сложно работать в «режиме разработки» на одном ноутбуке разработчика. В результате разработчикам часто приходится тестировать свой код в среде, которая является подмножеством их полной системы, с совершенно другим поведением. Поскольку многоузловой кластер Riak можно легко запустить на одном ноутбуке без чрезмерного потребления ресурсов или сложной настройки, в процессе разработки можно легче создавать код, готовый к развертыванию в рабочей среде.

Использование супервизоров Erlang/OTP делает Riak гораздо более устойчивым к сбоям подкомпонентов. Риак идет дальше; Вдохновленный таким поведением, кластер Riak также может легко продолжать функционировать, даже когда целые узлы выходят из строя и исчезают из системы. Это может привести к порой удивительному уровню устойчивости. Одним из примеров этого был случай, когда крупное предприятие проводило стресс-тестирование различных баз данных и намеренно выводило их из строя, чтобы наблюдать за их граничными условиями. Когда они добрались до Риака, они растерялись. Каждый раз, когда они находили способ (посредством манипуляций на уровне ОС, плохого IPC и т. д.) привести к сбою подсистемы Riak, они наблюдали очень кратковременное падение производительности, а затем система возвращалась к нормальному поведению. Это прямой результат продуманного подхода «пусть рухнет». Риак аккуратно перезапускал каждую из этих подсистем по требованию, и вся система просто продолжала функционировать. Этот опыт показывает именно ту устойчивость, которую обеспечивает подход Erlang/OTP к созданию программ.

15.7.1. Благодарности

Эта глава основана на конспектах лекций Франческо Чезарини и Саймона Томпсона 2009 года, прочитанных в Центрально-Европейской школе функционального программирования, проходившей в Будапеште и Коморно. Большой вклад внес Саймон Томпсон из Кентского университета в Кентербери, Великобритания. Особая благодарность выражается всем рецензентам, которые на разных этапах написания этой главы предоставили ценные отзывы.

Архитектура приложений с открытым исходным кодом Архитектура приложений с открытым исходным кодом Эми Браун и Грег Уилсон (ред.) ISBN 978-1-257-63801-7 [Лицензия](https://barionleg.github.io/aosabook/src/v1/web/fr/intro.html#license) / [Купить](https://barionleg.github.io/aosabook/src/v1/web/fr/index.html#purchase) / [Новости](https://barionleg.github.io/aosabook/src/v1/web/fr/index.html#news) / [Внести вклад](https://barionleg.github.io/aosabook/src/v1/web/fr/index.html#contribute) / [Часто задаваемые вопросы](https://barionleg.github.io/aosabook/src/v1/web/fr/faq.html) Глава 15. Риак и Эрланг/OTP [Франческо Чезарини](https://barionleg.github.io/aosabook/src/v1/web/fr/intro.html#cesarini-francesco) , [Энди Гросс](https://barionleg.github.io/aosabook/src/v1/web/fr/intro.html#gross-andy) и [Джастин Шихи](https://barionleg.github.io/aosabook/src/v1/web/fr/intro.html#sheehy-justin) Riak — это распределенная отказоустойчивая база данных с открытым исходным кодом, которая демонстрирует, как создавать высоконагруженные системы с использованием Erlang/OTP. Во многом благодаря возможностям Erlang для массово масштабируемых систем, Riak предлагает функции, не характерные для баз данных, такие как высокая доступность с линейной масштабируемостью, как с точки зрения емкости, так и пропускной способности.

Пара Erlang/OTP обеспечивает идеальную платформу для разработки таких систем, как Riak, поскольку она изначально обеспечивает распределенную связь между узлами, очереди сообщений, детекторы ошибок и абстракцию систем клиент-сервер. Кроме того, наиболее часто используемые шаблоны в Erlang реализованы в библиотеках, обычно называемых «OTP Behaviors». Они содержат общий код для управления параллелизмом и обработки ошибок, что упрощает параллельное программирование и предотвращает попадание разработчика в ловушки, присущие этому типу программирования. «Поведения» отслеживаются супервизорами, которые сами по себе являются «Поведениями», сгруппированными в деревьях надзора. Дерево контроля упаковывается в приложение и затем является блоком программы Erlang.

Полная система Erlang, такая как Riak, представляет собой набор слабосвязанных приложений, которые взаимодействуют друг с другом. Некоторые приложения написаны разработчиком, некоторые входят в стандартную комплектацию Erlang/OTP, а другие могут быть компонентами с открытым исходным кодом. Они загружаются последовательно и запускаются сценарием запуска, созданным на основе списка приложений и их версий.

Что различается между системами, так это запускаемые приложения, интегрированные в выпуск. В стандартном дистрибутиве Erlang файлы запуска запускают приложения Kernel и StdLib (стандартная библиотека). После установки также запускается приложение SASL (Библиотека поддержки системной архитектуры). SASL содержит инструменты выпуска и обновления, а также функции ведения журналов. Riak ведет себя следующим образом, запуская специфичные для Riak приложения и их зависимости, в том числе Kernel , StdLib и SASL . Полная, готовая к использованию сборка Riak использует эти стандартные элементы дистрибутива Erlang/OTP и запускает их одновременно при riak startвызове команды в командной строке. Riak состоит из нескольких сложных приложений, и эту главу не следует рассматривать как полное руководство. Но в качестве введения в OTP, где используются примеры из исходного кода Riak. Рисунки и примеры упрощены для целей демонстрации.

15.1. Краткое введение в Erlang Erlang — это функциональный и параллельный язык программирования, который компилируется в байтовый код и выполняется на виртуальной машине. Программы состоят из функций, которые вызывают друг друга, что часто приводит к побочным эффектам, таким как передача сообщений между процессами, ввод/вывод или операции с базой данных. Переменным в Erlang можно присваивать только один раз, т.е. как только их значение будет присвоено, их больше нельзя будет изменить. В языке широко используется сопоставление с образцом, как в следующем примере вычисления факториала:

-модуль(факториал). -экспорт([фак/1]). факт(0) -> 1; fac(N), когда N>0 -> Prev = fac(N-1), N*Prev. В этом примере первое предложение определяет факториал 0, второе — факториал положительных чисел. Тело каждого предложения представляет собой последовательность выражений, а последнее выражение является результатом этого предложения. Вызов этой функции с отрицательным числом приведет к ошибке во время выполнения, поскольку ни одно предложение не соответствует. Необработка этого случая является примером «незащитного» программирования, практика, поощряемая в Erlang.

В модуле функции вызываются обычным способом; В противном случае имя модуля должно иметь префикс, например factorial:fac(3). Можно определить функции с тем же именем, но с разным количеством аргументов, называемым arity . В директиве экспорта модуля factorialфункция facарности 1 объявлена ​​как fac/1.

Erlang поддерживает кортежи (также называемые «типами продуктов») и списки. Кортежи также заключаются в фигурные скобки {ok,37}. Доступ к элементам кортежей осуществляется по их позиции. Записи — это еще один тип данных; они позволяют нам хранить фиксированное количество элементов, к которым осуществляется доступ и манипулирование ими по имени. Мы определяем запись следующим образом: -record(state, {id, msg_list=[]}). чтобы создать ее экземпляр, мы используем выражение Var = #state{id=1}и извлекаем его содержимое, используя: Var#state.id. Для переменного количества элементов мы используем списки, определенные в квадратных скобках: {[}23,34{]}. Обозначение {[}X|Xs{]}указывает на непустой список с началом («головой») Xи концом («хвостом») хвостом Xs. Идентификаторы, начинающиеся со строчной буквы, обозначают атомы , которые не имеют значения; Элемент okв кортеже {ok,37}является примером атома. Атомы часто используются для дифференциации результатов функции: как и результаты ok, могут быть результаты формы {error, "Error String"}.

Процессы в системах Erlang выполняются одновременно в выделенном пространстве памяти и взаимодействуют друг с другом посредством передачи сообщений. Процессы можно использовать для самых разных приложений: от шлюзов баз данных до обработчиков протоколов и управления трассировками журналов других процессов. Хотя эти процессы обрабатывают разные типы запросов, в способах обработки этих запросов есть сходства.

Поскольку процессы существуют только внутри виртуальной машины (ВМ), одна виртуальная машина может одновременно запускать миллионы процессов, и эту возможность широко использует Riak. Например, каждый запрос к базе данных — чтение, запись и удаление — моделируется как отдельный процесс, и такой подход был бы невозможен в большинстве реализаций потоков на уровне ОС.

Процессы идентифицируются идентификаторами процессов, называемыми PID, но их также можно зарегистрировать под псевдонимом; псевдонимы следует использовать только для долгоживущих «статических» процессов. Регистрация процесса под собственным псевдонимом позволяет другим процессам передавать ему сообщения, даже не зная его PID. Процессы создаются с помощью встроенной функции (BIF) spawn(Module, Function, Arguments). BIF — это функции, интегрированные в виртуальную машину для достижения того, что было бы невозможно или слишком медленно выполнить в «чистом Эрланге». BIF spawn/3принимает в качестве параметров a Module, a Functionи список Arguments. Этот вызов возвращает PID только что созданного процесса («порожденного») и в качестве побочного эффекта создает новый процесс, который начинается с выполнения этой функции модуля с аргументами, описанными выше.

Сообщение Msgотправляется PID-процессу: Pid с помощью Pid ! Msg. Процесс может определить свой собственный PID, вызвав BIF self, а затем передать его другим процессам, чтобы они могли с ним взаимодействовать. Предположим, процесс ожидает получения сообщений вида {ok, N}и {error, Reason}. Для их обработки он использует следующий код:

получить {ок, N} -> N+1; {ошибка, _} -> 0 конец Результатом является число, определяемое предложением сопоставления с образцом. Если значение переменной не требуется для сопоставления с образцом, в качестве подстановочного знака можно использовать символ подчеркивания, как показано выше.

Передача сообщений между процессами является асинхронной, и сообщения, полученные процессом, помещаются в почтовый ящик процесса в порядке поступления. Теперь предположим, что приведенное receiveвыше выражение выполнено: если первый элемент в почтовом ящике равен {ok, N}, {error, Reason}будет возвращен соответствующий результат. Если первое сообщение в почтовом ящике не в этой форме, оно будет храниться в почтовом ящике, а второе будет обработано таким же образом. Если ни одно сообщение не соответствует, блок приема будет ждать, пока не будет получено подходящее сообщение.

Процессы завершаются по двум причинам. Если больше нет кода для выполнения, говорят, что они завершаются по обычной причине . Если процесс обнаруживает ошибку во время выполнения, считается, что он завершился по ненормальной причине . Завершающий процесс не повлияет на другие процессы, если они не связаны друг с другом. Процессы могут связываться друг с другом, вызывая функцию BIF link(Pid)или вызывая spawn_link(Module, Function, Arguments). Если процесс завершается, он отправляет сигнал EXIT процессам, связанным с ним. Если причина завершения ненормальная, процесс завершается сам, распространяя сигнал EXIT. Вызывая функцию BIF process_flag(trap_exit, true), процессы могут получать сигналы EXIT в виде сообщений Erlang в свой почтовый ящик и обрабатывать их вместо завершения.

Riak использует сигналы EXIT для мониторинга работоспособности процессов, выполняющих некритическую работу, инициированную конечными автоматами, обрабатывающими запросы. Когда эти процессы завершаются ненормально, сигнал EXIT позволяет либо игнорировать ошибку, либо перезапустить процесс.

15.2. Скелеты процессов Ранее мы представили идею о том, что процессы следуют общему шаблону независимо от цели, для которой они созданы. Для начала процесс должен быть «порожден» и, при необходимости, зарегистрирован его псевдоним. Первым действием вновь созданного процесса является инициализация данных цикла процесса. Эти данные часто являются результатом аргументов, передаваемых функции BIF spawn во время инициализации процесса. Его данные хранятся в переменной, которая считается состоянием процесса. Состояние, часто хранящееся в записи, передается функции приема-оценки, запускающей цикл, который принимает сообщение, обрабатывает его, обновляет состояние и возвращает его в качестве аргумента — «хвостовой рекурсивный» вызов. Если одно из обрабатываемых им сообщений является сообщением «стоп», процесс выполнит соответствующую очистку и завершится.

Это повторяющаяся тема процессов, независимо от поставленной перед ними задачи. Имея это в виду, давайте посмотрим на различия между процессами, которые соответствуют этому шаблону:

Аргументы, передаваемые функции BIF, spawnбудут отличаться от одного процесса к другому. Вам необходимо решить, следует ли регистрировать процесс под псевдонимом, и если да, то какой псевдоним использовать. В функции инициализации состояния процесса предпринимаемые действия будут различаться в зависимости от задач, которые будет выполнять процесс. Состояние системы в каждом случае представлено данными цикла, однако содержимое данных будет различаться в зависимости от процесса. При выполнении цикла получения-оценки процессы будут получать разные сообщения и обрабатывать их по-разному. Наконец, когда процесс выключен, очистка будет варьироваться от одного процесса к другому. Таким образом, даже если существует скелет родовых действий, эти действия дополняются конкретными, непосредственно связанными с задачами, поставленными перед каждым процессом. Используя этот скелет в качестве шаблона, программисты могут создавать процессы Erlang, которые действуют как серверы, конечные автоматы, обработчики событий и супервизоры. Но вместо того, чтобы каждый раз переопределять эти шаблоны, они были разработаны как модули и названы «поведениями». Они являются частью промежуточной платформы OTP.

15.3. Поведение OTP: «Поведение» Основная команда разработчиков Riak разбросана примерно по дюжине географических регионов. Без очень тонкой координации и шаблонов для работы результат будет состоять из различных реализаций клиент/сервер, не обрабатывающих крайние особые случаи и связанные с ними ошибки конкуренции. Вероятно, не будет единого способа обработки инцидентов на клиенте и сервере или обеспечения того, чтобы ответ на запрос действительно был ответом, а не просто сообщением, соответствующим внутренним сообщениям протокола.

OTP — это набор библиотек Erlang и принципов проектирования, предоставляющий готовые к использованию инструменты для разработки надежных систем. Большинство этих шаблонов и библиотек предоставляются в форме «поведений».

Поведение OTP решает эти проблемы, предоставляя модули, реализующие наиболее распространенные шаблоны параллелизма. Под прикрытием, без ведома программиста, модули обеспечивают надежную обработку ошибок и особых случаев. В результате поведение OTP обеспечивает набор стандартизированных блоков для проектирования и построения промышленных систем качества.

15.3.1. Введение Поведения OTP предоставляются в виде модулей в приложении, stdlib которое является частью дистрибутива Erlang/OTP. Конкретный код, написанный программистом, помещается в отдельный модуль и вызывается с помощью набора предопределенных функций обратного вызова для каждого из вариантов поведения. Этот «модуль обратного вызова» будет содержать весь конкретный код, необходимый для достижения желаемой функциональности.

Поведение OTP включает в себя рабочие процессы, которые фактически выполняют вычисления, и супервизоры, чья задача — контролировать работников и других супервизоров. Поведение работников, часто схематически изображаемое в виде кружков, включает в себя серверы, обработчики событий и конечные автоматы. Руководители, представленные в виде прямоугольников, контролируют своих детей, как рабочих, так и руководителей, создавая дерево надзора.

[Дерево контроля OTP Riak] Рисунок 15.1: Дерево надзора OTP Riak

Деревья контроля сгруппированы в поведение, называемое приложением. Приложения OTP — это не только фундаментальные блоки систем Erlang, но и способ упаковки повторно используемых компонентов. Системы промышленного уровня, такие как Riak, состоят из набора слабосвязанных и потенциально распределенных приложений. Некоторые из этих приложений являются частью стандартного дистрибутива Erlang, а другие — частями, специально реализующими функциональные возможности Riak.

Примеры приложений OTP включают Corba ORB или агент простого протокола сетевого управления (SNMP). Приложение OTP — это повторно используемый компонент, который группирует модули с супервизорами и рабочими процессами. С этого момента, когда будет использоваться термин «приложение», он будет означать приложение OTP.

Модули поведения содержат весь общий код для каждого типа поведения. Хотя можно реализовать свой собственный модуль поведения, это требуется делать очень редко, поскольку те, которые предоставляются дистрибутивом Erlang/OTP, будут соответствовать большинству шаблонов, которые вы будете использовать в своем коде. Общая функциональность, предоставляемая в модуле поведения, включает следующие операции:

создание и при необходимости запись процесса; отправка и получение клиентских сообщений посредством синхронных или асинхронных вызовов, включая определение внутреннего протокола сообщений; хранение данных цикла и управление циклом процесса; И остановка процесса. Данные цикла — это переменная, которая будет содержать данные, которые потребуются поведению между вызовами. После вызова возвращается обновленная версия данных. Эти обновленные данные, часто называемые новыми данными в цикле, будут переданы в качестве аргумента при следующем вызове. Данные в цикле часто называют состоянием поведения.

Функциональность, которая должна быть включена в модуль общего приложения серверного типа для реализации конкретного поведения, включает в себя:

инициализация данных цикла процесса и, если процесс зарегистрирован, имя процесса. конкретное управление клиентскими запросами и, если синхронно, ответ, отправляемый обратно клиенту. управление и обновление данных в цикле процесса между различными запросами. очистка данных цикла перед завершением процесса. 15.3.2. Общие серверы Общие серверы, реализующие поведение клиент/сервер, определяются в поведении, gen_serverкоторое является частью приложения stdlib(Стандартная библиотека). Для объяснения универсальных серверов мы будем использовать модуль riak_core_node_watcher.erlприложения riak_core. Это сервер, который отслеживает и сообщает о доступности подсервисов и узлов в кластере Riak. Заголовки и директивы модулей следующие:

-модуль(riak_core_node_watcher). -поведение (gen_server). %% API -export([start_link/0,service_up/2,service_down/1,node_up/0,node_down/0,services/0, Services/1,nodes/1,avsn/0]). %% обратных вызовов gen_server -export([init/1,handle_call/3,handle_cast/2,handle_info/2,terminate/2, code_change/3]).

-record(state, {status=up, Services=[], Peers=[], avsn=0, bcast_tref, bcast_mod={gen_server, abcast}}). Общий сервер можно легко распознать по директиве. -behavior(gen_server). Эта директива используется компилятором для обеспечения правильного экспорта всех функций обратного вызова. Запись «state» будет использоваться для данных цикла сервера.

15.3.3. Запуск сервера В поведении gen_serverвместо использования BIF spawnи функций spawn_linkвы будете использовать функции gen_server:startи gen_server:start_link. Основное различие между spawnи startзаключается в синхронном характере их вызова. Использование startвместо spawnделает запуск рабочего процесса более детерминированным и позволяет избежать непредвиденных условий гонки, поскольку вызов не вернет PID рабочего процесса до тех пор, пока он не будет инициализирован. Вы можете вызвать эту функцию, используя одну из следующих сигнатур:

gen_server:start_link(ServerName, CallbackModule, Arguments, Options) gen_server:start_link(CallbackModule, Arguments, Options) ServerName— это кортеж в форме {local, Name}или {global, Name}, затем указывается, что Nameэто глобальный или локальный псевдоним процесса, если он должен быть зарегистрирован. Глобальные имена обеспечивают прозрачный доступ к серверам в кластере распределенных узлов Erlang. Если вы не хотите регистрировать процесс и вместо этого ссылаетесь на него, используя его PID, вам следует опустить аргумент match, используя вместо этого функцию start_link/3или start/3. CallbackModule— это имя модуля, в котором размещены определенные функции обратного вызова, Argumentsявляется действительным «термином» Erlang, который передается функции обратного вызова init/1, а также Optionsявляется списком, который позволяет вам указать параметры управления памятью, такие как fullsweep_afterи heapsize, а также трассировку и параметры отладки.

В нашем примере мы вызываем start_link/4, регистрируя процесс с тем же именем, что и модуль обратного вызова, с помощью макроса ?MODULE. Этот макрос транслируется в имя модуля препроцессором при компиляции кода. Всегда полезно называть свое поведение псевдонимом, совпадающим с именем модуля, в котором оно реализовано. Мы не передаем аргументы, просто предоставляя пустой список. Список опций также пуст:

start_link() -> gen_server:start_link({local, ?MODULE}, ?MODULE, [], []). Очевидная разница между функциями start_linkи startзаключается в том, что start_linkпроцесс связывается с его родителем, чаще всего с супервизором, а start это не так. Это заслуживает указания, поскольку ответственность за привязку к супервизору лежит на поведении OTP. Функции startчасто используются при тестировании поведения оболочки, поэтому ошибка ввода, вызывающая сбой процесса оболочки, не повлияет на поведение. Все формы функций startи start_linkвозвратов {ok, Pid}.

Функции startи start_linkсоздадут новый процесс, который вызовет функцию обратного вызова init(Arguments)с предоставленными CallbackModuleпараметрами Arguments. Функция initдолжна инициализировать LoopDataсервер и должна вернуть кортеж в форме {ok, LoopData}. LoopData содержит первый экземпляр данных цикла, которые будут передаваться между функциями обратного вызова. Если вы хотите сохранить некоторые аргументы, которые вы передали функции init, вы можете сделать это в переменной LoopData. LoopDataв сервере мониторинга узлов Riak — это результат вызова функции schedule_broadcast/1с записью типа, stateполя которой имеют значения по умолчанию:

init([]) ->

%% Следите за событиями включения/выключения узла 
net_kernel:monitor_nodes(true), 

%% Настройка таблицы ETS для отслеживания состояния узла 
ets:new(?MODULE, [protected,named_table]), 

{ok, Schedule_broadcast (#состояние{})}.

Хотя процесс-супервизор может вызвать функцию start_link/4, функцию вызывает другой процесс init/1 : тот, который только что был создан. Поскольку целью этого сервера является обнаружение, запись и сообщение о доступности подсервисов Riak, инициализация запрашивает среду выполнения Erlang уведомлять ее о таких событиях и состоит из таблицы для хранения этой информации. Это необходимо сделать при инициализации, поскольку вызовы к серверу завершится неудачно, если эта структура еще не существует. Делайте только то, что необходимо, и минимизируйте операции в вашей функции init, поскольку вызов initвыполняется синхронно, что предотвращает запуск всех других процессов до тех пор, пока функция не вернет свой результат.

15.3.4. Передача сообщений Если вы хотите отправить синхронное сообщение на свой сервер, вы будете использовать функцию gen_server:call/2. Асинхронные вызовы выполняются с помощью функции gen_server:cast/2. Давайте возьмем две функции из Service API Riak; остальную часть кода мы предоставим позже. Они вызываются клиентскими процессами и приводят к отправке синхронного сообщения серверному процессу, зарегистрированному с тем же именем, что и модуль. Обратите внимание, что проверка данных, отправляемых на сервер, должна выполняться на стороне клиента. Если клиент отправит неверную информацию, сервер отключится.

service_up(Id, Pid) -> gen_server:call(?MODULE, {service_up, Id, Pid}).

service_down(Id) -> gen_server:call(?MODULE, {service_down, Id}). Как только сообщения получены, процесс gen_serverвызывает функцию обратного вызова, handle_call/3обрабатывающую сообщения в том же порядке, в котором они были отправлены:

handle_call({service_up, Id, Pid}, _From, State) -> %% Обновить набор активных сервисов локально Services = ordsets:add_element(Id, State#state.services), S2 = State#state { Services = Services } ,

%% Удалите все существующие mrefs для этой службы 
delete_service_mref(Id), 

%% Настройте монитор для Pid, ​​представляющего эту службу 
Mref = erlang:monitor(process, Pid), 
erlang:put(Mref, Id), 
erlang:put( Id, Mref), 

%% Обновите нашу локальную таблицу ETS и транслируйте 
S3 = local_update(S2), 
{reply, ok, update_avsn(S3)}; 

handle_call({service_down, Id}, _From, State) -> %% Обновить набор активных сервисов локально Services = ordsets:del_element(Id, State#state.services), S2 = State#state { Services = Services },

% % Удалить все существующие mrefs для этой службы 
delete_service_mref(Id), 

%% Обновить локальную таблицу ETS и транслировать 
S3 = local_update(S2), 
{reply, ok, update_avsn(S3)};

Обратите внимание на возвращаемое значение функции обратного вызова. Кортеж содержит управляющий атом reply, сообщающий универсальному коду, что gen_serverвторой элемент кортежа (который в обоих случаях является атомом ok) является ответом, возвращаемым клиенту. Третий элемент кортежа — new State, который в новой итерации сервера передается в качестве третьего аргумента функции handle_call/3; в обоих случаях состояние обновляется, чтобы отразить новый набор доступных услуг. Аргумент _From представляет собой кортеж, содержащий уникальную ссылку на сообщение и PID клиентского процесса. Весь кортеж используется в библиотечных функциях, которые мы не будем обсуждать в этой главе. В большинстве случаев вам это не понадобится.

Модуль gen_serverсодержит собственные механизмы и ограждения, которые проходят под поверхностью. Если ваш клиент отправляет синхронное сообщение на ваш сервер, а вы не получаете ответа в течение пяти секунд, процесс выполнения функции call/2завершается. Вы можете переопределить это, используя gen_server:call(Name, Message, Timeout)значение Timeoutв миллисекундах или атом infinity.

Первоначально механизм тайм-аута был введен для защиты от взаимоблокировок, гарантируя, что серверы, которые случайно звонят друг другу, по умолчанию завершаются после тайм-аута. Затем отслеживается отчет о сбое, что позволяет отладить и исправить эту ошибку. Большинство приложений будут нормально работать с пятисекундным таймаутом, но при очень больших нагрузках вам может потребоваться более тонкая настройка этого значения и, возможно, даже его использование infinity; этот выбор зависит от приложения. Весь критический код в Erlang/OTP использует infinity. В коде Riak, в зависимости от местоположения, для таймаута используются разные значения: infinityчасто используется между связанными внутренними компонентами, а значение Timeout, заданное пользовательским параметром, используется в тех случаях, когда клиентское приложение, взаимодействующее с Riak, указало, что операция имеет тайм-аут.

При использовании функции gen_server:call/2другие меры защиты обрабатывают случай, когда сообщение отправляется на несуществующий сервер, и случай, когда сервер выходит из строя перед отправкой обратно своего ответа. В обоих случаях вызывающий процесс остановится. В «чистом» Эрланге отправка сообщения, которое никогда не обрабатывается (сопоставление с образцом) в предложении приема, является ошибкой, которая может вызвать утечку памяти. Чтобы преодолеть эту проблему, Riak использует две разные стратегии, каждая из которых использует «объемные» предложения сопоставления. В местах, где сообщение может быть отправлено пользователем, нераспознанное сообщение может быть незаметно забыто. Если такое сообщение может прийти только от внутренних компонентов Riak, этот случай считается ошибкой, которая затем вызывает внутренний отчет о сбое, предупреждающий об ошибке, и перезагрузку рабочего процесса, который его получил.

Передача асинхронных сообщений работает таким же образом. Сообщения отправляются асинхронно на общий сервер и обрабатываются функцией обратного вызова handle_cast/2. Функция должна возвращать кортеж вида {reply, NewState}. Асинхронные вызовы используются, когда ответ сервера не требуется и существует небольшой риск создания большего количества сообщений, чем сервер может обработать. В тех случаях, когда ответ не обязателен, но мы хотим дождаться обработки сообщения, прежде чем повторно передавать новый запрос, мы будем использовать функцию gen_server:call/2, которая возвращает атом okобратно. Представьте себе процесс, который генерирует записи базы данных с большей скоростью, чем может потреблять Riak. Используя асинхронные вызовы, мы рискуем заполнить почтовый ящик процесса и, следовательно, использовать всю память узла Erlang. Для регулирования нагрузки Riak использует свойства сериализации сообщений синхронных вызовов gen_server, которые обрабатывают следующий запрос только после полной обработки предыдущего. Этот подход позволяет избежать добавления кода управления перегрузкой: помимо обеспечения параллелизма, процессы gen_serverмогут использоваться для введения точек сериализации.

15.3.5. Выключение сервера Как остановить сервер? В функциях обратного вызова handle_call/3и handle_cast/2вместо возврата {reply, Reply, NewState}или {noreply, NewState}можно вернуть {stop, Reason, Reply, NewState}или соответственно {stop, Reason, NewState}. Что-то должно вызвать это возвращаемое значение, часто это сообщение о завершении работы, отправленное на сервер. Как только кортеж остановки, содержащий Reasonи получен State, общий код выполняет функцию обратного вызова terminate(Reason, State).

Эта функция terminate— лучшее место для вставки кода очистки сервера State и любых других постоянных данных, используемых системой. В нашем примере мы отправляем финальное сообщение нашим узлам, чтобы они знали, что этот монитор узла теперь остановлен. В этом примере переменная Stateсодержит запись с полями statusи peers :

завершения(_Reason, State) -> %% Сообщите нашим узлам, что мы отключаем широковещательную рассылку(State#state.peers, State#state {status = down }). Использование функций обратного вызова поведения в качестве библиотечных функций и вызов их из других мест программы — очень плохая практика. Например, никогда не следует вызывать riak_core_node_watcher:init(Args)из другого модуля, чтобы получить исходное состояние данных цикла. Это необходимо сделать посредством синхронного вызова сервера. Вызовы функций обратного вызова должны исходить только из модулей библиотеки поведения, вызовы, возникающие в результате события в системе, и никогда непосредственно от пользователя.

15.4. Другое «поведение работников» Большое количество других «поведений работников» может быть реализовано и реализовано на основе тех же идей.

15.4.1. Конечные автоматы Конечные автоматы (FSM), реализованные в модуле поведения gen_fsm, являются важнейшим компонентом при реализации стеков протоколов в телекоммуникационных системах (область, для которой был изобретен Erlang). Состояния определяются как функции обратного вызова, названные в честь состояния и возвращающие кортеж, содержащий следующие Stateи обновленные данные цикла. Вы можете отправлять события в эти состояния синхронно или асинхронно. Модуль обратного вызова конечного автомата также должен экспортировать стандартные функции обратного вызова, а именно init, terminateи handle_info.

Очевидно, что конечные автоматы не являются специфичными для телекоммуникаций. В Riak они используются в обработчиках запросов. Когда клиент отправляет запрос типа get, putили delete, процесс, слушающий этот запрос, создаст новый процесс, реализующий gen_fsmсоответствующее поведение. Например, riak_kv_get_fsmотвечает за обработку запроса get, получение данных и возврат их клиентскому процессу. Процесс FSM проходит через разные состояния в зависимости от того, определяет ли он, у каких узлов запрашивать данные, отправляет ли он сообщения этим узлам и получает ли он данные в ответ.

15.4.2. Менеджеры мероприятий Обработчики событий — это еще одно поведение, реализованное в модуле gen_event. Идея состоит в том, чтобы создать центральную точку, принимающую события определенного типа. События могут отправляться синхронно или асинхронно, и при их получении применяется заранее определенный набор действий. При получении события мы можем, например, отследить его в файле, отправить сигнал тревоги в виде SMS или объединить его в статистику. Каждое из этих действий определяется в отдельном модуле обратного вызова со своими собственными данными цикла, сохраняемыми между вызовами. Обработчики можно добавлять, удалять или обновлять для каждого обработчика событий. Итак, на практике для каждого обработчика событий может быть несколько модулей обратного вызова, и в разных обработчиках могут существовать разные экземпляры этих модулей. К обработчикам относятся процессы, получающие сигналы тревоги, отслеживаемые данные в реальном времени, события, связанные с событиями, или простые журналы.

В Riak одно из применений поведения gen_event — управление подписками на «кольцевые события», т. е. изменения членства в узлах или назначения разделов в кластере Riak. Процессы на узле Riak могут зарегистрировать функцию в экземпляре riak_core_ring_events, которая реализует данное поведение gen_event. Когда центральный процесс, управляющий кольцом этого узла, изменяет запись о членстве для всего кластера, он запускает событие, которое заставляет каждый модуль обратного вызова вызывать зарегистрированную функцию. Таким образом, различным частям Riak будет проще реагировать на изменения в любой из центральных структур данных Riak, не усложняя центральный менеджер этой структуры данных.

Наиболее распространенные модели конкуренции и общения управляются одним из трех основных типов поведения, которые мы только что представили: gen_server, gen_fsmи gen_event. Однако в больших системах со временем могут возникнуть шаблоны, специфичные для приложения, и потребовать создания нового поведения. Riak включает такое поведение, riak_core_vnodeкоторое формализует способ реализации виртуального узла. Виртуальные узлы — это основная абстракция хранилища в Riak, предоставляющая единый интерфейс от хранилища «ключ-значение» к соответствующим автоматам. Интерфейс модуля обратного вызова определяется с помощью функции behavior_info/1следующим образом:

Behavior_info(обратные вызовы) -> [{init,1}, {handle_command,3}, {handoff_starting,2}, {handoff_cancelled,1}, {handoff_finished,2}, {handle_handoff_command,3}, {handle_handoff_data,2}, { encode_handoff_item,2}, {is_empty,1}, {terminate,2}, {delete,1}]; В этом примере показана behavior_info/1функция riak_core_vnode. Список кортежей {CallbackFunction, Arity} определяет контракт, который должен соблюдать модуль обратного вызова. Конкретные реализации виртуальных узлов должны экспортировать эти функции, иначе компилятор выдаст предупреждение. Реализовать собственное поведение OTP относительно просто. Помимо определения ваших функций обратного вызова, используя модули proc_libи sys модули, вы должны запускать их с определенными функциями, управлять системными сообщениями и отслеживать родительский процесс на случай, если он завершится.

15.5. Руководители Задача супервизора поведения — следить за своими дочерними процессами и по заранее настроенным правилам выполнять необходимые действия при их завершении. Дети могут быть как другими руководителями, так и работниками процесса. Это позволяет коду Riak сосредоточиться на правильном случае, что позволяет супервизору обрабатывать ошибки программного обеспечения, поврежденные данные или системные ошибки единообразно во всей системе. В мире Erlang этот незащищенный подход к программированию часто называют стратегией «пусть произойдет сбой». Дочерние процессы, составляющие дерево контроля, могут включать как супервизоры, так и рабочие процессы. Рабочие процессы — это поведение OTP, включая gen_fsm, gen_serverи gen_event. Команда Риака, которой не нужно заниматься маргинальными делами, может работать с меньшей базой кода. Эту базу кода благодаря использованию поведений проще понять, поскольку она имеет дело только с конкретным кодом. Riak имеет супервизор высокого уровня, как и в большинстве приложений Erlang, а также супервизоры более низкого уровня для управления группами процессов по функциональности, такие как виртуальные узлы Riak, прослушиватели сокетов TCP и обработчики запросов-ответов.

15.5.1. Функции обратного вызова супервизора Чтобы продемонстрировать, как реализован супервизор поведения, мы воспользуемся модулем riak_core_sup.erl. Этот основной супервизор является супервизором самого высокого уровня основного приложения Riak. Он запускает статический набор рабочих и супервизоров, а также динамическое количество рабочих, управляющих соединениями HTTP и HTTPS RESTful API узла, число, определенное в файлах конфигурации, специфичных для приложения узла. Подобно gen_servers, все модули обратного вызова супервизора должны включать директиву -behavior(supervisor).. Они запускаются с помощью функций startили start_linkпринимают в качестве необязательных аргументов ServerName, the CallBackModuleи a Argument, которые будут переданы в функцию обратного вызова init/1.

Глядя на первые строки кода модуля riak_core_sup.erl, помимо директивы поведения и макроса, который мы опишем позже, мы можем увидеть функцию start_link/3:

-модуль(riak_core_sup). -поведение (руководитель). %% API -export([start_link/0]). %% Обратные вызовы супервизора -export([init/1]). -define(CHILD(I, Type), {I, {I, start_link, []}, постоянный, 5000, Тип, [I]}). start_link() -> супервизор:start_link({local, ?MODULE}, ?MODULE, []). Запуск супервизора вызовет создание («порождение») нового процесса и вызов функции обратного вызова init/1модуля обратного вызова riak_core_sup.erl. Это ServerNameкортеж в форме {local, Name}или {global, Name}, где Name— зарегистрированное имя супервизора. В нашем примере и зарегистрированное имя, и модуль — это атом riak_core_sup, взятый из макроса ?MODULE. Мы передаем пустой список в качестве аргумента init/1, который будет рассматриваться как нулевое значение. Эта функция initявляется единственной функцией обратного вызова супервизора. Он должен вернуть кортеж в формате:

{ок, {SupervisorSpecification, ChildSpecificationList}} где SupervisorSpecification— кортеж из трех элементов {RestartStrategy, AllowedRestarts, MaxSeconds}, содержащий информацию о том, как обрабатывать сбои и перезапуски процессов. RestartStrategy— это один из трех параметров конфигурации, указывающий, как повлияют на «родственные» процессы в случае нештатного завершения работы:

one_for_one: ни один из других процессов в дереве надзора не затрагивается. rest_for_one: Процессы, запущенные после завершения процесса, останавливаются и перезапускаются. one_for_all: Все процессы остановлены и перезапущены. AllowedRestartsуказывает, сколько раз дочерние элементы супервизора могут завершить работу в интервале, MaxSeconds прежде чем супервизор завершит себя (и его дочерние элементы). Когда процесс завершается, он отправляет сигнал EXIT своему супервизору, который, в зависимости от стратегии перезапуска, соответствующим образом обрабатывает завершение работы. Супервизор завершает работу после достижения максимально разрешенного количества перезапусков и гарантирует, что циклические перезапуски и другие проблемы, не решенные на его уровне, позже перейдут на следующий уровень. Скорее всего, проблема в процессе в другом поддереве, что позволяет супервизору более высокого уровня закрыть контролирующее поддерево и переделать его.

Глядя на последнюю строку функции обратного вызова init/1модуля riak_core_sup.erl, мы можем заметить, что этот конкретный монитор имеет стратегию «один к одному», что означает, что процессы независимы друг от друга. Супервизор допустит максимум десять перезапусков, чтобы перезапустить себя.

ChildSpecificationListуказывает, каких дочерних элементов супервизор должен запускать и отслеживать, а также информацию о том, как его остановить и перезапустить. Он представлен списком кортежей в следующем виде:

{Id, {Модуль, Функция, Аргументы}, Перезапуск, Завершение работы, Тип, Список модулей} Id— уникальный идентификатор данного супервизора. Кортеж Module, Functionи Argumentsпредставляет собой экспортированную функцию, которая запускает вызов start_linkфункции поведения, которая возвращает кортеж в форме {ok, Pid}. Стратегия Restartописывает, что должно произойти в зависимости от типа остановки процесса, который может быть:

процессы transient, которые никогда не перезапускаются; процессы temporary, которые перезапускаются только в случае аварийного завершения работы; И процессы permanent, которые всегда перезапускаются независимо от того, является ли причина их остановки нормальной или ненормальной. Shutdown— значение в миллисекундах, указывающее время, по истечении которого поведению разрешено выполнять функцию, terminateесли оно останавливается из-за перезапуска или завершения работы. Атом infinityтакже можно использовать, но для поведения, отличного от супервизоров, это настоятельно не рекомендуется. Typeявляется либо атомом workerв отношении универсальных серверов, обработчиков событий и конечных автоматов, либо атомом supervisor. Связанные со ModuleListсписком модулей, реализующих это поведение, они используются для управления и приостановки процессов во время процедур горячего обновления программного обеспечения. Только существующие или реализованные пользователем варианты поведения могут быть частью этого списка и, следовательно, включены в дерево контроля.

К настоящему моменту мы должны быть в состоянии описать стратегию перезагрузки, определяющую межпроцессные зависимости, пороги устойчивости к сбоям и процедуры эскалации на основе общей архитектуры. Мы также должны уметь понимать, что происходит в init/1примере функции модуля riak_core_sup.erl. Для начала давайте изучим макрос CHILD. Он создает спецификацию для одного дочернего процесса, используя имя модуля обратного вызова как Id, делая его постоянным и определяя 5-секундное время завершения. Потоки могут быть рабочими или супервайзерами. Давайте посмотрим на пример и посмотрим, что мы можем из него извлечь:

-define(CHILD(I, Type), {I, {I, start_link, []}, постоянный, 5000, Тип, [I]}).

init([]) -> RiakWebs = списки регистров: Flatten(riak_core_web:bindings(http), riak_core_web:bindings(https)) of [] -> %% проверка старых настроек, если app.config %% не был обновлен riak_core_web:old_binding(); Привязка -> Конец привязки ,

Children = 
             [?CHILD(riak_core_vnode_sup, супервизор), 
              ?CHILD(riak_core_handoff_manager, рабочий), 
              ?CHILD(riak_core_handoff_listener, рабочий), 
              ?CHILD(riak_core_ring_events, рабочий), 
              ?CHILD(riak_core_ring_manager, рабочий), ?CHILD(riak_core_ring_manager, рабочий), 
              ? CHILD(riak_core_node_watcher_events, рабочий), 
              ?CHILD(riak_core_node_watcher, рабочий), 
              ?CHILD(riak_core_gossip, рабочий) | 
              RiakWebs 
             ], 
{ok, {{one_for_one, 10, 10}, Дети}}.

Большинство из Childrenзапущенных этим супервизором статически определенных рабочих (или, в случае с vnode_supсупервизором). Исключением является часть RiakWebs, определение которой является динамическим и зависит от HTTP-части файла конфигурации Riak.

За исключением приложений библиотечного типа, все приложения OTP, включая приложения Riak, будут иметь собственное дерево контроля. В Riak в узле Erlang выполняются несколько приложений высокого уровня, например, riak_coreдля алгоритмов распределенных систем riak_kvдля семантики хранения ключей/значений, webmachineдля HTTP и многих других. Ниже мы видели расширенное дерево, riak_coreпредставляющее многоуровневый надзор, которым управляет Riak. Одним из основных преимуществ этой структуры является то, что работа подсистемы может быть прервана (из-за ошибки, проблемы окружающей среды или преднамеренного действия), а затем первоначально будет остановлено только это поддерево.

Супервизор перезапустит необходимые процессы, и вся система не будет затронута. На практике мы обнаружили, что эта операция корректна для Riak. Пользователь может придумать, как выключить виртуальный узел, но супервизор перезапустит его riak_core_vnode_sup. Если они успешно прервут последнее, супервизор riak_core перезапустит его, передав сообщение об отключении супервизору более высокого уровня. Этот механизм изоляции и восстановления инцидентов позволяет разработчикам Riak (и Erlang) довольно просто создавать отказоустойчивые системы.

Ценность этой модели мониторинга была продемонстрирована, когда промышленный пользователь создал экстремальную среду, чтобы определить, где произойдет сбой нескольких систем баз данных. Эта среда порождала гигантские пики нагрузки и условия, благоприятные для инцидентов. Они были сбиты с толку, обнаружив, что Риак просто не остановится даже в самых худших условиях. Точнее, конечно, они могли прерывать процессы или подсистемы по отдельности и разными способами, но супервайзеры очищали и перезапускали все необходимое для восстановления всей системы в рабочем состоянии.

15.5.2. Приложения Поведение, applicationкоторое мы представили ранее, используется для упаковки модулей или ресурсов Erlang в повторно используемые компоненты. В OTP есть два типа приложений. Наиболее распространенная форма, называемая обычными приложениями, запускает управляющее дерево и все необходимые статические рабочие процессы. «Библиотечные» приложения, такие как «Стандартная библиотека», интегрированные в дистрибутив Erlang, содержат «библиотечные» модули, но не запускают дерево управления. Это не означает, что код не содержит процессов или деревьев супервизии. Это всего лишь означает, что они будут запущены как часть дерева, принадлежащего другому приложению.

Система Erlang будет состоять из набора слабо связанных приложений. Некоторые из них написаны разработчиками, другие доступны с открытым исходным кодом, а третьи являются неотъемлемой частью дистрибутива Erlang/OTP. Система времени выполнения Erlang и ее инструменты одинаково обрабатывают все приложения, независимо от того, являются ли они частью дистрибутива Erlang или нет.

15.6. Репликация и связь в Riak Riak был разработан для обеспечения исключительной надежности и доступности в больших масштабах и был вдохновлен системой хранения данных Dynamo от Amazon [ DHJ+07 ]. Архитектуры Dynamo и Riak сочетают в себе аспекты как распределенных хеш-таблиц (DHT), так и традиционных баз данных. Два ключевых метода, которые используют Riak и Dynamo, — это последовательное хеширование для размещения реплик и протокол сплетен для обмена общим состоянием.

Согласованное хеширование требует, чтобы все узлы в системе знали друг о друге и знали, какими разделами владеет каждый узел. Эти данные о назначении можно хранить в файле конфигурации с централизованным управлением, но в больших конфигурациях это становится чрезвычайно сложно. Другой альтернативой является использование центрального сервера конфигурации, но это создает единую точку отказа в системе. Вместо этого Riak использует протокол сплетен для распространения данных о членстве в кластере и владельце разделов по всей системе.

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

При запуске кластера Riak все узлы должны быть настроены с одинаковым количеством разделов. Затем кольцо согласованного хеширования делится на количество разделов, и каждый интервал сохраняется локально как {HashRange, Owner}пара. Первый узел кластера просто заявляет права на все разделы. Когда новый узел присоединяется к кластеру, он обращается к существующему узлу за списком {HashRange, Owner} одноранговых узлов. Затем он запрашивает пары (количество разделов)/(количество узлов), обновляя свое локальное состояние, чтобы отразить новое владение. Обновленная информация о владельце затем передается одноранговому узлу. Это обновленное состояние затем распространилось по всему кластеру с использованием описанного выше алгоритма.

Используя протокол сплетен, Riak избегает создания единой точки отказа в виде централизованного сервера конфигурации, освобождая системных операторов от необходимости поддерживать критические данные конфигурации кластера. Любой узел может затем использовать полученные данные о назначении разделов в системе для маршрутизации запросов. При совместном использовании протокол Gossip и последовательное хеширование позволяют Riak функционировать как действительно децентрализованная система, что имеет важные последствия для развертывания и эксплуатации крупномасштабных систем.

15.7. Выводы и извлеченные уроки Большинство программистов считают, что меньшие и простые базы кода не только легче поддерживать, но и часто содержат меньше ошибок. Используя базовые примитивы распределения Erlang для связи в кластере, Riak может начать с фундаментально надежного уровня асинхронного обмена сообщениями и построить свои собственные протоколы, не беспокоясь об этой базовой реализации. По мере того, как Riak становился зрелой системой, некоторые аспекты ее сетевого взаимодействия отошли от использования встроенного дистрибутива Erlang (к прямому манипулированию TCP-сокетами), в то время как другие оставались хорошо подходящими для включенных примитивов. Начав с встроенной передачи сообщений Erlang для всего, команда Riak смогла очень быстро построить всю систему. Эти примитивы достаточно чисты и понятны, чтобы потом было легко заменить те немногие места, где они оказались не лучшим образом подходящими для производства.

Кроме того, благодаря характеру обмена сообщениями Erlang и легкому ядру виртуальной машины Erlang пользователь может с легкостью запускать 12 узлов на 1 машине или 12 узлов на 12 машинах. Это значительно упрощает разработку и тестирование по сравнению с более тяжелыми механизмами обмена сообщениями и кластеризации. Это было особенно ценно из-за фундаментально распределенной природы Riak. Исторически сложилось так, что большинство распределенных систем очень сложно работать в «режиме разработки» на одном ноутбуке разработчика. В результате разработчикам часто приходится тестировать свой код в среде, которая является подмножеством их полной системы, с совершенно другим поведением. Поскольку многоузловой кластер Riak можно легко запустить на одном ноутбуке без чрезмерного потребления ресурсов или сложной настройки, в процессе разработки можно легче создавать код, готовый к развертыванию в рабочей среде.

Использование супервизоров Erlang/OTP делает Riak гораздо более устойчивым к сбоям подкомпонентов. Риак идет дальше; Вдохновленный таким поведением, кластер Riak также может легко продолжать функционировать, даже когда целые узлы выходят из строя и исчезают из системы. Это может привести к порой удивительному уровню устойчивости. Одним из примеров этого был случай, когда крупное предприятие проводило стресс-тестирование различных баз данных и намеренно выводило их из строя, чтобы наблюдать за их граничными условиями. Когда они добрались до Риака, они растерялись. Каждый раз, когда они находили способ (посредством манипуляций на уровне ОС, плохого IPC и т. д.) привести к сбою подсистемы Riak, они наблюдали очень кратковременное падение производительности, а затем система возвращалась к нормальному поведению. Это прямой результат продуманного подхода «пусть рухнет». Риак аккуратно перезапускал каждую из этих подсистем по требованию, и вся система просто продолжала функционировать. Этот опыт показывает именно ту устойчивость, которую обеспечивает подход Erlang/OTP к созданию программ.

15.7.1. Благодарности Эта глава основана на конспектах лекций Франческо Чезарини и Саймона Томпсона 2009 года, прочитанных в Центрально-Европейской школе функционального программирования, проходившей в Будапеште и Коморно. Большой вклад внес Саймон Томпсон из Кентского университета в Кентербери, Великобритания. Особая благодарность выражается всем рецензентам, которые на разных этапах написания этой главы предоставили ценные отзывы.