පණිවිඩ තැරැව්කරුවන් අවබෝධ කර ගැනීම. ActiveMQ සහ Kafka සමඟ පණිවිඩ යැවීමේ යාන්ත්‍ර විද්‍යාව ඉගෙන ගැනීම. පරිච්ඡේදය 3. කෆ්කා

කුඩා පොතක පරිවර්තනයේ අඛණ්ඩ පැවැත්ම:
පණිවිඩ තැරැව්කරුවන් අවබෝධ කර ගැනීම
කර්තෘ: Jakub Korab, ප්‍රකාශකයා: O'Reilly Media, Inc., ප්‍රකාශනය කළ දිනය: ජූනි 2017, ISBN: 9781492049296.

පෙර පරිවර්තන කොටස: පණිවිඩ තැරැව්කරුවන් අවබෝධ කර ගැනීම. ActiveMQ සහ Kafka සමඟ පණිවිඩ යැවීමේ යාන්ත්‍ර විද්‍යාව ඉගෙන ගැනීම. 1 වන පරිච්ඡේදය හැඳින්වීම

3 වන පරිච්ඡේදය

කාෆ්කා

සම්ප්‍රදායික පණිවිඩ තැරැව්කරුවන්ගේ සීමාවන් මඟහරවා ගැනීමට සහ විවිධ ලක්ෂ්‍යයට-ලක්ෂ්‍ය අන්තර්ක්‍රියා සඳහා බහු පණිවිඩ තැරැව්කරුවන් පිහිටුවීමෙන් වැළකීමට LinkedIn විසින් Kafka දියුණු කරන ලදී, එය මෙම පොතේ 28 පිටුවේ "පරිමාණය කිරීම සහ පිටතට" යටතේ විස්තර කර ඇත. නිෂ්පාදකයින්ගේ හෝ අනෙකුත් පාරිභෝගිකයින්ගේ ඵලදායිතාවයට බලපෑම් නොකර බහු පද්ධති විසින් එම දත්ත භාවිතා කිරීමට තවමත් ඉඩ ලබා දෙන අතරම, පිටු ක්ලික් කිරීම් සහ ප්‍රවේශ ලොග වැනි ඉතා විශාල දත්ත ප්‍රමාණයක් එක්-මාර්ගයට ඇතුළු කිරීම මත LinkedIn බොහෝ දුරට රඳා පවතින අවස්ථා භාවිතා කරන්න. ඇත්ත වශයෙන්ම, Kafka පැවතීමට හේතුව විශ්ව දත්ත නල මාර්ගය විස්තර කරන ආකාරයේ පණිවිඩකරණ ගෘහ නිර්මාණ ශිල්පයක් ලබා ගැනීමයි.

මෙම අවසාන ඉලක්කයට අනුව, වෙනත් අවශ්‍යතා ස්වභාවිකවම මතු විය. කෆ්කා කළ යුත්තේ:

• අතිශයින්ම වේගවත් වන්න
• පණිවිඩ සමඟ වැඩ කිරීමේදී වැඩි කලාප පළලක් ලබා දෙන්න
• Publisher-Subscriber සහ Point-to-Point මාදිලි සඳහා සහය වන්න
• පාරිභෝගිකයින් එකතු කිරීමත් සමඟ වේගය අඩු නොකරන්න. උදාහරණයක් ලෙස, ගමනාන්තයේ පාරිභෝගිකයින් සංඛ්‍යාව වර්ධනය වන විට ActiveMQ හි පෝලිමේ සහ මාතෘකාව යන දෙකෙහිම කාර්ය සාධනය පිරිහී යයි.
• තිරස් ලෙස පරිමාණය කළ හැකි වන්න; පණිවිඩ දිගටම පවතින එක් තැරැව්කරුවෙකුට එය කළ හැක්කේ උපරිම තැටි වේගයකින් පමණක් නම්, කාර්ය සාධනය වැඩි කිරීම සඳහා තනි තැරැව්කාර අවස්ථාවකින් ඔබ්බට යාම අර්ථවත් කරයි
• පණිවිඩ ගබඩා කිරීමට සහ නැවත ලබා ගැනීමට ප්‍රවේශය සීමා කරන්න

මේ සියල්ල සාක්ෂාත් කර ගැනීම සඳහා, කෆ්කා විසින් සේවාලාභීන්ගේ සහ පණිවිඩ හුවමාරු තැරැව්කරුවන්ගේ භූමිකාවන් සහ වගකීම් නැවත අර්ථකථනය කරන ගෘහ නිර්මාණ ශිල්පයක් අනුගමනය කළේය. JMS ආකෘතිය ඉතා තැරැව්කාර නැඹුරුවක් ඇති අතර, තැරැව්කරු පණිවිඩ බෙදා හැරීම සඳහා වගකිව යුතු අතර සේවාදායකයින්ට පණිවිඩ යැවීම සහ ලැබීම ගැන පමණක් කරදර විය යුතුය. අනෙක් අතට, Kafka, සේවාලාභී කේන්ද්‍රීය වන අතර, පාරිභෝගිකයා අතිශය වේගවත් සහ පරිමාණය කළ හැකි තැරැව්කරුවෙකු සඳහා හුවමාරු කර ගැනීම සඳහා පාරිභෝගිකයින්ට අදාළ පණිවිඩ සාධාරණ ලෙස බෙදා හැරීම වැනි සම්ප්‍රදායික තැරැව්කරුවෙකුගේ බොහෝ විශේෂාංග ලබා ගනී. සාම්ප්‍රදායික පණිවිඩකරණ පද්ධති සමඟ වැඩ කර ඇති පුද්ගලයින් සඳහා, කෆ්කා සමඟ වැඩ කිරීම සඳහා මනසෙහි මූලික වෙනසක් අවශ්‍ය වේ.
සාම්ප්‍රදායික තැරැව්කරුවකු හා සසඳන විට විශාල ප්‍රමාණයේ බොහෝ ඇණවුම් මඟින් ප්‍රතිදානය වැඩි කළ හැකි පණිවිඩ යැවීමේ යටිතල ව්‍යුහයක් නිර්මාණය කිරීමට මෙම ඉංජිනේරු දිශාව හේතු වී ඇත. අප දකින පරිදි, මෙම ප්‍රවේශය වෙළඳාම් සමඟ පැමිණේ, එයින් අදහස් වන්නේ Kafka ඇතැම් ආකාරයේ වැඩ බර සහ ස්ථාපිත මෘදුකාංග සඳහා සුදුසු නොවන බවයි.

ඒකාබද්ධ ගමනාන්ත ආකෘතිය

ඉහත විස්තර කර ඇති අවශ්‍යතා සපුරාලීම සඳහා, කෆ්කා විසින් එක් ආකාරයක ගමනාන්තයක් යටතේ ප්‍රකාශන-දායකත්වය සහ ලක්ෂ්‍යයට පණිවිඩ යැවීම ඒකාබද්ධ කර ඇත - මාතෘකාව. පණිවුඩකරණ පද්ධති සමඟ වැඩ කළ පුද්ගලයින්ට මෙය ව්‍යාකූල වන අතර, "මාතෘකාව" යන වචනයෙන් (මාතෘකාවෙන්) කියවීම නොනැසී පවතින විකාශන යාන්ත්‍රණයකට යොමු වේ. මෙම පොතෙහි හැඳින්වීමෙහි අර්ථ දක්වා ඇති පරිදි කෆ්කා මාතෘකා දෙමුහුන් ගමනාන්ත වර්ගයක් ලෙස සැලකිය යුතුය.

