വിതരണം ചെയ്ത ആപ്ലിക്കേഷനുകളുടെ നിർമ്മാണ ബ്ലോക്കുകൾ. ആദ്യ സമീപനം

അവസാനത്തിൽ ലേഖനം റിയാക്ടീവ് ആർക്കിടെക്ചറിന്റെ സൈദ്ധാന്തിക അടിത്തറ ഞങ്ങൾ പരിശോധിച്ചു. ഡാറ്റാ ഫ്ലോകൾ, റിയാക്ടീവ് Erlang/Elixir സിസ്റ്റങ്ങൾ നടപ്പിലാക്കുന്നതിനുള്ള വഴികൾ, അവയിലെ സന്ദേശമയയ്‌ക്കൽ പാറ്റേണുകൾ എന്നിവയെക്കുറിച്ച് സംസാരിക്കേണ്ട സമയമാണിത്:

• അഭ്യർത്ഥന-പ്രതികരണം
• അഭ്യർത്ഥന-ചങ്ക്ഡ് പ്രതികരണം
• അഭ്യർത്ഥനയോടെയുള്ള പ്രതികരണം
• പ്രസിദ്ധീകരിക്കുക-സബ്‌സ്‌ക്രൈബ് ചെയ്യുക
• വിപരീതമായി പ്രസിദ്ധീകരിക്കുക-സബ്‌സ്‌ക്രൈബ് ചെയ്യുക
• ചുമതല വിതരണം

SOA, MSA, സന്ദേശമയയ്‌ക്കൽ

SOA, MSA എന്നിവ ബിൽഡിംഗ് സിസ്റ്റങ്ങളുടെ നിയമങ്ങൾ നിർവചിക്കുന്ന സിസ്റ്റം ആർക്കിടെക്ചറുകളാണ്, അതേസമയം സന്ദേശമയയ്ക്കൽ അവ നടപ്പിലാക്കുന്നതിനുള്ള പ്രാകൃതങ്ങൾ നൽകുന്നു.

ഈ അല്ലെങ്കിൽ ആ സിസ്റ്റം ആർക്കിടെക്ചർ പ്രൊമോട്ട് ചെയ്യാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല. ഒരു നിർദ്ദിഷ്‌ട പ്രോജക്‌റ്റിനും ബിസിനസ്സിനും ഏറ്റവും ഫലപ്രദവും ഉപയോഗപ്രദവുമായ രീതികൾ ഉപയോഗിക്കുന്നതിനാണ് ഞാൻ. ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്ന മാതൃക എന്തുതന്നെയായാലും, Unix-way-ൽ ഒരു കണ്ണുകൊണ്ട് സിസ്റ്റം ബ്ലോക്കുകൾ സൃഷ്ടിക്കുന്നതാണ് നല്ലത്: കുറഞ്ഞ കണക്റ്റിവിറ്റി ഉള്ള ഘടകങ്ങൾ, വ്യക്തിഗത എന്റിറ്റികൾക്ക് ഉത്തരവാദികൾ. എപിഐ രീതികൾ എന്റിറ്റികൾക്കൊപ്പം സാധ്യമായ ഏറ്റവും ലളിതമായ പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു.

മെസേജിംഗ്, പേര് സൂചിപ്പിക്കുന്നത് പോലെ, ഒരു സന്ദേശ ബ്രോക്കർ ആണ്. സന്ദേശങ്ങൾ സ്വീകരിക്കുകയും അയയ്ക്കുകയും ചെയ്യുക എന്നതാണ് ഇതിന്റെ പ്രധാന ലക്ഷ്യം. വിവരങ്ങൾ അയയ്‌ക്കുന്നതിനുള്ള ഇന്റർഫേസുകൾ, സിസ്റ്റത്തിനുള്ളിൽ വിവരങ്ങൾ കൈമാറുന്നതിനുള്ള ലോജിക്കൽ ചാനലുകളുടെ രൂപീകരണം, റൂട്ടിംഗ്, ബാലൻസിംഗ്, അതുപോലെ തന്നെ സിസ്റ്റം തലത്തിൽ തകരാർ കൈകാര്യം ചെയ്യൽ എന്നിവയ്ക്ക് ഇത് ഉത്തരവാദിയാണ്.
ഞങ്ങൾ വികസിപ്പിക്കുന്ന സന്ദേശമയയ്‌ക്കൽ rabbitmq-മായി മത്സരിക്കാനോ മാറ്റിസ്ഥാപിക്കാനോ ശ്രമിക്കുന്നില്ല. അതിന്റെ പ്രധാന സവിശേഷതകൾ:

