В අවසාන ලිපියයි අපි RabbitMQ පොකුරු දෝෂ ඉවසීම සහ ඉහළ ලබා ගැනීම සඳහා බැලුවා. දැන් අපි Apache Kafka ගැඹුරට හාරා බලමු.

මෙහි ප්‍රතිනිර්මාණ ඒකකය වන්නේ කොටසයි. සෑම මාතෘකාවකටම කොටස් එකක් හෝ කිහිපයක් ඇත. සෑම අංශයකටම අනුගාමිකයින් සමඟ හෝ නැතිව නායකයෙකු සිටී. මාතෘකාවක් නිර්මාණය කිරීමේදී, ඔබ කොටස් ගණන සහ අනුකරණ සංගුණකය සඳහන් කරයි. සාමාන්‍ය අගය 3 වේ, එයින් අදහස් වන්නේ අනුරූ තුනක්: එක් නායකයෙක් සහ අනුගාමිකයින් දෙදෙනෙක්.

සහල්. 1. තැරැව්කරුවන් තිදෙනෙකු අතර කොටස් හතරක් බෙදා හරිනු ලැබේ

සියලුම කියවීම් සහ ලිවීම් ඉල්ලීම් නායකයා වෙත ය. නවතම පණිවිඩ ලබා ගැනීම සඳහා අනුගාමිකයින් වරින් වර නායකයා වෙත ඉල්ලීම් යවයි. පාරිභෝගිකයින් කිසි විටෙකත් අනුගාමිකයින් වෙත නොයනු ඇත; දෙවැන්න පවතින්නේ අතිරික්තය සහ වැරදි ඉවසීම සඳහා පමණි.

කොටස් කිරීමේ අසාර්ථකත්වය

තැරැව්කරුවකු අසමත් වූ විට, අංශ කිහිපයක නායකයින් බොහෝ විට අසමත් වේ. ඒ සෑම එකක් තුළම, වෙනත් නෝඩයකින් අනුගාමිකයෙකු නායකයා බවට පත්වේ. ඇත්ත වශයෙන්ම, මෙය සැමවිටම එසේ නොවේ, මන්ද සමමුහුර්ත කිරීමේ සාධකය ද බලපායි: සමමුහුර්ත අනුගාමිකයින් සිටීද, එසේ නොවේ නම්, සමමුහුර්ත නොකළ අනුරුවකට මාරු වීමට අවසර තිබේද යන්න. නමුත් දැන් අපි දේවල් සංකීර්ණ නොකරමු.

තැරැව්කරු 3 ජාලයෙන් ඉවත් වන අතර, තැරැව්කරු 2 හි 2 වන කොටස සඳහා නව නායකයෙකු තේරී පත් වේ.

සහල්. 2. තැරැව්කරු 3 මිය යන අතර තැරැව්කරු 2 හි ඔහුගේ අනුගාමිකයා 2 කොටසේ නව නායකයා ලෙස තේරී පත් වේ.

එවිට තැරැව්කරු 1 පිටත් වන අතර 1 වන කොටස ද එහි නායකයා අහිමි වේ, එහි භූමිකාව තැරැව්කරු 2 වෙත පැවරේ.

සහල්. 3. එක බ්‍රෝකර් කෙනෙක් ඉතුරුයි. සියලුම නායකයින් ශුන්‍ය අතිරික්තයක් සහිත එක් තැරැව්කරුවෙකු මත සිටී

තැරැව්කරු 1 නැවත සබැඳිව පැමිණෙන විට, එය අනුගාමිකයින් හතර දෙනෙකු එක් කරයි, එක් එක් කොටස සඳහා යම් අතිරික්තයක් ලබා දෙයි. නමුත් සියලුම නායකයින් තවමත් තැරැව්කාර 2 හි රැඳී සිටියහ.

සහල්. 4. නායකයින් තැරැව්කරු 2 මත රැඳී සිටියි

බ්‍රෝකර් 3 එන විට, අපි එක් කොටසකට අනුපිටපත් තුනකට ආපසු යමු. නමුත් සියලුම නායකයින් තවමත් තැරැව්කරු 2 මත ය.

සහල්. 5. තැරැව්කරුවන් 1 සහ 3 නැවත පිහිටුවීමෙන් පසු නායකයින් අසමතුලිතව ස්ථානගත කිරීම

RabbitMQ ට වඩා හොඳ නායකයා නැවත සමතුලිත කිරීම සඳහා කෆ්කා සතුව මෙවලමක් තිබේ. එහිදී, ඔබට සංක්‍රමණය අතරතුර අතිරික්තය අඩු කිරීමෙන් ප්‍රධාන නෝඩය සංක්‍රමණය කිරීමේ ප්‍රතිපත්ති වෙනස් කළ තෙවන පාර්ශවීය ප්ලගිනයක් හෝ ස්ක්‍රිප්ට් එකක් භාවිතා කිරීමට සිදු විය. ඊට අමතරව, විශාල පෝලිම් සඳහා සමමුහුර්ත කිරීමේදී අපට නොලැබීම පිළිගැනීමට සිදු විය.

නායක භූමිකාව සඳහා "කැමති අනුරූ" යන සංකල්පය කෆ්කා සතුව ඇත. මාතෘකා කොටස් සෑදූ විට, කෆ්කා නායකයන් නෝඩ් හරහා ඒකාකාරව බෙදා හැරීමට උත්සාහ කරන අතර එම පළමු නායකයින් කැමති ලෙස සලකුණු කරයි. කාලයාගේ ඇවෑමෙන්, සේවාදායක නැවත පණගැන්වීම්, අසාර්ථකවීම් සහ සම්බන්ධතා බිඳවැටීම් හේතුවෙන්, ඉහත විස්තර කර ඇති ආන්තික අවස්ථාවෙහිදී මෙන් නායකයින් වෙනත් නෝඩ් වල අවසන් විය හැක.

මෙය නිවැරදි කිරීම සඳහා, Kafka විකල්ප දෙකක් ඉදිරිපත් කරයි:

• විකල්පය auto.leader.rebalance.enable=ඇත්ත පාලක නෝඩයට නායකයින් කැමති අනුරූ වෙත ස්වයංක්‍රීයව නැවත පැවරීමට සහ එමගින් ඒකාකාර ව්‍යාප්තිය ප්‍රතිස්ථාපනය කිරීමට ඉඩ සලසයි.
• පරිපාලකයාට ස්ක්‍රිප්ට් ධාවනය කළ හැක kafka-preferred-replica-election.sh අතින් නැවත පැවරීම සඳහා.

සහල්. 6. නැවත සමතුලිත කිරීමෙන් පසු අනුරූ

මෙය අසාර්ථකත්වයේ සරල අනුවාදයක් විය, නමුත් මෙහි එතරම් සංකීර්ණ කිසිවක් නොමැති වුවද යථාර්ථය වඩාත් සංකීර්ණ වේ. ඒ සියල්ල සමමුහුර්ත කළ අනුරූ (In-Sync Replicas, ISR) වෙත පැමිණේ.

සමමුහුර්ත අනුරූ (ISR)

ISR යනු "සමමුහුර්ත" (සමමුහුර්ත) ලෙස සලකනු ලබන කොටසක අනුරූ සමූහයකි. නායකයෙක් ඇත, නමුත් අනුගාමිකයන් නොසිටින්නට පුළුවන. අනුගාමිකයෙකු පරතරය කල් ඉකුත් වීමට පෙර නායකයාගේ සියලුම පණිවිඩවල නිශ්චිත පිටපත් සාදා ඇත්නම් එය සමමුහුර්ත කර ඇති බව සලකනු ලැබේ. replica.lag.time.max.ms.

ISR කට්ටලයෙන් අනුගාමිකයෙකු ඉවත් කරනු ලබන්නේ නම්:

• පරතරය සඳහා තෝරා ගැනීමට ඉල්ලීමක් කළේ නැත replica.lag.time.max.ms (මියගොස් ඇතැයි අනුමාන කෙරේ)
• කාල පරතරය තුළ යාවත්කාලීන කිරීමට නොහැකි විය replica.lag.time.max.ms (මන්දගාමී ලෙස සැලකේ)

අනුගාමිකයින් පරතරය තුළ නියැදි ඉල්ලීම් කරයි replica.fetch.wait.max.ms, 500ms දක්වා පෙරනිමි වේ.

ISR හි අරමුණ පැහැදිලිව පැහැදිලි කිරීම සඳහා, අපි නිෂ්පාදකයාගේ තහවුරු කිරීම් සහ සමහර අසාර්ථක අවස්ථා දෙස බැලිය යුතුය. තැරැව්කරු තහවුරු කිරීමක් එවන විට නිෂ්පාදකයින්ට තෝරා ගත හැකිය:

• acks=0, තහවුරු කිරීම යවනු නොලැබේ
• acks=1, නායකයා ඔහුගේ ප්‍රාදේශීය ලොගයට පණිවිඩයක් ලියා පසුව තහවුරු කිරීම යවනු ලැබේ
• acks=සියල්ල, ISR හි සියලුම අනුපිටපත් ප්‍රාදේශීය ලඝු-සටහන් වෙත පණිවිඩය ලියා පසුව තහවුරු කිරීම යවනු ලැබේ

