د پیغام بروکرانو پوهیدل. د ActiveMQ او کافکا سره د پیغام رسولو میکانیزم زده کول. دریم څپرکی. کافکا

د یو کوچني کتاب د ژباړې دوام:
د پیغام بروکرانو پوهیدل
لیکوال: جاکوب کوراب، خپرونکی: O'Reilly Media, Inc.، د خپرولو نیټه: جون 2017، ISBN: 9781492049296.

پخوانۍ ژباړل شوې برخه: د پیغام بروکرانو پوهیدل. د ActiveMQ او کافکا سره د پیغام رسولو میکانیزم زده کول. لومړی څپرکی پیژندنه

دریم څپرکی

کافکا

کافکا په لینکډین کې رامینځته شوی ترڅو د دودیز پیغام بروکرز ځینې محدودیتونه ترلاسه کړي او د مختلف نقطو څخه نقطې متقابل عمل لپاره د ډیری پیغام بروکرونو رامینځته کولو څخه مخنیوی وکړي ، کوم چې پدې کتاب کې په 28 مخ کې د "سکل کولو او بهر" لاندې تشریح شوي. د قضیې کارول LinkedIn په لویه کچه د ډیرو ډیرو ډیټاونو په یو طرفه مصرف باندې تکیه کړې، لکه د پاڼې کلیکونه او د لاسرسي لاګ، پداسې حال کې چې لاهم دا ډاټا د ډیری سیسټمونو لخوا کارول کیږي پرته له دې چې د تولید کونکو یا نورو مصرف کونکو تولید اغیزه وکړي. په حقیقت کې، د کافکا د شتون دلیل د پیغام رسولو ډول ډول جوړښت ترلاسه کول دي چې د یونیورسل ډیټا پایپ لاین تشریح کوي.

دې حتمي هدف ته په پام سره، نور اړتیاوې په طبیعي توګه راپورته شوې. کافکا باید:

• ډیر ګړندی اوسئ
• کله چې د پیغامونو سره کار کوئ ډیر بینډ ویت چمتو کړئ
• د خپرونکي - پیرودونکي او پوائنټ څخه پوائنټ ماډلونو ملاتړ وکړئ
• د پیرودونکو اضافه کولو سره سست مه کوئ. د مثال په توګه، په ActiveMQ کې د کتار او موضوع دواړو فعالیت کمیږي ځکه چې په منزل کې د مصرف کونکو شمیر وده کوي.
• په افقي ډول د توزیع وړ وي؛ که چیرې یو بروکر چې پیغامونو ته دوام ورکړي یوازې د ډیسک په اعظمي سرعت کې دا کار کولی شي ، نو دا د فعالیت لوړولو لپاره د یو واحد بروکر مثال څخه هاخوا ته ځي.
• د پیغامونو ذخیره کولو او بیا ترلاسه کولو ته لاسرسی محدود کړئ

د دې ټولو لاسته راوړلو لپاره، کافکا یو جوړښت غوره کړ چې د پیرودونکو او پیغام رسولو بروکرانو رول او مسؤلیتونه یې بیا تعریف کړل. د JMS ماډل خورا بروکر متمرکز دی، چیرې چې بروکر د پیغامونو ویشلو مسولیت لري او پیرودونکي یوازې د پیغامونو لیږلو او ترلاسه کولو په اړه اندیښنه لري. کافکا، له بلې خوا، د پیرودونکي متمرکز دی، د پیرودونکي سره د دودیز بروکر ډیری ځانګړتیاوې په پام کې نیسي، لکه د خورا ګړندۍ او توزیع وړ بروکر په بدل کې مصرف کونکو ته د اړونده پیغامونو عادلانه ویش. د هغو خلکو لپاره چې د دودیز پیغام رسولو سیسټمونو سره کار کوي، د کافکا سره کار کول د ذهن بنسټیز بدلون ته اړتیا لري.
د انجینرۍ دا لارښود د پیغام رسولو زیربنا رامینځته کولو لامل شوی چې د دودیز بروکر په پرتله د اندازې ډیری امرونو لخوا د ټرپټ زیاتولو وړتیا لري. لکه څنګه چې موږ به وګورو، دا طریقه د سوداګرۍ بندونو سره راځي، دا پدې مانا ده چې کافکا د ځانګړي ډول کاري بارونو او نصب شوي سافټویر لپاره مناسب ندي.

د متحد منزل ماډل

د پورته ذکر شویو اړتیاو د پوره کولو لپاره، کافکا د یو ډول منزل لاندې د خپریدو-سبسکرایب او پوائنټ-ټو-پوائنټ پیغام رسولو سره یوځای کړی دی. موضوع. دا د هغو خلکو لپاره مغشوش دی چې د پیغام رسولو سیسټمونو سره کار کوي، چیرې چې د "موضوع" کلمه د نشر میکانیزم ته اشاره کوي چې له هغې څخه (له موضوع څخه) لوستل د دوام وړ ندي. د کافکا موضوعات باید د هایبرډ منزل ډول وګڼل شي، لکه څنګه چې د دې کتاب په سریزه کې تعریف شوي.

د دې څپرکي د پاتې برخې لپاره، پرته له دې چې موږ په واضح ډول بل ډول بیان کړو، د "موضوع" اصطلاح به د کافکا موضوع ته اشاره وکړي.

د دې لپاره چې په بشپړه توګه پوه شي چې موضوعات څنګه چلند کوي او کوم تضمینونه وړاندې کوي، موږ باید لومړی وګورو چې دوی په کافکا کې څنګه پلي کیږي.
د کافکا هره موضوع خپله لیکنه لري.
تولیدونکي چې کافکا ته پیغامونه لیږي په دې لاګ کې لیکي، او پیرودونکي د لاګ څخه د اشارو په کارولو سره لوستل کوي چې په دوامداره توګه مخ په وړاندې ځي. په دوره توګه، کافکا د لاګ پخوانۍ برخې ړنګوي، ایا په دې برخو کې پیغامونه لوستل شوي که نه. د کافکا د ډیزاین مرکزي برخه دا ده چې بروکر پروا نه کوي چې پیغامونه لوستل کیږي یا نه - دا د پیرودونکي مسؤلیت دی.