• വിതരണ.
  എല്ലാ ക്ലസ്റ്റർ നോഡുകളിലും എക്സ്ചേഞ്ച് പോയിന്റുകൾ സൃഷ്ടിക്കാൻ കഴിയും, അവ ഉപയോഗിക്കുന്ന കോഡിന് കഴിയുന്നത്ര അടുത്ത്.
• ലാളിത്യം.
  ബോയിലർ പ്ലേറ്റ് കോഡ് കുറയ്ക്കുന്നതിലും ഉപയോഗത്തിന്റെ എളുപ്പത്തിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കുക.
• മികച്ച പ്രകടനം.
  ഞങ്ങൾ rabbitmq-ന്റെ പ്രവർത്തനക്ഷമത ആവർത്തിക്കാൻ ശ്രമിക്കുന്നില്ല, എന്നാൽ വാസ്തുവിദ്യയും ഗതാഗത പാളിയും മാത്രം ഹൈലൈറ്റ് ചെയ്യുന്നു, അത് OTP-യിൽ കഴിയുന്നത്ര ലളിതമായി ഉൾക്കൊള്ളുന്നു, ചെലവ് കുറയ്ക്കുന്നു.
• വഴക്കം.
  ഓരോ സേവനത്തിനും നിരവധി എക്സ്ചേഞ്ച് ടെംപ്ലേറ്റുകൾ സംയോജിപ്പിക്കാൻ കഴിയും.
• ഡിസൈൻ അനുസരിച്ച് പ്രതിരോധം.
• സ്കേലബിളിറ്റി.
  ആപ്ലിക്കേഷനോടൊപ്പം സന്ദേശമയയ്‌ക്കൽ വളരുന്നു. ലോഡ് വർദ്ധിക്കുന്നതിനനുസരിച്ച്, നിങ്ങൾക്ക് എക്സ്ചേഞ്ച് പോയിന്റുകൾ വ്യക്തിഗത മെഷീനുകളിലേക്ക് നീക്കാൻ കഴിയും.

അഭിപ്രായം. കോഡ് ഓർഗനൈസേഷന്റെ കാര്യത്തിൽ, സങ്കീർണ്ണമായ Erlang/Elixir സിസ്റ്റങ്ങൾക്ക് മെറ്റാ-പ്രോജക്‌റ്റുകൾ അനുയോജ്യമാണ്. എല്ലാ പ്രോജക്റ്റ് കോഡും ഒരു ശേഖരത്തിൽ സ്ഥിതിചെയ്യുന്നു - ഒരു കുട പ്രോജക്റ്റ്. അതേ സമയം, മൈക്രോസർവീസുകൾ പരമാവധി ഒറ്റപ്പെടുത്തുകയും ഒരു പ്രത്യേക സ്ഥാപനത്തിന് ഉത്തരവാദികളായ ലളിതമായ പ്രവർത്തനങ്ങൾ നടത്തുകയും ചെയ്യുന്നു. ഈ സമീപനത്തിലൂടെ, മുഴുവൻ സിസ്റ്റത്തിന്റെയും API നിലനിർത്തുന്നത് എളുപ്പമാണ്, മാറ്റങ്ങൾ വരുത്തുന്നത് എളുപ്പമാണ്, യൂണിറ്റ്, ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ എഴുതാൻ ഇത് സൗകര്യപ്രദമാണ്.