කෆ්කා පාරිභාෂිතය තුළ, ISR පණිවිඩයක් සුරකින ලද්දේ නම්, එය "කැප වී ඇත". Acks=සියල්ල ආරක්ෂිතම විකල්පයයි, නමුත් අමතර ප්‍රමාදයක්ද එක් කරයි. අසාර්ථක වීමේ උදාහරණ දෙකක් සහ විවිධ 'ඇක්ස්' විකල්පයන් ISR සංකල්පය සමඟ අන්තර්ක්‍රියා කරන ආකාරය බලමු.

Acks=1 සහ ISR

මෙම උදාහරණයේදී, නායකයා සියලු අනුගාමිකයින්ගේ සෑම පණිවිඩයක්ම සුරැකෙන තෙක් බලා නොසිටින්නේ නම්, නායකයා අසමත් වුවහොත් දත්ත අහිමි විය හැකි බව අපට පෙනෙනු ඇත. සමමුහුර්ත නොකළ අනුගාමිකයෙකු වෙත සංචාලනය සැකසීමෙන් සබල හෝ අබල කළ හැක unclean.leader.election.enable.

මෙම උදාහරණයේ දී, නිෂ්පාදකයාට acks=1 අගය ඇත. මෙම කොටස තැරැව්කරුවන් තිදෙනා හරහා බෙදා හරිනු ලැබේ. තැරැව්කරු 3 පිටුපසින් ඇත, එය තත්පර අටකට පෙර නායකයා සමඟ සමමුහුර්ත වූ අතර දැන් පණිවිඩ 7456 ක් පිටුපසින් ඇත. තැරැව්කරු 1 තත්පරයක් පසුපසින් සිටියේය. නායකයා බලා නොසිටින මන්දගාමී හෝ මිය ගිය අනුගාමිකයින්ගේ උඩිස් හිසකින් තොරව අපගේ නිෂ්පාදකයා පණිවිඩයක් යවා ඉක්මනින් ආපසු ලබා ගනී.

සහල්. 7. අනුපිටපත් තුනක් සහිත ISR

තැරැව්කරු 2 අසමත් වන අතර නිෂ්පාදකයාට සම්බන්ධතා දෝෂයක් ලැබේ. නායකත්වය තැරැව්කරු 1 වෙත ගිය පසු, අපට පණිවිඩ 123 ක් අහිමි වේ. තැරැව්කරු 1 හි අනුගාමිකයා ISR හි කොටසක් වූ නමුත් එය වැටෙන විට නායකයා සමඟ සම්පුර්ණයෙන්ම සමමුහුර්ත නොවීය.

සහල්. 8. එය කඩා වැටෙන විට පණිවිඩ නැති වී යයි

වින්යාසය තුළ bootstrap.servers නිෂ්පාදකයාට තැරැව්කරුවන් කිහිප දෙනෙකු ලැයිස්තුගත කර ඇති අතර නව අංශයේ නායකයා කවුදැයි වෙනත් තැරැව්කරුවෙකුගෙන් විමසිය හැක. එය පසුව තැරැව්කරු 1 වෙත සම්බන්ධතාවයක් ස්ථාපිත කර පණිවිඩ යැවීම දිගටම කරගෙන යයි.

සහල්. 9. කෙටි විවේකයකින් පසු පණිවිඩ යැවීම නැවත ආරම්භ වේ

Broker 3 ඊටත් වඩා පිටුපසින්. එය ලබා ගැනීමේ ඉල්ලීම් කරන නමුත් සමමුහුර්ත කළ නොහැක. මෙය තැරැව්කරුවන් අතර මන්දගාමී ජාල සම්බන්ධතාවය, ගබඩා කිරීමේ ගැටළු ආදිය නිසා විය හැක. එය ISR වෙතින් ඉවත් කරනු ලැබේ. දැන් ISR එක අනුරුවකින් සමන්විත වේ - නායකයා! නිෂ්පාදකයා දිගටම පණිවිඩ යැවීම සහ තහවුරු කිරීම් ලබා ගනී.

සහල්. 10. තැරැව්කරු 3 හි අනුගාමිකයා ISR වෙතින් ඉවත් කරනු ලැබේ

තැරැව්කරු 1 පහළට යන අතර පණිවිඩ 3 ක් අහිමි වීමත් සමඟ නායකත්ව භූමිකාව තැරැව්කරු 15286 වෙත යයි! නිෂ්පාදකයාට සම්බන්ධතා දෝෂ පණිවිඩයක් ලැබේ. ISR වලින් පිටත නායකයෙකු වෙත සංක්‍රමණය විය හැකි වූයේ සැකසුම නිසා පමණි unclean.leader.election.enable=ඇත්ත. එය ස්ථාපනය කර ඇත්නම් බොරු, එවිට සංක්‍රාන්තිය සිදු නොවන අතර සියලුම කියවීම් සහ ලිවීම් ඉල්ලීම් ප්‍රතික්ෂේප කරනු ලැබේ. මෙම අවස්ථාවෙහිදී, අපි තැරැව්කරු 1 අනුරුවෙහි ඔහුගේ නොවෙනස් දත්ත සමඟ නැවත පැමිණෙන තෙක් බලා සිටිමු, එය නැවත නායකත්වය භාර ගනී.

සහල්. 11. තැරැව්කරු 1 වැටේ. අසාර්ථක වූ විට, පණිවිඩ විශාල සංඛ්යාවක් අහිමි වේ

නිෂ්පාදකයා අවසාන තැරැව්කරු සමඟ සම්බන්ධතාවයක් ඇති කර ගන්නා අතර ඔහු දැන් අංශයේ නායකයා බව දකී. ඔහු තැරැව්කරු 3 වෙත පණිවිඩ යැවීමට පටන් ගනී.

සහල්. 12. කෙටි විවේකයකින් පසු, 0 කොටස වෙත නැවත පණිවිඩ යවනු ලැබේ

නව සම්බන්ධතා ඇති කර ගැනීමට සහ නව නායකයෙකු සෙවීමට කෙටි බාධා කිරීම් හැරුණු විට, නිෂ්පාදකයා නිරන්තරයෙන් පණිවිඩ යවන බව අපි දුටුවෙමු. මෙම වින්‍යාසය අනුකූලතාවයේ (දත්ත ආරක්ෂාව) වියදමින් ලබා ගත හැකි බව සහතික කරයි. කෆ්කාට පණිවිඩ දහස් ගණනක් අහිමි වූ නමුත් නව ලිවීම් දිගටම පිළිගත්තේය.

Acks=සියල්ල සහ ISR

අපි නැවතත් මෙම දර්ශනය නැවත කියමු, නමුත් සමඟ acks=සියල්ල. තැරැව්කරු 3 තත්පර හතරක සාමාන්‍ය ප්‍රමාදයක් ඇත. නිෂ්පාදකයා සමඟ පණිවිඩයක් යවයි acks=සියල්ල, සහ දැන් ඉක්මන් ප්‍රතිචාරයක් නොලැබේ. නායකයා ISR හි සියලුම අනුරූ මගින් පණිවිඩය සුරැකෙන තෙක් බලා සිටී.

සහල්. 13. අනුරූ තුනක් සහිත ISR. එකක් මන්දගාමී වන අතර, එහි ප්‍රතිඵලයක් ලෙස පටිගත කිරීම් ප්‍රමාද වේ

තත්පර හතරක අමතර ප්‍රමාදයකින් පසු, තැරැව්කරු 2 ඇක් එකක් යවයි. සියලුම අනුරූ දැන් සම්පූර්ණයෙන්ම යාවත්කාලීන කර ඇත.

සහල්. 14. සියලුම අනුපිටපත් පණිවිඩ සුරැකීම සහ යැවීම

තැරැව්කරු 3 දැන් තවත් පසුපසට වැටී ISR වෙතින් ඉවත් කර ඇත. ISR හි මන්දගාමී අනුරූ කිසිවක් ඉතිරිව නොමැති නිසා ප්‍රමාදය සැලකිය යුතු ලෙස අඩු වේ. තැරැව්කරු 2 දැන් තැරැව්කරු 1 සඳහා පමණක් බලා සිටින අතර, ඔහුට සාමාන්‍යයෙන් 500 ms ප්‍රමාදයක් ඇත.

සහල්. 15. තැරැව්කරු 3 හි අනුරුව ISR වෙතින් ඉවත් කරනු ලැබේ

එවිට තැරැව්කරු 2 වැටෙන අතර නායකත්වය තැරැව්කරු 1 වෙත පණිවිඩ නැති නොවී යයි.

සහල්. 16. Broker 2 වැටෙනවා

නිෂ්පාදකයා නව නායකයෙකු සොයාගෙන ඔහුට පණිවිඩ යැවීමට පටන් ගනී. ISR දැන් එක අනුරුවකින් සමන්විත වන නිසා ප්‍රමාදය තවදුරටත් අඩු වේ! එබැවින් විකල්පය acks=සියල්ල අතිරික්තය එකතු නොකරයි.

සහල්. 17. තැරැව්කරු 1 හි අනුරුව පණිවිඩ අහිමි නොවී පෙරමුණ ගනී

එවිට තැරැව්කරු 1 කඩා වැටෙන අතර ඊයම් තැරැව්කරු 3 වෙත පණිවිඩ 14238 ක් අහිමි වේ!

සහල්. 18. තැරැව්කරු 1 මිය යාම සහ අපිරිසිදු සැකසුම සමඟ නායකත්ව සංක්‍රාන්තිය පුළුල් දත්ත නැතිවීමට හේතු වේ