මෙම පරිච්ඡේදයේ ඉතිරි කොටස සඳහා, අපි වෙනත් ආකාරයකින් පැහැදිලිව සඳහන් නොකරන්නේ නම්, "මාතෘකාව" යන යෙදුම කෆ්කා මාතෘකාවක් වෙත යොමු වනු ඇත.

මාතෘකා හැසිරෙන ආකාරය සහ ඒවා සපයන සහතික මොනවාද යන්න සම්පූර්ණයෙන් අවබෝධ කර ගැනීමට, අපි මුලින්ම ඒවා Kafka හි ක්‍රියාත්මක කරන ආකාරය දෙස බැලිය යුතුය.
කෆ්කා හි සෑම මාතෘකාවකටම තමන්ගේම ලඝු-සටහනක් ඇත.
කෆ්කා වෙත පණිවිඩ යවන නිෂ්පාදකයින් මෙම ලොගයට ලියන අතර පාරිභෝගිකයින් නිරන්තරයෙන් ඉදිරියට යන පොයින්ටර් භාවිතයෙන් ලොගයෙන් කියවයි. වරින් වර, කෆ්කා ලොගයේ පැරණිතම කොටස් මකා දමයි, එම කොටස්වල පණිවිඩ කියවා ඇතත් නැතත්. කෆ්කාගේ සැලසුමේ කේන්ද්‍රීය කොටස නම්, තැරැව්කරු පණිවිඩ කියෙව්වත් නැතත් තැකීමක් නොකරයි - එය සේවාදායකයාගේ වගකීමයි.

"ලොග්" සහ "පොයින්ටර්" යන පද නොපෙන්වයි කෆ්කා ලියකියවිලි. තේරුම් ගැනීමට උපකාර කිරීම සඳහා මෙම සුප්‍රසිද්ධ යෙදුම් මෙහි භාවිතා වේ.

මෙම ආකෘතිය ActiveMQ ට වඩා සම්පූර්ණයෙන්ම වෙනස් වේ, එහිදී සියලුම පෝලිම් වල පණිවිඩ එකම ලොගයේ ගබඩා කර ඇති අතර තැරැව්කරු විසින් පණිවිඩ කියවීමෙන් පසු මකා දැමූ ලෙස සලකුණු කරයි.
අපි දැන් ටිකක් ගැඹුරට හාරා මාතෘකා ලොගය වඩාත් විස්තරාත්මකව බලමු.
කෆ්කා ලොගය කොටස් කිහිපයකින් සමන්විත වේ (රූපය 3-1) කෆ්කා සෑම කොටසකම දැඩි ඇණවුම් කිරීම සහතික කරයි. මෙයින් අදහස් කරන්නේ යම් අනුපිළිවෙලකට කොටස වෙත ලියා ඇති පණිවිඩ එම අනුපිළිවෙලින් කියවන බවයි. සෑම කොටසක්ම රෝලිං ලොග් ගොනුවක් ලෙස ක්‍රියාත්මක වේ උප කුලකයක් (උප කට්ටලය) එහි නිෂ්පාදකයින් විසින් මාතෘකාවට යවන ලද සියලුම පණිවිඩ. සාදන ලද මාතෘකාවෙහි, පෙරනිමියෙන්, එක් කොටසක් අඩංගු වේ. කොටස් පිළිබඳ අදහස තිරස් පරිමාණය සඳහා Kafka හි කේන්ද්‍රීය අදහසයි.

රූපය 3-1. කෆ්කා කොටස්

නිෂ්පාදකයෙක් කෆ්කා මාතෘකාවකට පණිවිඩයක් යවන විට, එය කුමන කොටසට පණිවිඩය යැවිය යුතුද යන්න තීරණය කරයි. අපි මෙය පසුව වඩාත් විස්තරාත්මකව බලමු.

පණිවිඩ කියවීම

පණිවිඩ කියවීමට අවශ්‍ය සේවාලාභියා නම් කරන ලද දර්ශකයක් කළමනාකරණය කරයි පාරිභෝගික කණ්ඩායම, එය පෙන්වා දෙයි ඕෆ්සෙට් කොටසේ පණිවිඩ. ඕෆ්සෙට් යනු කොටසක ආරම්භයේ දී 0 න් ආරම්භ වන වර්ධක පිහිටුමකි. පරිශීලක-නිර්වචනය කරන ලද group_id හරහා API හි සඳහන් වන මෙම පාරිභෝගික කණ්ඩායම අනුරූප වේ එක් තාර්කික පාරිභෝගිකයෙක් හෝ පද්ධතියක්.

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

කියවීමේ ගැටලුව පහත පරිදි නිරූපණය කළ හැකිය:

• මාතෘකාවට කොටස් කිහිපයක් ඇත
• පාරිභෝගිකයින් කිහිප දෙනෙකුට එකවර මාතෘකාවක් භාවිතා කළ හැකිය
• පාරිභෝගිකයන් පිරිසකට වෙනම අවස්ථා කිහිපයක් තිබිය හැක

මෙය සුළුපටු නොවන බොහෝ-බොහෝ ගැටලුවකි. පාරිභෝගික කණ්ඩායම්, පාරිභෝගික අවස්ථාවන් සහ කොටස් අතර සබඳතා Kafka හසුරුවන්නේ කෙසේද යන්න තේරුම් ගැනීමට, ක්‍රමානුකූලව වඩාත් සංකීර්ණ කියවීම් අවස්ථා මාලාවක් දෙස බලමු.

පාරිභෝගිකයින් සහ පාරිභෝගික කණ්ඩායම්

එක් කොටසක් සහිත මාතෘකාවක් ආරම්භක ලක්ෂ්‍යයක් ලෙස ගනිමු (රූපය 3-2).

රූපය 3-2. පාරිභෝගිකයා කොටස් වලින් කියවයි

පාරිභෝගික අවස්ථාවක් මෙම මාතෘකාවට තමන්ගේම group_id සමඟ සම්බන්ධ වූ විට, එය එම කොටසෙහි කියවීමේ කොටසක් සහ ඕෆ්සෙට් එකක් පවරනු ලැබේ. මෙම ඕෆ්සෙට්හි පිහිටුම සේවාලාභියා තුළ වින්‍යාස කර ඇත්තේ නවතම ස්ථානයට (නවතම පණිවිඩය) හෝ මුල්ම ස්ථානයට (පැරණිම පණිවිඩය) දර්ශකයක් ලෙසය. පාරිභෝගිකයා මාතෘකාවෙන් පණිවිඩ (ඡන්ද විමසීම්) ඉල්ලා සිටින අතර එමඟින් ඒවා ලොගයෙන් අනුක්‍රමිකව කියවීමට හේතු වේ.
ඕෆ්සෙට් ස්ථානය නිතිපතා කෆ්කා වෙත කැපවී අභ්‍යන්තර මාතෘකාවක පණිවිඩ ලෙස ගබඩා කර ඇත _පාරිභෝගික_ඕෆ්සෙට්. සාමාන්‍ය තැරැව්කරුවෙකු මෙන් නොව කියවීමේ පණිවිඩ තවමත් මකා නොදමන අතර, සේවාදායකයාට දැනටමත් නරඹා ඇති පණිවිඩ නැවත සැකසීමට ඕෆ්සෙට් එක රිවයින්ඩ් කළ හැක.

