কাফকাতে অ্যাসিঙ্ক্রোনাস API সহ রিফান্ড টুল পরিষেবা বিকাশের অভিজ্ঞতা

একটি সুবিন্যস্ত প্রক্রিয়া এবং কয়েক ডজন আন্তঃসংযুক্ত পরিষেবা সহ, ল্যামোডার মতো একটি কোম্পানিকে কী করে তুলতে পারে, পদ্ধতিতে একটি উল্লেখযোগ্য পরিবর্তন? অনুপ্রেরণা সম্পূর্ণ ভিন্ন হতে পারে: আইনী থেকে শুরু করে সমস্ত প্রোগ্রামারদের মধ্যে অন্তর্নিহিত পরীক্ষা করার ইচ্ছা।

তবে এর অর্থ এই নয় যে আপনি অতিরিক্ত সুবিধার উপর নির্ভর করতে পারবেন না। কাফকার উপর ইভেন্ট-চালিত API প্রয়োগ করলে আপনি ঠিক কী জিততে পারেন, সের্গেই জাইকা বলবেন (সামান্য) এছাড়াও স্টাফ শঙ্কু এবং আকর্ষণীয় আবিষ্কার সম্পর্কে নিশ্চিত হতে হবে - পরীক্ষা তাদের ছাড়া করতে পারে না।

দাবিত্যাগ: এই নিবন্ধটি সের্গেই নভেম্বর 2018-এ HighLoad++-এ অনুষ্ঠিত বৈঠকের উপাদানগুলির উপর ভিত্তি করে। কাফকার সাথে কাজ করার লাইভ অভিজ্ঞতা শ্রোতাদের আকৃষ্ট করেছিল সময়সূচীর অন্যান্য প্রতিবেদনের চেয়ে কম নয়। এটি আমাদের কাছে মনে হয় যে এটি এই সত্যটির একটি দুর্দান্ত উদাহরণ যে সমমনা ব্যক্তিদের খুঁজে পাওয়া সর্বদা সম্ভব এবং প্রয়োজনীয় এবং হাইলোড ++ এর সংগঠকরা এটির জন্য একটি অনুকূল পরিবেশ তৈরি করার চেষ্টা চালিয়ে যাবেন।

প্রক্রিয়া সম্পর্কে

Lamoda হল একটি বৃহৎ ই-কমার্স প্ল্যাটফর্ম যার নিজস্ব যোগাযোগ কেন্দ্র, ডেলিভারি সার্ভিস (এবং অনেক অংশীদার), একটি ফটো স্টুডিও, একটি বিশাল গুদাম এবং এই সবই তার নিজস্ব সফটওয়্যারে কাজ করে। কয়েক ডজন পেমেন্ট পদ্ধতি আছে, b2b অংশীদার যারা এই পরিষেবাগুলির কিছু বা সমস্ত ব্যবহার করতে পারে এবং তাদের পণ্যগুলির সর্বশেষ তথ্য জানতে চায়৷ উপরন্তু, Lamoda রাশিয়ান ফেডারেশন ছাড়াও তিনটি দেশে কাজ করে এবং সেখানে সবকিছু একটু ভিন্ন। মোট, একটি নতুন অর্ডার কনফিগার করার জন্য সম্ভবত একশোরও বেশি উপায় রয়েছে, যা অবশ্যই নিজস্ব উপায়ে প্রক্রিয়া করা উচিত। এই সবগুলি কয়েক ডজন পরিষেবার সাহায্যে কাজ করে যা কখনও কখনও অ-স্পষ্ট উপায়ে যোগাযোগ করে। এছাড়াও একটি কেন্দ্রীয় ব্যবস্থা রয়েছে যার প্রধান দায়িত্ব হল অর্ডার স্ট্যাটাস। আমরা তাকে BOB বলি, আমি তার সাথে কাজ করি।

ইভেন্ট-চালিত API সহ রিফান্ড টুল

ঘটনা-চালিত শব্দটি বরং হ্যাকনিড, একটু এগিয়ে আমরা এর দ্বারা কী বোঝায় তা আরও বিস্তারিতভাবে সংজ্ঞায়িত করব। আমি সেই প্রসঙ্গে শুরু করব যেখানে আমরা কাফকাতে ইভেন্ট-চালিত API পদ্ধতির চেষ্টা করার সিদ্ধান্ত নিয়েছি।

যে কোনও দোকানে, গ্রাহকরা যে অর্ডারগুলির জন্য অর্থ প্রদান করেন তার পাশাপাশি, এমন সময় রয়েছে যখন দোকানটিকে অর্থ ফেরত দিতে হবে, কারণ পণ্যটি ক্লায়েন্টের সাথে খাপ খায় না। এটি একটি তুলনামূলকভাবে সংক্ষিপ্ত প্রক্রিয়া: আমরা প্রয়োজনে তথ্য পরিষ্কার করি এবং অর্থ স্থানান্তর করি।

কিন্তু আইনে পরিবর্তনের কারণে রিটার্ন আরও জটিল হয়ে ওঠে এবং এর জন্য আমাদের একটি পৃথক মাইক্রোসার্ভিস বাস্তবায়ন করতে হয়েছিল।

আমাদের প্রেরণা:

1. আইন FZ-54 - সংক্ষেপে, আইনটি প্রতিটি আর্থিক লেনদেন সম্পর্কে ট্যাক্স অফিসে রিপোর্ট করার প্রয়োজন, তা রিটার্ন বা রসিদই হোক না কেন, কয়েক মিনিটের একটি মোটামুটি সংক্ষিপ্ত SLA-তে। আমরা, ই-কমার্স হিসাবে, বেশ অনেকগুলি অপারেশন করি। প্রযুক্তিগতভাবে, এর অর্থ নতুন দায়িত্ব (এবং তাই একটি নতুন পরিষেবা) এবং সমস্ত জড়িত সিস্টেমে উন্নতি।
2. BOB বিভক্ত BOB-কে বিপুল সংখ্যক নন-কোর দায়িত্ব থেকে মুক্তি দিতে এবং এর সামগ্রিক জটিলতা কমাতে কোম্পানির একটি অভ্যন্তরীণ প্রকল্প।

এই চিত্রটি প্রধান ল্যামোডা সিস্টেমগুলি দেখায়। এখন তাদের অধিকাংশই বেশি একটি সঙ্কুচিত মনোলিথের চারপাশে 5-10টি মাইক্রোসার্ভিসের নক্ষত্র. তারা ধীরে ধীরে বৃদ্ধি পাচ্ছে, কিন্তু আমরা তাদের ছোট করার চেষ্টা করছি, কারণ মাঝখানে নির্বাচিত একটি টুকরো স্থাপন করা ভীতিকর - আপনি এটি পড়তে দিতে পারবেন না। আমরা সমস্ত বিনিময় (তীর) সংরক্ষণ করতে বাধ্য হচ্ছি এবং প্রতিশ্রুতি দিচ্ছি যে সেগুলির মধ্যে যে কোনওটি অনুপলব্ধ হতে পারে৷

এছাড়াও BOB-তে প্রচুর বিনিময় রয়েছে: পেমেন্ট সিস্টেম, ডেলিভারি, বিজ্ঞপ্তি ইত্যাদি।

প্রযুক্তিগতভাবে BOB হল:

• ~150k লাইনের কোড + ~100k লাইনের পরীক্ষার;
• php7.2 + Zend 1 এবং Symfony উপাদান 3;
• >100 API এবং ~50 আউটবাউন্ড ইন্টিগ্রেশন;
• 4টি দেশ তাদের নিজস্ব ব্যবসায়িক যুক্তি নিয়ে।

একটি BOB স্থাপন করা ব্যয়বহুল এবং বেদনাদায়ক, কোডের পরিমাণ এবং এটি যে কাজগুলি সমাধান করে তা এমন যে কেউ এটি সম্পূর্ণরূপে তাদের মাথায় রাখতে পারে না। সাধারণভাবে, এটি সরল করার অনেক কারণ রয়েছে।

রিটার্ন প্রসেস

প্রাথমিকভাবে, দুটি সিস্টেম প্রক্রিয়ার সাথে জড়িত: BOB এবং পেমেন্ট। এখন আরও দুটি আছে:

• ফিসকালাইজেশন সার্ভিস, যা ফিসকেলাইজেশন সমস্যা এবং বাহ্যিক পরিষেবাগুলির সাথে যোগাযোগের যত্ন নেবে।
• রিফান্ড টুল, যাতে নতুন এক্সচেঞ্জগুলি সহজভাবে নেওয়া হয় যাতে BOB স্ফীত না হয়।

এখন প্রক্রিয়া এই মত দেখায়:

1. BOB ফেরতের জন্য একটি অনুরোধ পায়৷
2. BOB এই রিফান্ড টুল সম্পর্কে কথা বলে।
3. রিফান্ড টুল অর্থপ্রদানকে বলে: "টাকা ফেরত দাও।"
4. পেমেন্ট টাকা ফেরত দেয়।
5. রিফান্ড টুল এবং BOB নিজেদের মধ্যে স্ট্যাটাস সিঙ্ক্রোনাইজ করে, কারণ আপাতত তাদের উভয়েরই এটি প্রয়োজন। আমরা এখনও সম্পূর্ণরূপে রিফান্ড টুলে স্যুইচ করতে প্রস্তুত নই, যেহেতু BOB-এর একটি UI আছে, অ্যাকাউন্টিংয়ের জন্য প্রতিবেদন রয়েছে এবং সাধারণভাবে প্রচুর ডেটা যা এত সহজে স্থানান্তর করা যায় না। দুটি চেয়ারে বসতে হবে।
6. ফিসকালাইজেশনের জন্য অনুরোধ চলে যায়।

ফলস্বরূপ, আমরা কাফকার একটি নির্দিষ্ট ইভেন্ট বাস তৈরি করেছি - ইভেন্ট-বাস, যার উপর সবকিছু শুরু হয়েছিল। হুররে, এখন আমাদের ব্যর্থতার একক পয়েন্ট (ব্যঙ্গাত্মক) আছে।

সুবিধা এবং অসুবিধাগুলি বেশ সুস্পষ্ট। আমরা একটি বাস করেছি, যার মানে এখন সমস্ত পরিষেবা এটির উপর নির্ভর করে। এটি নকশাটিকে সরল করে, তবে সিস্টেমে ব্যর্থতার একটি একক পয়েন্ট প্রবর্তন করে। কাফকার পতন হবে, প্রক্রিয়া উঠবে।

ঘটনা-চালিত API কি?

এই প্রশ্নের একটি ভাল উত্তর মার্টিন ফাউলারের রিপোর্টে রয়েছে (GOTO 2017) "ইভেন্ট-চালিত আর্কিটেকচারের অনেক অর্থ".

সংক্ষেপে আমরা যা করেছি:

1. এর মাধ্যমে সমস্ত অ্যাসিঙ্ক্রোনাস এক্সচেঞ্জ গুটিয়েছে৷ ইভেন্ট স্টোরেজ. প্রতিটি আগ্রহী ভোক্তাকে নেটওয়ার্কে স্থিতি পরিবর্তন সম্পর্কে অবহিত করার পরিবর্তে, আমরা একটি কেন্দ্রীভূত দোকানে একটি রাজ্য পরিবর্তন ইভেন্ট লিখি এবং একটি বিষয়ে আগ্রহী গ্রাহকরা সেখান থেকে প্রদর্শিত সমস্ত কিছু পড়েন।
2. ইভেন্ট (ইভেন্ট) এই ক্ষেত্রে একটি বিজ্ঞপ্তি (বিজ্ঞপ্তি) কোথাও কিছু পরিবর্তন হয়েছে। উদাহরণস্বরূপ, অর্ডার স্ট্যাটাস পরিবর্তিত হয়েছে। একজন ভোক্তা যিনি স্ট্যাটাস পরিবর্তনের সাথে থাকা কিছু ডেটার বিষয়ে চিন্তা করেন এবং যা বিজ্ঞপ্তিতে নেই তিনি নিজেই তাদের স্ট্যাটাস খুঁজে পেতে পারেন।
3. সর্বাধিক বিকল্প হল সম্পূর্ণ ইভেন্ট সোর্সিং, রাষ্ট্র স্থানান্তর, যেখানে ইভেন্টে প্রক্রিয়াকরণের জন্য প্রয়োজনীয় সমস্ত তথ্য রয়েছে: কোথা থেকে এবং কোন স্থিতিতে তারা স্যুইচ করেছে, কীভাবে সঠিকভাবে ডেটা পরিবর্তিত হয়েছে, ইত্যাদি। একমাত্র প্রশ্ন হল সুবিধা এবং তথ্যের পরিমাণ যা আপনি সংরক্ষণ করতে পারেন।

রিফান্ড টুল চালু করার অংশ হিসাবে, আমরা তৃতীয় বিকল্পটি ব্যবহার করেছি। এটি ইভেন্ট পরিচালনাকে সহজ করে কারণ কোন বিশদ তথ্য পুনরুদ্ধার করার প্রয়োজন নেই, এছাড়াও এটি এমন পরিস্থিতিকে দূর করে যেখানে প্রতিটি নতুন ইভেন্ট ভোক্তাদের কাছ থেকে অনুরোধ পাওয়ার জন্য একটি ঝাঁকুনি তৈরি করে।

সার্ভিস রিফান্ড টুল আনলোডতাই কাফকা প্রয়োজনের চেয়ে বেশি পরীক্ষা। আমি মনে করি না যে রিফান্ড পরিষেবাটি যদি একটি উচ্চ-লোড প্রকল্প হয়ে ওঠে, ব্যবসাটি খুশি হবে।

Async বিনিময় AS IS

অ্যাসিঙ্ক্রোনাস এক্সচেঞ্জের জন্য, পিএইচপি বিভাগ সাধারণত RabbitMQ ব্যবহার করে। আমরা অনুরোধের জন্য ডেটা সংগ্রহ করেছি, এটিকে সারিতে রেখেছি এবং একই পরিষেবার ভোক্তা এটি গণনা করে পাঠিয়েছে (বা এটি পাঠায়নি)। এপিআইয়ের জন্য, ল্যামোডা সক্রিয়ভাবে সোয়াগার ব্যবহার করে। আমরা API ডিজাইন করি, সোয়াগারে বর্ণনা করি, ক্লায়েন্ট এবং সার্ভার কোড তৈরি করি। আমরা সামান্য বর্ধিত JSON RPC 2.0 ব্যবহার করি।

কিছু জায়গায় esb-বাস ব্যবহার করা হয়, কেউ সক্রিয়MQ-তে থাকেন, কিন্তু, সাধারণভাবে, RabbitMQ - স্ট্যান্ডার্ড.