අපට විකල්පය ස්ථාපනය කිරීමට නොහැකි විය unclean.leader.election.enable අර්ථයට සැබෑ. පෙරනිමියෙන් එය සමාන වේ බොරු. සැකසුම් acks=සියල්ල с unclean.leader.election.enable=ඇත්ත සමහර එකතු කළ දත්ත ආරක්ෂාව සමඟ ප්‍රවේශ්‍යතාව සපයයි. නමුත් ඔබට පෙනෙන පරිදි, අපට තවමත් පණිවිඩ අහිමි විය හැක.

නමුත් අපට දත්ත ආරක්ෂාව වැඩි කිරීමට අවශ්‍ය නම් කුමක් කළ යුතුද? ඔබට තැබිය හැකිය unclean.leader.election.enable = බොරු, නමුත් මෙය අවශ්‍යයෙන්ම දත්ත නැතිවීමෙන් අපව ආරක්ෂා නොකරනු ඇත. නායකයා දැඩි ලෙස වැටී එය සමඟ දත්ත රැගෙන ගියහොත්, පණිවිඩ තවමත් නැති වී ඇති අතර පරිපාලකයා තත්වය යථා තත්වයට පත් කරන තෙක් ලබා ගැනීමේ හැකියාව නැති වේ.

සියලුම පණිවිඩ අතිරික්ත බව සහතික කිරීම වඩා හොඳය, එසේ නොමැතිනම් පටිගත කිරීම ඉවතලන්න. එවිට, අවම වශයෙන් තැරැව්කරුගේ දෘෂ්ටි කෝණයෙන්, දත්ත නැතිවීම සිදුවිය හැක්කේ එකවර අසාර්ථකවීම් දෙකක් හෝ වැඩි ගණනක් සිදු වූ විට පමණි.

Acks=සියල්ල, min.insync.replicas සහ ISR

මාතෘකා වින්‍යාසය සමඟ min.insync.replicas අපි දත්ත ආරක්ෂණ මට්ටම වැඩි කරනවා. අපි නැවතත් පෙර දර්ශනයේ අවසාන කොටස හරහා යමු, නමුත් මෙවරත් සමඟ min.insync.replicas=2.

එබැවින් තැරැව්කරු 2 හි අනුරූ නායකයෙකු සිටින අතර තැරැව්කරු 3 හි අනුගාමිකයා ISR වෙතින් ඉවත් කරනු ලැබේ.

සහල්. 19. අනුරූ දෙකකින් ISR

තැරැව්කරු 2 වැටෙන අතර නායකත්වය තැරැව්කරු 1 වෙත පණිවිඩ නැතිවීමකින් තොරව ලබා දෙයි. නමුත් දැන් ISR සමන්විත වන්නේ එක් අනුරුවකින් පමණි. මෙය වාර්තා ලබා ගැනීමට අවම සංඛ්‍යාව සපුරාලන්නේ නැත, එබැවින් තැරැව්කරු ලිවීමේ උත්සාහයට දෝෂයක් සමඟ ප්‍රතිචාර දක්වයි NotEnoughReplicas.

සහල්. 20. ISR ගණන min.insync.replicas හි නිශ්චිතව දක්වා ඇති ප්‍රමාණයට වඩා එකක් අඩුය

මෙම වින්‍යාසය අනුකූලතාව සඳහා ලබා ගැනීමේ හැකියාව කැප කරයි. පණිවිඩයක් පිළිගැනීමට පෙර, එය අවම වශයෙන් අනුපිටපත් දෙකකටවත් ලියා ඇති බව අපි සහතික කරමු. මෙය නිෂ්පාදකයාට වැඩි විශ්වාසයක් ලබා දෙයි. මෙහිදී, පණිවිඩය නැතිවීම සිදුවිය හැක්කේ කෙටි කාලසීමාවකදී අනුපිටපත් දෙකක් එකවර අසමත් වුවහොත් පමණක්, පණිවිඩය අතිරේක අනුගාමිකයෙකුට ප්‍රතිනිර්මාණය වන තුරු පමණි. නමුත් ඔබ අධි ව්‍යාකූල අයෙක් නම්, ඔබට අනුවර්තන සාධකය 5 ට සැකසිය හැක, සහ min.insync.replicas විසින් 3. මෙහිදී තැරැව්කරුවන් තිදෙනෙකු වාර්තාව අහිමි වීමට එකවර වැටිය යුතුය! ඇත්ත වශයෙන්ම, ඔබ මෙම විශ්වසනීයත්වය සඳහා අමතර ප්රමාදයකින් ගෙවනු ලැබේ.

දත්ත ආරක්ෂාව සඳහා ප්‍රවේශ්‍යතාව අවශ්‍ය වූ විට

මෙන් RabbitMQ සමඟ නඩුව, සමහර විට දත්ත ආරක්ෂාව සඳහා ප්‍රවේශ්‍යතාව අවශ්‍ය වේ. ඔබ සිතිය යුතු දේ මෙන්න:

• ප්‍රකාශකයාට හුදෙක් දෝෂයක් ලබා දී උඩු ප්‍රවාහ සේවාවට හෝ පරිශීලකයාට පසුව නැවත උත්සාහ කළ හැකිද?
• පසුව නැවත උත්සාහ කිරීමට ප්‍රකාශකයාට පණිවිඩය දේශීයව හෝ දත්ත ගබඩාවක සුරැකිය හැකිද?

පිළිතුර නැත නම්, ලබා ගැනීමේ හැකියාව ප්‍රශස්ත කිරීම දත්ත ආරක්ෂාව වැඩි දියුණු කරයි. ඔබ පටිගත නොකිරීම වෙනුවට ලබා ගත හැකි බව තේරුවහොත් ඔබට අඩු දත්ත අහිමි වනු ඇත. මේ අනුව, ඒ සියල්ල සමතුලිතතාවයක් සොයා ගැනීමට පැමිණෙන අතර, තීරණය නිශ්චිත තත්වය මත රඳා පවතී.

ISR හි අර්ථය

දත්ත ආරක්ෂාව සහ ප්‍රමාදය අතර ප්‍රශස්ත ශේෂය තෝරා ගැනීමට ISR කට්ටලය ඔබට ඉඩ සලසයි. උදාහරණයක් ලෙස, ප්‍රමාදය අනුව මිය ගිය හෝ මන්දගාමී අනුරූ වල බලපෑම අවම කරමින්, බහුතර අනුපිටපත් අසාර්ථක වූ විට ලබා ගත හැකි බව සහතික කරන්න.

අර්ථය අපිම තෝරා ගනිමු replica.lag.time.max.ms ඔබගේ අවශ්යතා අනුව. අත්‍යවශ්‍යයෙන්ම, මෙම පරාමිතිය යන්නෙන් අදහස් කරන්නේ අප කොපමණ ප්‍රමාදයක් පිළිගැනීමට කැමතිද යන්නයි acks=සියල්ල. පෙරනිමි අගය තත්පර දහයකි. මෙය ඔබට දිගු නම්, ඔබට එය අඩු කළ හැකිය. එවිට අනුගාමිකයින් ඉවත් කර නිතර එකතු වන බැවින් ISR හි වෙනස්වීම් සංඛ්‍යාතය වැඩි වනු ඇත.

RabbitMQ යනු හුදෙක් අනුකරණය කළ යුතු දර්පණ කට්ටලයකි. මන්දගාමී දර්පණ අමතර ප්‍රමාදයක් හඳුන්වා දෙන අතර, මිය ගිය දර්පණවලට ප්‍රතිචාර දැක්වීමට එක් එක් නෝඩයේ (නෙට් ටික්) තිබේද යන්න පරීක්ෂා කරන පැකට් බලා සිටිය හැක. ISR යනු මෙම ප්‍රමාද ගැටළු මඟහරවා ගැනීමට සිත්ගන්නා ක්‍රමයකි. නමුත් ISR හට හැකිලීමට හැක්කේ නායකයාට පමණක් වන බැවින් අපට අතිරික්තය අහිමි වීමේ අවදානමක් ඇත. මෙම අවදානම වළක්වා ගැනීම සඳහා, සැකසුම භාවිතා කරන්න min.insync.replicas.

පාරිභෝගික සම්බන්ධතා සහතිකය

සැකසුම් තුළ bootstrap.servers නිෂ්පාදකයාට සහ පාරිභෝගිකයාට ගනුදෙනුකරුවන් සම්බන්ධ කිරීම සඳහා බහු තැරැව්කරුවන් නියම කළ හැක. අදහස නම්, එක් නෝඩයක් පහළට ගිය විට, සේවාදායකයාට සම්බන්ධතාවයක් විවෘත කළ හැකි අමතර ඒවා කිහිපයක් ඉතිරිව ඇති බවයි. මේවා අනිවාර්යයෙන්ම අංශ නායකයන් නොවේ, නමුත් මූලික පැටවීම සඳහා උල්පත් පුවරුවකි. සේවාලාභියාට ඔවුන්ගෙන් විමසිය හැක්කේ කුමන නෝඩය කියවීම/ලිවීම කොටස් නායකයා ධාරකය කරන්නේද යන්නයි.