സിസ്റ്റം ഘടകങ്ങൾ നേരിട്ട് അല്ലെങ്കിൽ ഒരു ബ്രോക്കർ വഴി സംവദിക്കുന്നു. ഒരു സന്ദേശമയയ്‌ക്കൽ വീക്ഷണകോണിൽ, ഓരോ സേവനത്തിനും നിരവധി ജീവിത ഘട്ടങ്ങളുണ്ട്:

• സേവന സമാരംഭം.
  ഈ ഘട്ടത്തിൽ, സേവനം നടപ്പിലാക്കുന്ന പ്രക്രിയയും ഡിപൻഡൻസികളും കോൺഫിഗർ ചെയ്യുകയും സമാരംഭിക്കുകയും ചെയ്യുന്നു.
• ഒരു എക്സ്ചേഞ്ച് പോയിന്റ് സൃഷ്ടിക്കുന്നു.
  സേവനത്തിന് നോഡ് കോൺഫിഗറേഷനിൽ വ്യക്തമാക്കിയ സ്റ്റാറ്റിക് എക്സ്ചേഞ്ച് പോയിന്റ് ഉപയോഗിക്കാം, അല്ലെങ്കിൽ ഡൈനാമിക് ആയി എക്സ്ചേഞ്ച് പോയിന്റുകൾ സൃഷ്ടിക്കാം.
• സേവന രജിസ്ട്രേഷൻ.
  സേവനം അഭ്യർത്ഥനകൾ നൽകുന്നതിന്, അത് എക്സ്ചേഞ്ച് പോയിന്റിൽ രജിസ്റ്റർ ചെയ്തിരിക്കണം.
• സാധാരണ പ്രവർത്തനം.
  സേവനം ഉപയോഗപ്രദമായ ജോലി സൃഷ്ടിക്കുന്നു.
• ഷട്ട് ഡൗൺ.
  2 തരം ഷട്ട്ഡൗൺ സാധ്യമാണ്: സാധാരണവും അടിയന്തിരവും. സാധാരണ പ്രവർത്തന സമയത്ത്, എക്സ്ചേഞ്ച് പോയിന്റിൽ നിന്ന് സേവനം വിച്ഛേദിക്കുകയും നിർത്തുകയും ചെയ്യുന്നു. അടിയന്തിര സാഹചര്യങ്ങളിൽ, മെസേജിംഗ് പരാജയം സ്ക്രിപ്റ്റുകളിലൊന്ന് നടപ്പിലാക്കുന്നു.

ഇത് വളരെ സങ്കീർണ്ണമാണെന്ന് തോന്നുന്നു, പക്ഷേ കോഡ് അത്ര ഭയാനകമല്ല. കുറച്ച് കഴിഞ്ഞ് ടെംപ്ലേറ്റുകളുടെ വിശകലനത്തിൽ അഭിപ്രായങ്ങളുള്ള കോഡ് ഉദാഹരണങ്ങൾ നൽകും.

എക്സ്ചേഞ്ച്

എക്‌സ്‌ചേഞ്ച് പോയിന്റ് എന്നത് സന്ദേശമയയ്‌ക്കൽ ടെംപ്ലേറ്റിലെ ഘടകങ്ങളുമായുള്ള ഇടപെടലിന്റെ യുക്തി നടപ്പിലാക്കുന്ന ഒരു സന്ദേശമയയ്‌ക്കൽ പ്രക്രിയയാണ്. ചുവടെ അവതരിപ്പിച്ചിരിക്കുന്ന എല്ലാ ഉദാഹരണങ്ങളിലും, ഘടകങ്ങൾ എക്സ്ചേഞ്ച് പോയിന്റുകളിലൂടെ സംവദിക്കുന്നു, ഇവയുടെ സംയോജനമാണ് സന്ദേശമയയ്‌ക്കൽ രൂപപ്പെടുന്നത്.

സന്ദേശ കൈമാറ്റ പാറ്റേണുകൾ (MEPs)

