ການກໍ່ສ້າງຕັນຂອງຄໍາຮ້ອງສະຫມັກແຈກຢາຍ. ວິທີການທໍາອິດ

ໃນທີ່ສຸດ ບົດຄວາມ ພວກເຮົາໄດ້ກວດເບິ່ງພື້ນຖານທິດສະດີຂອງສະຖາປັດຕະຍະກໍາ reactive. ມັນເຖິງເວລາທີ່ຈະເວົ້າກ່ຽວກັບການໄຫລຂອງຂໍ້ມູນ, ວິທີການປະຕິບັດລະບົບ Erlang / Elixir ທີ່ມີປະຕິກິລິຍາແລະຮູບແບບການສົ່ງຂໍ້ຄວາມໃນພວກມັນ:

• ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຕອບ​ສະ​ຫນອງ​
• ການ​ຕອບ​ສະ​ຫນອງ​ການ​ຮ້ອງ​ຂໍ​
• ຕອບ​ກັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​
• ເຜີຍແຜ່-ສະໝັກໃຊ້
• Inverted Publish-subscribe
• ການແຈກຢາຍໜ້າວຽກ

SOA, MSA ແລະການສົ່ງຂໍ້ຄວາມ

SOA, MSA ແມ່ນສະຖາປັດຕະຍະກໍາລະບົບທີ່ກໍານົດກົດລະບຽບສໍາລັບລະບົບການກໍ່ສ້າງ, ໃນຂະນະທີ່ການສົ່ງຂໍ້ຄວາມສະຫນອງພື້ນຖານສໍາລັບການປະຕິບັດຂອງພວກເຂົາ.

ຂ້ອຍບໍ່ຕ້ອງການທີ່ຈະສົ່ງເສີມນີ້ຫຼືສະຖາປັດຕະຍະກໍາລະບົບນັ້ນ. ຂ້ອຍແມ່ນສໍາລັບການນໍາໃຊ້ການປະຕິບັດທີ່ມີປະສິດທິພາບແລະເປັນປະໂຫຍດທີ່ສຸດສໍາລັບໂຄງການແລະທຸລະກິດສະເພາະ. ສິ່ງໃດກໍ່ຕາມທີ່ພວກເຮົາເລືອກ, ມັນດີກວ່າທີ່ຈະສ້າງລະບົບຕັນດ້ວຍສາຍຕາຂອງ Unix-way: ອົງປະກອບທີ່ມີການເຊື່ອມຕໍ່ຫນ້ອຍທີ່ສຸດ, ຮັບຜິດຊອບສໍາລັບແຕ່ລະຫນ່ວຍງານ. ວິທີການ API ດໍາເນີນການທີ່ງ່າຍດາຍທີ່ສຸດທີ່ເປັນໄປໄດ້ກັບຫນ່ວຍງານ.

ການສົ່ງຂໍ້ຄວາມແມ່ນ, ຕາມຊື່ແນະນໍາ, ນາຍຫນ້າຂໍ້ຄວາມ. ຈຸດປະສົງຕົ້ນຕໍຂອງມັນແມ່ນເພື່ອຮັບແລະສົ່ງຂໍ້ຄວາມ. ມັນຮັບຜິດຊອບສໍາລັບການໂຕ້ຕອບສໍາລັບການສົ່ງຂໍ້ມູນ, ການສ້າງຊ່ອງທາງທີ່ມີເຫດຜົນສໍາລັບການສົ່ງຂໍ້ມູນພາຍໃນລະບົບ, ເສັ້ນທາງແລະການດຸ່ນດ່ຽງ, ເຊັ່ນດຽວກັນກັບການຈັດການຄວາມຜິດໃນລະດັບລະບົບ.
ການສົ່ງຂໍ້ຄວາມທີ່ພວກເຮົາກໍາລັງພັດທະນາບໍ່ໄດ້ພະຍາຍາມແຂ່ງຂັນກັບຫຼືປ່ຽນແທນ rabbitmq. ຄຸນ​ນະ​ສົມ​ບັດ​ຕົ້ນ​ຕໍ​ຂອງ​ຕົນ​:

• ການແຜ່ກະຈາຍ.
  ຈຸດແລກປ່ຽນສາມາດຖືກສ້າງຂື້ນຢູ່ໃນທຸກກຸ່ມຂອງກຸ່ມ, ໃກ້ທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້ກັບລະຫັດທີ່ໃຊ້ພວກມັນ.