RabbitMQ හි, සේවාලාභීන්ට ඕනෑම නෝඩයකට සම්බන්ධ විය හැකි අතර, අභ්‍යන්තර මාර්ගගත කිරීම එය යා යුතු තැනට ඉල්ලීම යවයි. මෙයින් අදහස් කරන්නේ ඔබට RabbitMQ ඉදිරිපිට load balancer එකක් ස්ථාපනය කළ හැකි බවයි. Kafka විසින් සේවාදායකයින්ට අනුරූප කොටස් නායකයා සත්කාරකත්වය සපයන node වෙත සම්බන්ධ වීමට අවශ්‍ය වේ. එවැනි තත්වයක් තුළ, ඔබට load balancer එකක් ස්ථාපනය කළ නොහැක. ලැයිස්තුව bootstrap.servers අසාර්ථක වීමෙන් පසු සේවාදායකයන්ට ප්‍රවේශ වීමට සහ නිවැරදි නෝඩ් සොයා ගැනීමට හැකි වීම ඉතා වැදගත් වේ.

කෆ්කා සම්මුති ගෘහ නිර්මාණ ශිල්පය

තැරැව්කරුගේ වැටීම ගැන පොකුර ඉගෙන ගන්නේ කෙසේද සහ නව නායකයෙකු තෝරා ගන්නේ කෙසේද යන්න අපි මෙතෙක් සලකා බැලුවේ නැත. කෆ්කා ජාල කොටස් සමඟ ක්‍රියා කරන ආකාරය තේරුම් ගැනීමට, ඔබ මුලින්ම සම්මුති ගෘහ නිර්මාණ ශිල්පය තේරුම් ගත යුතුය.

සෑම Kafka පොකුරක්ම Zookeeper පොකුරක් සමඟ යොදවා ඇත, එය බෙදාහැරීමේ සම්මුති සේවාවක් වන අතර එය පවතින තත්ත්වයට වඩා අනුකූලතාවයට ප්‍රමුඛත්වය දෙමින් පද්ධතියට යම් යම් රාජ්‍යයක් මත සම්මුතියකට පැමිණීමට ඉඩ සලසයි. කියවීමේ සහ ලිවීමේ මෙහෙයුම් අනුමත කිරීමට Zookeeper nodes බහුතරයකගේ කැමැත්ත අවශ්‍ය වේ.

සත්වෝද්‍යාන පාලකයා පොකුරේ තත්ත්වය ගබඩා කරයි:

• මාතෘකා ලැයිස්තුව, කොටස්, වින්‍යාසය, වත්මන් නායක අනුරූ, කැමති අනුරූ.
• පොකුරු සාමාජිකයන්. සෑම තැරැව්කරුවෙක්ම Zookeeper පොකුරට ping කරයි. නිශ්චිත කාල සීමාවක් තුළ එයට ping එකක් නොලැබුනේ නම්, Zookeeper විසින් තැරැව්කරු ලබා ගත නොහැකි බව වාර්තා කරයි.
• පාලකය සඳහා ප්රධාන සහ අමතර නෝඩ් තෝරාගැනීම.

පාලක නෝඩය අනුරූ නායකයින් තෝරා ගැනීම සඳහා වගකිව යුතු කෆ්කා තැරැව්කරුවන්ගෙන් එකකි. සත්වෝද්‍යාන පාලකයා විසින් පොකුරු සාමාජිකත්වය සහ මාතෘකා වෙනස්වීම් පිළිබඳව පාලක වෙත දැනුම්දීම් යවන අතර, පාලකය මෙම වෙනස්කම් මත ක්‍රියා කළ යුතුය.

උදාහරණයක් ලෙස, අපි නව මාතෘකාවක් ගනිමු කොටස් දහයක් සහ අනුකරණ සාධකය 3. පාලකය විසින් එක් එක් කොටස සඳහා නායකයෙකු තෝරා ගත යුතු අතර, තැරැව්කරුවන් අතර නායකයින් ප්‍රශස්ත ලෙස බෙදා හැරීමට උත්සාහ කරයි.

එක් එක් අංශ පාලකය සඳහා:

• ISR සහ නායකයා පිළිබඳ Zookeeper හි තොරතුරු යාවත්කාලීන කිරීම;
• ISR සහ නායකයා පිළිබඳව තැරැව්කරුවන්ට දන්වමින්, මෙම කොටසෙහි අනුරුවක් සත්කාරකත්වය සපයන සෑම තැරැව්කරුවෙකු වෙතම LeaderAndISRcommand යවයි.

නායකයෙකු සමඟ තැරැව්කරුවෙකු වැටෙන විට, Zookeeper පාලකයාට දැනුම්දීමක් යවන අතර, එය නව නායකයෙකු තෝරා පත් කර ගනී. නැවතත්, පාලකය ප්‍රථමයෙන් Zookeeper යාවත්කාලීන කරන අතර පසුව නායකත්ව වෙනස පිළිබඳව දැනුම් දෙන සෑම තැරැව්කරුවකුටම විධානයක් යවයි.

සෑම නායකයෙක්ම ISR බඳවා ගැනීම සඳහා වගකිව යුතුය. සැකසුම් replica.lag.time.max.ms එහි ඇතුළු වන්නේ කවුරුන්ද යන්න තීරණය කරයි. ISR වෙනස් වූ විට, නායකයා නව තොරතුරු Zookeeper වෙත සම්ප්‍රේෂණය කරයි.

කිසියම් වෙනස්කමක් පිළිබඳව සත්වෝද්‍යාන පාලකවරයාට සැමවිටම දැනුම් දෙනු ලැබේ, එවිට අසාර්ථක වූ විට කළමනාකරණය නව නායකයෙකු වෙත සුමටව සංක්‍රමණය වේ.

සහල්. 21. කෆ්කා සම්මුතිය

අනුකරණ ප්රොටෝකෝලය

ප්‍රතිනිර්මාණය කිරීමේ විස්තර අවබෝධ කර ගැනීම ඔබට විභව දත්ත නැතිවීමේ අවස්ථා වඩාත් හොඳින් අවබෝධ කර ගැනීමට උපකාරී වේ.

නියැදි විමසුම්, Log End Offset (LEO) සහ Highwater Mark (HW)

අනුගාමිකයින් වරින් වර නායකයා වෙත ලබා ගැනීමේ ඉල්ලීම් යවන බව අපි සලකමු. පෙරනිමි පරතරය 500ms වේ. මෙය RabbitMQ ට වඩා වෙනස් වන්නේ RabbitMQ හි ප්‍රතිනිර්මාණය පෝලිම් දර්පණයෙන් නොව මාස්ටර් විසින් ආරම්භ කරන බැවිනි. ස්වාමියා දර්පණ වලට වෙනස්කම් තල්ලු කරයි.

නායකයා සහ සියලුම අනුගාමිකයින් Log End Offset (LEO) සහ Highwater (HW) ලේබලය සුරකියි. LEO සලකුණ දේශීය අනුරුවෙහි අවසාන පණිවිඩයේ ඕෆ්සෙට් එක ගබඩා කරයි, සහ HW විසින් අවසන් කැපවීමේ ඕෆ්සෙට් දරයි. කැපවීමේ තත්ත්වය සඳහා, සියලුම ISR අනුරූ හරහා පණිවිඩය පැවතිය යුතු බව මතක තබා ගන්න. මෙයින් අදහස් කරන්නේ LEO සාමාන්‍යයෙන් HW ට වඩා තරමක් ඉදිරියෙන් සිටින බවයි.

නායකයාට පණිවිඩයක් ලැබුණු විට එය දේශීයව ගබඩා කරයි. අනුගාමිකයා ඔහුගේ LEO සම්ප්‍රේෂණය කිරීමෙන් ලබා ගැනීමේ ඉල්ලීමක් කරයි. එවිට නායකයා මෙම LEO වෙතින් ආරම්භ වන පණිවිඩ සමූහයක් යවන අතර වත්මන් HW ද සම්ප්‍රේෂණය කරයි. ලබා දී ඇති ඕෆ්සෙට් හි සියලුම අනුපිටපත් පණිවිඩය ගබඩා කර ඇති බවට නායකයාට තොරතුරු ලැබුණු විට, එය HW ලකුණ චලනය කරයි. HW චලනය කළ හැක්කේ නායකයාට පමණි, එබැවින් සියලුම අනුගාමිකයින් ඔවුන්ගේ ඉල්ලීමට ප්‍රතිචාරවල වත්මන් අගය දැන ගනු ඇත. මෙයින් අදහස් කරන්නේ පණිවිඩය සහ HW දැනුම යන දෙකෙහිම අනුගාමිකයින් නායකයාට වඩා පසුගාමී විය හැකි බවයි. පාරිභෝගිකයින්ට පණිවිඩ ලැබෙන්නේ වත්මන් HW දක්වා පමණි.

"පවත්නා" යන්නෙන් අදහස් කරන්නේ තැටියට නොව මතකයට ලියන බව සලකන්න. කාර්ය සාධනය සඳහා, කෆ්කා නිශ්චිත කාල පරතරයකින් තැටියට සමමුහුර්ත කරයි. RabbitMQ හි ද එවැනි විරාමයක් ඇත, නමුත් එය ප්‍රකාශකයාට පිළිගැනීමක් යවන්නේ මාස්ටර් සහ සියලුම දර්පණ තැටියට පණිවිඩය ලියා පසුව පමණි. කෆ්කා සංවර්ධකයින්, කාර්ය සාධන හේතූන් මත, පණිවිඩය මතකයට ලියා ඇති වහාම ඇක් එකක් යැවීමට තීරණය කළහ. කෆ්කා ඔට්ටු අල්ලයි, අතිරික්තය පිළිගත් පණිවිඩ කෙටියෙන් මතකයේ පමණක් ගබඩා කිරීමේ අවදානම සමනය කරයි.