ആഗോളതലത്തിൽ, എക്സ്ചേഞ്ച് പാറ്റേണുകളെ ടു-വേ, വൺ-വേ എന്നിങ്ങനെ വിഭജിക്കാം. ആദ്യത്തേത് ഇൻകമിംഗ് സന്ദേശത്തിനുള്ള പ്രതികരണത്തെ സൂചിപ്പിക്കുന്നു, രണ്ടാമത്തേത് ചെയ്യരുത്. ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിലെ ടു-വേ പാറ്റേണിന്റെ ഒരു മികച്ച ഉദാഹരണമാണ് അഭ്യർത്ഥന-പ്രതികരണ പാറ്റേൺ. ടെംപ്ലേറ്റും അതിന്റെ പരിഷ്ക്കരണങ്ങളും നോക്കാം.

അഭ്യർത്ഥന-പ്രതികരണം അല്ലെങ്കിൽ RPC

മറ്റൊരു പ്രക്രിയയിൽ നിന്ന് ഞങ്ങൾക്ക് ഒരു പ്രതികരണം ലഭിക്കേണ്ടിവരുമ്പോൾ RPC ഉപയോഗിക്കുന്നു. ഈ പ്രക്രിയ ഒരേ നോഡിൽ പ്രവർത്തിക്കുന്നതോ മറ്റൊരു ഭൂഖണ്ഡത്തിലോ ആയിരിക്കാം. സന്ദേശമയയ്‌ക്കൽ വഴി ക്ലയന്റും സെർവറും തമ്മിലുള്ള ആശയവിനിമയത്തിന്റെ ഒരു ഡയഗ്രം ചുവടെയുണ്ട്.

സന്ദേശമയയ്‌ക്കൽ പൂർണ്ണമായും അസമന്വിതമായതിനാൽ, ക്ലയന്റിനായി കൈമാറ്റം 2 ഘട്ടങ്ങളായി തിരിച്ചിരിക്കുന്നു:

1. അഭ്യർത്ഥന സമർപ്പിക്കുക

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

   എക്സ്ചേഞ്ച് എക്സ്ചേഞ്ച് പോയിന്റിന്റെ തനതായ പേര്
   ResponseMatchingTag പ്രതികരണം പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള പ്രാദേശിക ലേബൽ. ഉദാഹരണത്തിന്, വ്യത്യസ്ത ഉപയോക്താക്കൾക്ക് സമാനമായ നിരവധി അഭ്യർത്ഥനകൾ അയയ്ക്കുന്ന സാഹചര്യത്തിൽ.
   അഭ്യർത്ഥന നിർവ്വചനം - അഭ്യർത്ഥന ശരീരം
   ഹാൻഡ്ലർപ്രോസസ്സ് ‒ ഹാൻഡ്ലറുടെ PID. ഈ പ്രക്രിയയ്ക്ക് സെർവറിൽ നിന്ന് ഒരു പ്രതികരണം ലഭിക്കും.

2. പ്രതികരണം പ്രോസസ്സ് ചെയ്യുന്നു

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   പ്രതികരണ പേലോഡ് - സെർവർ പ്രതികരണം.

സെർവറിനായി, പ്രക്രിയയിൽ 2 ഘട്ടങ്ങളും ഉൾപ്പെടുന്നു:

1. എക്സ്ചേഞ്ച് പോയിന്റ് ആരംഭിക്കുന്നു
2. സ്വീകരിച്ച അഭ്യർത്ഥനകളുടെ പ്രോസസ്സിംഗ്

ഈ ടെംപ്ലേറ്റ് കോഡ് ഉപയോഗിച്ച് ചിത്രീകരിക്കാം. ഒരു കൃത്യമായ സമയ രീതി നൽകുന്ന ഒരു ലളിതമായ സേവനം ഞങ്ങൾ നടപ്പിലാക്കേണ്ടതുണ്ടെന്ന് പറയാം.

സെർവർ കോഡ്