د "لاګ" او "پوائنټر" اصطلاحات په کې نه ښکاري د کافکا اسناد. دا پیژندل شوي اصطلاحات دلته د پوهیدو لپاره کارول کیږي.

دا ماډل د ActiveMQ څخه په بشپړ ډول توپیر لري، چیرې چې د ټولو کتارونو پیغامونه په ورته لاګ کې زیرمه شوي، او بروکر پیغامونه د لوستلو وروسته حذف شوي په نښه کوي.
راځئ چې اوس یو څه ژور وخورئ او د موضوع لاګ په ډیر تفصیل سره وګورو.
د کافکا لوګ له څو برخو څخه جوړ دی (شکل 3-1). کافکا په هره برخه کې د سخت نظم تضمین کوي. دا پدې مانا ده چې په یو ځانګړي ترتیب کې ویش ته لیکل شوي پیغامونه به په ورته ترتیب کې لوستل شي. هره برخه د رولینګ لاګ فایل په توګه پلي کیږي چې پکې شامل دي یوه فرعي ټولګه (فرعي سیټ) د دې تولید کونکو لخوا موضوع ته لیږل شوي ټول پیغامونه. جوړ شوی موضوع، په ډیفالټ، یوه برخه لري. د برخې مفکوره د افقی اندازه کولو لپاره د کافکا مرکزي مفکوره ده.

شکل 3-1. د کافکا برخې

کله چې یو تولید کونکی د کافکا موضوع ته پیغام واستوي، دا پریکړه کوي چې کوم برخې ته پیغام واستوي. موږ به دا وروسته په تفصیل سره وګورو.

د پیغامونو لوستل

هغه پیرودونکی چې غواړي پیغامونه ولولي د نومول شوي پوائنټر اداره کوي د مصرف کوونکو ډله، کوم چې اشاره کوي بندول په ویش کې پیغامونه. آفسیټ یو زیاتیدونکی موقعیت دی چې د برخې په پیل کې په 0 پیل کیږي. دا د مصرف کونکي ګروپ، په API کې د کارن لخوا تعریف شوي group_id له لارې راجع شوی، سره مطابقت لري یو منطقي مصرف کونکي یا سیسټم.

د پیغام رسولو ډیری سیسټمونه په موازي ډول د پیغامونو پروسس کولو لپاره د ډیری مثالونو او تارونو په کارولو سره د منزل څخه ډاټا لوستل کوي. په دې توګه، معمولا ډیری پیرودونکي مثالونه وي چې د ورته مصرف کونکي ګروپ شریکوي.

د لوستلو ستونزه په لاندې ډول ښودل کیدی شي:

• موضوع څو برخې لري
• د مصرف کونکو ډیری ګروپونه کولی شي په ورته وخت کې یوه موضوع وکاروي
• د مصرف کونکو یوه ډله کولی شي ډیری جلا مثالونه ولري

دا یو غیر معمولی ډیری څخه ډیری ستونزه ده. د دې لپاره چې پوه شي چې کافکا څنګه د مصرف کونکو ډلو ، مصرف کونکو مثالونو او برخو ترمینځ اړیکې اداره کوي ، راځئ چې په تدریجي ډول ډیر پیچلي لوستلو سناریوګانو لړۍ وګورو.

مصرف کونکي او مصرف کونکي ډلې

راځئ چې د یوې برخې سره یوه موضوع د پیل ټکي په توګه واخلو (شکل 3-2).

انځور 3-2. مصرف کونکي د ویش څخه لوستل کیږي

کله چې د مصرف کونکي مثال دې موضوع ته د خپل ګروپ_id سره وصل شي ، نو دا د لوستلو برخه ټاکل کیږي او پدې برخه کې آفسیټ ټاکل کیږي. د دې آفسیټ موقعیت په پیرودونکي کې خورا وروستي موقعیت (نوي پیغام) یا لومړني موقعیت (زوړ پیغام) ته د اشارې په توګه تنظیم شوی. مصرف کونکي د موضوع څخه د پیغامونو غوښتنه کوي، کوم چې دوی د لاګ څخه په ترتیب سره لوستل کیږي.
د آفسټ موقف په منظمه توګه بیرته کافکا ته ژمن دی او په داخلي موضوع کې د پیغامونو په توګه ساتل کیږي _د مصرف کونکي_افسیټ. لوستل شوي پیغامونه لاهم نه دي حذف شوي ، د منظم بروکر برعکس ، او پیرودونکی کولی شي آفسیټ بیا وګرځوي ترڅو دمخه لیدل شوي پیغامونه بیا پروسس کړي.

کله چې دوهم منطقي مصرف کونکی د مختلف ګروپ_id په کارولو سره وصل شي ، دا دوهم پوائنټر اداره کوي چې له لومړي څخه خپلواک وي (شکل 3-3). په دې توګه، د کافکا موضوع د یوې کتار په څیر عمل کوي چیرې چې یو مصرف کونکي شتون لري او د نورمال خپرونکي (pub-sub) موضوع په څیر کار کوي چې ډیری پیرودونکي یې ګډون کوي، د اضافي ګټې سره چې ټول پیغامونه زیرمه شوي او څو ځله پروسس کیدی شي.

شکل 3-3. په مختلف مصرف کونکو ګروپونو کې دوه مصرف کونکي د ورته برخې څخه لوستل کیږي

د مصرف کونکي ګروپ کې مصرف کونکي

کله چې یو مصرف کونکي مثال د یوې برخې څخه ډیټا لولي ، دا د پوائنټر بشپړ کنټرول لري او پیغامونه پروسس کوي لکه څنګه چې په تیرو برخه کې تشریح شوي.
که چیرې د مصرف کونکو ډیری مثالونه د ورته ګروپ_id سره د یوې برخې سره یوې موضوع سره وصل شوي وي ، نو بیا هغه مثال چې وروستی وصل شوی وي په پوائنټر باندې کنټرول ورکړل شي او له هغې شیبې څخه به ټول پیغامونه ترلاسه کړي (شکل 3-4).

انځور 3-4. په ورته مصرف کونکي ګروپ کې دوه مصرف کونکي د ورته برخې څخه لوستل کیږي