නායකයා අසාර්ථකයි

නායකයෙකු වැටෙන විට, Zookeeper පාලකයාට දැනුම් දෙන අතර, එය නව නායක අනුරුවක් තෝරා ගනී. නව නායකයා ඔහුගේ LEO අනුව නව HW ලකුණක් සකසයි. එවිට අනුගාමිකයින්ට නව නායකයා පිළිබඳ තොරතුරු ලැබේ. කෆ්කාගේ අනුවාදය මත පදනම්ව, අනුගාමිකයා අවස්ථා දෙකෙන් එකක් තෝරා ගනු ඇත:

1. එය දන්නා HW වෙත ප්‍රාදේශීය ලොගය කප්පාදු කර මෙම ලකුණෙන් පසු පණිවිඩ සඳහා නව නායකයා වෙත ඉල්ලීමක් යවනු ඇත.
2. ඔහු නායකයා ලෙස තේරී පත් වූ අවස්ථාවේ එච්ඩබ්ලිව් සොයා ගැනීමට නායකයා වෙත ඉල්ලීමක් යවනු ඇත, පසුව මෙම ඕෆ්සෙට් වෙත ලොගය කපා හරිනු ඇත. එය පසුව මෙම ඕෆ්සෙට් එකෙන් පටන් ගෙන වරින් වර ලබා ගැනීමේ ඉල්ලීම් කිරීමට පටන් ගනී.

පහත හේතූන් මත අනුගාමිකයෙකුට ලොගය කප්පාදු කිරීමට අවශ්‍ය විය හැක:

• නායකයෙකු අසමත් වූ විට, Zookeeper සමඟ ලියාපදිංචි වූ ISR කට්ටලයේ පළමු අනුගාමිකයා මැතිවරණය ජයග්‍රහණය කර නායකයා බවට පත්වේ. ISR හි සියලුම අනුගාමිකයින්ට, "සමමුහුර්තව" ලෙස සලකනු ලැබුවද, හිටපු නායකයාගෙන් සියලුම පණිවිඩවල පිටපත් නොලැබෙන්නට ඇත. විශේෂාංගගත අනුගාමිකයාට වඩාත්ම යාවත්කාලීන පිටපතක් නොතිබීම සම්පූර්ණයෙන්ම විය හැකිය. කෆ්කා අනුරූ අතර අපසරනයක් නොමැති බව සහතික කරයි. මේ අනුව, නොගැලපීම් වලක්වා ගැනීම සඳහා, සෑම අනුගාමිකයෙක්ම ඔහුගේ තේරී පත්වන අවස්ථාවේදී නව නායකයාගේ HW අගයට එහි ලොගය කපා හැරිය යුතුය. මෙය සැකසීමට තවත් හේතුවකි acks=සියල්ල අනුකූලතාව සඳහා ඉතා වැදගත් වේ.
• පණිවිඩ වරින් වර තැටියට ලියා ඇත. සියලුම පොකුරු නෝඩ් එකවර අසමත් වුවහොත්, විවිධ ඕෆ්සෙට් සහිත අනුරූ තැටි මත ගබඩා වේ. තැරැව්කරුවන් නැවත අන්තර්ජාලයට එන විට, පත්වන නව නායකයා ඔහුගේ අනුගාමිකයින් පිටුපසින් සිටිනු ඇත්තේ ඔහු අනෙක් අයට පෙර තැටියට ගැලවීම නිසා විය හැකිය.

පොකුර සමඟ නැවත එක්වීම

පොකුරට නැවත සම්බන්ධ වන විට, අනුරූ නායකයෙකු අසමත් වූ විට සිදු කරන දේම කරයි: ඔවුන් නායකයාගේ අනුරුව පරීක්ෂා කර ඔවුන්ගේ ලොගය එහි HW වෙත කපා දමයි (මැතිවරණයේදී). සැසඳීමේ දී, RabbitMQ සමානව නැවත එක් වූ නෝඩ් සම්පූර්ණයෙන්ම අලුත් ලෙස සලකයි. අවස්ථා දෙකේදීම, තැරැව්කරු පවතින ඕනෑම තත්වයක් ඉවතලයි. ස්වයංක්‍රීය සමමුහුර්තකරණය භාවිතා කරන්නේ නම්, ස්වාමියා "මුළු ලෝකයටම බලා සිටීමට ඉඩ දෙන්න" ක්‍රමයකින් නව දර්පණයට දැනට පවතින සියලුම අන්තර්ගතයන් සම්පූර්ණයෙන්ම අනුකරණය කළ යුතුය. මෙම මෙහෙයුම අතරතුර මාස්ටර් කියවීමේ හෝ ලිවීමේ මෙහෙයුම් කිසිවක් පිළිගන්නේ නැත. මෙම ප්රවේශය විශාල පෝලිම්වල ගැටළු ඇති කරයි.

Kafka යනු බෙදා හරින ලද ලොගයක් වන අතර සාමාන්‍යයෙන් එය RabbitMQ පෝලිමකට වඩා වැඩි පණිවිඩ ගබඩා කරයි, එය කියවීමෙන් පසු පෝලිමෙන් දත්ත ඉවත් කරනු ලැබේ. ක්රියාකාරී පෝලිම් සාපේක්ෂව කුඩා විය යුතුය. නමුත් Kafka යනු එහිම රඳවා ගැනීමේ ප්‍රතිපත්තියක් සහිත ලඝු-සටහනකි, එයට දින හෝ සති කාල සීමාවක් සැකසිය හැක. බෙදා හරින ලද ලොගයක් සඳහා පෝලිම් අවහිර කිරීම සහ සම්පූර්ණ සමමුහුර්ත කිරීමේ ප්‍රවේශය සම්පූර්ණයෙන්ම පිළිගත නොහැකිය. ඒ වෙනුවට, කෆ්කා අනුගාමිකයින් ඔවුන්ගේ පිටපත නායකයාට වඩා ඉදිරියෙන් තිබේ නම්, නායකයාගේ HW වෙත (ඔහු තේරී පත් වූ අවස්ථාවේදී) ඔවුන්ගේ ලඝු සටහන සරලව කපා හැරේ. බොහෝ දුරට ඉඩ ඇති අවස්ථාවක, අනුගාමිකයා පිටුපස සිටින විට, එය හුදෙක් එහි වත්මන් LEO සමඟින් ආරම්භ කර ඉල්ලීම් කිරීමට පටන් ගනී.

නව හෝ නැවත සම්බන්ධ වූ අනුගාමිකයින් ISR වලින් පිටත ආරම්භ වන අතර කැපවීම් වලට සහභාගී නොවේ. ඔවුන් හුදෙක් කණ්ඩායම සමඟ එක්ව වැඩ කරන අතර, ඔවුන් නායකයා සමඟ සම්බන්ධ වී ISR වෙත ඇතුළු වන තෙක් ඔවුන්ට හැකි ඉක්මනින් පණිවිඩ ලබා ගනී. අගුලු දැමීමක් නොමැති අතර ඔබගේ සියලු දත්ත ඉවත දැමීමට අවශ්‍ය නොවේ.

සම්බන්ධතාවය නැතිවීම

Kafka සතුව RabbitMQ වලට වඩා වැඩි සංරචක ඇත, එබැවින් එය පොකුර විසන්ධි වූ විට වඩාත් සංකීර්ණ හැසිරීම් සමූහයක් ඇත. නමුත් කෆ්කා මුලින් නිර්මාණය කර ඇත්තේ පොකුරු සඳහා වන බැවින් විසඳුම් ඉතා හොඳින් සිතා බලා ඇත.

සම්බන්ධතා අසාර්ථක අවස්ථා කිහිපයක් පහත දැක්වේ:

• අවස්ථාව 1: අනුගාමිකයා නායකයාව නොදකියි, නමුත් තවමත් සත්ව පාලකයා දකී.
• දර්ශනය 2: නායකයාට අනුගාමිකයින් කිසිවෙක් නොපෙනේ, නමුත් තවමත් Zookeeper දකී.
• දර්ශනය 3: අනුගාමිකයා නායකයා දකින නමුත් සත්වෝද්‍යාන පාලකයා නොදකියි.
• සිනාරියෝ 4: නායකයා අනුගාමිකයන් දකින නමුත් සත්වෝද්‍යාන පාලකයා නොදකියි.
• අවස්ථාව 5: අනුගාමිකයා අනෙකුත් Kafka nodes සහ Zookeeper යන දෙකෙන්ම සම්පූර්ණයෙන්ම වෙන්ව සිටී.
• සිනාරියෝ 6: නායකයා අනෙකුත් කෆ්කා නෝඩ් සහ සූකීපර් යන දෙකෙන්ම සම්පූර්ණයෙන්ම වෙන්ව සිටී.
• අවස්ථාව 7: කෆ්කා පාලක නෝඩයට වෙනත් කෆ්කා නෝඩයක් දැකිය නොහැක.
• අවස්ථාව 8: Kafka පාලකය Zookeeper දකින්නේ නැත.

සෑම දර්ශනයකටම තමන්ගේම හැසිරීමක් ඇත.

අවස්ථාව 1: අනුගාමිකයා නායකයාව නොදකියි, නමුත් තවමත් Zookeeper දකී