api.hrl-ൽ സേവന API നിർവചിക്കാം:

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

നമുക്ക് time_controller.erl-ൽ സേവന കൺട്രോളർ നിർവചിക്കാം

%% В примере показан только значимый код. Вставив его в шаблон gen_server можно получить рабочий сервис.

%% инициализация gen_server
init(Args) ->
  %% подключение к точке обмена
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% обработка события потери связи с точкой обмена. Это же событие приходит, если точка обмена еще не запустилась.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% обработка API
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% завершение работы gen_server
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

ക്ലയന്റ് കോഡ്

സേവനത്തിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്നതിന്, നിങ്ങൾക്ക് ക്ലയന്റിൽ എവിടെയും സന്ദേശമയയ്‌ക്കൽ അഭ്യർത്ഥന API-ലേക്ക് വിളിക്കാം:

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% repeat or fail logic
end

ഒരു വിതരണം ചെയ്ത സിസ്റ്റത്തിൽ, ഘടകങ്ങളുടെ കോൺഫിഗറേഷൻ വളരെ വ്യത്യസ്തമായിരിക്കും, അഭ്യർത്ഥന സമയത്ത്, സന്ദേശമയയ്‌ക്കൽ ഇതുവരെ ആരംഭിച്ചേക്കില്ല, അല്ലെങ്കിൽ സേവന കൺട്രോളർ അഭ്യർത്ഥനയ്‌ക്ക് സേവനം നൽകാൻ തയ്യാറാകില്ല. അതിനാൽ, ഞങ്ങൾക്ക് സന്ദേശമയയ്‌ക്കൽ പ്രതികരണം പരിശോധിക്കുകയും പരാജയ കേസ് കൈകാര്യം ചെയ്യുകയും വേണം.
വിജയകരമായി അയച്ചതിന് ശേഷം, ക്ലയന്റിന് സേവനത്തിൽ നിന്ന് ഒരു പ്രതികരണമോ പിശകോ ലഭിക്കും.
നമുക്ക് handle_info-ൽ രണ്ട് കേസുകളും കൈകാര്യം ചെയ്യാം:

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

അഭ്യർത്ഥന-ചങ്ക്ഡ് പ്രതികരണം

വലിയ സന്ദേശങ്ങൾ അയക്കുന്നത് ഒഴിവാക്കുന്നതാണ് നല്ലത്. മുഴുവൻ സിസ്റ്റത്തിന്റെയും പ്രതികരണശേഷിയും സുസ്ഥിരമായ പ്രവർത്തനവും ഇതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു ചോദ്യത്തിനുള്ള പ്രതികരണം വളരെയധികം മെമ്മറി എടുക്കുകയാണെങ്കിൽ, അതിനെ ഭാഗങ്ങളായി വിഭജിക്കേണ്ടത് നിർബന്ധമാണ്.

അത്തരം കേസുകളുടെ രണ്ട് ഉദാഹരണങ്ങൾ ഞാൻ നിങ്ങൾക്ക് നൽകാം:

• ഘടകങ്ങൾ ഫയലുകൾ പോലുള്ള ബൈനറി ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നു. പ്രതികരണത്തെ ചെറിയ ഭാഗങ്ങളായി വിഭജിക്കുന്നത് ഏത് വലുപ്പത്തിലുള്ള ഫയലുകളിലും കാര്യക്ഷമമായി പ്രവർത്തിക്കാനും മെമ്മറി ഓവർഫ്ലോകൾ ഒഴിവാക്കാനും നിങ്ങളെ സഹായിക്കുന്നു.
• ലിസ്റ്റിംഗുകൾ. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഡാറ്റാബേസിലെ ഒരു വലിയ പട്ടികയിൽ നിന്ന് എല്ലാ റെക്കോർഡുകളും തിരഞ്ഞെടുത്ത് അവയെ മറ്റൊരു ഘടകത്തിലേക്ക് മാറ്റേണ്ടതുണ്ട്.