දෙවන තාර්කික පාරිභෝගිකයෙකු වෙනත් group_id භාවිතා කරමින් සම්බන්ධ වන විට, එය පළමු දර්ශකයෙන් ස්වාධීන වන දෙවන දර්ශකයක් කළමනාකරණය කරයි (රූපය 3-3) මේ අනුව, Kafka මාතෘකාවක් එක් පාරිභෝගිකයෙකු සිටින පෝලිමක් මෙන් සහ බහු පාරිභෝගිකයින් දායක වන සාමාන්‍ය ප්‍රකාශන-දායක (pub-sub) මාතෘකාවක් මෙන් ක්‍රියා කරයි, සියලු පණිවිඩ ගබඩා කර ඇති අතර කිහිප වතාවක් සැකසිය හැකි අමතර ප්‍රතිලාභයක් ඇත.

රූපය 3-3. විවිධ පාරිභෝගික කණ්ඩායම්වල පාරිභෝගිකයන් දෙදෙනෙක් එකම කොටසකින් කියවති

පාරිභෝගික කණ්ඩායමක පාරිභෝගිකයින්

එක් පාරිභොගික අවස්ථාවක් කොටසකින් දත්ත කියවන විට, එය පෙර කොටසේ විස්තර කර ඇති පරිදි දර්ශකයෙහි සම්පූර්ණ පාලනය සහ පණිවිඩ සැකසීම සිදු කරයි.
පාරිභෝගිකයින් කිහිප දෙනෙකු එකම group_id සමඟ එක් කොටසක් සහිත මාතෘකාවකට සම්බන්ධ කර ඇත්නම්, අවසන් වරට සම්බන්ධ වූ අවස්ථාවට දර්ශකය පාලනය කරන අතර එතැන් සිට එයට සියලුම පණිවිඩ ලැබෙනු ඇත (රූපය 3-4).

රූපය 3-4. එකම පාරිභෝගික කණ්ඩායමක පාරිභෝගිකයන් දෙදෙනෙක් එකම කොටසකින් කියවති

පාරිභෝගික අවස්ථා ගණන කොටස් ගණන ඉක්මවා යන මෙම සැකසුම් ක්‍රමය, එක්තරා ආකාරයක සුවිශේෂී පාරිභෝගිකයෙකු ලෙස සැලකිය හැකිය. බහු පාරිභෝගිකයින් සමාන්තරව ධාවනය කිරීම ("ක්‍රියාකාරී-ක්‍රියාකාරී" හෝ "උණුසුම්-උණුසුම්") වඩා සාමාන්‍ය දෙයක් වුවද, ඔබට ඔබේ පාරිභෝගික අවස්ථාවන්හි "ක්‍රියාකාරී-නිෂ්ක්‍රීය" (හෝ "උණුසුම්-උණුසුම්") පොකුරු අවශ්‍ය නම් මෙය ප්‍රයෝජනවත් විය හැක. පාරිභෝගිකයන් පොරොත්තුවෙන්.

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

බොහෝ විට, අපි පාරිභෝගිකයින්ගේ අවස්ථා කිහිපයක් නිර්මාණය කරන විට, අපි මෙය කරන්නේ පණිවිඩ සමාන්තරව සැකසීමට හෝ කියවීමේ වේගය වැඩි කිරීමට හෝ කියවීමේ ක්‍රියාවලියේ ස්ථායිතාව වැඩි කිරීමට ය. වරකට කොටසකින් දත්ත කියවිය හැක්කේ එක් පාරිභෝගික අවස්ථාවකට පමණක් බැවින්, Kafka හි මෙය සාක්ෂාත් කර ගන්නේ කෙසේද?

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

කෆ්කා හි මෙම ගැටළුව විසඳීම සඳහා කැනොනිකල් මාර්ගය වන්නේ b භාවිතා කිරීමයිОතවත් කොටස්.

කොටස් කිරීම

තනි තැරැව්කාර අවස්ථාවක කලාප පළලෙන් ඔබ්බට මාතෘකාවක් කියවීම සහ පරිමාණය කිරීම සමාන්තරකරණය කිරීමේ ප්‍රධාන යාන්ත්‍රණය කොටස් වේ. මෙය වඩාත් හොඳින් අවබෝධ කර ගැනීම සඳහා, කොටස් දෙකක් සහිත මාතෘකාවක් සහ එක් පාරිභෝගිකයෙකු මෙම මාතෘකාවට දායක වන තත්වයක් සලකා බලමු (රූපය 3-5).

රූපය 3-5. එක් පාරිභෝගිකයෙක් බහුවිධ කොටස් වලින් කියවයි

මෙම අවස්ථාවෙහිදී, කොටස් දෙකෙහිම එහි group_id වලට අනුරූප වන පොයින්ටර් පාලනය පාරිභෝගිකයාට ලබා දී ඇති අතර කොටස් දෙකෙන්ම පණිවිඩ කියවීම ආරම්භ කරයි.
මෙම මාතෘකාවට එකම group_id සඳහා අමතර පාරිභෝගිකයෙකු එක් කළ විට, Kafka පළමු පාරිභෝගිකයා සිට දෙවන පාරිභෝගිකයා දක්වා එක් කොටසක් නැවත වෙන් කරයි. ඊට පසු, පාරිභෝගිකයාගේ සෑම අවස්ථාවක්ම මාතෘකාවේ එක් කොටසකින් කියවනු ලැබේ (රූපය 3-6).

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

රූපය 3-6. එකම පාරිභෝගික කණ්ඩායමේ පාරිභෝගිකයින් දෙදෙනෙකු විවිධ කොටස් වලින් කියවනු ලැබේ

JMS පෝලිම පවත්වා ගැනීමට අවශ්‍ය පණිවිඩ බෙදා හැරීමට සාපේක්ෂව මෙම යෝජනා ක්‍රමය Kafka තැරැව්කරුගේ සංකීර්ණත්වය බෙහෙවින් අඩු කරයි. මෙන්න ඔබ පහත කරුණු ගැන කරදර විය යුතු නැත:

• රවුන්ඩ් රොබින් වෙන් කිරීම, පෙර ලබා ගැනීමේ බෆරවල වත්මන් ධාරිතාව හෝ පෙර පණිවිඩ (JMS පණිවිඩ කණ්ඩායම් සඳහා) මත පදනම්ව ඊළඟ පණිවිඩය ලැබිය යුත්තේ කුමන පාරිභෝගිකයාටද?
• කුමන පණිවිඩ යවන්නේ කුමන පාරිභෝගිකයින්ටද සහ අසාර්ථක වූ විට ඒවා නැවත ලබාදිය යුතුද යන්න.

කෆ්කා තැරැව්කරු කළ යුත්තේ පාරිභෝගිකයා විසින් පාරිභෝගිකයා ඉල්ලා සිටින විට අනුක්‍රමිකව පණිවිඩ යැවීමයි.