Async এক্সচেঞ্জ হতে হবে

ইভেন্ট-বাসের মাধ্যমে একটি বিনিময় ডিজাইন করার সময়, একটি সাদৃশ্য খুঁজে পাওয়া যেতে পারে। আমরা একইভাবে ইভেন্ট স্ট্রাকচার বর্ণনার মাধ্যমে ভবিষ্যতের ডেটা বিনিময় বর্ণনা করি। ইয়ামল ফরম্যাট, আমাদের নিজেদেরকে কোড জেনারেশন করতে হয়েছিল, জেনারেটর স্পেসিফিকেশন অনুযায়ী ডিটিও তৈরি করে এবং ক্লায়েন্ট এবং সার্ভারকে তাদের সাথে কাজ করতে শেখায়। প্রজন্ম দুটি ভাষায় যায় - গোলং এবং পিএইচপি. এটি লাইব্রেরিগুলিকে সামঞ্জস্যপূর্ণ রাখে। জেনারেটরটি গোলাঙ্গে লেখা, যার জন্য এটি গোগি নাম পেয়েছে।

কাফকার উপর ইভেন্ট-সোর্সিং একটি সাধারণ জিনিস। কাফকা কনফ্লুয়েন্টের মূল এন্টারপ্রাইজ সংস্করণ থেকে একটি সমাধান আছে, আছে নাকাদি, ডোমেইন এলাকায় আমাদের "ভাইদের" থেকে একটি সমাধান Zalando. আমাদের ভ্যানিলা কাফকা দিয়ে শুরু করার অনুপ্রেরণা সমাধানটি বিনামূল্যে ছেড়ে দেওয়া যতক্ষণ না আমরা শেষ পর্যন্ত সিদ্ধান্ত নিয়েছি যে আমরা এটি সর্বত্র ব্যবহার করব কিনা, এবং কৌশল এবং উন্নতির জন্য নিজেদেরকে জায়গা ছেড়ে দিন: আমরা আমাদের জন্য সমর্থন চাই JSON RPC 2.0, দুই ভাষার জন্য জেনারেটর এবং আর কি দেখি।

এটা পরিহাসের বিষয় যে এমন একটি সুখী ক্ষেত্রেও, যখন একই রকম জালান্ডো ব্যবসায় একই রকম সমাধান তৈরি করে, আমরা কার্যকরভাবে এটি ব্যবহার করতে পারি না।

স্থাপত্যগতভাবে, স্টার্টআপে, প্যাটার্নটি নিম্নরূপ: আমরা সরাসরি কাফকা থেকে পড়ি, কিন্তু আমরা কেবল ইভেন্ট-বাসের মাধ্যমে লিখি। কাফকাতে পড়ার জন্য অনেক রেডিমেড জিনিস আছে: দালাল, ব্যালেন্সার, এবং এটি অনুভূমিক স্কেলিং এর জন্য কমবেশি প্রস্তুত, আমি এটি রাখতে চেয়েছিলাম। রেকর্ডটি হল, আমরা একটি গেটওয়ে ওরফে ইভেন্টস-বাসের মধ্য দিয়ে মোড়ানো করতে চেয়েছিলাম এবং এখানে কেন।

ঘটনা-বাস

অথবা অনুষ্ঠানের বাস। এটি শুধুমাত্র একটি রাষ্ট্রহীন http গেটওয়ে যা বেশ কয়েকটি গুরুত্বপূর্ণ ভূমিকা নেয়:

• বৈধতা উত্পাদন - ঘটনাগুলি আমাদের স্পেসিফিকেশন পূরণ করে তা পরীক্ষা করুন।
• ঘটনা দ্বারা মাস্টার সিস্টেম, অর্থাৎ, এটি কোম্পানির প্রধান এবং একমাত্র সিস্টেম যা কোন ইভেন্টগুলির সাথে কোন কাঠামো বৈধ বলে বিবেচিত হয় সেই প্রশ্নের উত্তর দেয়। বৈধতা শুধুমাত্র ডাটা প্রকার এবং অনমনীয় বিষয়বস্তু স্পেসিফিকেশনের জন্য enums.
• হ্যাশ ফাংশন শার্ডিংয়ের জন্য - কাফকা বার্তাটির গঠন হল কী-মান এবং এটিকে কোথায় রাখতে হবে তা হ্যাশ থেকে গণনা করা হয়।

কেন

আমরা একটি সুবিন্যস্ত প্রক্রিয়া সহ একটি বড় কোম্পানিতে কাজ করি। কেন কিছু পরিবর্তন? এটি একটি পরীক্ষাএবং আমরা বেশ কিছু সুবিধা পাওয়ার আশা করি।

1:n+1 বিনিময় (এক থেকে বহু)

কাফকার সাথে, নতুন গ্রাহকদের API-এর সাথে সংযুক্ত করা খুব সহজ।

ধরা যাক আপনার কাছে এমন একটি ডিরেক্টরি রয়েছে যা একসাথে বেশ কয়েকটি সিস্টেমে আপ-টু-ডেট রাখতে হবে (এবং কিছু নতুনগুলিতে)। পূর্বে, আমরা একটি বান্ডিল উদ্ভাবন করেছি যা সেট-এপিআই প্রয়োগ করেছিল এবং গ্রাহকদের ঠিকানা মাস্টার সিস্টেমে রিপোর্ট করা হয়েছিল। এখন মাস্টার সিস্টেম বিষয়টিতে আপডেট পাঠায় এবং আগ্রহী সবাই পড়ে। একটি নতুন সিস্টেম উপস্থিত হয়েছে - তারা বিষয়টিতে স্বাক্ষর করেছে। হ্যাঁ, এছাড়াও একটি বান্ডিল, কিন্তু সহজ.

রিফান্ড-টুলের ক্ষেত্রে, যা BOB-এর একটি অংশ, কাফকার মাধ্যমে তাদের সিঙ্ক্রোনাইজ রাখা আমাদের জন্য সুবিধাজনক। অর্থপ্রদান বলছে যে টাকা ফেরত দেওয়া হয়েছে: BOB, RT এ সম্পর্কে জানতে পেরেছে, তাদের স্থিতি পরিবর্তন করেছে, ফিসকালাইজেশন সার্ভিস এটি সম্পর্কে জানতে পেরেছে এবং একটি চেক ছিটকে দিয়েছে।

আমাদের একটি একক বিজ্ঞপ্তি পরিষেবা তৈরি করার পরিকল্পনা রয়েছে যা ক্লায়েন্টকে তার অর্ডার / রিটার্নের খবর সম্পর্কে অবহিত করবে। এখন এই দায়িত্ব সিস্টেম জুড়ে ছড়িয়ে পড়েছে। কাফকা থেকে প্রাসঙ্গিক তথ্য ধরতে এবং এটিতে প্রতিক্রিয়া জানাতে (এবং অন্যান্য সিস্টেমে এই বিজ্ঞপ্তিগুলি অক্ষম করতে) বিজ্ঞপ্তি পরিষেবাকে শেখানো আমাদের পক্ষে যথেষ্ট হবে। কোন নতুন সরাসরি বিনিময় প্রয়োজন হবে না.

ডেটা-চালিত