• ຄວາມລຽບງ່າຍ.
  ສຸມໃສ່ການຫຼຸດຜ່ອນລະຫັດ boilerplate ແລະຄວາມງ່າຍຂອງການນໍາໃຊ້.
• ການປະຕິບັດທີ່ດີກວ່າ.
  ພວກເຮົາບໍ່ໄດ້ພະຍາຍາມເຮັດເລື້ມຄືນການເຮັດວຽກຂອງ rabbitmq, ແຕ່ເນັ້ນໃສ່ພຽງແຕ່ຊັ້ນຖາປັດຕະຍະແລະການຂົນສົ່ງ, ທີ່ພວກເຮົາເຫມາະກັບ OTP ເທົ່າທີ່ເປັນໄປໄດ້, ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍ.
• ຢືດຢຸ່ນ.
  ແຕ່ລະບໍລິການສາມາດລວມຕົວແບບແລກປ່ຽນຈໍານວນຫຼາຍ.
• ຄວາມຢືດຢຸ່ນໂດຍການອອກແບບ.
• ຄວາມສາມາດໃນການຂະຫຍາຍ.
  ການສົ່ງຂໍ້ຄວາມຈະເລີນເຕີບໂຕດ້ວຍແອັບພລິເຄຊັນ. ໃນຂະນະທີ່ການໂຫຼດເພີ່ມຂຶ້ນ, ທ່ານສາມາດຍ້າຍຈຸດແລກປ່ຽນກັບເຄື່ອງຈັກສ່ວນບຸກຄົນ.

ຂໍ້ສັງເກດ. ໃນຂໍ້ກໍານົດຂອງອົງການຈັດຕັ້ງລະຫັດ, ໂຄງການ meta ແມ່ນເຫມາະສົມດີສໍາລັບລະບົບ Erlang / Elixir ສະລັບສັບຊ້ອນ. ລະຫັດໂຄງການທັງຫມົດແມ່ນຢູ່ໃນຫນຶ່ງ repository - ໂຄງການ umbrella . ໃນເວລາດຽວກັນ, microservices ແມ່ນຢູ່ໂດດດ່ຽວສູງສຸດແລະປະຕິບັດການດໍາເນີນງານງ່າຍດາຍທີ່ຮັບຜິດຊອບສໍາລັບຫນ່ວຍງານແຍກຕ່າງຫາກ. ດ້ວຍວິທີການນີ້, ມັນງ່າຍທີ່ຈະຮັກສາ API ຂອງລະບົບທັງຫມົດ, ມັນງ່າຍທີ່ຈະເຮັດການປ່ຽນແປງ, ມັນສະດວກໃນການຂຽນຫນ່ວຍແລະການທົດສອບການເຊື່ອມໂຍງ.

ອົງປະກອບຂອງລະບົບຕິດຕໍ່ພົວພັນໂດຍກົງຫຼືຜ່ານນາຍຫນ້າ. ຈາກທັດສະນະການສົ່ງຂໍ້ຄວາມ, ແຕ່ລະການບໍລິການມີຫຼາຍໄລຍະຊີວິດ:

• ການເລີ່ມຕົ້ນການບໍລິການ.
  ໃນຂັ້ນຕອນນີ້, ຂະບວນການແລະຄວາມເພິ່ງພາອາໄສທີ່ປະຕິບັດການບໍລິການໄດ້ຖືກຕັ້ງຄ່າແລະເປີດຕົວ.
• ການສ້າງຈຸດແລກປ່ຽນ.
  ການບໍລິການສາມາດນໍາໃຊ້ຈຸດແລກປ່ຽນຄົງທີ່ທີ່ລະບຸໄວ້ໃນການຕັ້ງຄ່າຂອງ node, ຫຼືສ້າງຈຸດແລກປ່ຽນແບບເຄື່ອນໄຫວ.
• ການລົງທະບຽນການບໍລິການ.
  ເພື່ອໃຫ້ການບໍລິການຮັບໃຊ້ການຮ້ອງຂໍ, ມັນຕ້ອງໄດ້ຮັບການລົງທະບຽນຢູ່ໃນຈຸດແລກປ່ຽນ.
• ເຮັດວຽກປົກກະຕິ.
  ການບໍລິການຜະລິດວຽກງານທີ່ເປັນປະໂຫຍດ.