د پروسس کولو دا طریقه، په کوم کې چې د پیرودونکو مثالونو شمیر د برخو شمیر څخه ډیر دی، د یو ډول ځانګړي مصرف کونکي په توګه فکر کیدی شي. دا ګټور کیدی شي که تاسو د خپلو مصرف کونکو مثالونو "فعال - غیر فعال" (یا "ګرم - ګرم") کلستر کولو ته اړتیا ولرئ، که څه هم په موازي ډول د ډیری مصرف کونکو چلول ("فعال - فعال" یا "ګرم - ګرم") په پرتله خورا عام دی. مصرف کونکي. په تیاره کې.

د دې پیغام توزیع چلند پورته تشریح کیدی شي د حیرانتیا وړ وي د دې په پرتله چې د عادي JMS کتار چلند کوي. په دې ماډل کې، کتار ته لیږل شوي پیغامونه به په مساوي ډول د دوو مصرف کونکو ترمنځ وویشل شي.

ډیری وختونه ، کله چې موږ د مصرف کونکو ډیری مثالونه رامینځته کوو ، موږ دا کار په موازي ډول د پیغامونو پروسس کولو لپاره کوو ، یا د لوستلو سرعت لوړولو ، یا د لوستلو پروسې ثبات ډیرولو لپاره. ځکه چې یوازې یو مصرف کونکي مثال کولی شي په یو وخت کې د برخې څخه ډاټا ولولي، دا په کافکا کې څنګه ترلاسه کیږي؟

د دې کولو یوه لاره دا ده چې د یو واحد مصرف کونکي مثال وکاروئ ترڅو ټول پیغامونه ولولئ او د تار حوض ته یې واستوئ. پداسې حال کې چې دا طریقه د پروسس کولو وسیله ډیروي، دا د مصرف کونکي منطق پیچلتیا ډیروي او د لوستلو سیسټم پیاوړتیا لپاره هیڅ نه کوي. که چیرې د مصرف کونکي یوه کاپي د بریښنا ناکامۍ یا ورته پیښې له امله ښکته شي ، نو تخفیف ودریږي.

په کافکا کې د دې ستونزې د حل لپاره معتبره لاره د بОنورې برخې.

تقسیم کول

تقسیمونه د یو واحد بروکر مثال د بینډ ویت هاخوا د یوې موضوع لوستلو او اندازه کولو لپاره د موازي کولو اصلي میکانیزم دی. د دې د ښه پوهیدو لپاره ، راځئ یو داسې وضعیت په پام کې ونیسو چیرې چې یوه موضوع د دوه برخو سره شتون لري او یو مصرف کونکی دې موضوع ته ګډون کوي ​​(شکل 3-5).

انځور 3-5. یو مصرف کونکی د ډیری برخو څخه لوستل کیږي

پدې سناریو کې ، مصرف کونکي ته په دواړو برخو کې د هغې ګروپ_id سره مطابقت لرونکي پوائنټرونو کنټرول ورکول کیږي او د دواړو برخو څخه د پیغامونو لوستل پیل کوي.
کله چې د ورته ګروپ_id لپاره اضافي مصرف کونکي پدې موضوع کې اضافه شي ، کافکا له لومړي څخه دوهم مصرف کونکي ته یوه برخه بیا ځای په ځای کوي. له هغې وروسته ، د مصرف کونکي هر مثال به د موضوع له یوې برخې څخه لوستل کیږي (شکل 3-6).

د دې لپاره چې ډاډ ترلاسه شي چې پیغامونه په موازي ډول په 20 تارونو کې پروسس شوي ، تاسو لږترلږه 20 برخو ته اړتیا لرئ. که چیرې لږې برخې شتون ولري، تاسو به د مرصفوونکو سره پاتې شئ چې د کار کولو لپاره هیڅ شی نلري، لکه څنګه چې مخکې د ځانګړي مصرف کونکو په بحث کې تشریح شوي.

انځور 3-6. په ورته مصرف کونکي ګروپ کې دوه پیرودونکي د مختلف برخو څخه لوستل کیږي

دا سکیم د JMS قطار ساتلو لپاره اړین پیغام ویش په پرتله د کافکا بروکر پیچلتیا خورا کموي. دلته تاسو اړتیا نلرئ د لاندې ټکو په اړه اندیښنه ولرئ:

• کوم مصرف کونکي باید راتلونکی پیغام ترلاسه کړي، د راؤنډ رابین تخصیص، د پری فیچ بفرونو اوسني ظرفیت، یا پخوانیو پیغامونو (لکه څنګه چې د JMS پیغام ګروپونو لپاره).
• کوم پیغامونه کوم مصرف کونکو ته لیږل کیږي او ایا دوی باید د ناکامۍ په صورت کې بیا تحویل شي.

ټول د کافکا بروکر باید پیغامونه په ترتیب سره مصرف کونکي ته انتقال کړي کله چې وروستی دوی غوښتنه وکړي.

په هرصورت، د ثبوت لوستلو موازي کولو او د ناکام پیغامونو بیا لیږلو اړتیاوې نه ځي - د دوی مسؤلیت په ساده ډول د بروکر څخه پیرودونکي ته تیریږي. دا پدې مانا ده چې دوی باید ستاسو په کوډ کې په پام کې ونیول شي.

پیغامونه لیږل

دا د دې پیغام تولیدونکي مسؤلیت دی چې پریکړه وکړي چې کوم برخې ته پیغام واستوي. د هغه میکانیزم د پوهیدو لپاره چې دا کار ترسره کیږي، موږ باید لومړی په پام کې ونیسو چې واقعیا موږ څه لیږو.

پداسې حال کې چې په JMS کې موږ د میټاډاټا (سرلیکونو او ملکیتونو) سره د پیغام جوړښت کاروو او یو بدن چې د پایلوډ (پیلوډ) لري، په کافکا کې پیغام دی. جوړه "کلیدي ارزښت". د پیغام تادیه د ارزښت په توګه لیږل کیږي. کیلي، له بلې خوا، په عمده توګه د ویشلو لپاره کارول کیږي او باید ولري د سوداګرۍ منطق ځانګړي کلیدياړونده پیغامونه په ورته ویش کې واچوئ.

په 2 فصل کې، موږ د آنلاین شرط کولو سناریو په اړه بحث وکړ چیرې چې اړوند پیښې باید د یو واحد مصرف کونکي لخوا پروسس شي:

1. د کارن حساب ترتیب شوی.
2. پیسې حساب ته لیږدول کیږي.
3. یو شرط جوړ شوی چې له حساب څخه پیسې وباسي.

که هره پیښه یوه موضوع ته لیږل شوي پیغام وي، نو طبیعي کیلي به د حساب ID وي.
کله چې یو پیغام د کافکا پروډیوسر API په کارولو سره لیږل کیږي، دا د پارشن فنکشن ته لیږدول کیږي کوم چې د پیغام او د کافکا کلستر اوسني حالت ته په پام سره، د برخې ID بیرته راګرځوي کوم چې پیغام باید واستول شي. دا خصوصیت په جاوا کې د Partitioner انٹرفیس له لارې پلي کیږي.

دا انٹرفیس داسې ښکاري:

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

د Partitioner تطبیق د کیلي په اړه د ډیفالټ عمومي هدف هیشینګ الګوریتم کاروي ترڅو د برخې ټاکلو لپاره ، یا راؤنډ رابین که چیرې کومه کیلي مشخصه شوې نه وي. دا ډیفالټ ارزښت په ډیری قضیو کې ښه کار کوي. په هرصورت، په راتلونکي کې تاسو غواړئ خپل ځان ولیکئ.

ستاسو د ویشلو ستراتیژي لیکل

راځئ چې یو مثال وګورو چیرې چې تاسو غواړئ د پیغام تادیې سره میټاډاټا ولیږئ. زموږ په مثال کې تادیه د لوبې حساب ته د زیرمه کولو لارښوونه ده. لارښوونه هغه څه دي چې موږ یې تضمین غواړو چې په لیږد کې بدلون نه راځي او غواړو ډاډ ترلاسه کړو چې یوازې یو باوري اپ سټریم سیسټم کولی شي دا لارښوونې پیل کړي. پدې حالت کې ، د لیږلو او ترلاسه کولو سیسټمونه د پیغام تصدیق کولو لپاره د لاسلیک کارولو سره موافق دي.
په نورمال JMS کې، موږ په ساده ډول د "پیغام لاسلیک" ملکیت تعریف کوو او پیغام ته یې اضافه کوو. په هرصورت، کافکا موږ ته د میټاډاټا تیرولو لپاره میکانیزم نه راکوي، یوازې یو کلیدي او ارزښت.

څرنګه چې ارزښت د بانک لیږد تادیه ده چې بشپړتیا یې موږ غواړو خوندي کړو، موږ د کیلي کارولو لپاره د ډیټا جوړښت تعریف کولو پرته بله چاره نلرو. فرض کړئ چې موږ د ویشلو لپاره د حساب ID ته اړتیا لرو، ځکه چې د حساب پورې اړوند ټول پیغامونه باید په ترتیب سره پروسس شي، موږ به د لاندې JSON جوړښت سره راشي:

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

ځکه چې د لاسلیک ارزښت به د تادیې په اساس توپیر ولري، د Partitioner انٹرفیس د ډیفالټ هش کولو ستراتیژي به د اعتبار وړ اړونده پیغامونه ګروپ نه کړي. له همدې امله، موږ به اړتیا ولرو چې خپله ستراتیژي ولیکئ چې دا کیلي به پارس کړي او د حساب ID ارزښت تقسیم کړي.

کافکا په پلورنځي کې د پیغامونو د فساد موندلو لپاره چیکسمونه شامل دي او د امنیت ځانګړتیاو بشپړ سیټ لري. حتی که څه هم، د صنعت ځانګړي اړتیاوې، لکه پورته پورته، ځینې وختونه څرګندیږي.

د کارونکي د ویشلو ستراتیژي باید ډاډ ترلاسه کړي چې ټول اړوند پیغامونه په ورته ویش کې پای ته رسیږي. پداسې حال کې چې دا ساده ښکاري، اړتیا د اړونده پیغامونو ترتیب کولو اهمیت او په موضوع کې د برخو شمیره څومره ثابته ده پیچلې کیدی شي.

په یوه موضوع کې د برخو شمیر کولی شي د وخت په تیریدو سره بدلون ومومي، ځکه چې دوی اضافه کیدی شي که ټرافیک د ابتدايي تمې څخه بهر وي. په دې توګه، د پیغام کیلي د هغه برخې سره تړل کیدی شي چې دوی په اصل کې لیږل شوي، د دولت یوه برخه د تولیدونکي مثالونو ترمنځ شریکولو معنی لري.

بل فاکتور چې باید په پام کې ونیول شي د پارشنونو په اوږدو کې د پیغامونو مساوي توزیع ده. په عموم ډول، کیلي په مساوي ډول په پیغامونو کې نه ویشل کیږي، او د هش فعالیت د کیلي کوچنۍ سیټ لپاره د پیغامونو عادلانه ویش تضمین نه کوي.
دا مهمه ده چې په یاد ولرئ که څه هم تاسو د پیغامونو ویشلو غوره کوئ، جلا کوونکی پخپله بیا کارولو ته اړتیا لري.

د کافکا کلسترونو ترمنځ په مختلفو جغرافيائی ځایونو کې د معلوماتو نقل کولو اړتیا ته پام وکړئ. د دې هدف لپاره، کافکا د MirrorMaker په نوم د کمانډ لاین وسیلې سره راځي، کوم چې د یو کلستر څخه د پیغامونو لوستلو او بل ته لیږدولو لپاره کارول کیږي.

MirrorMaker باید د نقل شوي موضوع کلیدونه درک کړي ترڅو د کلسترونو ترمینځ د نقل کولو پرمهال د پیغامونو ترمینځ نسبي نظم وساتي ، ځکه چې د دې موضوع لپاره د برخو شمیر ممکن په دوه کلسترونو کې یو شان نه وي.

د دودیز ویشلو ستراتیژی نسبتا نادر دي، ځکه چې ډیفالټ هیشینګ یا رانډ رابین په ډیری سناریوګانو کې ښه کار کوي. په هرصورت، که تاسو د پیاوړې ترتیب کولو تضمینونو ته اړتیا لرئ یا د تادیاتو څخه میټاډاټا ایستلو ته اړتیا لرئ، نو بیا ویش کول هغه څه دي چې تاسو یې باید نږدې وګورئ.