ഈ പ്രതികരണങ്ങളെ ഞാൻ ലോക്കോമോട്ടീവ് എന്ന് വിളിക്കുന്നു. എന്തായാലും, 1024 MB യുടെ 1 സന്ദേശങ്ങൾ 1 GB എന്ന ഒറ്റ സന്ദേശത്തേക്കാൾ മികച്ചതാണ്.

Erlang ക്ലസ്റ്ററിൽ, ഞങ്ങൾക്ക് ഒരു അധിക ആനുകൂല്യം ലഭിക്കുന്നു - എക്സ്ചേഞ്ച് പോയിന്റിലെയും നെറ്റ്‌വർക്കിലെയും ലോഡ് കുറയ്ക്കുന്നു, കാരണം പ്രതികരണങ്ങൾ ഉടൻ സ്വീകർത്താവിന് അയയ്ക്കുന്നു, എക്സ്ചേഞ്ച് പോയിന്റ് മറികടന്ന്.

അഭ്യർത്ഥനയോടെയുള്ള പ്രതികരണം

ഡയലോഗ് സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്നതിനുള്ള ആർപിസി പാറ്റേണിന്റെ വളരെ അപൂർവമായ പരിഷ്ക്കരണമാണിത്.

പ്രസിദ്ധീകരിക്കുക-സബ്‌സ്‌ക്രൈബ് ചെയ്യുക (ഡാറ്റ ഡിസ്ട്രിബ്യൂഷൻ ട്രീ)

ഇവന്റ്-ഡ്രൈവ് സിസ്റ്റങ്ങൾ ഡാറ്റ തയ്യാറായാലുടൻ അവ ഉപഭോക്താക്കളിലേക്ക് എത്തിക്കുന്നു. അതിനാൽ, ഒരു പുൾ അല്ലെങ്കിൽ പോൾ മോഡലിനെക്കാൾ സിസ്റ്റങ്ങൾ ഒരു പുഷ് മോഡലിന് കൂടുതൽ സാധ്യതയുണ്ട്. നിരന്തരം അഭ്യർത്ഥിച്ച് ഡാറ്റയ്ക്കായി കാത്തിരിക്കുന്നതിലൂടെ വിഭവങ്ങൾ പാഴാകുന്നത് ഒഴിവാക്കാൻ ഈ സവിശേഷത നിങ്ങളെ അനുവദിക്കുന്നു.
ഒരു നിർദ്ദിഷ്ട വിഷയത്തിലേക്ക് വരിക്കാരായ ഉപഭോക്താക്കൾക്ക് ഒരു സന്ദേശം വിതരണം ചെയ്യുന്ന പ്രക്രിയ ചിത്രം കാണിക്കുന്നു.

ഈ പാറ്റേൺ ഉപയോഗിക്കുന്നതിനുള്ള ക്ലാസിക് ഉദാഹരണങ്ങളാണ് സംസ്ഥാനത്തിന്റെ വിതരണം: കമ്പ്യൂട്ടർ ഗെയിമുകളിലെ ഗെയിം ലോകം, എക്സ്ചേഞ്ചുകളിലെ മാർക്കറ്റ് ഡാറ്റ, ഡാറ്റ ഫീഡുകളിലെ ഉപയോഗപ്രദമായ വിവരങ്ങൾ.

സബ്സ്ക്രൈബർ കോഡ് നോക്കാം:

init(_Args) ->
  %% подписываемся на обменник, ключ = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% если точка обмена недоступна, то пытаемся переподключиться
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% обрабатываем пришедшие сообщения
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% при остановке потребителя - отключаемся от точки обмена
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

ഏത് സൗകര്യപ്രദമായ സ്ഥലത്തും ഒരു സന്ദേശം പ്രസിദ്ധീകരിക്കാൻ ഉറവിടത്തിന് ഫംഗ്‌ഷനെ വിളിക്കാനാകും:

messaging:publish_message(Exchange, Key, Message).