• ປິດ​ເຄື່ອງ.
  ມີ 2 ປະເພດຂອງການປິດທີ່ເປັນໄປໄດ້: ປົກກະຕິແລະສຸກເສີນ. ໃນລະຫວ່າງການດໍາເນີນງານປົກກະຕິ, ການບໍລິການຖືກຕັດການເຊື່ອມຕໍ່ຈາກຈຸດແລກປ່ຽນແລະຢຸດ. ໃນສະຖານະການສຸກເສີນ, ການສົ່ງຂໍ້ຄວາມຈະດໍາເນີນການຫນຶ່ງຂອງ scripts ລົ້ມເຫລວ.

ມັນເບິ່ງຂ້ອນຂ້າງສັບສົນ, ແຕ່ລະຫັດບໍ່ແມ່ນທັງຫມົດທີ່ຫນ້າຢ້ານ. ຕົວຢ່າງລະຫັດທີ່ມີຄໍາຄິດເຫັນຈະຖືກໃຫ້ຢູ່ໃນການວິເຄາະຂອງແມ່ແບບຕໍ່ມາເລັກນ້ອຍ.

ການແລກປ່ຽນ

ຈຸດແລກປ່ຽນແມ່ນຂະບວນການສົ່ງຂໍ້ຄວາມທີ່ປະຕິບັດເຫດຜົນຂອງການໂຕ້ຕອບກັບອົງປະກອບພາຍໃນແມ່ແບບການສົ່ງຂໍ້ຄວາມ. ໃນທຸກຕົວຢ່າງທີ່ນໍາສະເຫນີຂ້າງລຸ່ມນີ້, ອົງປະກອບປະຕິສໍາພັນຜ່ານຈຸດແລກປ່ຽນ, ການປະສົມປະສານຂອງຮູບແບບການສົ່ງຂໍ້ຄວາມ.

ຮູບແບບການແລກປ່ຽນຂໍ້ຄວາມ (MEPs)

ໃນທົ່ວໂລກ, ຮູບແບບການແລກປ່ຽນສາມາດແບ່ງອອກເປັນສອງທາງແລະຫນຶ່ງທາງ. ອະດີດຫມາຍເຖິງການຕອບສະຫນອງຕໍ່ຂໍ້ຄວາມທີ່ເຂົ້າມາ, ສຸດທ້າຍບໍ່ໄດ້ເຮັດ. ຕົວຢ່າງຄລາສສິກຂອງຮູບແບບສອງທາງໃນສະຖາປັດຕະຍະກໍາລູກຄ້າ - ເຄື່ອງແມ່ຂ່າຍແມ່ນຮູບແບບການຮ້ອງຂໍການຕອບສະຫນອງ. ໃຫ້ເບິ່ງຢູ່ໃນແມ່ແບບແລະການດັດແປງຂອງມັນ.

ຄໍາຕອບຄໍາຮ້ອງຂໍຫຼື RPC

RPC ຖືກນໍາໃຊ້ໃນເວລາທີ່ພວກເຮົາຕ້ອງການໄດ້ຮັບການຕອບສະຫນອງຈາກຂະບວນການອື່ນ. ຂະບວນການນີ້ອາດຈະເຮັດວຽກຢູ່ໃນ node ດຽວກັນຫຼືຕັ້ງຢູ່ໃນທະວີບທີ່ແຕກຕ່າງກັນ. ຂ້າງລຸ່ມນີ້ແມ່ນແຜນວາດຂອງການໂຕ້ຕອບລະຫວ່າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍໂດຍຜ່ານການສົ່ງຂໍ້ຄວາມ.

ເນື່ອງຈາກການສົ່ງຂໍ້ຄວາມແມ່ນ asynchronous ຢ່າງສົມບູນ, ສໍາລັບລູກຄ້າ, ການແລກປ່ຽນແບ່ງອອກເປັນ 2 ໄລຍະ:

1. ສົ່ງຄໍາຮ້ອງຂໍ

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

   ການແລກປ່ຽນ - ຊື່ທີ່ເປັນເອກະລັກຂອງຈຸດແລກປ່ຽນ
   ResponseMatchingTag - ປ້າຍທ້ອງຖິ່ນເພື່ອປະມວນຜົນການຕອບສະໜອງ. ຕົວຢ່າງ, ໃນກໍລະນີຂອງການສົ່ງຄໍາຮ້ອງຂໍຫຼາຍອັນທີ່ເປັນຂອງຜູ້ຊົມໃຊ້ທີ່ແຕກຕ່າງກັນ.
   ຄໍາ​ນິ​ຍາມ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ - ຂໍ​ຮ່າງ​ກາຍ​
   ຂະບວນການຈັດການ - PID ຂອງຕົວຈັດການ. ຂະບວນການນີ້ຈະໄດ້ຮັບການຕອບສະຫນອງຈາກເຄື່ອງແມ່ຂ່າຍ.