د کافکا اندازه کولو او فعالیت ګټې پیرودونکي ته د دودیز بروکر ځینې مسؤلیتونو لیږدولو څخه راځي. پدې حالت کې، پریکړه کیږي چې د احتمالي اړونده پیغامونو ویشلو لپاره د څو پیرودونکو ترمنځ په موازي توګه کار وکړي.

د JMS بروکران هم اړتیا لري چې د ورته اړتیاو سره معامله وکړي. په زړه پورې خبره دا ده چې ورته مصرف کونکي ته د اړونده پیغامونو لیږلو میکانیزم چې د JMS پیغام ګروپونو له لارې پلي کیږي (د سټیکي بار بیلانس کولو (SLB) ستراتیژۍ کې بدلون) ، هم لیږونکي ته اړتیا لري چې پیغامونه د اړوند په توګه په نښه کړي. د JMS په قضیه کې، بروکر مسؤل دی چې د اړونده پیغامونو دې ګروپ له ډیری څخه یو مصرف کونکي ته واستوي، او د ګروپ مالکیت انتقال کړي که چیرې پیرودونکي له لاسه ورکړي.

د تولید کونکي تړونونه

تقسیم کول یوازینی شی ندی چې د پیغامونو لیږلو په وخت کې په پام کې ونیول شي. راځئ چې په جاوا API کې د تولید کونکي ټولګي د لیږلو() میتودونو ته یو نظر وګورو:

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

دا باید سمدلاسه په یاد ولرئ چې دواړه میتودونه راتلونکي ته راستنیږي ، کوم چې دا په ګوته کوي چې د لیږلو عملیات سمدلاسه نه ترسره کیږي. پایله دا ده چې یو پیغام (ProducerRecord) د هرې فعالې برخې لپاره د لیږلو بفر ته لیکل کیږي او د کافکا پیرودونکي کتابتون کې د شالید تار په توګه بروکر ته لیږل کیږي. پداسې حال کې چې دا شیان په زړه پوري ګړندي کوي ، پدې معنی چې یو بې تجربه غوښتنلیک کولی شي پیغامونه له لاسه ورکړي که چیرې پروسه ودرول شي.

د تل په څیر، د فعالیت په قیمت کې د لیږلو عملیات ډیر باوري کولو لپاره یوه لاره شتون لري. د دې بفر اندازه 0 ته ټاکل کیدی شي، او د لیږلو غوښتنلیک تار به مجبور شي تر هغه پورې انتظار وکړي چې بروکر ته د پیغام لیږد بشپړ شي، په لاندې ډول:

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

د پیغامونو لوستلو په اړه نور

د پیغامونو لوستل اضافي پیچلتیاوې لري چې باید په اړه یې اټکل وشي. د JMS API برعکس، کوم چې کولی شي د پیغام په ځواب کې د پیغام اوریدونکي چلوي، د د مصرفوونکو کافکا یوازې رایې ورکوي. راځئ چې میتود ته نږدې کتنه وکړو ټولپوښتنه()د دې هدف لپاره کارول کیږي:

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

د میتود بیرته ستنیدو ارزښت د کانټینر جوړښت دی چې ډیری توکي لري د مصرف کونکي ریکارډ د احتمالي څو برخو څخه. د مصرف کونکي ریکارډ پخپله د اړونده میټاډاټا سره د کلیدي ارزښت جوړه لپاره یو هولډر څیز دی، لکه هغه برخه چې له هغې څخه اخیستل کیږي.

لکه څنګه چې په 2 فصل کې بحث شوی، موږ باید په پام کې ونیسو چې پیغامونه په بریالیتوب یا ناکامه توګه پروسس شوي وروسته څه پیښیږي، د بیلګې په توګه، که چیرې پیرودونکي د پیغام پروسس کولو توان ونلري یا که هغه بند شي. په JMS کې، دا د اعتراف حالت له لارې اداره شوی. بروکر به یا په بریالیتوب سره پروسس شوی پیغام ړنګ کړي، یا خام یا جعلي پیغام بیا وړاندې کړي (فرض کړئ چې معامله کارول شوې وي).
کافکا په بل ډول کار کوي. پیغامونه د پروف ریډینګ وروسته په بروکر کې نه حذف کیږي ، او د ناکامۍ په صورت کې څه پیښیږي پخپله د پروف ریډینګ کوډ مسؤلیت دی.

لکه څنګه چې موږ وویل، د مصرف کونکي ګروپ په لاګ کې د آفسیټ سره تړاو لري. د دې آفسیټ سره تړلی د لاګ موقعیت د راتلونکي پیغام سره مطابقت لري چې په ځواب کې صادریږي ټولپوښتنه(). په وخت کې ټکی کله چې دا آفسیټ ډیریږي د لوستلو لپاره پریکړه کونکی دی.

د لوستلو ماډل ته بیرته راستنیدل چې دمخه بحث شوی، د پیغام پروسس کول درې مرحلې لري:

1. د لوستلو لپاره یو پیغام ترلاسه کړئ.
2. پیغام پروسس کړئ.
3. پیغام تایید کړئ.

د کافکا مصرف کونکي د ترتیب کولو اختیار سره راځي enable.auto.commit. دا په مکرر ډول کارول شوی ډیفالټ ترتیب دی ، لکه څنګه چې د "آټو" کلمه لرونکي ترتیباتو کې معمول دی.

د کافکا 0.10 څخه دمخه، یو پیرودونکی به د دې اختیار په کارولو سره په راتلونکي تلیفون کې د لوستل شوي وروستي پیغام آفسیټ واستوي ټولپوښتنه() د پروسس وروسته. د دې معنی دا وه چې کوم پیغامونه چې دمخه راوړل شوي وي بیا پروسس کیدی شي که چیرې پیرودونکي دمخه پروسس کړي وي مګر په غیر متوقع ډول د زنګ وهلو دمخه ویجاړ شوي وي ټولپوښتنه(). ځکه چې بروکر د دې په اړه هیڅ حالت نه ساتي چې یو پیغام څو ځله لوستل شوی، راتلونکی پیرودونکي چې دا پیغام بیرته ترلاسه کوي به نه پوهیږي چې څه بد پیښ شوي. دا چلند د سودو-معاملې وه. آفسیټ یوازې هغه وخت ژمن و که چیرې پیغام په بریالیتوب سره پروسس شوی وي، مګر که چیرې پیرودونکي لغوه شي، بروکر به ورته پیغام بیا بل پیرودونکي ته واستوي. دا چلند د پیغام رسولو تضمین سره مطابقت درلود "لږترلږه یو ځل".