সিস্টেমের মধ্যে তথ্য স্বচ্ছ হয়ে যায় - আপনার যতই "রক্তাক্ত উদ্যোগ" থাকুক না কেন এবং আপনার ব্যাকলগ যতই মোটামুটি হোক না কেন। Lamoda এর একটি ডেটা অ্যানালিটিক্স বিভাগ রয়েছে যা সিস্টেম থেকে ডেটা সংগ্রহ করে এবং এটিকে ব্যবসায়িক এবং বুদ্ধিমান উভয় সিস্টেমের জন্য একটি পুনঃব্যবহারযোগ্য ফর্মে রূপান্তরিত করে। কাফকা আপনাকে দ্রুত তাদের প্রচুর ডেটা দিতে এবং এই তথ্যগুলিকে আপ টু ডেট রাখতে দেয়৷

প্রতিলিপি লগ

র‌্যাবিটএমকিউর মতো বার্তাগুলি পড়ার পরে অদৃশ্য হয়ে যায় না। যখন ইভেন্টে প্রক্রিয়া করার জন্য পর্যাপ্ত তথ্য থাকে, তখন আমাদের কাছে বস্তুর সর্বশেষ পরিবর্তনগুলির একটি ইতিহাস থাকে, এবং যদি ইচ্ছা হয়, এই পরিবর্তনগুলি প্রয়োগ করার ক্ষমতা।

প্রতিলিপি লগের স্টোরেজ সময়কাল এই বিষয়ে লেখার তীব্রতার উপর নির্ভর করে, কাফকা আপনাকে নমনীয়ভাবে স্টোরেজ সময় এবং ডেটা ভলিউমের জন্য সীমা নির্ধারণ করতে দেয়। নিবিড় বিষয়গুলির জন্য, এটি গুরুত্বপূর্ণ যে সমস্ত ভোক্তাদের কাছে তথ্যটি অদৃশ্য হয়ে যাওয়ার আগে পড়ার সময় আছে, এমনকি স্বল্পমেয়াদী অকার্যকরতার ক্ষেত্রেও। সাধারণত এর জন্য ডেটা সংরক্ষণ করা সম্ভব দিনের একক, যা একটি সমর্থন জন্য যথেষ্ট যথেষ্ট.

আরও, ডকুমেন্টেশনের একটু রিটেলিং, যারা কাফকার সাথে পরিচিত নন তাদের জন্য (ছবিটি ডকুমেন্টেশন থেকেও)

AMQP-এ সারি রয়েছে: আমরা গ্রাহকের জন্য সারিতে বার্তা লিখি। একটি নিয়ম হিসাবে, একটি সিস্টেম একই ব্যবসায়িক যুক্তি সহ একটি সারি প্রক্রিয়া করে। আপনার যদি বেশ কয়েকটি সিস্টেমকে অবহিত করার প্রয়োজন হয়, আপনি অ্যাপ্লিকেশনটিকে বিভিন্ন সারিতে লিখতে শেখাতে পারেন বা তাদের ক্লোন করে এমন একটি ফ্যানআউট মেকানিজমের সাথে একটি বিনিময় সেট আপ করতে পারেন।

কাফকারও একই রকম বিমূর্ততা আছে বিষয়, যা আপনি বার্তা লিখুন, কিন্তু তারা পড়ার পরে অদৃশ্য হয় না. ডিফল্টরূপে, আপনি যখন কাফকার সাথে সংযুক্ত হন, তখন আপনি সমস্ত বার্তা পাবেন, এবং আপনি যেখানে ছেড়েছিলেন সেখানে সংরক্ষণ করার বিকল্প আপনার কাছে থাকে। অর্থাৎ, আপনি ক্রমানুসারে পড়ুন, আপনি বার্তাটিকে পঠিত হিসাবে চিহ্নিত করতে পারবেন না, তবে আইডিটি সংরক্ষণ করুন, যেখান থেকে আপনি পরে পড়া চালিয়ে যেতে পারবেন। আপনি যে আইডিতে থামলেন তাকে অফসেট (অফসেট) বলা হয় এবং প্রক্রিয়াটিকে কমিট অফসেট বলা হয়।

তদনুসারে, বিভিন্ন যুক্তি প্রয়োগ করা যেতে পারে। উদাহরণস্বরূপ, আমাদের কাছে বিভিন্ন দেশের জন্য 4টি উদাহরণে BOB রয়েছে - Lamoda রাশিয়া, কাজাখস্তান, ইউক্রেন, বেলারুশে রয়েছে। যেহেতু তারা আলাদাভাবে মোতায়েন করা হয়েছে, তাদের সামান্য নিজস্ব কনফিগারেশন এবং তাদের নিজস্ব ব্যবসায়িক যুক্তি রয়েছে। আমরা বার্তায় নির্দেশ করি যে এটি কোন দেশকে বোঝায়। প্রতিটি দেশের প্রতিটি BOB গ্রাহক একটি আলাদা গ্রুপআইডি দিয়ে পড়েন, এবং যদি বার্তাটি এতে প্রযোজ্য না হয়, তারা এটি এড়িয়ে যান, যেমন অবিলম্বে অফসেট +1 কমিট. যদি একই বিষয় আমাদের অর্থপ্রদান পরিষেবা দ্বারা পড়া হয়, তাহলে এটি একটি পৃথক গোষ্ঠীর সাথে এটি করে এবং সেই কারণে অফসেটগুলি ছেদ করে না।

ইভেন্ট প্রয়োজনীয়তা:

• ডেটার সম্পূর্ণতা। আমি ইভেন্টে পর্যাপ্ত ডেটা রাখতে চাই যাতে এটি প্রক্রিয়া করা যায়।

• ইন্টিগ্রিটি। ঘটনাটি সামঞ্জস্যপূর্ণ এবং এটি এটি পরিচালনা করতে পারে কিনা তা আমরা ইভেন্ট-বাসে অর্পণ করি।
• আদেশটি গুরুত্বপূর্ণ। প্রত্যাবর্তনের ক্ষেত্রে, আমরা ইতিহাস নিয়ে কাজ করতে বাধ্য হই। বিজ্ঞপ্তিগুলির সাথে, অর্ডারটি গুরুত্বপূর্ণ নয়, যদি সেগুলি একজাতীয় বিজ্ঞপ্তি হয়, তবে যে অর্ডারটি প্রথমে এসেছে তা নির্বিশেষে ইমেলটি একই হবে৷ রিটার্নের ক্ষেত্রে, একটি সুস্পষ্ট প্রক্রিয়া রয়েছে, আপনি যদি অর্ডার পরিবর্তন করেন, তবে ব্যতিক্রম দেখা দেবে, ফেরত তৈরি বা প্রক্রিয়া করা হবে না - আমরা একটি ভিন্ন স্থিতিতে শেষ হব।
• ধারাবাহিকতা। আমাদের একটি সংগ্রহস্থল আছে, এবং এখন আমরা একটি API এর পরিবর্তে ইভেন্ট তৈরি করি। আমাদের পরিষেবাগুলিতে নতুন ইভেন্টগুলি এবং বিদ্যমানগুলির পরিবর্তনগুলি সম্পর্কে তথ্য দ্রুত এবং সস্তায় পাঠানোর জন্য আমাদের একটি উপায় দরকার৷ এটি একটি পৃথক গিট সংগ্রহস্থল এবং কোড জেনারেটরগুলিতে একটি সাধারণ স্পেসিফিকেশনের মাধ্যমে অর্জন করা হয়। অতএব, বিভিন্ন পরিষেবার ক্লায়েন্ট এবং সার্ভারগুলি আমাদের সাথে সমন্বিত হয়।