2. ກຳລັງປະມວນຜົນການຕອບສະໜອງ

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

   ການຕອບສະ ໜອງ Payload - ເຊີບເວີຕອບສະຫນອງ.

ສໍາລັບເຄື່ອງແມ່ຂ່າຍ, ຂະບວນການຍັງປະກອບດ້ວຍ 2 ໄລຍະ:

1. ເລີ່ມຕົ້ນຈຸດແລກປ່ຽນ
2. ການປະມວນຜົນຄໍາຮ້ອງຂໍທີ່ໄດ້ຮັບ

ໃຫ້ເຮົາສະແດງຕົວຢ່າງແມ່ແບບນີ້ດ້ວຍລະຫັດ. ໃຫ້ເວົ້າວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປະຕິບັດການບໍລິການທີ່ງ່າຍດາຍທີ່ສະຫນອງວິທີການທີ່ໃຊ້ເວລາທີ່ແນ່ນອນດຽວ.

ລະຫັດເຊີບເວີ

ໃຫ້ກໍານົດ API ການບໍລິການໃນ api.hrl:

%% =====================================================
%%  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};

ການ​ຕອບ​ສະ​ຫນອງ​ການ​ຮ້ອງ​ຂໍ​

ມັນດີທີ່ສຸດທີ່ຈະຫຼີກເວັ້ນການສົ່ງຂໍ້ຄວາມຂະຫນາດໃຫຍ່. ການຕອບສະຫນອງແລະຄວາມຫມັ້ນຄົງຂອງລະບົບທັງຫມົດແມ່ນຂຶ້ນກັບນີ້. ຖ້າການຕອບສະຫນອງຕໍ່ການສອບຖາມໃຊ້ເວລາເຖິງຄວາມຊົງຈໍາຫຼາຍ, ຫຼັງຈາກນັ້ນການແຍກມັນອອກເປັນພາກສ່ວນແມ່ນບັງຄັບ.

ຂ້າພະເຈົ້າຂໍຍົກຕົວຢ່າງບາງອັນຂອງກໍລະນີດັ່ງກ່າວ:

• ອົງປະກອບແລກປ່ຽນຂໍ້ມູນຖານສອງ, ເຊັ່ນໄຟລ໌. ການແຍກການຕອບສະໜອງອອກເປັນສ່ວນນ້ອຍໆຈະຊ່ວຍໃຫ້ທ່ານເຮັດວຽກໄດ້ຢ່າງມີປະສິດທິພາບກັບໄຟລ໌ທຸກຂະໜາດ ແລະ ຫຼີກລ່ຽງຄວາມຈຳທີ່ລົ້ນເຫຼືອ.
• ລາຍຊື່. ຕົວຢ່າງ, ພວກເຮົາຈໍາເປັນຕ້ອງເລືອກບັນທຶກທັງຫມົດຈາກຕາຕະລາງຂະຫນາດໃຫຍ່ໃນຖານຂໍ້ມູນແລະໂອນພວກມັນໄປຫາອົງປະກອບອື່ນ.

ຂ້າພະເຈົ້າໂທຫາການຕອບສະຫນອງເຫຼົ່ານີ້ locomotive. ໃນກໍລະນີໃດກໍ່ຕາມ, 1024 ຂໍ້ຄວາມຂອງ 1 MB ແມ່ນດີກ່ວາຂໍ້ຄວາມດຽວຂອງ 1 GB.

ໃນກຸ່ມ Erlang, ພວກເຮົາໄດ້ຮັບຜົນປະໂຫຍດເພີ່ມເຕີມ - ການຫຼຸດຜ່ອນການໂຫຼດໃນຈຸດແລກປ່ຽນແລະເຄືອຂ່າຍ, ນັບຕັ້ງແຕ່ການຕອບໂຕ້ຖືກສົ່ງໄປຫາຜູ້ຮັບທັນທີ, ຂ້າມຈຸດແລກປ່ຽນ.

ຕອບ​ກັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​