සහල්. 22. අවස්ථාව 1: අනුරූ තුනක ISR

සම්බන්ධතා අසාර්ථකත්වය තැරැව්කරු 3 තැරැව්කරුවන් 1 සහ 2 වෙතින් වෙන් කරයි, නමුත් Zookeeper වෙතින් නොවේ. තැරැව්කරු 3 හට තවදුරටත් ලබා ගැනීමේ ඉල්ලීම් යැවිය නොහැක. කාලය ගත වූ පසු replica.lag.time.max.ms එය ISR වෙතින් ඉවත් කර ඇති අතර පණිවිඩ කැපවීම් වලට සහභාගී නොවේ. සම්බන්ධතාවය ප්‍රතිසාධනය කළ පසු, එය ඉල්ලීම් ලබා ගැනීම නැවත ආරම්භ කර නායකයා සමඟ සම්බන්ධ වූ විට ISR වෙත සම්බන්ධ වනු ඇත. සත්වෝද්‍යාන පාලකයාට දිගටම පිං ලැබෙනු ඇති අතර තැරැව්කරු ජීවතුන් අතර සිටින බව උපකල්පනය කරයි.

සහල්. 23. අවස්ථාව 1: replica.lag.time.max.ms පරතරය තුළ ලබා ගැනීමේ ඉල්ලීමක් නොලැබුනේ නම් තැරැව්කරු ISR වෙතින් ඉවත් කරනු ලැබේ.

RabbitMQ හි මෙන් split-මොළයක් හෝ node suspension නොමැත. ඒ වෙනුවට, අතිරික්තය අඩු වේ.

දර්ශනය 2: නායකයාට අනුගාමිකයින් කිසිවක් නොපෙනේ, නමුත් තවමත් සත්ව පාලකයා දකී

සහල්. 24. සිනාරියෝ 2. නායකයා සහ අනුගාමිකයින් දෙදෙනෙක්

ජාල සම්බන්ධතාවයේ බිඳවැටීමක් නායකයා අනුගාමිකයන්ගෙන් වෙන් කරයි, නමුත් තැරැව්කරුට තවමත් Zookeeper දැකිය හැක. පළමු අවස්ථාවේ දී මෙන්, ISR හැකිලී යයි, නමුත් මෙවර නායකයාට පමණක් සියලු අනුගාමිකයින් ලබා ගැනීමේ ඉල්ලීම් යැවීම නතර කරයි. නැවතත්, තාර්කික බෙදීමක් නොමැත. ඒ වෙනුවට, සම්බන්ධතාවය යථා තත්ත්වයට පත් වන තෙක් නව පණිවිඩ සඳහා අතිරික්තයක් නැති වී යයි. සත්වෝද්‍යාන පාලකයාට දිගටම පිං ලැබෙන අතර තැරැව්කරු ජීවතුන් අතර සිටින බව විශ්වාස කරයි.

සහල්. 25. සිනාරියෝ 2. ISR හැකිලී ඇත්තේ නායකයාට පමණි

දර්ශනය 3. අනුගාමිකයා නායකයා දකින නමුත් සත්වෝද්‍යාන පාලකයා නොදකියි

අනුගාමිකයා Zookeeper වෙතින් වෙන් වී ඇත, නමුත් නායකයා සමඟ තැරැව්කරුගෙන් නොවේ. එහි ප්‍රතිඵලයක් වශයෙන්, අනුගාමිකයා ඉල්ලීම් ලබා ගැනීම සහ ISR හි සාමාජිකයෙකු වීම දිගටම කරගෙන යයි. Zookeeper හට තවදුරටත් pings නොලැබෙන අතර තැරැව්කාර බිඳවැටීමක් ලියාපදිංචි කරයි, නමුත් එය අනුගාමිකයෙකු පමණක් බැවින්, යථා තත්ත්වයට පත්වීමෙන් පසු ප්‍රතිවිපාක නොමැත.

සහල්. 26. සිනාරියෝ 3: අනුගාමිකයා නායකයා වෙත ලබා ගැනීමේ ඉල්ලීම් දිගටම යවයි

දර්ශනය 4. නායකයා අනුගාමිකයින් දකින නමුත් Zookeeper දකින්නේ නැත

සහල්. 27. සිනාරියෝ 4. නායකයා සහ අනුගාමිකයින් දෙදෙනෙක්

නායකයා Zookeeper වෙතින් වෙන් වී ඇත, නමුත් අනුගාමිකයන් සිටින තැරැව්කරුවන්ගෙන් නොවේ.

සහල්. 28. සිනාරියෝ 4: නායකයා සත්වෝද්‍යාන පාලකයාගෙන් හුදකලා විය

ටික වේලාවකට පසු, Zookeeper විසින් තැරැව්කරු අසමත් වීමක් ලියාපදිංචි කර එය පාලකයාට දැනුම් දෙනු ඇත. ඔහු තම අනුගාමිකයින් අතරින් නව නායකයෙකු තෝරා ගනු ඇත. කෙසේ වෙතත්, මුල් නායකයා තමා නායකයා යැයි සිතමින් දිගටම ඇතුළත් කිරීම් භාර ගනු ඇත acks=1. අනුගාමිකයින් තවදුරටත් ඔහුට ලබා ගැනීමේ ඉල්ලීම් එවන්නේ නැත, එබැවින් ඔහු ඔවුන් මිය ගිය බව සලකනු ඇති අතර ISR තමන්ටම හැකිලීමට උත්සාහ කරයි. නමුත් එයට Zookeeper සමඟ සම්බන්ධයක් නොමැති නිසා, එයට මෙය කිරීමට නොහැකි වනු ඇති අතර, එම අවස්ථාවේදී වැඩිදුර ප්‍රවේශයන් පිළිගැනීම ප්‍රතික්ෂේප කරනු ඇත.

පණිවිඩ acks=සියල්ල ISR ප්‍රථමයෙන් සියලුම අනුපිටපත් ක්‍රියාත්මක කරන නිසාත්, පණිවිඩ ඒවාට නොපැමිණෙන නිසාත් පිළිගැනීමක් නොලැබෙනු ඇත. මුල් නායකයා ඔවුන්ව ISR වෙතින් ඉවත් කිරීමට උත්සාහ කරන විට, එය එසේ කිරීමට නොහැකි වන අතර කිසිදු පණිවිඩයක් පිළිගැනීම කිසිසේත්ම නවත්වනු ඇත.

සේවාලාභීන් ඉක්මනින් නායකයාගේ වෙනස දකින අතර නව සේවාදායකයට වාර්තා යැවීමට පටන් ගනී. ජාලය ප්‍රතිසාධනය කළ පසු, මුල් නායකයා එය තවදුරටත් නායකයෙකු නොවන බව දකින අතර ලොග් අපසරනය වැලැක්වීමට අපොහොසත් වූ අවස්ථාවේ නව නායකයා සතුව තිබූ HW අගයට එහි ලොගය කප්පාදු කරයි. එය පසුව නව නායකයා වෙත ලබා ගැනීමේ ඉල්ලීම් යැවීම ආරම්භ කරනු ඇත. මුල් නායකයාගෙන් නව නායකයාට පිටපත් නොකළ සියලුම වාර්තා නැති වී යයි. එනම් නායකයන් දෙදෙනකු වැඩකරමින් සිටි එම තත්පර කිහිපය තුළ මුල් නායකයා විසින් පිළිනොගත් පණිවිඩ නැතිවී යන බවයි.

සහල්. 29. අවස්ථාව 4. තැරැව්කරු 1 හි නායකයා ජාලය ප්‍රතිසාධනය කිරීමෙන් පසු අනුගාමිකයෙකු බවට පත් වේ

අවස්ථාව 5: අනුගාමිකයා අනෙකුත් Kafka nodes සහ Zookeeper යන දෙකෙන්ම සම්පූර්ණයෙන්ම වෙන්ව සිටී

අනුගාමිකයා අනෙකුත් Kafka nodes සහ Zookeeper යන දෙකෙන්ම සම්පූර්ණයෙන්ම හුදකලා වේ. ජාලය යථා තත්ත්වයට පත් වන තෙක් ඔහු හුදෙක් ISR වෙතින් ඉවත් කර, පසුව අනෙක් අය සමඟ සම්බන්ධ වේ.

සහල්. 30. අවස්ථාව 5: හුදකලා අනුගාමිකයෙකු ISR වෙතින් ඉවත් කරනු ලැබේ

සිනාරියෝ 6: නායකයා අනෙකුත් කෆ්කා නෝඩ් සහ සූකීපර් යන දෙකෙන්ම සම්පූර්ණයෙන්ම වෙන්ව සිටී

සහල්. 31. සිනාරියෝ 6. නායකයා සහ අනුගාමිකයින් දෙදෙනෙක්

නායකයා ඔහුගේ අනුගාමිකයන්, පාලකයා සහ සත්වෝද්‍යාන පාලකයාගෙන් සම්පූර්ණයෙන්ම හුදෙකලා වේ. කෙටි කාලයක් සඳහා එය දිගටම ඇතුළත් කිරීම් භාර ගනු ඇත acks=1.

සහල්. 32. අවස්ථාව 6: නායකයා අනෙකුත් කෆ්කා සහ සත්වෝද්‍යාන පාලක නෝඩ් වලින් හුදකලා කිරීම