කෙසේ වෙතත්, සෝදුපත් කියවීම සමාන්තරගත කිරීම සහ අසාර්ථක පණිවිඩ නැවත යැවීම සඳහා වන අවශ්‍යතා පහව යන්නේ නැත - ඒවා සඳහා වගකීම තැරැව්කරුගෙන් සේවාදායකයා වෙත පැවරේ. මෙයින් අදහස් කරන්නේ ඒවා ඔබගේ කේතයේ සැලකිල්ලට ගත යුතු බවයි.

පණිවිඩ යැවීම

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

JMS හි අපි පාර-දත්ත (ශීර්ෂ සහ ගුණාංග) සහිත පණිවිඩ ව්‍යුහයක් සහ ගෙවීම් (ගෙවීම්) අඩංගු ශරීරයක් භාවිතා කරන අතර, Kafka හි පණිවිඩය වන්නේ යුගල "ප්රධාන වටිනාකම". පණිවිඩය ගෙවීම අගයක් ලෙස යවනු ලැබේ. අනෙක් අතට, යතුර ප්රධාන වශයෙන් කොටස් කිරීම සඳහා භාවිතා වන අතර එය අඩංගු විය යුතුය ව්‍යාපාර තාර්කික විශේෂිත යතුරඅදාළ පණිවිඩ එකම කොටසේ තැබීමට.

2 වන පරිච්ඡේදයේ, තනි පාරිභෝගිකයෙකු විසින් අනුපිළිවෙලට අදාළ සිදුවීම් සැකසීමට අවශ්‍ය වන මාර්ගගත ඔට්ටු ඇල්ලීමේ අවස්ථාව අපි සාකච්ඡා කළෙමු:

1. පරිශීලක ගිණුම වින්‍යාස කර ඇත.
2. ගිණුමට මුදල් බැර කෙරේ.
3. ගිණුමෙන් මුදල් ලබා ගන්නා ඔට්ටුවක් සාදනු ලැබේ.

සෑම සිදුවීමක්ම මාතෘකාවක් වෙත පළ කරන ලද පණිවිඩයක් නම්, ස්වභාවික යතුර ගිණුම් හැඳුනුම්පත වනු ඇත.
Kafka Producer API භාවිතයෙන් පණිවිඩයක් යවන විට, එය කොටස් ශ්‍රිතයකට යවනු ලබන අතර, එම පණිවිඩය සහ Kafka පොකුරේ වත්මන් තත්ත්වය අනුව, පණිවිඩය යැවිය යුතු කොටසේ ID නැවත ලබා දේ. මෙම අංගය ජාවා හි ක්‍රියාත්මක වන්නේ Partitioner අතුරුමුහුණත හරහාය.

මෙම අතුරු මුහුණත මේ ආකාරයෙන් පෙනේ:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

ඔබේම කොටස් කිරීමේ උපාය ලිවීම

ඔබට පණිවිඩ ගෙවීම සමඟ පාර-දත්ත යැවීමට අවශ්‍ය උදාහරණයක් බලමු. අපගේ උදාහරණයේ ගෙවීම ක්‍රීඩා ගිණුමට තැන්පතුවක් කිරීමට උපදෙස් වේ. උපදෙස් යනු සම්ප්‍රේෂණයේදී වෙනස් නොවන බවට සහතික වීමට අප කැමති දෙයක් වන අතර එම උපදෙස් ආරම්භ කළ හැක්කේ විශ්වාසදායක උඩුගත පද්ධතියකට පමණක් බව සහතික කර ගැනීමට අවශ්‍ය වේ. මෙම අවස්ථාවෙහිදී, පණිවිඩය සත්‍යාපනය කිරීම සඳහා අත්සනක් භාවිතා කිරීමට යැවීමේ සහ ලැබීමේ පද්ධති එකඟ වේ.
සාමාන්‍ය JMS වලදී, අපි හුදෙක් "පණිවිඩ අත්සන" ගුණාංගයක් නිර්වචනය කර එය පණිවිඩයට එක් කරන්නෙමු. කෙසේ වෙතත්, Kafka අපට පාර-දත්ත සම්මත කිරීමේ යාන්ත්‍රණයක් ලබා නොදේ, යතුරක් සහ අගයක් පමණි.

වටිනාකම අපට සුරැකීමට අවශ්‍ය බැංකු හුවමාරු ගෙවීමක් වන බැවින්, යතුරෙහි භාවිතා කිරීමට දත්ත ව්‍යුහය නිර්වචනය කිරීම හැර අපට වෙනත් විකල්පයක් නොමැත. කොටස් කිරීම සඳහා අපට ගිණුම් හැඳුනුම්පතක් අවශ්‍ය යැයි උපකල්පනය කරමින්, ගිණුමකට අදාළ සියලුම පණිවිඩ අනුපිළිවෙලින් සැකසිය යුතු බැවින්, අපි පහත JSON ව්‍යුහය ඉදිරිපත් කරන්නෙමු:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

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

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

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

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

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

MirrorMaker විසින් එම මාතෘකාව සඳහා වන කොටස් සංඛ්‍යාව පොකුරු දෙකකින් සමාන නොවිය හැකි බැවින්, පොකුරු අතර ප්‍රතිවර්තනය කිරීමේදී පණිවිඩ අතර සාපේක්ෂ අනුපිළිවෙලක් පවත්වා ගැනීම සඳහා අනුකරණය කරන ලද මාතෘකාවේ යතුරු තේරුම් ගත යුතුය.

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

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

JMS තැරැව්කරුවන් ද එවැනි අවශ්‍යතා සමඟ කටයුතු කළ යුතුය. JMS Message Groups (ඇලෙන බර තුලනය කිරීමේ (SLB) ක්‍රමෝපායේ වෙනසක්) හරහා ක්‍රියාත්මක කර ඇති එකම පාරිභෝගිකයාට අදාළ පණිවිඩ යැවීමේ යාන්ත්‍රණයට පණිවිඩ සම්බන්ධ ලෙස සලකුණු කිරීම ද එවන්නාට අවශ්‍ය වේ. JMS සම්බන්ධයෙන් ගත් කල, මෙම සම්බන්ධිත පණිවිඩ සමූහය බොහෝ පාරිභෝගිකයින් අතරින් එක් පාරිභෝගිකයෙකුට යැවීම සහ පාරිභෝගිකයා වැටුණහොත් සමූහයේ හිමිකාරිත්වය පැවරීම සඳහා තැරැව්කරු වගකිව යුතුය.

නිෂ්පාදක ගිවිසුම්

පණිවිඩ යැවීමේදී සලකා බැලිය යුතු එකම දෙය කොටස් කිරීම නොවේ. අපි Java API හි නිෂ්පාදක පන්තියේ send() ක්‍රම දෙස බලමු:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

ක්‍රම දෙකම අනාගතය ආපසු ලබා දෙන බව වහාම සටහන් කළ යුතුය, එයින් පෙන්නුම් කරන්නේ යැවීමේ මෙහෙයුම වහාම සිදු නොවන බවයි. එහි ප්‍රතිඵලය වන්නේ එක් එක් ක්‍රියාකාරී කොටස් සඳහා යැවීමේ බෆරයට පණිවිඩයක් (ProducerRecord) ලියා Kafka client library හි පසුබිම් නූලක් ලෙස තැරැව්කරු වෙත යැවීමයි. මෙය දේවල් ඇදහිය නොහැකි තරම් වේගවත් කරන අතර, එයින් අදහස් වන්නේ අද්දැකීම් අඩු යෙදුමකට එහි ක්‍රියාවලිය නතර කළහොත් පණිවිඩ නැති විය හැකි බවයි.