ນີ້ແມ່ນການດັດແກ້ທີ່ຫາຍາກຫຼາຍຂອງຮູບແບບ RPC ສໍາລັບການກໍ່ສ້າງລະບົບໂຕ້ຕອບ.

Publish-subscribe (ຕົ້ນໄມ້ການແຈກຢາຍຂໍ້ມູນ)

ລະບົບທີ່ຂັບເຄື່ອນເຫດການສົ່ງພວກມັນໃຫ້ກັບຜູ້ບໍລິໂພກທັນທີທີ່ຂໍ້ມູນກຽມພ້ອມ. ດັ່ງນັ້ນ, ລະບົບແມ່ນມັກຈະເປັນຕົວແບບຊຸກຍູ້ຫຼາຍກ່ວາແບບດຶງຫຼືແບບສໍາຫຼວດ. ຄຸນນະສົມບັດນີ້ອະນຸຍາດໃຫ້ທ່ານເພື່ອຫຼີກເວັ້ນການສູນເສຍຊັບພະຍາກອນໂດຍການຮ້ອງຂໍຢ່າງຕໍ່ເນື່ອງແລະລໍຖ້າຂໍ້ມູນ.
ຕົວເລກສະແດງໃຫ້ເຫັນເຖິງຂະບວນການແຈກຢາຍຂໍ້ຄວາມໃຫ້ກັບຜູ້ບໍລິໂພກທີ່ຈອງຫົວຂໍ້ສະເພາະ.

ຕົວຢ່າງຄລາສສິກຂອງການນໍາໃຊ້ຮູບແບບນີ້ແມ່ນການແຈກຢາຍຂອງລັດ: ໂລກເກມໃນເກມຄອມພິວເຕີ, ຂໍ້ມູນຕະຫຼາດໃນການແລກປ່ຽນ, ຂໍ້ມູນທີ່ເປັນປະໂຫຍດໃນຂໍ້ມູນ.

ມາເບິ່ງລະຫັດຜູ້ຈອງ:

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).

ການແລກປ່ຽນ - ຊື່​ຂອງ​ຈຸດ​ແລກ​ປ່ຽນ​,
ທີ່ສໍາຄັນ - ກະແຈກຳນົດເສັ້ນທາງ
ຂໍ້ຄວາມ - ໂຫຼດ

Inverted Publish-subscribe

ໂດຍການຂະຫຍາຍ pub-sub, ທ່ານສາມາດໄດ້ຮັບຮູບແບບທີ່ສະດວກສໍາລັບການຕັດໄມ້. ຊຸດຂອງແຫຼ່ງແລະຜູ້ບໍລິໂພກສາມາດແຕກຕ່າງກັນຫມົດ. ຕົວເລກສະແດງໃຫ້ເຫັນກໍລະນີທີ່ມີຜູ້ບໍລິໂພກຫນຶ່ງແລະຫຼາຍແຫຼ່ງ.

ຮູບແບບການແຈກຢາຍໜ້າວຽກ

ເກືອບທຸກໆໂຄງການກ່ຽວຂ້ອງກັບວຽກງານການປະມວນຜົນທີ່ເລື່ອນໄປ, ເຊັ່ນ: ການສ້າງບົດລາຍງານ, ການຈັດສົ່ງການແຈ້ງເຕືອນ, ແລະການດຶງຂໍ້ມູນຈາກລະບົບພາກສ່ວນທີສາມ. ອັດຕາການຜ່ານຂອງລະບົບທີ່ປະຕິບັດວຽກງານເຫຼົ່ານີ້ສາມາດປັບຂະຫນາດໄດ້ງ່າຍໂດຍການເພີ່ມຕົວຈັດການ. ທັງຫມົດທີ່ຍັງຄົງຢູ່ສໍາລັບພວກເຮົາແມ່ນເພື່ອປະກອບເປັນກຸ່ມຂອງໂປເຊດເຊີແລະແຈກຢາຍວຽກງານລະຫວ່າງພວກມັນໃຫ້ເທົ່າທຽມກັນ.