කල් ඉකුත් වූ පසු ඉල්ලීම් නොලැබීම replica.lag.time.max.ms, එය ISR තමන්ටම හැකිලීමට උත්සාහ කරනු ඇත, නමුත් Zookeeper සමඟ සන්නිවේදනයක් නොමැති නිසා එය කළ නොහැකි වනු ඇත, එවිට එය ලිවීම් පිළිගැනීම නවත්වනු ඇත.

මේ අතර, සත්වෝද්‍යාන පාලකයා හුදකලා තැරැව්කරු මියගිය බවට සලකුණු කරන අතර පාලකයා නව නායකයෙකු තෝරා ගනු ඇත.

සහල්. 33. දර්ශනය 6. නායකයන් දෙදෙනෙක්

මුල් නායකයා තත්පර කිහිපයක් සඳහා ඇතුළත් කිරීම් පිළිගත හැකි නමුත්, පසුව ඕනෑම පණිවිඩයක් පිළිගැනීම නතර කරයි. නවතම පාර-දත්ත සමඟින් සෑම තත්පර 60කට වරක් සේවාදායකයන් යාවත්කාලීන වේ. නායකයා වෙනස් වීම පිළිබඳව ඔවුන්ට දැනුම් දෙනු ලබන අතර නව නායකයා වෙත ඇතුළත් කිරීම් යැවීම ආරම්භ කරනු ඇත.

සහල්. 34. අවස්ථාව 6: නිෂ්පාදකයින් නව නායකයෙකු වෙත මාරු වේ

සම්බන්ධතාවය නැතිවීමෙන් මුල් නායකයා විසින් කරන ලද සියලුම තහවුරු කිරීම් අහිමි වනු ඇත. ජාලය ප්‍රතිසාධනය කළ පසු, එය තවදුරටත් නායකයා නොවන බව Zookeeper හරහා මුල් නායකයා සොයා ගනු ඇත. එවිට එය මැතිවරණ අවස්ථාවේ නව නායකයාගේ HW වෙත එහි ලොගය කපා හැර අනුගාමිකයෙකු ලෙස ඉල්ලීම් යැවීමට පටන් ගනී.

සහල්. 35. අවස්ථාව 6: ජාල සම්බන්ධතාවය ප්‍රතිසාධනය කිරීමෙන් පසු මුල් නායකයා අනුගාමිකයෙකු බවට පත්වේ

මෙම තත්වය තුළ, තාර්කික වෙන්වීමක් කෙටි කාලයක් සඳහා සිදු විය හැක, නමුත් එසේ නම් පමණි acks=1 и min.insync.replicas එසේම 1. ජාලය ප්‍රතිසාධනය කිරීමෙන් පසුව, මුල් නායකයා තවදුරටත් නායකයා නොවන බව වටහා ගත් විට, නැතහොත් නායකයා වෙනස් වී ඇති බව සියලු ගනුදෙනුකරුවන් වටහාගෙන නව නායකයාට ලිවීමට පටන් ගත් විට - තාර්කික වෙන්වීම ස්වයංක්‍රීයව අවසන් වේ. ඕනෑම අවස්ථාවක, සමහර පණිවිඩ නැති වනු ඇත, නමුත් සමඟ පමණි acks=1.

ජාලය බෙදීමට මොහොතකට පෙර අනුගාමිකයින් පසුපසට ඇද වැටුණු අතර නායකයා ISR ඔහුට පමණක් සම්පීඩනය කළ මෙම අවස්ථාවෙහි තවත් ප්‍රභේදයක් තිබේ. එවිට සම්බන්ධතාවය අහිමි වීම නිසා එය හුදකලා වේ. නව නායකයෙකු තේරී පත් වේ, නමුත් මුල් නායකයා දිගටම ඇතුළත් කිරීම් පිළිගනී acks=සියල්ල, ISR හි ඔහු හැර වෙන කිසිවෙක් නොමැති නිසා. ජාලය යථා තත්ත්වයට පත් වූ පසු මෙම වාර්තා නැති වී යයි. මෙම විකල්පය වළක්වා ගත හැකි එකම මාර්ගය වේ min.insync.replicas = 2.

අවස්ථාව 7: Kafka Controller Node හට වෙනත් Kafka Node එකක් දැකිය නොහැක

සාමාන්‍යයෙන්, කෆ්කා නෝඩයක් සමඟ සම්බන්ධතාවය නැති වූ පසු, පාලකයට කිසිදු නායකයෙකු වෙනස් කිරීමේ තොරතුරු එයට සම්ප්‍රේෂණය කිරීමට නොහැකි වනු ඇත. නරකම අවස්ථාවෙහිදී, මෙය කෙටි කාලීන තාර්කික වෙන්වීමකට තුඩු දෙනු ඇත, 6 වන අවස්ථාවෙහි මෙන්. බොහෝ විට, දෙවනුව අසමත් වුවහොත් තැරැව්කරු නායකත්වය සඳහා අපේක්ෂකයෙකු බවට පත් නොවනු ඇත.

අවස්ථාව 8: Kafka පාලකය Zookeeper දකින්නේ නැත

Zookeeper හට වැටුණු පාලකයෙන් ping එකක් නොලැබෙන අතර පාලකය ලෙස නව Kafka node එකක් තෝරා ගනු ඇත. මුල් පාලකයට දිගටම එලෙසම පෙනී සිටිය හැක, නමුත් එයට Zookeeper වෙතින් දැනුම්දීම් නොලැබෙන නිසා එයට ඉටු කිරීමට කිසිදු කාර්යයක් නොමැත. ජාලය යථා තත්ත්වයට පත් වූ පසු, ඔහු තවදුරටත් පාලකයෙකු නොවන බවත්, සාමාන්‍ය කෆ්කා නෝඩයක් බවට පත්ව ඇති බවත් ඔහුට වැටහෙනු ඇත.

අවස්ථා වලින් නිගමන

අපි දකින්නේ අනුගාමික සම්බන්ධතාව නැතිවීම නිසා පණිවිඩ නැතිවීම සිදු නොවන නමුත් ජාලය ප්‍රතිසාධනය වන තෙක් අතිරික්තය තාවකාලිකව අඩු කරන බවයි. මෙය, ඇත්ත වශයෙන්ම, නෝඩ් එකක් හෝ කිහිපයක් නැති වුවහොත් දත්ත නැති වීමට හේතු විය හැක.

සම්බන්ධතාවය නැතිවීම හේතුවෙන් නායකයා සත්වෝද්‍යාන පාලකයාගෙන් වෙන් වුව හොත්, මෙහි ප්‍රතිඵලයක් ලෙස පණිවිඩ අහිමි විය හැක acks=1. Zookeeper සමඟ සන්නිවේදනය නොමැතිකම නායකයින් දෙදෙනා සමඟ කෙටි තාර්කික භේදයක් ඇති කරයි. මෙම ගැටළුව පරාමිතිය මගින් විසඳනු ලැබේ acks=සියල්ල.

පරාමිතිය min.insync.replicas අනුරූ දෙකකට හෝ වැඩි ගණනකට එවැනි කෙටි කාලීන අවස්ථා 6 වැනි අවස්ථාවෙහි මෙන් නැතිවූ පණිවිඩවලට හේතු නොවන බවට අමතර සහතිකයක් සපයයි.

නැතිවූ පණිවිඩවල සාරාංශය

Kafka හි ඔබට දත්ත නැති විය හැකි සියලුම ක්‍රම අපි ලැයිස්තුගත කරමු:

• පණිවිඩ භාවිතයෙන් තහවුරු කර ඇත්නම් ඕනෑම නායකයෙක් අසාර්ථක වේ acks=1
• නායකත්වයේ ඕනෑම අපිරිසිදු සංක්‍රාන්තියක්, එනම්, ISR වලින් පිටත අනුගාමිකයෙකුට, සමඟ පවා acks=සියල්ල
• පණිවිඩ භාවිතා කර තහවුරු කර ඇත්නම් Zookeeper වෙතින් නායකයා හුදකලා කිරීම acks=1
• දැනටමත් ISR සමූහය තමාටම හකුලා ගෙන ඇති නායකයා සම්පූර්ණයෙන් හුදකලා කිරීම. සියලුම පණිවිඩ පවා නැති වනු ඇත acks=සියල්ල. මෙය සත්‍ය වන්නේ නම් පමණි min.insync.replicas=1.
• සියලුම කොටස් නෝඩ් වල එකවර අසාර්ථක වීම. පණිවිඩ මතකයෙන් පිළිගෙන ඇති නිසා, සමහරක් තවමත් තැටියට ලියා නොතිබිය හැකිය. සේවාදායකයන් නැවත ආරම්භ කිරීමෙන් පසු, සමහර පණිවිඩ අතුරුදහන් විය හැක.

අපිරිසිදු නායකත්ව සංක්‍රාන්ති වළක්වා ගත හැක්කේ ඒවා තහනම් කිරීමෙන් හෝ අවම වශයෙන් අතිරික්තයන් දෙකක් සහතික කිරීමෙන් ය. වඩාත්ම කල් පවතින වින්යාසය යනු සංයෝජනයකි acks=සියල්ල и min.insync.replicas 1 ට වැඩි

RabbitMQ සහ Kafka වල විශ්වසනීයත්වය සෘජුවම සංසන්දනය කිරීම