සෑම විටම මෙන්, කාර්ය සාධනයේ වියදමින් යැවීමේ මෙහෙයුම වඩාත් විශ්වාසදායක කිරීමට ක්රමයක් තිබේ. මෙම බෆරයේ ප්‍රමාණය 0 ලෙස සැකසිය හැකි අතර, පහත පරිදි තැරැව්කරු වෙත පණිවිඩ මාරු කිරීම අවසන් වන තෙක් බලා සිටීමට යවන යෙදුම් නූලට බල කෙරෙනු ඇත:

RecordMetadata metadata = producer.send(record).get();

පණිවිඩ කියවීම ගැන වැඩි විස්තර

පණිවිඩ කියවීමට අනුමාන කළ යුතු අමතර සංකීර්ණතා ඇත. JMS API මෙන් නොව, පණිවිඩයකට ප්‍රතිචාර වශයෙන් පණිවිඩ අසන්නෙකු ධාවනය කළ හැකි, the පාරිභෝගික කෆ්කා ඡන්ද විමසීම් පමණි. අපි ක්රමය දෙස සමීපව බලමු මත විමසුම ()මෙම කාර්යය සඳහා භාවිතා වේ:

ConsumerRecords < K, V > poll(long timeout);

ක්‍රමයේ ප්‍රතිලාභ අගය බහු වස්තු අඩංගු බහාලුම් ව්‍යුහයකි පාරිභෝගික වාර්තාව විය හැකි කොටස් කිහිපයකින්. පාරිභෝගික වාර්තාව එය ව්‍යුත්පන්න කර ඇති කොටස වැනි ආශ්‍රිත පාර-දත්ත සමඟ යතුරු-අගය යුගල සඳහා ධාරක වස්තුවකි.

2 වන පරිච්ඡේදයේ සාකච්ඡා කර ඇති පරිදි, පණිවිඩ සාර්ථකව හෝ අසාර්ථක ලෙස සැකසීමෙන් පසු ඒවාට සිදුවන්නේ කුමක්ද යන්න අප මතක තබා ගත යුතුය, උදාහරණයක් ලෙස, සේවාදායකයාට පණිවිඩය සැකසීමට නොහැකි නම් හෝ එය ගබ්සා වුවහොත්. JMS හි, මෙය පිලිගැනීමේ මාදිලියක් හරහා හසුරුවන ලදී. තැරැව්කරු විසින් සාර්ථකව සැකසූ පණිවිඩය මකා දමනු ඇත, නැතහොත් අමු හෝ ව්‍යාජ පණිවිඩය නැවත ලබා දෙනු ඇත (ගනුදෙනු භාවිතා කර ඇතැයි උපකල්පනය කරයි).
කෆ්කා ඉතා වෙනස් ලෙස ක්රියා කරයි. සෝදුපත් කියවීමෙන් පසු තැරැව්කරු තුළ පණිවිඩ මකා නොදමනු ලබන අතර, අසාර්ථක වූ විට සිදු වන්නේ සෝදුපත් කියවීමේ කේතයේම වගකීමයි.

අප පවසා ඇති පරිදි, පාරිභෝගික කණ්ඩායම ලොග් හි ඕෆ්සෙට් සමඟ සම්බන්ධ වේ. මෙම ඕෆ්සෙට් හා සම්බන්ධ ලොග් පිහිටීම ප්‍රතිචාර වශයෙන් නිකුත් කිරීමට නියමිත ඊළඟ පණිවිඩයට අනුරූප වේ මත විමසුම (). මෙම ඕෆ්සෙට් වැඩි වන කාලය කියවීම සඳහා තීරණාත්මක වේ.

කලින් සාකච්ඡා කළ කියවීමේ ආකෘතිය වෙත ආපසු යාම, පණිවිඩ සැකසීම අදියර තුනකින් සමන්විත වේ:

1. කියවීම සඳහා පණිවිඩයක් ලබා ගන්න.
2. පණිවිඩය සකසන්න.
3. පණිවිඩය තහවුරු කරන්න.

කෆ්කා පාරිභෝගිකයා වින්‍යාස කිරීමේ විකල්පයක් සමඟ පැමිණේ enable.auto.commit. මෙය "ස්වයංක්‍රීය" යන වචනය අඩංගු සැකසුම් වල බහුලව භාවිතා වන පරිදි නිතර භාවිතා වන පෙරනිමි සැකසුමකි.

Kafka 0.10 ට පෙර, මෙම විකල්පය භාවිතා කරන සේවාලාභියෙකු මීළඟ ඇමතුමේදී කියවූ අවසාන පණිවිඩයේ ඕෆ්සෙට් යවනු ලැබේ. මත විමසුම () සැකසීමෙන් පසු. මෙයින් අදහස් කරන්නේ සේවාදායකයා දැනටමත් ඒවා සකසා ඇති නමුත් ඇමතීමට පෙර අනපේක්ෂිත ලෙස විනාශ වී ඇත්නම් දැනටමත් ලබාගෙන ඇති ඕනෑම පණිවිඩයක් නැවත සැකසීමට හැකි බවයි. මත විමසුම (). පණිවිඩයක් කොපමණ වාරයක් කියවා ඇත්ද යන්න ගැන තැරැව්කරු කිසිදු තත්වයක් තබා නොගන්නා නිසා, එම පණිවිඩය ලබා ගන්නා ඊළඟ පාරිභෝගිකයා නරක දෙයක් සිදු වූ බව නොදනී. මෙම හැසිරීම ව්යාජ ගනුදෙනුවක් විය. පණිවිඩය සාර්ථකව සකසනු ලැබුවහොත් පමණක් ඕෆ්සෙට් සිදු කරනු ලැබේ, නමුත් සේවාදායකයා ගබ්සා කළහොත්, තැරැව්කරු එම පණිවිඩයම වෙනත් සේවාදායකයෙකුට යවනු ඇත. මෙම හැසිරීම පණිවිඩ බෙදා හැරීමේ සහතිකයට අනුකූල විය "අවම වශයෙන් එක් වරක්«.

Kafka 0.10 හි, සේවාදායක කේතය වෙනස් කර ඇති අතර එමඟින් වින්‍යාස කර ඇති පරිදි සේවාදායක පුස්තකාලය මඟින් කැපවීම වරින් වර ක්‍රියාත්මක වේ. auto.commit.interval.ms. මෙම හැසිරීම JMS AUTO_ACKNOWLEDGE සහ DUPS_OK_ACKNOWLEDGE මාදිලි අතර කොතැනක හෝ ඇත. autocommit භාවිතා කරන විට, පණිවිඩ ඇත්ත වශයෙන්ම සකසන ලද්දේද යන්න නොසලකා ඒවා කැප කළ හැකිය - මන්දගාමී පාරිභෝගිකයෙකු සම්බන්ධයෙන් මෙය සිදුවිය හැකිය. පාරිභෝගිකයෙකු ගබ්සා කළහොත්, ඊළඟ පාරිභෝගිකයා විසින් පණිවිඩ ලබා දෙනු ඇත, එය කැපවූ ස්ථානයෙන් ආරම්භ වන අතර, එය මඟ හැරුණු පණිවිඩයකට හේතු විය හැක. මෙම අවස්ථාවෙහිදී, කෆ්කාට පණිවිඩ නැති වූයේ නැත, කියවීමේ කේතය ඒවා ක්‍රියාත්මක කළේ නැත.