লামোডায় কাফকা

আমাদের তিনটি কাফকা ইনস্টলেশন রয়েছে:

1. লগ
2. R&D;
3. ঘটনা-বাস

আজ আমরা শুধুমাত্র শেষ পয়েন্ট সম্পর্কে কথা বলছি। ইভেন্ট-বাসে, আমাদের খুব বড় ইনস্টলেশন নেই - 3 টি ব্রোকার (সার্ভার) এবং শুধুমাত্র 27 টি বিষয়। একটি নিয়ম হিসাবে, একটি বিষয় একটি প্রক্রিয়া। কিন্তু এটি একটি সূক্ষ্ম বিন্দু, এবং এখন আমরা এটি স্পর্শ করব।

উপরে rps চার্ট আছে. ফেরত প্রক্রিয়া একটি ফিরোজা লাইন (হ্যাঁ, x-অক্ষের একটি) দিয়ে চিহ্নিত করা হয়েছে এবং গোলাপী হল বিষয়বস্তু আপডেট প্রক্রিয়া।

Lamoda ক্যাটালগে লক্ষ লক্ষ পণ্য রয়েছে এবং ডেটা সব সময় আপডেট করা হয়। কিছু সংগ্রহ ফ্যাশনের বাইরে চলে যায়, নতুনগুলি তাদের জায়গায় প্রকাশিত হয়, নতুন মডেলগুলি ক্রমাগত ক্যাটালগে উপস্থিত হয়। আমরা ভবিষ্যদ্বাণী করার চেষ্টা করি যে আমাদের গ্রাহকরা আগামীকাল কী বিষয়ে আগ্রহী হবে, তাই আমরা ক্রমাগত নতুন জিনিস কিনি, সেগুলির ছবি তুলি এবং শোকেস আপডেট করি।

গোলাপী শিখর হল পণ্য আপডেট, অর্থাৎ পণ্য পরিবর্তন। দেখা যায় ছেলেরা ছবি তুলেছে, ছবি তুলেছে, তারপর আবার! — ইভেন্ট একটি প্যাক লোড.

Lamoda ইভেন্ট কেস ব্যবহার

আমরা নিম্নলিখিত ক্রিয়াকলাপগুলির জন্য নির্মিত আর্কিটেকচার ব্যবহার করি:

• রিটার্ন স্ট্যাটাস ট্র্যাকিং: সমস্ত জড়িত সিস্টেম থেকে কল-টু-অ্যাকশন এবং স্ট্যাটাস ট্র্যাকিং। অর্থপ্রদান, অবস্থা, আর্থিককরণ, বিজ্ঞপ্তি। এখানে আমরা পদ্ধতি পরীক্ষা করেছি, সরঞ্জাম তৈরি করেছি, সমস্ত বাগ সংগ্রহ করেছি, ডকুমেন্টেশন লিখেছি এবং আমাদের সহকর্মীদের বলেছি কীভাবে এটি ব্যবহার করতে হয়।
• পণ্য কার্ড আপডেট: কনফিগারেশন, মেটা-ডেটা, বৈশিষ্ট্য। একটি সিস্টেম পাঠ করে (যা প্রদর্শন করে), এবং বেশ কয়েকটি লেখা।
• ইমেইল, পুশ এবং এসএমএস: অর্ডার একত্রিত হয়েছে, আদেশ এসেছে, ফেরত গ্রহণ করা হয়েছে, ইত্যাদি, তাদের অনেক আছে.
• স্টক, গুদাম পুনর্নবীকরণ - নামগুলির পরিমাণগত আপডেট, শুধু সংখ্যা: গুদামে রসিদ, রিটার্ন। এটি প্রয়োজনীয় যে পণ্য সংরক্ষণের সাথে যুক্ত সমস্ত সিস্টেম সর্বাধিক আপ-টু-ডেট ডেটা সহ কাজ করে। এই মুহুর্তে, সিঙ্ক আপডেট সিস্টেমটি বেশ জটিল, কাফকা এটিকে সরল করবেন।
• তথ্য বিশ্লেষণ (R&D বিভাগ), ML টুল, বিশ্লেষণ, পরিসংখ্যান। আমরা তথ্য স্বচ্ছ হতে চাই - কাফকা এর জন্য উপযুক্ত।

এখন স্টাফড বাম্প এবং ছয় মাসে ঘটে যাওয়া আকর্ষণীয় আবিষ্কার সম্পর্কে আরও আকর্ষণীয় অংশ।

ডিজাইন সমস্যা

ধরা যাক আমরা একটি নতুন জিনিস করতে চাই - উদাহরণস্বরূপ, পুরো ডেলিভারি প্রক্রিয়াটি কাফকার কাছে হস্তান্তর করুন। এখন প্রক্রিয়াটির একটি অংশ বিওবি-তে অর্ডার প্রসেসিং-এ বাস্তবায়িত হয়েছে। ডেলিভারি পরিষেবাতে অর্ডার স্থানান্তর করার পিছনে, একটি মধ্যবর্তী গুদামে চলে যাওয়া এবং আরও অনেক কিছু রয়েছে, একটি স্ট্যাটাস মডেল রয়েছে। একটি সম্পূর্ণ মনোলিথ রয়েছে, এমনকি দুটি, এছাড়াও বিতরণের জন্য নিবেদিত একগুচ্ছ API। তারা ডেলিভারি সম্পর্কে অনেক বেশি জানে।

এগুলি একই রকম এলাকা বলে মনে হয়, কিন্তু BOB-এ অর্ডার প্রসেসিং এবং ডেলিভারি সিস্টেমের জন্য স্ট্যাটাসগুলি আলাদা। উদাহরণস্বরূপ, কিছু কুরিয়ার পরিষেবা মধ্যবর্তী স্থিতি পাঠায় না, তবে শুধুমাত্র চূড়ান্তগুলি: "বিতরিত" বা "হারানো"। অন্যরা, বিপরীতভাবে, পণ্য চলাচল সম্পর্কে মহান বিস্তারিত রিপোর্ট. প্রত্যেকেরই নিজস্ব বৈধতার নিয়ম রয়েছে: কারও জন্য, ইমেলটি বৈধ, যার অর্থ এটি প্রক্রিয়া করা হবে; অন্যদের জন্য, এটি বৈধ নয়, তবে অর্ডারটি এখনও প্রক্রিয়া করা হবে, কারণ যোগাযোগের জন্য একটি টেলিফোন রয়েছে এবং কেউ বলবে যে এই জাতীয় আদেশটি মোটেই প্রক্রিয়া করা হবে না।

তথ্য প্রবাহ

কাফকার ক্ষেত্রে, তথ্য প্রবাহ সংগঠিত করার প্রশ্ন ওঠে। এই টাস্কটি বেশ কয়েকটি পয়েন্টে কৌশলের পছন্দের সাথে যুক্ত, আসুন সেগুলি সব দিয়ে যাই।

এক বিষয়ে নাকি ভিন্ন বিষয়ে?