ຂໍໃຫ້ເບິ່ງສະຖານະການທີ່ເກີດຂື້ນໂດຍໃຊ້ຕົວຢ່າງຂອງ 3 handlers. ເຖິງແມ່ນວ່າຢູ່ໃນຂັ້ນຕອນຂອງການແຈກຢາຍວຽກງານ, ຄໍາຖາມກ່ຽວກັບຄວາມຍຸຕິທໍາຂອງການແຈກຢາຍແລະການລົ້ນຂອງຕົວຈັດການເກີດຂື້ນ. ການແຈກຢາຍແບບຮອບວຽນຈະຮັບຜິດຊອບຕໍ່ຄວາມຍຸຕິທໍາ, ແລະເພື່ອຫຼີກເວັ້ນການສະຖານະການ overflow ຂອງ handlers, ພວກເຮົາຈະແນະນໍາຂໍ້ຈໍາກັດ. prefetch_limit. ໃນເງື່ອນໄຂຊົ່ວຄາວ prefetch_limit ຈະປ້ອງກັນບໍ່ໃຫ້ຜູ້ຈັດການຄົນຫນຶ່ງໄດ້ຮັບວຽກງານທັງຫມົດ.

ການສົ່ງຂໍ້ຄວາມຈັດການຄິວ ແລະບູລິມະສິດການປະມວນຜົນ. ໂປເຊດເຊີໄດ້ຮັບວຽກງານເມື່ອພວກເຂົາມາຮອດ. ວຽກງານສາມາດສໍາເລັດສົບຜົນສໍາເລັດຫຼືລົ້ມເຫລວ:

• messaging:ack(Tack) - ເອີ້ນວ່າຖ້າຫາກວ່າຂໍ້ຄວາມໄດ້ຖືກປະມວນຜົນສົບຜົນສໍາເລັດ
• messaging:nack(Tack) - ເອີ້ນ​ວ່າ​ໃນ​ສະ​ຖາ​ນະ​ການ​ສຸກ​ເສີນ​ທັງ​ຫມົດ​. ເມື່ອວຽກງານຖືກສົ່ງຄືນ, ການສົ່ງຂໍ້ຄວາມຈະສົ່ງຕໍ່ໄປຫາຕົວຈັດການອື່ນ.

ສົມມຸດວ່າຄວາມລົ້ມເຫຼວທີ່ຊັບຊ້ອນເກີດຂຶ້ນໃນຂະນະທີ່ດໍາເນີນການສາມຫນ້າວຽກ: ໂປເຊດເຊີ 1, ຫຼັງຈາກໄດ້ຮັບຫນ້າວຽກ, crashed ໂດຍບໍ່ມີເວລາທີ່ຈະລາຍງານຫຍັງກັບຈຸດແລກປ່ຽນ. ໃນກໍລະນີນີ້, ຈຸດແລກປ່ຽນຈະໂອນຫນ້າວຽກໄປຫາຕົວຈັດການອື່ນຫຼັງຈາກຫມົດເວລາ ack ໄດ້ຫມົດອາຍຸ. ດ້ວຍເຫດຜົນບາງຢ່າງ, ຜູ້ຈັດການ 3 ໄດ້ປະຖິ້ມວຽກງານແລະສົ່ງ nack; ດັ່ງນັ້ນ, ວຽກງານດັ່ງກ່າວໄດ້ຖືກໂອນໄປຫາຜູ້ຈັດການອື່ນທີ່ເຮັດສໍາເລັດມັນ.

ບົດສະຫຼຸບເບື້ອງຕົ້ນ

ພວກເຮົາໄດ້ກວມເອົາການກໍ່ສ້າງພື້ນຖານຂອງລະບົບການແຈກຢາຍແລະໄດ້ຮັບຄວາມເຂົ້າໃຈພື້ນຖານຂອງການນໍາໃຊ້ຂອງພວກເຂົາໃນ Erlang / Elixir.

ໂດຍການລວມເອົາຮູບແບບພື້ນຖານ, ທ່ານສາມາດສ້າງ paradigms ສະລັບສັບຊ້ອນເພື່ອແກ້ໄຂບັນຫາທີ່ເກີດຂື້ນ.

ໃນພາກສຸດທ້າຍຂອງຊຸດ, ພວກເຮົາຈະເບິ່ງບັນຫາທົ່ວໄປຂອງການບໍລິການຈັດລຽງ, ເສັ້ນທາງແລະການດຸ່ນດ່ຽງ, ແລະຍັງເວົ້າກ່ຽວກັບພາກປະຕິບັດຂອງຂະຫນາດແລະຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງລະບົບ.

ສິ້ນສຸດພາກທີສອງ.

ການ​ຖ່າຍ​ຮູບ Marius Christensen
ຮູບປະກອບທີ່ກະກຽມໂດຍໃຊ້ websequencediagrams.com

ແຫຼ່ງຂໍ້ມູນ: www.habr.com