මෙම ප්‍රකාරයට 0.9 අනුවාදයේ ඇති පොරොන්දුවම ඇත: පණිවිඩ සැකසීමට හැකිය, නමුත් එය අසාර්ථක වුවහොත්, ඕෆ්සෙට් එක කැප නොකළ හැකි අතර, බෙදා හැරීම දෙගුණ කිරීමට හේතු විය හැක. ක්‍රියාත්මක කරන විට ඔබට ලැබෙන පණිවිඩ ගණන වැඩි වේ මත විමසුම (), මෙම ගැටලුව වැඩි වේ.

21 පිටුවේ "පෝලිමක සිට පණිවිඩ කියවීම" තුළ සාකච්ඡා කර ඇති පරිදි, අසාර්ථක මාතයන් සැලකිල්ලට ගත් විට පණිවිඩ යැවීමේ පද්ධතියක එක් වරක් පණිවිඩයක් බෙදා හැරීම වැනි දෙයක් නොමැත.

කෆ්කා හි, ඕෆ්සෙට් (ඕෆ්සෙට්) කිරීමට (කැපවීමට) ක්‍රම දෙකක් තිබේ: ස්වයංක්‍රීයව සහ අතින්. අවස්ථා දෙකේදීම, පණිවිඩය සකසන ලද නමුත් කැපවීමට පෙර අසාර්ථක වුවහොත් පණිවිඩ කිහිප වතාවක් සැකසිය හැක. කැපවීම පසුබිමේ සිදු වූවා නම් සහ එය සැකසීමට පෙර ඔබේ කේතය සම්පූර්ණ කර ඇත්නම් (සමහර විට Kafka 0.9 සහ ඊට පෙර) පණිවිඩය කිසිසේත් ක්‍රියාවට නොදැමීමට ඔබට තෝරා ගත හැකිය.

පරාමිතිය සැකසීමෙන් ඔබට Kafka පාරිභෝගික API හි අතින් ඕෆ්සෙට් කැපවීමේ ක්‍රියාවලිය පාලනය කළ හැක enable.auto.commit පහත ක්‍රමවලින් එකක් අසත්‍ය සහ පැහැදිලිව ඇමතීමට:

void commitSync();
void commitAsync();

ඔබට "අවම වශයෙන් එක් වරක්" පණිවිඩය සැකසීමට අවශ්‍ය නම්, ඔබ විසින් ඕෆ්සෙට් එක අතින් සිදු කළ යුතුය කැප සමමුහුර්ත ()පණිවිඩ සැකසීමෙන් පසු වහාම මෙම විධානය ක්‍රියාත්මක කිරීමෙන්.

මෙම ක්‍රම මඟින් පණිවිඩ සැකසීමට පෙර ඒවා පිළිගැනීමට ඉඩ නොදේ, නමුත් ඒවා ගණුදෙණු කරන බව පෙන්වන අතරම විභව සැකසුම් ප්‍රමාදයන් ඉවත් කිරීමට කිසිවක් නොකරයි. කෆ්කා හි ගනුදෙනු නැත. සේවාදායකයාට පහත සඳහන් දෑ කිරීමට හැකියාවක් නැත.

• ව්‍යාජ පණිවිඩයක් ස්වයංක්‍රීයව ආපසු හරවන්න. පණිවිඩ නැවත ලබා දීමට තැරැව්කරු මත විශ්වාසය තැබිය නොහැකි බැවින් පාරිභෝගිකයින් විසින්ම ගැටළු සහගත ගෙවීම් සහ පසුපෙළ ඇනහිටීම් වලින් පැන නගින ව්‍යතිරේක හැසිරවිය යුතුය.
• එක් පරමාණුක මෙහෙයුමකදී මාතෘකා කිහිපයකට පණිවිඩ යවන්න. අපි නුදුරේදීම දකින පරිදි, විවිධ මාතෘකා සහ කොටස් පාලනය කිරීම යවන විට ගනුදෙනු සම්බන්ධීකරණය නොකරන Kafka පොකුරේ විවිධ යන්ත්‍ර මත පැවතිය හැක. මෙය ලියන අවස්ථාව වන විට, KIP-98 සමඟ මෙය සිදු කිරීමට යම් කාර්යයක් සිදු කර ඇත.
• එක් මාතෘකාවකින් එක් පණිවිඩයක් කියවීම වෙනත් මාතෘකාවකට තවත් පණිවිඩයක් යැවීම සමඟ සම්බන්ධ කරන්න. නැවතත්, කෆ්කා හි ගෘහ නිර්මාණ ශිල්පය එක් බස් රථයක් ලෙස ධාවනය වන බොහෝ ස්වාධීන යන්ත්‍ර මත රඳා පවතින අතර මෙය සැඟවීමට උත්සාහ නොකරයි. උදාහරණයක් ලෙස, ඔබට සම්බන්ධ කිරීමට ඉඩ දෙන API සංරචක නොමැත පාරිභෝගික и නිෂ්පාදකයා ගනුදෙනුවක. JMS හි, මෙය වස්තුව මගින් සපයනු ලැබේ සැසියඑයින් නිර්මාණය වේ MessageProducers и MessageConsumers.

අපට ගණුදෙණු මත විශ්වාසය තැබිය නොහැකි නම්, සම්ප්‍රදායික පණිවුඩකරණ පද්ධති මගින් සපයනු ලබන ඒවාට වඩා සමීප අර්ථකථන සපයන්නේ කෙසේද?

පාරිභෝගික බිඳවැටීමකදී වැනි පණිවිඩය සැකසීමට පෙර පාරිභෝගිකයාගේ ඕෆ්සෙට් වැඩි වීමේ හැකියාවක් තිබේ නම්, පාරිභෝගිකයාට කොටසක් පැවරූ විට එහි පාරිභෝගික කණ්ඩායමට පණිවිඩය මඟ හැරී ගියේ දැයි දැන ගැනීමට ක්‍රමයක් නැත. එබැවින් එක් උපාය මාර්ගයක් වන්නේ ඕෆ්සෙට් එක පෙර ස්ථානයට ආපසු යාමයි. Kafka පාරිභෝගික API මේ සඳහා පහත ක්‍රම සපයයි:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

ක්රමය සොයන්න () ක්රමය සමඟ භාවිතා කළ හැකිය
OffsetsForTimes(සිතියම සෙවීමට වේලා මුද්දර) අතීතයේ යම් නිශ්චිත අවස්ථාවක තත්වයකට ආපසු යාමට.