په کافکا 0.10 کې، د پیرودونکي کوډ بدل شوی ترڅو د مراجعینو د کتابتون لخوا په منظمه توګه د ترتیب سره سم ژمنې پیل شي. auto.commit.interval.ms. دا چلند د JMS AUTO_ACKNOWLEDGE او DUPS_OK_ACKNOWLEDGE حالتونو تر مینځ یو ځای دی. کله چې د اتوماتیک کمیټ کاروئ، پیغامونه ژمن کیدی شي پرته لدې چې دوی واقعیا پروسس شوي وي - دا د ورو مصرف کونکي په حالت کې پیښ کیدی شي. که چیرې یو مصرف کونکی لغوه شي، پیغامونه به د راتلونکي پیرودونکي لخوا راوړل شي، د ژمنې موقعیت څخه پیل کیږي، کوم چې کیدای شي د پیغام له لاسه ورکړي. په دې حالت کې، کافکا پیغامونه له لاسه ورنکړل، د لوستلو کوډ یوازې دوی پروسس نه کړل.

دا حالت ورته ژمنې لري لکه څنګه چې په 0.9 نسخه کې دي: پیغامونه پروسس کیدی شي، مګر که دا ناکام شي، آفسیټ ممکن ژمن نه وي، په بالقوه توګه د سپارلو دوه چنده کیدو لامل کیږي. ډیر پیغامونه چې تاسو یې د اجرا کولو پرمهال راوړئ ټولپوښتنه()، هرڅومره چې دا ستونزه زیاته شي.

لکه څنګه چې په 21 مخ کې "له کتار څخه د پیغامونو لوستل" کې بحث شوی، د پیغام رسولو سیسټم کې د یو ځل پیغام رسولو په څیر هیڅ شی شتون نلري کله چې د ناکامۍ طریقې په پام کې ونیول شي.

په کافکا کې، د آفسټ (افسیټ) د ژمنې کولو دوه لارې شتون لري: په اتوماتيک ډول او په لاسي ډول. په دواړو حالتونو کې ، پیغامونه څو ځله پروسس کیدی شي که چیرې پیغام پروسس شوی وي مګر د ژمنې دمخه ناکام شوی. تاسو کولی شئ دا هم غوره کړئ چې پیغام په بشپړ ډول پروسس نه کړئ که چیرې ژمنې په شالید کې پیښ شي او ستاسو کوډ د پروسس کیدو دمخه بشپړ شوی و (شاید په کافکا 0.9 او مخکی کې).

تاسو کولی شئ د پیرامیټر په ترتیبولو سره د کافکا مصرف کونکي API کې د لارښود آفسیټ کمیټ پروسه کنټرول کړئ enable.auto.commit د لاندې میتودونو څخه یوه ته غلط او په ښکاره ډول ویل:

void commitSync();
void commitAsync();

که تاسو غواړئ پیغام "لږترلږه یو ځل" پروسس کړئ، نو تاسو باید په لاسي ډول آفسیټ ژمن کړئ ژمنه همغږي()د پیغامونو پروسس کولو وروسته سمدلاسه د دې کمانډ اجرا کولو سره.

دا میتودونه اجازه نه ورکوي چې پیغامونه د پروسس کیدو دمخه تسلیم شي ، مګر دوی د احتمالي پروسس ځنډونو له مینځه وړو لپاره هیڅ نه کوي پداسې حال کې چې د لیږد لید وړاندې کوي. په کافکا کې هیڅ معامله نشته. پیرودونکي د لاندې کارونو کولو وړتیا نلري:

• په اوتومات ډول یو جعلي پیغام بیرته راوګرځوئ. مصرف کونکي پخپله باید استثناوې اداره کړي چې د ستونزې لرونکي تادیاتو او پس منظر بندیدو څخه رامینځته کیږي ، ځکه چې دوی نشي کولی د پیغامونو بیا رسولو لپاره په بروکر باندې تکیه وکړي.
• په یو اټومي عملیاتو کې ډیری موضوعاتو ته پیغامونه واستوئ. لکه څنګه چې موږ به په لنډه توګه وګورو، د مختلفو موضوعاتو کنټرول او برخې کولی شي د کافکا کلستر کې په مختلفو ماشینونو کې ژوند وکړي چې د لیږلو په وخت کې لیږدونه همغږي نه کوي. د دې لیکلو په وخت کې، د KIP-98 سره دا ممکنه کولو لپاره ځینې کارونه ترسره شوي.
• له یوې موضوع څخه د یو پیغام لوستل بلې موضوع ته د بل پیغام لیږلو سره شریک کړئ. یوځل بیا، د کافکا جوړښت په ډیری خپلواک ماشینونو پورې اړه لري چې د یو بس په توګه پرمخ ځي او د دې پټولو لپاره هیڅ هڅه نه کیږي. د مثال په توګه، د API اجزا شتون نلري چې تاسو ته د لینک کولو اجازه درکوي مصرف کونکی и جوړونکی په معامله کې. په JMS کې، دا د اعتراض لخوا چمتو کیږي په غونډهله کوم څخه چې پیدا کیږي د پیغام تولیدونکي и پېغام مصرفوونکو.

که موږ په راکړو ورکړو تکیه نشو کولی، څنګه کولی شو د دودیز پیغام رسولو سیسټمونو لخوا چمتو شوي سیمانټیکونه نږدې چمتو کړو؟

که چیرې احتمال شتون ولري چې د پیغام پروسس کیدو دمخه د پیرودونکي آفیسټ ممکن ډیر شي ، لکه د مصرف کونکي حادثې په جریان کې ، نو بیا مصرف کونکي هیڅ لاره نلري چې پوه شي چې ایا د مصرف کونکي ډلې پیغام له لاسه ورکړی کله چې ورته ویش ټاکل شوی وي. نو یوه ستراتیژي دا ده چې آفسیټ پخواني موقعیت ته واړوي. د کافکا مصرف کونکي API د دې لپاره لاندې میتودونه وړاندې کوي:

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