আমরা একটি ইভেন্ট স্পেসিফিকেশন আছে. BOB-তে, আমরা লিখি যে অমুক এবং অমুক অর্ডার ডেলিভারি করা দরকার, এবং নির্দেশ করে: অর্ডার নম্বর, এর রচনা, কিছু SKU এবং বার কোড ইত্যাদি। যখন পণ্য গুদামে পৌঁছাবে, ডেলিভারি স্ট্যাটাস, টাইমস্ট্যাম্প এবং প্রয়োজনীয় সমস্ত কিছু পেতে সক্ষম হবে। কিন্তু তারপর আমরা BOB-তে এই ডেটার আপডেট পেতে চাই। আমাদের ডেলিভারি থেকে ডেটা পাওয়ার একটি বিপরীত প্রক্রিয়া আছে। এটা কি একই ঘটনা? অথবা এটি একটি পৃথক বিনিময় যে একটি পৃথক বিষয় প্রাপ্য?

সম্ভবত, তারা খুব অনুরূপ হবে, এবং একটি বিষয় তৈরি করার প্রলোভন অযৌক্তিক নয়, কারণ একটি পৃথক বিষয় মানে পৃথক ভোক্তা, পৃথক কনফিগারেশন, এই সবের একটি পৃথক প্রজন্ম। কিন্তু বাস্তবতা নয়।

নতুন ক্ষেত্র নাকি নতুন ঘটনা?

কিন্তু আপনি যদি একই ঘটনা ব্যবহার করেন, তাহলে আরেকটি সমস্যা দেখা দেয়। উদাহরণস্বরূপ, সমস্ত ডেলিভারি সিস্টেম একটি ডিটিও তৈরি করতে পারে না যা একটি BOB তৈরি করতে পারে। আমরা তাদের আইডি পাঠাই, কিন্তু তারা সেভ করে না, কারণ তাদের প্রয়োজন নেই, এবং ইভেন্ট-বাস প্রক্রিয়া শুরু করার দৃষ্টিকোণ থেকে, এই ক্ষেত্রটি প্রয়োজন।

যদি আমরা ইভেন্ট-বাসের জন্য একটি নিয়ম প্রবর্তন করি যে এই ক্ষেত্রটি প্রয়োজন, তাহলে আমরা BOB বা স্টার্ট ইভেন্ট হ্যান্ডলারে অতিরিক্ত বৈধতা নিয়ম সেট করতে বাধ্য হব। বৈধতা পুরো পরিষেবা জুড়ে ছড়িয়ে পড়তে শুরু করে - এটি খুব সুবিধাজনক নয়।

আরেকটি সমস্যা হল ক্রমবর্ধমান উন্নয়নের প্রলোভন। আমাদের বলা হয় যে আমাদের ইভেন্টে কিছু যোগ করতে হবে, এবং হতে পারে, যদি আমরা সাবধানে চিন্তা করি, এটি একটি পৃথক ইভেন্ট হওয়া উচিত ছিল। কিন্তু আমাদের স্কিমে, একটি পৃথক ইভেন্ট একটি পৃথক বিষয়। একটি পৃথক বিষয় হল পুরো প্রক্রিয়া যা আমি উপরে বর্ণনা করেছি। বিকাশকারীকে JSON স্কিমাতে আরও একটি ক্ষেত্র যোগ করতে এবং এটি পুনরায় তৈরি করতে প্রলুব্ধ করা হয়।

রিফান্ডের ক্ষেত্রে, আমরা অর্ধ বছরে ইভেন্টে পৌঁছেছি। আমাদের রিফান্ড আপডেট নামে একটি মেটা ইভেন্ট ছিল, যেখানে এই আপডেটটি আসলে কী তা বর্ণনা করে একটি টাইপ ফিল্ড ছিল। এর থেকে আমাদের কাছে যাচাইকারীদের সাথে "সুন্দর" সুইচ ছিল যা বলেছিল কীভাবে এই ধরণের সাথে এই ইভেন্টটিকে বৈধ করা যায়।

ইভেন্ট সংস্করণ

কাফকার বার্তা যাচাই করতে, আপনি ব্যবহার করতে পারেন অভ্র, কিন্তু এটা অবিলম্বে এটি উপর শুয়ে এবং Confluent ব্যবহার করা প্রয়োজন ছিল. আমাদের ক্ষেত্রে, ভার্সন করার ক্ষেত্রে আমাদের সতর্ক থাকতে হবে। প্রতিলিপি লগ থেকে বার্তাগুলি পুনরায় পড়া সবসময় সম্ভব হবে না, কারণ মডেলটিতে "বামে" আছে। মূলত, এটি সংস্করণগুলি তৈরি করতে দেখা যাচ্ছে যাতে মডেলটি পিছিয়ে সামঞ্জস্যপূর্ণ হয়: উদাহরণস্বরূপ, একটি ক্ষেত্র অস্থায়ীভাবে ঐচ্ছিক করুন৷ যদি পার্থক্যগুলি খুব শক্তিশালী হয়, আমরা একটি নতুন বিষয়ে লিখতে শুরু করি, এবং ক্লায়েন্টরা যখন পুরানোটি পড়া শেষ করে তখন তাদের প্রতিস্থাপন করা হয়।

পার্টিশন পড়া অর্ডার গ্যারান্টি

কাফকার ভেতরের বিষয়গুলোকে পার্টিশনে ভাগ করা হয়েছে। আমরা যখন সত্তা এবং এক্সচেঞ্জ ডিজাইন করছি তখন এটি খুব গুরুত্বপূর্ণ নয়, তবে এটি গুরুত্বপূর্ণ যখন আমরা সিদ্ধান্ত নিই কিভাবে এটি ব্যবহার করা যায় এবং স্কেল করা যায়।

সাধারণ ক্ষেত্রে, আপনি কাফকাকে একটি বিষয় লিখুন। ডিফল্টরূপে, একটি পার্টিশন ব্যবহার করা হয় এবং এই বিষয়ের সমস্ত বার্তা এতে পড়ে। এবং ভোক্তা এই বার্তাগুলি যথাক্রমে পাঠ করে। ধরা যাক, এখন, আমাদের সিস্টেমটি প্রসারিত করতে হবে যাতে বার্তা দুটি ভিন্ন ভোক্তারা পড়তে পারে। আপনি যদি, উদাহরণস্বরূপ, এসএমএস পাঠান, তাহলে আপনি কাফকাকে একটি অতিরিক্ত পার্টিশন করতে বলতে পারেন, এবং কাফকা বার্তাগুলিকে দুটি অংশে বিভক্ত করা শুরু করবে - অর্ধেক সেখানে, অর্ধেক সেখানে।

কাফকা কিভাবে তাদের ভাগ করে? প্রতিটি বার্তার একটি বডি থাকে (যেটিতে আমরা JSON সঞ্চয় করি) এবং একটি কী। আপনি এই কীটির সাথে একটি হ্যাশ ফাংশন সংযুক্ত করতে পারেন, যা বার্তাটি কোন পার্টিশনে পড়বে তা নির্ধারণ করবে।

রিফান্ডের ক্ষেত্রে আমাদের ক্ষেত্রে, এটি গুরুত্বপূর্ণ, যদি আমরা দুটি পার্টিশন নিই, তাহলে সমান্তরাল ভোক্তা প্রথমটির আগে দ্বিতীয় ইভেন্টটি প্রক্রিয়া করবে এবং সমস্যা হবে। হ্যাশ ফাংশন নিশ্চিত করে যে একই কী সহ বার্তাগুলি একই পার্টিশনে শেষ হয়।

ইভেন্ট বনাম কমান্ড