විශ්වසනීයත්වය සහ ඉහළ පවතින බව සහතික කිරීම සඳහා, වේදිකා දෙකම ප්‍රාථමික සහ ද්විතියික අනුකරණ පද්ධතියක් ක්‍රියාත්මක කරයි. කෙසේ වෙතත්, RabbitMQ සතුව Achilles විලුඹ ඇත. අසාර්ථක වීමෙන් පසු නැවත සම්බන්ධ වන විට, නෝඩ් ඔවුන්ගේ දත්ත ඉවතලන අතර සමමුහුර්තකරණය අවහිර කරනු ලැබේ. මෙම ද්විත්ව පහර RabbitMQ හි විශාල පෝලිම් වල දිගුකාලීන පැවැත්ම ප්‍රශ්න කරයි. ඔබට අඩු කරන ලද අතිරික්තය හෝ දිගු අවහිර කිරීමේ කාලය පිළිගැනීමට සිදුවනු ඇත. අතිරික්තය අඩු කිරීම දැවැන්ත දත්ත අහිමි වීමේ අවදානම වැඩි කරයි. නමුත් පෝලිම් කුඩා නම්, අතිරික්තය සඳහා, නැවත නැවත සම්බන්ධතා උත්සාහයන් භාවිතා කිරීමෙන් කෙටි කාලසීමාවන් (තත්පර කිහිපයක්) සමඟ කටයුතු කළ හැකිය.

කෆ්කාට මේ ප්‍රශ්නය නැහැ. එය දත්ත බැහැර කරන්නේ නායකයා සහ අනුගාමිකයා අතර ඇති අපසරන ලක්ෂ්‍යයෙන් පමණි. සියලුම බෙදාගත් දත්ත සුරකිනු ලැබේ. ඊට අමතරව, අනුවර්තනය පද්ධතිය අවහිර නොකරයි. නව අනුගාමිකයා අල්ලා ගන්නා අතරතුර නායකයා දිගටම තනතුරු භාර ගනී, එබැවින් devops සඳහා, පොකුරට සම්බන්ධ වීම හෝ නැවත සම්බන්ධ වීම සුළු කාර්යයක් බවට පත්වේ. ඇත්ත වශයෙන්ම, පිටපත් කිරීමේදී ජාල කලාප පළල වැනි ගැටළු තවමත් පවතී. ඔබ එකවර අනුගාමිකයින් කිහිප දෙනෙකු එකතු කළහොත්, ඔබට කලාප පළල සීමාවක් හමුවිය හැක.

RabbitMQ යනු පොකුරක බහු සේවාදායකයන් එකවර අසමත් වන විට විශ්වසනීයත්වය අතින් Kafka ට වඩා උසස් වේ. අප දැනටමත් පවසා ඇති පරිදි, RabbitMQ ප්‍රකාශකයාට තහවුරු කිරීමක් යවන්නේ පණිවිඩය මාස්ටර් සහ සියලුම දර්පණ මගින් තැටියට ලියා පසුව පමණි. නමුත් මෙය හේතු දෙකක් නිසා අමතර ප්‍රමාදයක් එකතු කරයි:

• සෑම මිලි තත්පර සිය ගණනකට වරක් fsync කරන්න
• දර්පණයේ අසාර්ථකත්වය දැකිය හැක්කේ එක් එක් නෝඩයේ (නෙට් ටික්) තිබේද යන්න පරීක්ෂා කරන පැකට් වල ආයු කාලය ඉකුත් වූ පසුව පමණි. දර්පණය මන්දගාමී වුවහොත් හෝ වැටෙන්නේ නම්, මෙය ප්‍රමාදයක් එක් කරයි.

කෆ්කාගේ ඔට්ටුව නම් පණිවිඩයක් නෝඩ් කිහිපයක් හරහා ගබඩා කර ඇත්නම්, එය මතකයට පහර දුන් වහාම පණිවිඩ පිළිගත හැකි බවයි. මේ නිසා, ඕනෑම ආකාරයක පණිවිඩ නැතිවීමේ අවදානමක් ඇත (පවා acks=සියල්ල, min.insync.replicas=2) එකවර අසමත් වීමකදී.

සමස්තයක් වශයෙන්, Kafka වඩා හොඳ මෘදුකාංග කාර්ය සාධනයක් පෙන්නුම් කරන අතර පොකුරු සඳහා බිම් මට්ටමේ සිට නිර්මාණය කර ඇත. විශ්වසනීයත්වය සඳහා අවශ්ය නම් අනුගාමිකයින් සංඛ්යාව 11 දක්වා වැඩි කළ හැකිය. අනුකරණ සාධකය 5 සහ සමමුහුර්තකරණයේ අවම අනුරූ ගණන min.insync.replicas=3 පණිවිඩ නැතිවීම ඉතා දුර්ලභ සිදුවීමක් බවට පත් කරනු ඇත. ඔබේ යටිතල ව්‍යූහයට මෙම ප්‍රතිවර්තන අනුපාතයට සහ අතිරික්තයේ මට්ටමට සහය විය හැකි නම්, ඔබට මෙම විකල්පය තෝරාගත හැක.

RabbitMQ පොකුරු කුඩා පෝලිම් සඳහා හොඳයි. නමුත් අධික වාහන තදබදයක් ඇති විට කුඩා පෝලිම් පවා ඉක්මනින් වර්ධනය විය හැක. පෝලිම් විශාල වූ පසු, ඔබට ලබා ගත හැකි බව සහ විශ්වසනීයත්වය අතර දැඩි තේරීම් කිරීමට සිදු වනු ඇත. RabbitMQ ක්ලස්ටරින් කිරීම වඩාත් සුදුසු වන්නේ RabbitMQ හි නම්‍යශීලීතාවයේ ප්‍රතිලාභ එහි පොකුරු කිරීමේ අවාසි වලට වඩා වැඩි වන සාමාන්‍ය නොවන තත්වයන් සඳහා ය.

RabbitMQ හි විශාල පෝලිම් වලට ඇති අවදානමට එක් ප්‍රතිවිරෝධයක් නම් ඒවා කුඩා පෝලිම් ගණනාවකට කැඩීමයි. ඔබට සම්පූර්ණ පෝලිමේ සම්පූර්ණ ඇණවුම් අවශ්‍ය නොවන්නේ නම්, නමුත් අදාළ පණිවිඩ පමණක් (උදාහරණයක් ලෙස, නිශ්චිත සේවාදායකයෙකුගෙන් ලැබෙන පණිවිඩ), හෝ කිසිවක් ඇණවුම් නොකරන්නේ නම්, මෙම විකල්පය පිළිගත හැකිය: මගේ ව්‍යාපෘතිය දෙස බලන්න Rebalancer පෝලිම බෙදීමට (ව්යාපෘතිය තවමත් මුල් අදියරේ පවතී).

අවසාන වශයෙන්, RabbitMQ සහ Kafka යන දෙකෙහිම පොකුරු සහ අනුකරණ යාන්ත්‍රණයන්හි දෝෂ ගණනාවක් ගැන අමතක නොකරන්න. කාලයාගේ ඇවෑමෙන්, පද්ධති වඩාත් පරිණත සහ ස්ථායී වී ඇත, නමුත් කිසිදු පණිවිඩයක් අලාභයෙන් 100% ආරක්ෂිත නොවනු ඇත! මීට අමතරව, දත්ත මධ්යස්ථාන තුළ මහා පරිමාණ අනතුරු සිදු වේ!

මට යමක් මග හැරී ඇත්නම්, වැරදීමක් සිදුවී ඇත්නම් හෝ ඔබ යම් කරුණක් සමඟ එකඟ නොවන්නේ නම්, අදහස් දැක්වීමට හෝ මා සම්බන්ධ කර ගැනීමට නිදහස් වන්න.

මගෙන් නිතර අසනු ලැබේ: "කෆ්කා හෝ RabbitMQ තෝරාගත යුත්තේ කුමක්ද?", "වඩා හොඳ වේදිකාව කුමක්ද?". සත්‍යය නම් එය ඔබගේ තත්වය, වර්තමාන අත්දැකීම් යනාදිය මත ඇත්ත වශයෙන්ම රඳා පවතින බවයි. මම මගේ මතය ඉදිරිපත් කිරීමට පසුබට වන්නේ සියලු භාවිත අවස්ථා සහ හැකි සීමාවන් සඳහා එක් වේදිකාවක් නිර්දේශ කිරීම අතිශය සරල කිරීමක් වන බැවිනි. මම මේ ලිපි මාලාව ලිව්වේ ඔබට ඔබේම මතයක් ගොඩනගා ගැනීමට හැකි වන පරිදිය.

මේ ක්‍රම දෙකම මේ ප්‍රදේශයේ නායකයන් බව මට කියන්න අවශ්‍යයි. ව්‍යාපෘති පිළිබඳ මගේ අත්දැකීම් අනුව මම සහතික කළ පණිවිඩ ඇණවුම් කිරීම සහ විශ්වසනීයත්වය වැනි දේවල් අගය කිරීමට නැඹුරු වන නිසා මම ටිකක් පක්ෂග්‍රාහී විය හැකිය.

මෙම විශ්වසනීයත්වය සහ සහතික කළ ඇණවුම් නොමැති වෙනත් තාක්ෂණයන් මම දකිමි, පසුව මම RabbitMQ සහ Kafka දෙස බලන අතර මෙම පද්ධති දෙකෙහිම ඇදහිය නොහැකි වටිනාකම අවබෝධ කරගනිමි.

මූලාශ්රය: www.habr.com