ව්‍යංගයෙන්, මෙම ප්‍රවේශය භාවිතා කිරීම යනු කලින් සැකසූ සමහර පණිවිඩ නැවත කියවා සැකසීමට බොහෝ දුරට ඉඩ ඇති බවයි. මෙය වලක්වා ගැනීම සඳහා, 4 වන පරිච්ඡේදයේ විස්තර කර ඇති පරිදි, කලින් බැලූ පණිවිඩ නිරීක්ෂණය කිරීමට සහ අනුපිටපත් ඉවත් කිරීමට අපට idempotent කියවීම භාවිතා කළ හැක.

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

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

ඉහළ ලබා ගැනීමේ හැකියාව

ඉහළ උපයෝජ්‍යතාව සඳහා කෆ්කාගේ ප්‍රවේශය ActiveMQ හි ප්‍රවේශයට වඩා බෙහෙවින් වෙනස් ය. Kafka නිර්මාණය කර ඇත්තේ සියලුම තැරැව්කාර අවස්ථාවන් එකවර පණිවිඩ ලබා ගන්නා සහ බෙදා හරින පරිමාණයෙන් බැහැර පොකුරු වටා ය.

කෆ්කා පොකුරක් විවිධ සේවාදායකයන් මත ක්‍රියාත්මක වන බහු තැරැව්කාර අවස්ථා වලින් සමන්විත වේ. Kafka නිර්මාණය කර ඇත්තේ සාමාන්‍ය ස්වාධීන දෘඪාංග මත ධාවනය වන පරිදි වන අතර, සෑම node එකක්ම එහිම වෙන්වූ ගබඩාවක් ඇත. බහු පරිගණක නෝඩ් කාලය සඳහා තරඟ කළ හැකි බැවින් ජාල අමුණා ඇති ගබඩාව (SAN) භාවිතා කිරීම නිර්දේශ නොකරයි.Ыඊ ගබඩා කාල පරතරයන් සහ ගැටුම් ඇති කිරීම.

කෆ්කා ය නිතර ම ක්රියාත්මක ව පවතී පද්ධති. බොහෝ විශාල Kafka භාවිතා කරන්නන් කිසිවිටෙක ඔවුන්ගේ පොකුරු වසා නොගන්නා අතර මෘදුකාංගය සෑම විටම අනුක්‍රමික නැවත ආරම්භයක් සමඟ යාවත්කාලීන වේ. තැරැව්කරුවන් අතර පණිවිඩ සහ අන්තර්ක්‍රියා සඳහා පෙර අනුවාදය සමඟ ගැළපීම සහතික කිරීම මගින් මෙය සාක්ෂාත් කරගනු ලැබේ.

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

මූලික අවස්ථාවෙහිදී, පහත ගුණාංග සහිත කෆ්කා පොකුරක් තුළ මාතෘකාවක් නිර්මාණය වේ:

• කොටස් ගණන. කලින් සාකච්ඡා කළ පරිදි, මෙහි භාවිතා වන නියම අගය සමාන්තර කියවීමේ අපේක්ෂිත මට්ටම මත රඳා පවතී.
• අනුකරණ සාධකය (සාධකය) පොකුරේ ඇති තැරැව්කාර අවස්ථා කීයක් මෙම කොටස සඳහා ලොග් අඩංගු විය යුතුද යන්න තීරණය කරයි.

සම්බන්ධීකරණය සඳහා ZooKeepers භාවිතා කරමින්, කෆ්කා පොකුරේ තැරැව්කරුවන් අතර සාධාරණ ලෙස නව කොටස් බෙදා හැරීමට උත්සාහ කරයි. මෙය සිදු කරනු ලබන්නේ පාලකයක් ලෙස ක්‍රියා කරන තනි අවස්ථාවක් මගිනි.

ධාවන වේලාවේදී එක් එක් මාතෘකා කොටස් සඳහා පාලකය තැරැව්කරුවකුට භූමිකාවන් පවරන්න නායක (නායක, මාස්ටර්, ඉදිරිපත් කරන්නා) සහ අනුගාමිකයින් (අනුගාමිකයින්, වහලුන්, යටත් නිලධාරීන්). මෙම කොටස සඳහා ප්‍රධානියා ලෙස ක්‍රියා කරන තැරැව්කරු නිෂ්පාදකයින් විසින් එවන ලද සියලුම පණිවිඩ ලබා ගැනීම සහ පාරිභෝගිකයින් වෙත පණිවිඩ බෙදා හැරීමේ වගකීම දරයි. මාතෘකා කොටසකට පණිවිඩ යවන විට, එම කොටස සඳහා අනුගාමිකයින් ලෙස ක්‍රියා කරන සියලුම තැරැව්කාර නෝඩ් වෙත ඒවා ප්‍රතිවර්තනය වේ. කොටසක් සඳහා ලඝු-සටහන් අඩංගු සෑම node එකක්ම හැඳින්වේ අනුරුව. තැරැව්කරුවෙකුට සමහර කොටස් සඳහා නායකයෙකු ලෙසත් අනෙක් ඒවා සඳහා අනුගාමිකයෙකු ලෙසත් ක්‍රියා කළ හැකිය.

නායකයා සතු සියලුම පණිවිඩ අඩංගු අනුගාමිකයෙකු කැඳවනු ලැබේ සමමුහුර්ත අනුරුව (සමමුහුර්ත තත්වයක පවතින අනුරුවක්, සමමුහුර්ත අනුරුවක්). කොටසක් සඳහා නායකයෙකු ලෙස ක්‍රියා කරන තැරැව්කරුවෙකු පහත වැටුණහොත්, යාවත්කාලීන හෝ එම කොටස සඳහා සමමුහුර්ත කර ඇති ඕනෑම තැරැව්කරුවෙකුට නායක භූමිකාව භාර ගත හැකිය. එය ඇදහිය නොහැකි තරම් තිරසාර නිර්මාණයකි.

නිෂ්පාදක වින්‍යාසයේ කොටසක් පරාමිතිය වේ ඇක්ස්, යෙදුම් ත්‍රෙඩ් එක දිගටම යැවීමට පෙර පණිවිඩයක් ලැබුණු බව (පිළිගත යුතු) අනුරූ කීයක් තීරණය කරයි: 0, 1, හෝ සියල්ල. ලෙස සකසා ඇත්නම් සියලු, පසුව පණිවිඩයක් ලැබුණු විට, මාතෘකා සැකසුම මගින් නිර්වචනය කරන ලද ඉඟි කිහිපයකින් (තමන් ඇතුළුව) වාර්තාවේ තහවුරු කිරීම් (පිළිගැනීම්) ලැබුණු වහාම නායකයා නිෂ්පාදකයා වෙත නැවත තහවුරු කිරීමක් යවනු ඇත. min.insync.replicas (පෙරනිමි 1). පණිවිඩය සාර්ථකව අනුකරණය කළ නොහැකි නම්, නිෂ්පාදකයා යෙදුම ව්‍යතිරේකයක් දමනු ඇත (NotEnoughReplicas හෝ NotEnoughReplicasAfterAppend).

සාමාන්‍ය වින්‍යාසයක් මඟින් 3 (1 නායකයෙක්, එක් කොටසකට අනුගාමිකයින් 2ක්) සහ පරාමිතිය අනුකරණ සාධකයක් සහිත මාතෘකාවක් නිර්මාණය කරයි. min.insync.replicas 2 ලෙස සකසා ඇත. මෙම අවස්ථාවෙහිදී, මාතෘකා කොටස කළමනාකරණය කරන තැරැව්කරුවන්ගෙන් එක් අයෙකුට සේවාදායක යෙදුම්වලට බලපෑමක් නොකර පහළට යාමට පොකුර ඉඩ දෙයි.

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