এই আমরা চালানো করেছি অন্য সমস্যা. একটি ইভেন্ট হল এক ধরনের ইভেন্ট: আমরা বলি যে কোথাও কিছু ঘটেছে (something_happened), উদাহরণস্বরূপ, একটি আইটেম বাতিল করা হয়েছে বা ফেরত হয়েছে। যদি কেউ এই ইভেন্টগুলি শোনে, তাহলে "আইটেম বাতিল" দ্বারা ফেরত সত্তা তৈরি করা হবে এবং সেটআপগুলির কোথাও "ফেরত হয়েছে" রেকর্ড করা হবে৷

কিন্তু সাধারণত, আপনি যখন ইভেন্টগুলি ডিজাইন করেন, তখন আপনি সেগুলি নিরর্থক লিখতে চান না - আপনি বাজি ধরছেন যে কেউ সেগুলি পড়বে। কিছু_হয়েছে (আইটেম_বাতিল করা, ফেরত_ফেরত) না লেখার প্রলোভন বেশি, কিন্তু কিছু_শুদ্ধ_হতে_হয়। উদাহরণস্বরূপ, আইটেম ফেরত দেওয়ার জন্য প্রস্তুত।

একদিকে, এটি ইভেন্টটি কীভাবে ব্যবহার করা হবে তার ইঙ্গিত দেয়। অন্যদিকে, এটি একটি সাধারণ ঘটনার নামের মতো অনেক কম। উপরন্তু, এখান থেকে এটি do_something কমান্ড থেকে দূরে নয়। কিন্তু কেউ এই ঘটনাটি পড়েছেন এমন কোনো নিশ্চয়তা আপনার নেই; এবং যদি পড়া হয়, তাহলে সফলভাবে পড়ুন; এবং যদি সে সফলভাবে পড়ে, তাহলে সে কিছু করেছে, এবং এই কিছু সফল হয়েছে। যে মুহুর্তে একটি ঘটনা do_something হয়ে যায়, প্রতিক্রিয়া প্রয়োজনীয় হয়ে ওঠে এবং এটিই সমস্যা।

RabbitMQ-তে একটি অ্যাসিঙ্ক্রোনাস এক্সচেঞ্জে, আপনি যখন একটি বার্তা পড়েন, http-এ যান, আপনার একটি প্রতিক্রিয়া থাকে - অন্তত বার্তাটি গৃহীত হয়েছিল। আপনি যখন কাফকাকে লেখেন, তখন একটি বার্তা থাকে যা আপনি কাফকাকে লিখেছিলেন, কিন্তু কীভাবে এটি প্রক্রিয়া করা হয়েছিল সে সম্পর্কে আপনি কিছুই জানেন না।

অতএব, আমাদের ক্ষেত্রে, আমাদের একটি প্রতিক্রিয়া ইভেন্ট প্রবর্তন করতে হয়েছিল এবং মনিটরিং সেট আপ করতে হয়েছিল যাতে এতগুলি ইভেন্ট উড়ে যায়, যদি অমুক এবং অমুক সময়ের পরে, একই সংখ্যক প্রতিক্রিয়া ইভেন্ট আসতে পারে। যদি তা না হয়, তাহলে মনে হয় কিছু ভুল হয়েছে। উদাহরণস্বরূপ, যদি আমরা "আইটেম_রেডি_টু_রিফান্ড" ইভেন্টটি পাঠিয়ে থাকি, আমরা আশা করি যে ফেরত তৈরি হবে, ক্লায়েন্ট টাকা ফেরত পাবে এবং "মানি_ফেরত" ইভেন্ট আমাদের কাছে পৌঁছে যাবে। কিন্তু এটি সঠিক নয়, তাই পর্যবেক্ষণ প্রয়োজন।

তারতম্য

একটি মোটামুটি সুস্পষ্ট সমস্যা আছে: আপনি যদি একটি বিষয় থেকে ধারাবাহিকভাবে পড়েন, এবং আপনার কাছে কিছু ধরণের খারাপ বার্তা থাকে, তাহলে ভোক্তা ক্র্যাশ হয়ে যাবে এবং আপনি আর এগোবেন না। তোমার দরকার সমস্ত ভোক্তাদের বন্ধ করুন, পড়া চালিয়ে যেতে আরও অফসেট কমিট করুন।

আমরা এটি সম্পর্কে জানতাম, আমরা এটির উপর বাজি ধরেছিলাম, এবং তবুও এটি ঘটেছিল। এবং এটি ঘটেছে কারণ ইভেন্টটি ইভেন্ট-বাসের দৃষ্টিকোণ থেকে বৈধ ছিল, ইভেন্টটি অ্যাপ্লিকেশন যাচাইকারীর দৃষ্টিকোণ থেকে বৈধ ছিল, কিন্তু পোস্টগ্রেএসকিউএলের দৃষ্টিকোণ থেকে এটি বৈধ ছিল না, কারণ আমাদের মাইএসকিউএল সিস্টেমে আনসাইনড আইএনটি সহ, এবং নতুন লিখিত সিস্টেমে পোস্টগ্রেএসকিউএল ছিল কেবল আইএনটি সহ। তিনি একটি সামান্য ছোট আকার আছে, এবং আইডি মাপসই করা হয়নি. Symfony একটি ব্যতিক্রম সঙ্গে মারা গেছে. অবশ্যই, আমরা ব্যতিক্রমটি ধরতে পেরেছি, কারণ আমরা এটির উপর স্থাপিত ছিলাম, এবং এই অফসেটটি কমিট করতে যাচ্ছিলাম, কিন্তু তার আগে আমরা সমস্যা কাউন্টারটি বৃদ্ধি করতে চেয়েছিলাম, যেহেতু বার্তাটি অসফলভাবে প্রক্রিয়া করা হয়েছিল। এই প্রকল্পের কাউন্টারগুলিও বেসে রয়েছে এবং সিমফনি ইতিমধ্যে বেসের সাথে যোগাযোগ বন্ধ করে দিয়েছে, এবং দ্বিতীয় ব্যতিক্রমটি অফসেট করার সুযোগ ছাড়াই পুরো প্রক্রিয়াটিকে হত্যা করেছে।

কিছুক্ষণের জন্য, পরিষেবাটি শুয়ে পড়ল - ভাগ্যক্রমে, কাফকার সাথে এটি এত ভীতিকর নয়, কারণ বার্তাগুলি থেকে যায়। কাজ পুনরুদ্ধার করা হলে, তারা পড়া যাবে. এটা আরামদায়ক.

কাফকার টুলিংয়ের মাধ্যমে একটি নির্বিচারে অফসেট সেট করার ক্ষমতা রয়েছে। তবে এটি করার জন্য, আপনাকে সমস্ত ভোক্তাদের থামাতে হবে - আমাদের ক্ষেত্রে, একটি পৃথক রিলিজ প্রস্তুত করুন যাতে কোনও ভোক্তা, পুনঃনিয়োগ করা হবে না। তারপর কাফকা টুলিংয়ের মাধ্যমে অফসেটটি স্থানান্তর করতে পারে এবং বার্তাটি পাস হবে।

আরেকটি সূক্ষ্মতা - প্রতিলিপি লগ বনাম rdkafka.so - আমাদের প্রকল্পের সুনির্দিষ্টতার সাথে সম্পর্কিত। আমাদের পিএইচপি আছে, এবং পিএইচপি-তে, একটি নিয়ম হিসাবে, সমস্ত লাইব্রেরি কাফকার সাথে rdkafka.so সংগ্রহস্থলের মাধ্যমে যোগাযোগ করে এবং তারপরে কিছু ধরণের মোড়ক থাকে। হয়তো এগুলি আমাদের ব্যক্তিগত অসুবিধা, তবে দেখা গেল যে ইতিমধ্যে যা পড়া হয়েছে তার একটি অংশ পুনরায় পড়া এত সহজ নয়। সাধারণভাবে, সফ্টওয়্যার সমস্যা ছিল।