എക്സ്ചേഞ്ച് - എക്സ്ചേഞ്ച് പോയിന്റിന്റെ പേര്,
കീ - റൂട്ടിംഗ് കീ
സന്ദേശം - പേലോഡ്

വിപരീതമായി പ്രസിദ്ധീകരിക്കുക-സബ്‌സ്‌ക്രൈബ് ചെയ്യുക

പബ്-സബ് വിപുലീകരിക്കുന്നതിലൂടെ, ലോഗിംഗിന് സൗകര്യപ്രദമായ ഒരു പാറ്റേൺ നിങ്ങൾക്ക് ലഭിക്കും. ഉറവിടങ്ങളുടെയും ഉപഭോക്താക്കളുടെയും കൂട്ടം തികച്ചും വ്യത്യസ്തമായിരിക്കും. ഒരു ഉപഭോക്താവും ഒന്നിലധികം ഉറവിടങ്ങളുമുള്ള ഒരു കേസ് ചിത്രം കാണിക്കുന്നു.

ടാസ്‌ക് വിതരണ രീതി

റിപ്പോർട്ടുകൾ സൃഷ്‌ടിക്കുക, അറിയിപ്പുകൾ കൈമാറുക, മൂന്നാം കക്ഷി സിസ്റ്റങ്ങളിൽ നിന്ന് ഡാറ്റ വീണ്ടെടുക്കുക തുടങ്ങിയ മാറ്റിവെച്ച പ്രോസസ്സിംഗ് ജോലികൾ മിക്കവാറും എല്ലാ പ്രോജക്റ്റുകളിലും ഉൾപ്പെടുന്നു. ഈ ടാസ്‌ക്കുകൾ നിർവഹിക്കുന്ന സിസ്റ്റത്തിന്റെ ത്രൂപുട്ട് ഹാൻഡ്‌ലറുകൾ ചേർത്ത് എളുപ്പത്തിൽ സ്കെയിൽ ചെയ്യാൻ കഴിയും. ഞങ്ങൾക്ക് അവശേഷിക്കുന്നത് പ്രോസസ്സറുകളുടെ ഒരു ക്ലസ്റ്റർ രൂപീകരിക്കുകയും അവയ്ക്കിടയിൽ ടാസ്‌ക്കുകൾ തുല്യമായി വിതരണം ചെയ്യുകയും ചെയ്യുക എന്നതാണ്.

3 ഹാൻഡ്ലറുകളുടെ ഉദാഹരണം ഉപയോഗിച്ച് ഉണ്ടാകുന്ന സാഹചര്യങ്ങൾ നോക്കാം. ടാസ്‌ക് വിതരണത്തിന്റെ ഘട്ടത്തിൽ പോലും, വിതരണത്തിന്റെ ന്യായവും കൈകാര്യം ചെയ്യുന്നവരുടെ ഓവർഫ്ലോയും ചോദ്യം ഉയർന്നുവരുന്നു. റൗണ്ട് റോബിൻ വിതരണത്തിന് ന്യായമായ ഉത്തരവാദിത്തം ഉണ്ടായിരിക്കും, കൂടാതെ ഹാൻഡ്‌ലർമാരുടെ ഓവർഫ്ലോ ഒരു സാഹചര്യം ഒഴിവാക്കാൻ, ഞങ്ങൾ ഒരു നിയന്ത്രണം കൊണ്ടുവരും prefetch_limit. ക്ഷണികമായ സാഹചര്യങ്ങളിൽ prefetch_limit എല്ലാ ജോലികളും സ്വീകരിക്കുന്നതിൽ നിന്ന് ഒരു ഹാൻഡ്ലറെ തടയും.

സന്ദേശമയയ്‌ക്കൽ ക്യൂകളും പ്രോസസ്സിംഗ് മുൻഗണനയും നിയന്ത്രിക്കുന്നു. ടാസ്‌ക്കുകൾ എത്തുമ്പോൾ പ്രോസസ്സറുകൾക്ക് ലഭിക്കുന്നു. ടാസ്ക് വിജയകരമായി പൂർത്തിയാക്കാം അല്ലെങ്കിൽ പരാജയപ്പെടാം:

• messaging:ack(Tack) - സന്ദേശം വിജയകരമായി പ്രോസസ്സ് ചെയ്താൽ വിളിക്കുന്നു
• messaging:nack(Tack) - എല്ലാ അടിയന്തിര സാഹചര്യങ്ങളിലും വിളിക്കുന്നു. ടാസ്‌ക് തിരികെ ലഭിച്ചുകഴിഞ്ഞാൽ, സന്ദേശമയയ്‌ക്കൽ അത് മറ്റൊരു ഹാൻഡ്‌ലർക്ക് കൈമാറും.

മൂന്ന് ടാസ്‌ക്കുകൾ പ്രോസസ്സ് ചെയ്യുമ്പോൾ സങ്കീർണ്ണമായ ഒരു പരാജയം സംഭവിച്ചുവെന്ന് കരുതുക: പ്രോസസ്സർ 1, ടാസ്‌ക് സ്വീകരിച്ച ശേഷം, എക്സ്ചേഞ്ച് പോയിന്റിലേക്ക് ഒന്നും റിപ്പോർട്ട് ചെയ്യാൻ സമയമില്ലാതെ തകർന്നു. ഈ സാഹചര്യത്തിൽ, എക്‌സ്‌ചേഞ്ച് പോയിന്റ്, എക്‌സ്‌ചേഞ്ച് ടൈംഔട്ട് കാലഹരണപ്പെട്ടതിന് ശേഷം മറ്റൊരു ഹാൻഡ്‌ലർക്ക് ചുമതല കൈമാറും. ചില കാരണങ്ങളാൽ, ഹാൻഡ്‌ലർ 3 ടാസ്‌ക് ഉപേക്ഷിച്ച് മയക്കത്തിലേക്ക് അയച്ചു; അതിന്റെ ഫലമായി, അത് വിജയകരമായി പൂർത്തിയാക്കിയ മറ്റൊരു ഹാൻഡ്‌ലറിലേക്കും ടാസ്‌ക് കൈമാറി.

പ്രാഥമിക സംഗ്രഹം

വിതരണം ചെയ്ത സിസ്റ്റങ്ങളുടെ അടിസ്ഥാന നിർമാണ ബ്ലോക്കുകൾ ഞങ്ങൾ കവർ ചെയ്തു, എർലാങ്/എലിക്‌സിറിൽ അവയുടെ ഉപയോഗത്തെക്കുറിച്ച് അടിസ്ഥാനപരമായ ധാരണയും നേടിയിട്ടുണ്ട്.

അടിസ്ഥാന പാറ്റേണുകൾ സംയോജിപ്പിക്കുന്നതിലൂടെ, ഉയർന്നുവരുന്ന പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് നിങ്ങൾക്ക് സങ്കീർണ്ണമായ മാതൃകകൾ നിർമ്മിക്കാൻ കഴിയും.

പരമ്പരയുടെ അവസാന ഭാഗത്ത്, സേവനങ്ങൾ സംഘടിപ്പിക്കുക, റൂട്ടിംഗ്, ബാലൻസ് ചെയ്യൽ എന്നിവയിലെ പൊതുവായ പ്രശ്നങ്ങൾ ഞങ്ങൾ നോക്കും, കൂടാതെ സിസ്റ്റങ്ങളുടെ സ്കേലബിളിറ്റിയുടെയും തെറ്റ് സഹിഷ്ണുതയുടെയും പ്രായോഗിക വശത്തെക്കുറിച്ചും സംസാരിക്കും.

രണ്ടാം ഭാഗത്തിന്റെ അവസാനം.

ഫോട്ടോ മാരിയസ് ക്രിസ്റ്റെൻസൻ
websequencediagrams.com ഉപയോഗിച്ച് തയ്യാറാക്കിയ ചിത്രീകരണങ്ങൾ

അവലംബം: www.habr.com