میتود لټون() د میتود سره کارول کیدی شي
offsetsForTimes(نقشه د لټون مهال ویش) په تیرو وختونو کې یو ځانګړي حالت ته بیرته راستنیدل.

په ښکاره ډول، د دې طریقې کارولو معنی دا ده چې دا خورا احتمال لري چې ځینې پیغامونه چې مخکې پروسس شوي وي لوستل شي او بیا پروسس شي. د دې څخه د مخنیوي لپاره، موږ کولی شو د پام وړ لوستل وکاروو، لکه څنګه چې په 4 څپرکي کې تشریح شوي، د مخکینیو لیدل شویو پیغامونو تعقیبولو او نقلونو له منځه وړلو لپاره.

په بدیل سره، ستاسو د پیرودونکي کوډ ساده ساتل کیدی شي، تر هغه چې د پیغام ضایع یا نقل د منلو وړ وي. کله چې موږ د کارونې قضیې په پام کې نیسو چې د کافکا لپاره عموما کارول کیږي، لکه د لوګو پیښو اداره کول، میټریکونه، کلیک تعقیب، او داسې نور، موږ پوهیږو چې د انفرادي پیغامونو له لاسه ورکول امکان نلري چې په شاوخوا غوښتنلیکونو کې د پام وړ اغیزه ولري. په داسې حالتونو کې، اصلي ارزښتونه په بشپړه توګه د منلو وړ دي. له بلې خوا، که ستاسو غوښتنلیک تادیاتو لیږلو ته اړتیا ولري، تاسو باید د هر انفرادي پیغام په احتیاط سره پاملرنه وکړئ. دا ټول په شرایطو کې راځي.

شخصي کتنې ښیي لکه څنګه چې د پیغامونو شدت زیاتیږي، د هر انفرادي پیغام ارزښت کمیږي. لوی پیغامونه ارزښتناکه وي کله چې په مجموعي بڼه کې لیدل کیږي.

لوړ شتون

د لوړ شتون په اړه د کافکا چلند د ActiveMQ چلند څخه خورا توپیر لري. کافکا د سکیل آوټ کلسترونو شاوخوا ډیزاین شوی چیرې چې ټول بروکر مثالونه په ورته وخت کې پیغامونه ترلاسه کوي او توزیع کوي.

د کافکا کلستر د ډیری بروکر مثالونه لري چې په مختلف سرورونو کې روان دي. کافکا په عادي سټنډرډ هارډویر کې د چلولو لپاره ډیزاین شوی و، چیرې چې هر نوډ خپل وقف شوی ذخیره لري. د شبکې تړل شوي ذخیره (SAN) کارول سپارښتنه نه کیږي ځکه چې ډیری کمپیوټر نوډونه د وخت لپاره سیالي کولی شي.Ыد ذخیره کولو وقفې او شخړې رامینځته کوي.

کافکا دی تل روان سیسټم د کافکا ډیری لوی کارونکي هیڅکله خپل کلسترونه نه بندوي او سافټویر تل د ترتیبي بیا پیل سره تازه کیږي. دا د پیغامونو او د بروکرانو تر مینځ تعاملاتو لپاره د پخوانۍ نسخې سره د مطابقت تضمین کولو سره ترلاسه کیږي.

بروکران د سرور کلستر سره وصل دي ځوکیپر، کوم چې د ترتیب کولو ډیټا راجسټری په توګه کار کوي او د هر بروکر رول همغږي کولو لپاره کارول کیږي. ZooKeeper پخپله یو توزیع شوی سیسټم دی چې د تاسیس له لارې د معلوماتو د نقل کولو له لارې لوړ شتون چمتو کوي. کورم.

په بنسټیزه قضیه کې، یوه موضوع د کافکا په کلستر کې د لاندې ځانګړتیاو سره رامینځته کیږي:

• د ویشونو شمیر. لکه څنګه چې مخکې بحث وشو، دقیق ارزښت چې دلته کارول کیږي د موازي لوستلو مطلوب کچې پورې اړه لري.
• د نقل کولو فکتور (فکتور) ټاکي چې په کلستر کې څومره بروکر مثالونه باید د دې برخې لپاره لاګونه ولري.

د همغږۍ لپاره د ZooKeepers په کارولو سره، کافکا هڅه کوي چې په کلستر کې د بروکرانو ترمنځ په عادلانه توګه نوي ویشونه وویشي. دا د یو واحد مثال لخوا ترسره کیږي چې د کنټرولر په توګه کار کوي.

د چلولو په وخت کې د هرې موضوع ویش لپاره کنټرولر یو بروکر ته دندې وټاکئ مشر (مشر، ماسټر، وړاندې کوونکی) او پیروان (پیروان، غلامان، تابعین). بروکر، د دې برخې لپاره د مشر په توګه کار کوي، د تولید کونکو لخوا دې ته لیږل شوي ټول پیغامونه ترلاسه کولو او مصرف کونکو ته د پیغامونو ویشلو مسولیت لري. کله چې پیغامونه د موضوع برخې ته لیږل کیږي، دوی ټولو بروکر نوډونو ته نقل شوي چې د دې برخې لپاره د پیروانو په توګه عمل کوي. هر نوډ چې د ویش لپاره لاګونه لري ویل کیږي نقل. یو بروکر کولی شي د ځینو برخو لپاره د مشر په توګه او د نورو لپاره د پیرو په توګه عمل وکړي.

یو پیروونکی چې د مشر لخوا ساتل شوي ټول پیغامونه لري ویل کیږي همغږي شوي نقل (یو نقل چې په همغږي حالت کې وي، په ترکیب کې نقل). که یو بروکر چې د یوې برخې لپاره د مشر په توګه کار کوي کم شي، هر هغه بروکر چې تازه وي یا د دې برخې لپاره همغږي شوی وي کولی شي د مشر رول په غاړه واخلي. دا د نه منلو وړ دوامداره ډیزاین دی.