পার্টিশনের সাথে কাজ করার বিশেষত্বে ফিরে আসা, ঠিক ডকুমেন্টেশনে এটি বলে ভোক্তা >= বিষয় পার্টিশন. কিন্তু আমি এটা সম্পর্কে অনেক পরে জানতে চেয়েছিলাম. আপনি যদি স্কেল করতে চান এবং দুইজন ভোক্তা থাকতে চান, আপনার অন্তত দুটি পার্টিশন দরকার। অর্থাৎ, যদি আপনার একটি পার্টিশন থাকে যাতে 20 হাজার বার্তা জমা হয় এবং আপনি একটি নতুন করে তৈরি করেন, তাহলে বার্তার সংখ্যা শীঘ্রই সমান হবে না। অতএব, দুটি সমান্তরাল ভোক্তা থাকার জন্য, আপনাকে পার্টিশনগুলির সাথে মোকাবিলা করতে হবে।

পর্যবেক্ষণ

আমি মনে করি যেভাবে আমরা এটি নিরীক্ষণ করি তা আরও স্পষ্ট করে দেবে বিদ্যমান পদ্ধতিতে কী সমস্যা রয়েছে।

উদাহরণস্বরূপ, আমরা গণনা করি যে ডাটাবেসের কতগুলি পণ্য সম্প্রতি তাদের স্থিতি পরিবর্তন করেছে, এবং সেই অনুযায়ী, এই পরিবর্তনগুলিতে ইভেন্ট হওয়া উচিত ছিল এবং আমরা এই নম্বরটি আমাদের মনিটরিং সিস্টেমে পাঠাই। তারপর কাফকা থেকে আমরা দ্বিতীয় সংখ্যা পাই, আসলে কত ঘটনা নিবন্ধিত হয়েছিল। স্পষ্টতই, এই দুটি সংখ্যার মধ্যে পার্থক্য সর্বদা শূন্য হওয়া উচিত।

এছাড়াও, আপনাকে প্রযোজক কীভাবে করছে, ইভেন্ট-বাস বার্তা পেয়েছে কিনা এবং ভোক্তা কীভাবে করছে তা নিরীক্ষণ করতে হবে। উদাহরণস্বরূপ, নীচের চার্টে, রিফান্ড টুলটি ভাল কাজ করছে, কিন্তু BOB-তে স্পষ্টভাবে কিছু সমস্যা রয়েছে (নীল শিখর)।

আমি ইতিমধ্যে ভোক্তা-গ্রুপ ল্যাগ উল্লেখ করেছি। মোটামুটিভাবে বলতে গেলে, এটি অপঠিত বার্তার সংখ্যা। সাধারণভাবে, আমাদের ভোক্তারা দ্রুত কাজ করে, তাই ব্যবধান সাধারণত 0 হয়, কিন্তু কখনও কখনও একটি স্বল্পমেয়াদী শীর্ষ হতে পারে। কাফকা বাক্সের বাইরে এটি করতে পারে, তবে আপনাকে কিছু ব্যবধান সেট করতে হবে।

একটি প্রকল্প আছে গর্ত করা, যা আপনাকে কাফকা সম্পর্কে আরও তথ্য দেবে। এটি কেবল উপভোক্তা-গ্রুপ API-এর মাধ্যমে স্ট্যাটাস দেয়, যেমন এই গ্রুপটি করছে। ঠিক আছে এবং ব্যর্থ ছাড়াও, সেখানে একটি সতর্কতা রয়েছে এবং আপনি জানতে পারেন যে আপনার ভোক্তারা উত্পাদনের গতির সাথে তাল মিলিয়ে চলতে পারে না - তাদের কাছে যা লেখা হচ্ছে তা প্রমাণ করার সময় নেই। সিস্টেমটি বেশ স্মার্ট এবং ব্যবহার করা সহজ।

এই API প্রতিক্রিয়া মত দেখায় কি. এখানে বব-লাইভ-ফিফা গ্রুপ, পার্টিশন রিফান্ড.আপডেট.ভি1, ওকে স্ট্যাটাস, ল্যাগ 0 হল শেষ ফাইনাল অফসেট এইরকম এবং এইরকম।

পর্যবেক্ষণ আপডেট_এ এসএলএ (আটকে গেছে) আমি ইতিমধ্যে উল্লেখ করেছি। উদাহরণস্বরূপ, আইটেমটি এমন অবস্থায় চলে গেছে যে এটি ফেরতের জন্য প্রস্তুত। আমরা ক্রোন সেট করেছি, যা বলে যে যদি এই বস্তুটি 5 মিনিটের মধ্যে ফেরত না দেওয়া হয় (আমরা অর্থপ্রদানের সিস্টেমের মাধ্যমে খুব দ্রুত অর্থ ফেরত দিই), তবে অবশ্যই কিছু ভুল হয়েছে এবং এটি অবশ্যই সমর্থনের জন্য একটি কেস। অতএব, আমরা কেবল ক্রোন নিই, যা এই জাতীয় জিনিসগুলি পড়ে এবং যদি সেগুলি 0-এর বেশি হয়, তবে এটি একটি সতর্কতা পাঠায়।

সংক্ষিপ্তভাবে বলতে গেলে, ইভেন্ট ব্যবহার করা যখন উপযোগী:

• তথ্য বিভিন্ন সিস্টেম দ্বারা প্রয়োজন হয়;
• প্রক্রিয়াকরণের ফলাফল গুরুত্বপূর্ণ নয়;
• সামান্য বা কোন ঘটনা।

দেখে মনে হচ্ছে নিবন্ধটির একটি খুব নির্দিষ্ট বিষয় রয়েছে - কাফকার উপর একটি অ্যাসিঙ্ক্রোনাস API, তবে এটির সাথে সম্পর্কিত, আমি অবিলম্বে অনেক কিছু সুপারিশ করতে চাই।
প্রথম, পরবর্তী হাইলোড++ তবে আপনাকে নভেম্বর পর্যন্ত অপেক্ষা করতে হবে, এপ্রিলে এর সেন্ট পিটার্সবার্গ সংস্করণ হবে এবং জুনে আমরা নভোসিবিরস্কে উচ্চ লোড সম্পর্কে কথা বলব।
দ্বিতীয়ত, প্রতিবেদনের লেখক সের্গেই জাইকা জ্ঞান ব্যবস্থাপনার বিষয়ে আমাদের নতুন সম্মেলনের প্রোগ্রাম কমিটির সদস্য KnowledgeConf. সম্মেলনটি একদিনের, ২৬ এপ্রিল অনুষ্ঠিত হবে, তবে এর কর্মসূচি খুবই সমৃদ্ধ।
এবং মে মাসে হবে পিএইচপি রাশিয়া и RIT++ (একটি অংশ হিসাবে DevOpsConf সহ) - সেখানে আপনি আপনার বিষয় অফার করতে পারেন, আপনার অভিজ্ঞতা সম্পর্কে কথা বলতে পারেন এবং আপনার স্টাফ বাম্প সম্পর্কে অভিযোগ করতে পারেন।

উত্স: www.habr.com