මෙම ප්‍රතිනිර්මාණ ක්‍රමය භාවිතා කිරීමෙන්, කෆ්කා දක්ෂ ලෙස එක් එක් පණිවිඩය මෙහෙයුම සමඟ තැටියට ලිවීමේ අවශ්‍යතාවය මග හරියි. සමමුහුර්ත (). නිෂ්පාදකයා විසින් එවන සෑම පණිවිඩයක්ම කොටස් ලොගය වෙත ලියා ඇත, නමුත් 2 වන පරිච්ඡේදයේ සාකච්ඡා කර ඇති පරිදි, ගොනුවකට ලිවීම මුලින් සිදු කරනු ලබන්නේ මෙහෙයුම් පද්ධතියේ බෆරය තුළය. මෙම පණිවිඩය වෙනත් කෆ්කා නිදසුනකට ප්‍රතිනිර්මාණය කර එහි මතකයේ තිබේ නම්, නායකයා නැතිවීමෙන් පණිවිඩයම නැති වූ බවක් අදහස් නොවේ - එය සමමුහුර්ත කළ අනුරුවකින් භාර ගත හැකිය.
මෙහෙයුම සිදු කිරීම ප්රතික්ෂේප කිරීම සමමුහුර්ත () එයින් අදහස් කරන්නේ කෆ්කාට මතකයට ලිවිය හැකි වේගයෙන් පණිවිඩ ලබා ගත හැකි බවයි. අනෙක් අතට, ඔබට තැටියට මතකය ෆ්ලෂ් කිරීම වළක්වා ගත හැකි වන තරමට වඩා හොඳය. මේ හේතුව නිසා Kafka තැරැව්කරුවන්ට 64 GB හෝ ඊට වැඩි මතකයක් වෙන් කිරීම සාමාන්‍ය දෙයක් නොවේ. මෙම මතක භාවිතය යනු සම්ප්‍රදායික පණිවිඩ තැරැව්කරුවකුට වඩා දහස් ගුණයක වේගයෙන් එක් කෆ්කා අවස්ථාවක් පහසුවෙන් ධාවනය කළ හැකි බවයි.

කෆ්කා මෙහෙයුම යෙදීම සඳහා වින්‍යාසගත කළ හැක සමමුහුර්ත () පැකේජ පණිවිඩ යැවීමට. Kafka හි ඇති සෑම දෙයක්ම පැකේජ-නැඹුරු බැවින්, එය ඇත්ත වශයෙන්ම බොහෝ භාවිත අවස්ථා සඳහා හොඳින් ක්‍රියා කරන අතර ඉතා ශක්තිමත් සහතික අවශ්‍ය පරිශීලකයින් සඳහා ප්‍රයෝජනවත් මෙවලමකි. Kafka හි පිරිසිදු කාර්ය සාධනයෙන් වැඩි ප්‍රමාණයක් පැමිණෙන්නේ තැරැව්කරුට පැකට් ලෙස යවන පණිවිඩ වලින් වන අතර මෙම පණිවිඩ තැරැව්කරුගෙන් අනුක්‍රමික කොටස් භාවිතා කරමින් කියවන බව ශුන්ය පිටපත මෙහෙයුම් (එක් මතක ප්රදේශයක සිට තවත් දත්ත පිටපත් කිරීමේ කාර්යය ඉටු නොකරන මෙහෙයුම්). දෙවැන්න විශාල කාර්ය සාධනයක් සහ සම්පත් ලාභයක් වන අතර එය කළ හැක්කේ කොටස් ක්‍රමය නිර්වචනය කරන යටින් පවතින ලඝු දත්ත ව්‍යුහයක් භාවිතයෙන් පමණි.

තනි කෆ්කා තැරැව්කරුවකුට වඩා කෆ්කා පොකුරක් තුළ වඩා හොඳ කාර්ය සාධනයක් කළ හැකිය, මන්ද මාතෘකා කොටස් බොහෝ වෙනම යන්ත්‍ර හරහා පරිමාණය කළ හැකි බැවිනි.

ප්රතිඵල

මෙම පරිච්ඡේදයේදී, අපි Kafka ගෘහ නිර්මාණ ශිල්පය සාම්ප්‍රදායික පණිවිඩ තැරැව්කරුවෙකුට වඩා බොහෝ ගුණයකින් වැඩි ප්‍රතිදානයක් සහිතව ඇදහිය නොහැකි තරම් ශක්තිමත් පණිවිඩකරණ නල මාර්ගයක් සැපයීම සඳහා සේවාදායකයින් සහ තැරැව්කරුවන් අතර සම්බන්ධතාවය ප්‍රතිනිර්මාණය කරන්නේ කෙසේදැයි සොයා බැලුවෙමු. මෙය සාක්ෂාත් කර ගැනීම සඳහා එය භාවිතා කරන ක්‍රියාකාරීත්වය පිළිබඳව අපි සාකච්ඡා කර ඇති අතර මෙම ක්‍රියාකාරීත්වය සපයන යෙදුම්වල ගෘහ නිර්මාණ ශිල්පය පිළිබඳව කෙටියෙන් සොයා බැලුවෙමු. මීළඟ පරිච්ඡේදයේදී, අපි පොදු ගැටලු පණිවිඩ යැවීම පදනම් කරගත් යෙදුම් විසඳා ගැනීමට සහ ඒවා සමඟ ගනුදෙනු කිරීමේ උපාය මාර්ග සාකච්ඡා කරමු. සාමාන්‍යයෙන් පණිවිඩකරණ තාක්ෂණයන් ගැන කතා කරන ආකාරය ගෙනහැර දැක්වීමෙන් අපි පරිච්ඡේදය අවසන් කරන්නෙමු, එවිට ඔබට ඔබේ භාවිත අවස්ථා සඳහා ඒවායේ යෝග්‍යතාවය ඇගයීමට හැකිය.

පෙර පරිවර්තන කොටස: පණිවිඩ තැරැව්කරුවන් අවබෝධ කර ගැනීම. ActiveMQ සහ Kafka සමඟ පණිවිඩ යැවීමේ යාන්ත්‍ර විද්‍යාව ඉගෙන ගැනීම. 1 වන පරිච්ඡේදය

පරිවර්තනය සිදු කරන ලදී: tele.gg/middle_java

ඉදිරියට පැවැත්වේ…

සමීක්ෂණයට සහභාගී විය හැක්කේ ලියාපදිංචි පරිශීලකයින්ට පමණි. පුරන්නකරුණාකර.

කෆ්කා ඔබේ සංවිධානයේ භාවිතා කරනවාද?

• බව

• කිසිදු

• කලින් භාවිතා කළා, දැන් නැහැ

• අපි භාවිතා කිරීමට සැලසුම් කරමු

පරිශීලකයින් 38 දෙනෙක් ඡන්දය දුන්හ. පරිශීලකයින් 8 දෙනෙක් ඡන්දය දීමෙන් වැළකී සිටියහ.

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