اې حبره!
زه د Tinkoff ټیم کې کار کوم، کوم چې د خپل خبرتیا مرکز رامینځته کوي. زه ډیری په جاوا کې د پسرلي بوټ په کارولو سره وده کوم او مختلف تخنیکي ستونزې حل کوم چې په پروژه کې رامینځته کیږي.
زموږ ډیری مایکرو خدمتونه د پیغام بروکر له لارې یو له بل سره په غیر متناسب ډول اړیکه نیسي. مخکې، موږ د بروکر په توګه IBM MQ کاروو، کوم چې نور نشي کولی د بار سره مقابله وکړي، مګر په ورته وخت کې د لوړ تحویلي تضمینونه درلودل.
د بدیل په توګه، موږ ته د اپاچي کافکا وړاندیز شوی و، کوم چې د اندازې لوړ ظرفیت لري، مګر، له بده مرغه، د مختلفو سناریوګانو لپاره ترتیب کولو لپاره نږدې انفرادي چلند ته اړتیا لري. برسېره پردې، لږترلږه یو ځل د تحویلي میکانیزم چې په کافکا کې په ډیفالټ کار کوي اجازه نه ورکوي چې د بکس څخه بهر د مطلوب کچې دوام وساتي. بیا، زه به د کافکا په ترتیب کې زموږ تجربه شریکه کړم، په ځانګړې توګه، زه به تاسو ته ووایم چې څنګه تنظیم او ژوند کول په سمه توګه یو ځل د سپارلو سره.
تضمین شوی تحویل او نور ډیر څه
لاندې بحث شوي تنظیمات به د ډیفالټ اتصال ترتیباتو سره د یو شمیر ستونزو مخنیوي کې مرسته وکړي. مګر لومړی زه غواړم یو پیرامیټر ته پام وکړم چې ممکن ممکن ډیبګ اسانه کړي.
دا به مرسته وکړي client.id د تولید کونکي او مصرف کونکي لپاره. په لومړي نظر کې، تاسو کولی شئ د غوښتنلیک نوم د ارزښت په توګه وکاروئ، او په ډیری قضیو کې به دا کار وکړي. که څه هم وضعیت کله چې یو غوښتنلیک ډیری مصرف کونکي کاروي او تاسو ورته ورته client.id ورکوئ ، د لاندې خبرتیا پایله ده:
org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0که تاسو غواړئ د کافکا سره په غوښتنلیک کې JMX وکاروئ ، نو دا ستونزه کیدی شي. د دې قضیې لپاره، دا غوره ده چې د غوښتنلیک نوم ترکیب وکاروئ او د بیلګې په توګه، د موضوع نوم د client.id ارزښت په توګه. زموږ د تشکیلاتو پایله د کمانډ محصول کې لیدل کیدی شي د کافکا مصرف کونکي ګروپونه له کنفلوینټ څخه د اسانتیاوو څخه:
اوس راځئ چې د تضمین شوي پیغام رسولو سناریو ته وګورو. د کافکا تولیدونکی یو پیرامیټر لري acks، کوم چې تاسو ته اجازه درکوي وروسته له دې تنظیم کړئ چې د کلستر مشر څومره مني چې پیغام په بریالیتوب سره لیکل شوی په پام کې نیولو ته اړتیا لري. دا پیرامیټر کولی شي لاندې ارزښتونه واخلي:
- 0 - اعتراف به په پام کې ونه نیول شي.
- 1 ډیفالټ پیرامیټر دی، یوازې 1 نقل ته اړتیا ده چې اعتراف وکړي.
- −1 — د ټولو همغږي شوي نقلونو څخه تسلیم کول اړین دي (د کلستر تنظیم کول min.insync.replicas).
د لیست شوي ارزښتونو څخه دا روښانه ده چې د −1 سره مساوي acks خورا قوي تضمین ورکوي چې پیغام به له لاسه ورنکړي.
لکه څنګه چې موږ ټول پوهیږو، ویشل شوي سیسټمونه د اعتبار وړ ندي. د انتقالي غلطیو په وړاندې د ساتنې لپاره، د کافکا تولیدونکی اختیار وړاندې کوي بیا هڅه کوي، کوم چې تاسو ته اجازه درکوي دننه د بیا لیږلو هڅو شمیر تنظیم کړئ Delivery.timeout.ms. څرنګه چې د بیاکتنې پیرامیټر د Integer.MAX_VALUE (2147483647) ډیفالټ ارزښت لري، د پیغام بیاکتنې شمیر یوازې د delivery.timeout.ms په بدلولو سره تنظیم کیدی شي.
موږ دقیقا یوځل تحویلي ته حرکت کوو
لیست شوي تنظیمات زموږ تولید کونکي ته اجازه ورکوي چې پیغامونه د لوړ تضمین سره وړاندې کړي. راځئ اوس په دې خبرې وکړو چې څنګه ډاډ ترلاسه کړو چې د کافکا موضوع ته د پیغام یوازې یوه کاپي لیکل کیږي؟ په ساده حالت کې، د دې کولو لپاره، تاسو اړتیا لرئ چې په تولیدونکي کې پیرامیټر تنظیم کړئ enable.idempotence رښتیا ته. Idempotency تضمین کوي چې یوازې یو پیغام د یوې موضوع ځانګړي برخې ته لیکل کیږي. د ایډیپټونسی د فعالولو لپاره لومړی شرط ارزښتونه دي acks = ټول، بیا هڅه > 0, max.in.flight.requests.per.connection ≤ 5. که دا پیرامیټونه د پراختیا کونکي لخوا ندي مشخص شوي، پورته ارزښتونه به په اوتومات ډول تنظیم شي.
کله چې ایډیمپوټینسي تنظیم شوې وي ، نو دا اړینه ده چې ډاډ ترلاسه کړئ چې ورته پیغامونه هر وخت په ورته برخو کې پای ته رسیږي. دا د partitioner.class کیلي او پیرامیټر تولید کونکي ته په ترتیب کولو سره ترسره کیدی شي. راځئ چې د کیلي سره پیل وکړو. دا باید د هرې سپارنې لپاره ورته وي. دا په اسانۍ سره د اصلي پوسټ څخه د سوداګرۍ IDs په کارولو سره ترلاسه کیدی شي. د partitioner.class پیرامیټر یو ډیفالټ ارزښت لري - . د دې ویشلو ستراتیژۍ سره، د ډیفالټ له مخې موږ دا کار کوو:
- که د پیغام لیږلو پر مهال ویش په واضح ډول مشخص شوی وي، نو موږ یې کاروو.
- که چیرې ویش مشخص شوی نه وي، مګر کیلي مشخص شوې وي، د کیلي د هش لخوا ویش غوره کړئ.
- که چیرې ویش او کیلي مشخص شوي نه وي، تقسیمونه یو له یو څخه غوره کړئ (راؤنډ روبین).
همدارنګه، د یو پیرامیټ سره د کیلي او idempotent لیږلو کارول max.in.flight.requests.per.connection = 1 تاسو ته په مصرف کونکي کې منظم پیغام پروسس درکوي. دا هم د یادولو وړ ده چې که ستاسو په کلستر کې د لاسرسي کنټرول تنظیم شوی وي، نو تاسو به د یوې موضوع لپاره په اراده توګه د لیکلو حقونو ته اړتیا ولرئ.
که چیرې ناڅاپه تاسو د کیلي لخوا د ایډمپوټینټ لیږلو وړتیاوې نلرئ یا د تولید کونکي اړخ منطق د مختلف برخو ترمینځ د ډیټا تسلسل ساتلو ته اړتیا لري ، نو معاملې به ژغورنې ته راشي. برسېره پردې، د زنځیر لیږد په کارولو سره، تاسو کولی شئ په مشروط ډول په کافکا کې ریکارډ همغږي کړئ، د بیلګې په توګه، په ډیټابیس کې د ریکارډ سره. تولید کونکي ته د لیږد لیږد فعالولو لپاره، دا باید بې کفایته وي او اضافي ټاکل شوي وي transactional.id. که ستاسو د کافکا کلستر د لاسرسي کنټرول تنظیم کړي وي ، نو د لیږد ریکارډ ، لکه د ایډمپوټینټ ریکارډ ، به د لیکلو اجازې ته اړتیا ولري ، کوم چې په transactional.id کې زیرمه شوي ارزښت په کارولو سره د ماسک لخوا ورکول کیدی شي.
په رسمي توګه، هر ډول تار، لکه د غوښتنلیک نوم، د لیږد پیژندونکي په توګه کارول کیدی شي. مګر که تاسو د ورته غوښتنلیک ډیری مثالونه د ورته transactional.id سره پیل کړئ ، نو لومړی پیل شوی مثال به د غلطۍ سره ودرول شي ، ځکه چې کافکا به دا د زومبي پروسه وګڼي.
org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.د دې ستونزې د حل لپاره، موږ د کوربه نوم په بڼه د غوښتنلیک نوم ته یو ضمیمه اضافه کوو، کوم چې موږ د چاپیریال تغیراتو څخه ترلاسه کوو.
تولیدونکی ترتیب شوی، مګر په کافکا کې لیږد یوازې د پیغام ساحه کنټرولوي. د لیږد حالت ته په پام سره، پیغام سمدستي موضوع ته ځي، مګر د اضافي سیسټم ځانګړتیاوې لري.
د دې لپاره چې دا ډول پیغامونه د وخت څخه دمخه د مصرف کونکي لخوا لوستل کیدو مخه ونیسي ، دا اړتیا لري پیرامیټر تنظیم کړي isolation.level to read_committed value. دا ډول مصرف کونکي به وکولی شي د پخوا په څیر غیر لیږدونکي پیغامونه ولولي ، او د لیږد پیغامونه یوازې د ژمنې وروسته.
که تاسو دمخه لیست شوي ټول تنظیمات تنظیم کړي وي ، نو تاسو دقیقا یوځل تحویلي تنظیم کړي. مبارک شه!
مګر یو بل nuance شتون لري. Transactional.id، کوم چې موږ پورته ترتیب کړی، په حقیقت کې د راکړې ورکړې مخکینی دی. د راکړې ورکړې په مدیر کې، د ترتیب شمیره ورته اضافه کیږي. ترلاسه شوي پیژندونکي ته صادریږي transactional.id.expiration.ms، کوم چې په کافکا کلستر کې ترتیب شوی او د "7 ورځو" اصلي ارزښت لري. که د دې وخت په جریان کې غوښتنلیک هیڅ پیغام نه وي ترلاسه کړی، نو کله چې تاسو د راتلونکي لیږد هڅه وکړئ نو تاسو به ترلاسه کړئ InvalidPidMappingException. د لیږد همغږي کونکی به بیا د راتلونکي لیږد لپاره د نوي ترتیب شمیره خپره کړي. په هرصورت، پیغام ممکن ورک شي که چیرې InvalidPidMappingException په سمه توګه اداره نشي.
د ټولټال پرځای
لکه څنګه چې تاسو لیدلی شئ، دا کافي نه ده چې یوازې کافکا ته پیغامونه واستوي. تاسو اړتیا لرئ د پیرامیټونو ترکیب غوره کړئ او د ګړندي بدلونونو لپاره چمتو اوسئ. په دې مقاله کې، ما هڅه وکړه چې دقیقا یو ځل د تحویلي ترتیب په تفصیل سره وښایه او د client.id او transactional.id تشکیلاتو سره ډیری ستونزې بیان کړې چې موږ ورسره مخ شوي یو. لاندې د تولید کونکي او مصرف کونکي تنظیماتو لنډیز دی.
تولیدوونکی:
- acks = ټول
- بیا هڅه وکړئ > 0
- enable.idempotence = ریښتیا
- max.in.flight.requests.per.connection ≤ 5 (1 د منظم لیږلو لپاره)
- transactional.id = ${application-name}-${hostname}
مصرف کونکی:
- isolation.level = read_committed
په راتلونکو غوښتنلیکونو کې د تېروتنې کمولو لپاره، موږ د پسرلي ترتیب کې خپل ریپر جوړ کړ، چیرې چې د ځینې لیست شوي پیرامیټونو لپاره ارزښتونه لا دمخه ټاکل شوي.
دلته د ځان مطالعې لپاره یو څو توکي دي:
سرچینه: www.habr.com