د تولید کونکي ترتیب برخه پیرامیټر دی acks، کوم چې دا ټاکي چې څومره عکس العملونه باید د پیغام رسید قبول کړي مخکې له دې چې د غوښتنلیک سلسلې لیږلو ته دوام ورکړي: 0، 1، یا ټول. که ټاکل شوی وي ټول، بیا کله چې یو پیغام ترلاسه شي ، مشر به ژر تر ژره تولید کونکي ته یو تصدیق واستوي کله چې دا د موضوع ترتیب لخوا تعریف شوي د څو اشارو (د ځان په شمول) د ریکارډ تصدیقونه (اعترافات) ترلاسه کړي. min.insync.replicas (ډیفالټ 1). که چیرې پیغام په بریالیتوب سره نقل نشي ، نو تولید کونکی به د غوښتنلیک استثنا وغورځوي (NotEnoughReplicas او یا NotEnoughReplicasAfterAppend).

یو عادي ترتیب د 3 د نقل کولو فکتور سره یوه موضوع رامینځته کوي (1 مشر، په هر تقسیم کې 2 پیروان) او پیرامیټر min.insync.replicas په 2 کې ټاکل شوی. په دې حالت کې، کلستر به یو له بروکرانو ته اجازه ورکړي چې د موضوع ویش اداره کړي پرته له دې چې د مراجعینو غوښتنلیکونو اغیزه وکړي.

دا موږ بیرته د فعالیت او اعتبار تر مینځ دمخه پیژندل شوي تجارت ته راوړو. نقل کول د پیروانو لخوا د تاییداتو (اعترافاتو) لپاره د اضافي انتظار وخت په لګښت کې پیښیږي. که څه هم، ځکه چې دا په موازي توګه پرمخ ځي، لږترلږه درې نوډونو ته نقل کول د دوو په څیر ورته فعالیت لري (د شبکې بینډ ویت کارولو زیاتوالي ته سترګې په لار دي).

د دې نقل کولو سکیم په کارولو سره، کافکا په هوښیارۍ سره د عملیاتو سره ډیسک ته د فزیکي پلوه هر پیغام لیکلو اړتیا څخه مخنیوی کوي. همغږي (). هر پیغام چې د تولید کونکي لخوا لیږل کیږي د برخې برخې ته لیکل کیږي، مګر لکه څنګه چې په 2 فصل کې بحث شوی، فایل ته لیکل په پیل کې د عملیاتي سیسټم بفر کې ترسره کیږي. که دا پیغام د کافکا بل مثال ته نقل شوی وي او د هغه په ​​حافظه کې وي، د مشر له لاسه ورکول پدې معنی ندي چې پیغام پخپله ورک شوی - دا د یو ترکیب شوي نقل لخوا اخیستل کیدی شي.
د عملیاتو د ترسره کولو څخه انکار همغږي () پدې معنی چې کافکا کولی شي پیغامونه په چټکۍ سره ترلاسه کړي څومره چې کولی شي حافظې ته ولیکي. برعکس، څومره چې تاسو کولی شئ ډیسک ته د حافظې فلش کولو څخه مخنیوی وکړئ، ښه. د دې دلیل لپاره، دا غیر معمولي نه ده چې د کافکا بروکرز لپاره 64 GB یا ډیر حافظه تخصیص شي. د دې حافظې کارول پدې معنی دي چې د کافکا یو مثال په اسانۍ سره د دودیز پیغام بروکر په پرتله څو زره ځله ګړندی سرعت چلولی شي.

کافکا هم د عملیاتو پلي کولو لپاره تنظیم کیدی شي همغږي () د پیغام کڅوړو لپاره. څرنګه چې په کافکا کې هرڅه د بسته بندۍ پر بنسټ دي، دا په حقیقت کې د ډیری کارولو قضیو لپاره خورا ښه کار کوي او د کاروونکو لپاره ګټور وسیله ده چې خورا پیاوړي تضمین ته اړتیا لري. د کافکا ډیری خالص فعالیت د هغه پیغامونو څخه راځي چې بروکر ته د کڅوړو په توګه لیږل کیږي او دا پیغامونه د بروکر لخوا په ترتیبي بلاکونو کې لوستل کیږي. صفر کاپي عملیات (عملیات چې په جریان کې د یوې حافظې ساحې څخه بلې ته د معلوماتو کاپي کولو دنده نه ترسره کیږي). وروستنی یو لوی فعالیت او د سرچینو لاسته راوړنه ده او یوازې د لاګ ډیټا اصلي جوړښت کارولو له لارې ممکنه ده چې د ویشلو سکیم تعریفوي.

د کافکا په کلستر کې د یو واحد کافکا بروکر په پرتله خورا ښه فعالیت ممکن دی، ځکه چې د موضوع برخې په ډیری جلا ماشینونو کې اندازه کیدی شي.

پایلې

په دې څپرکي کې، موږ وګورو چې د کافکا جوړښت څنګه د پیرودونکو او بروکرانو ترمنځ اړیکې بیا تصور کوي ترڅو د نه منلو وړ پیاوړې پیغام رسولو پایپ لاین چمتو کړي، د دودیز پیغام بروکر په پرتله څو چنده لوی له لارې. موږ د هغه فعالیت په اړه بحث کړی چې دا د دې لاسته راوړلو لپاره کاروي او په لنډ ډول یې د غوښتنلیکونو جوړښت ته کتنه کړې چې دا فعالیت چمتو کوي. په راتلونکي څپرکي کې، موږ به عامو ستونزو ته وګورو چې د پیغام رسولو پر بنسټ غوښتنلیکونه اړتیا لري چې د دوی سره د معاملو لپاره ستراتیژیو حل او بحث وکړي. موږ به د دې څپرکي پای ته ورسوو چې څنګه په عمومي ډول د پیغام رسولو ټیکنالوژیو په اړه وغږیږو نو تاسو کولی شئ د خپلو کارولو قضیو لپاره د دوی مناسبیت ارزونه وکړئ.

پخوانۍ ژباړل شوې برخه: د پیغام بروکرانو پوهیدل. د ActiveMQ او کافکا سره د پیغام رسولو میکانیزم زده کول. 1 برخه

ژباړه ترسره شوه: tele.gg/midle_java

نور بیا…

یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. ننوزئمهرباني وکړئ

آیا کافکا ستاسو په سازمان کې کارول کیږي؟

• چې

• نه

• پخوا کارول کیده، اوس نه

• موږ د کارولو پلان لرو

38 کاروونکو رایه ورکړه. 8 کاروونکي منع شوي.

سرچینه: www.habr.com