🥇কাফকা কিভাবে সত্যি হলো

হে হাবর!

আমি Tinkoff দলে কাজ করি, যেটি নিজস্ব বিজ্ঞপ্তি কেন্দ্র তৈরি করছে। বেশিরভাগ অংশে, আমি স্প্রিং বুট ব্যবহার করে জাভাতে বিকাশ করি এবং প্রকল্পে উদ্ভূত বিভিন্ন প্রযুক্তিগত সমস্যার সমাধান করি।

আমাদের বেশিরভাগ মাইক্রোসার্ভিস একটি মেসেজ ব্রোকারের মাধ্যমে অ্যাসিঙ্ক্রোনাসভাবে একে অপরের সাথে যোগাযোগ করে। পূর্বে, আমরা একটি ব্রোকার হিসাবে IBM MQ ব্যবহার করতাম, যা আর লোডের সাথে মানিয়ে নিতে পারে না, কিন্তু একই সময়ে উচ্চ ডেলিভারি গ্যারান্টি ছিল।

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

গ্যারান্টিযুক্ত ডেলিভারি এবং আরও অনেক কিছু

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

এইটা সাহায্য করবে 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 মান হিসাবে ব্যবহার করা ভাল। আমাদের কনফিগারেশনের ফলাফল কমান্ডের আউটপুটে দেখা যায় কাফকা-ভোক্তা-গোষ্ঠী Confluent থেকে ইউটিলিটিগুলি থেকে:

এখন গ্যারান্টিযুক্ত বার্তা বিতরণের দৃশ্যকল্পটি দেখি। কাফকা প্রযোজকের একটি প্যারামিটার আছে acks, যা আপনাকে বার্তাটিকে সফলভাবে লিখিত হিসাবে বিবেচনা করার জন্য ক্লাস্টার নেতা কতজন স্বীকার করবে তা কনফিগার করতে দেয়। এই পরামিতি নিম্নলিখিত মান নিতে পারে:

0 - স্বীকৃতি বিবেচনা করা হবে না।
1 — ডিফল্ট প্যারামিটার, শুধুমাত্র 1টি প্রতিলিপি স্বীকার করতে হবে।
−1 — সমস্ত সিঙ্ক্রোনাইজড রেপ্লিকা (ক্লাস্টার সেটিং) থেকে স্বীকৃতি প্রয়োজন min.insync.replicas).

তালিকাভুক্ত মানগুলি থেকে, এটি দেখা যায় যে -1 এর সমান acks সবচেয়ে শক্তিশালী গ্যারান্টি দেয় যে বার্তাটি হারিয়ে যাবে না।

আমরা সবাই জানি, বিতরণ সিস্টেমগুলি অবিশ্বস্ত। ক্ষণস্থায়ী ব্যর্থতা থেকে রক্ষা পেতে, কাফকা প্রযোজক প্যারামিটার প্রদান করে পুনরায় চেষ্টা করে, যা আপনাকে পুনরায় জমা দেওয়ার প্রচেষ্টার সংখ্যা সেট করতে দেয় বিতরণ.সময় শেষ. যেহেতু পুনঃপ্রচারের প্যারামিটারের একটি ডিফল্ট মান রয়েছে Integer.MAX_VALUE (2147483647), তাই বার্তার পুনরায় জমা দেওয়ার সংখ্যা শুধুমাত্র delivery.timeout.ms পরিবর্তন করে সামঞ্জস্য করা যেতে পারে।

ঠিক একবার ডেলিভারির দিকে অগ্রসর হচ্ছে

এই সেটিংস আমাদের প্রযোজককে উচ্চ গ্যারান্টি সহ বার্তাগুলি সরবরাহ করার অনুমতি দেয়। আসুন এখন আলোচনা করা যাক কিভাবে নিশ্চিত করা যায় যে একটি বার্তার একটি কপি একটি কাফকা বিষয়ে লেখা হয়েছে? সহজ ক্ষেত্রে, এর জন্য, আপনাকে প্রযোজক পরামিতি সেট করতে হবে enable.idempotence সত্য থেকে অদম্যতা নিশ্চিত করে যে একটি বিষয়ের একটি নির্দিষ্ট বিভাজনে শুধুমাত্র একটি বার্তা লেখা হয়। অদম্যতা সক্ষম করার পূর্বশর্ত হল মান acks = সব, পুনরায় চেষ্টা করুন > 0, max.in.flight.requests.per.connection ≤ 5. যদি এই পরামিতিগুলি বিকাশকারী দ্বারা সেট না করা হয় তবে উপরের মানগুলি স্বয়ংক্রিয়ভাবে সেট হয়ে যাবে।

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

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

এছাড়াও, একটি কী এবং idempotent ব্যবহার করে একটি প্যারামিটার সহ পাঠান max.in.flight.requests.per.connection = 1 আপনাকে ভোক্তার উপর নির্দেশিত বার্তা পরিচালনা করে। আলাদাভাবে, এটি মনে রাখা উচিত যে যদি আপনার ক্লাস্টারে অ্যাক্সেস কন্ট্রোল কনফিগার করা থাকে, তবে আপনার বিষয়টিতে অদম্য লেখার অধিকারের প্রয়োজন হবে।

যদি হঠাৎ করে আপনার কী দ্বারা idempotent পাঠানোর ক্ষমতার অভাব হয়, বা প্রযোজকের পক্ষের যুক্তির জন্য বিভিন্ন পার্টিশনের মধ্যে ডেটা সামঞ্জস্য বজায় রাখা প্রয়োজন, তাহলে লেনদেনগুলি উদ্ধারে আসবে। উপরন্তু, একটি চেইন লেনদেন ব্যবহার করে, আপনি শর্তসাপেক্ষে কাফকাতে একটি রেকর্ড সিঙ্ক্রোনাইজ করতে পারেন, উদাহরণস্বরূপ, একটি ডাটাবেসের রেকর্ডের সাথে। প্রযোজকের কাছে লেনদেনমূলক প্রেরণ সক্ষম করতে, এটি অবশ্যই অদম্য হতে হবে এবং অতিরিক্তভাবে সেট করতে হবে 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.

এই সমস্যাটি সমাধান করার জন্য, আমরা অ্যাপ্লিকেশন নামের সাথে একটি হোস্টনাম প্রত্যয় যোগ করি, যা আমরা পরিবেশের ভেরিয়েবল থেকে পাই।

প্রযোজক সেট আপ করা হয়েছে, কিন্তু কাফকা লেনদেন শুধুমাত্র বার্তার সুযোগ নিয়ন্ত্রণ করে। লেনদেনের স্থিতি নির্বিশেষে, বার্তাটি অবিলম্বে বিষয়টিতে চলে যায়, তবে অতিরিক্ত সিস্টেম বৈশিষ্ট্য রয়েছে।

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

কিন্তু আরো একটি nuance আছে. আমরা উপরে যে transactional.id সেট করেছি তা আসলে লেনদেন উপসর্গ। লেনদেন ম্যানেজারে, এটির সাথে একটি ক্রম নম্বর যুক্ত করা হয়। ফলে শনাক্তকারী জারি করা হয় transactional.id.expiration.ms, যা কাফকা ক্লাস্টারে কনফিগার করা হয়েছে এবং এর ডিফল্ট মান 7 দিনের। যদি এই সময়ের মধ্যে অ্যাপ্লিকেশনটি কোনো বার্তা না পায়, তাহলে আপনি যখন পরবর্তী লেনদেনের চেষ্টা করবেন তখন আপনি পাবেন অবৈধপিডম্যাপিং ব্যতিক্রম. এর পরে, লেনদেন সমন্বয়কারী পরবর্তী লেনদেনের জন্য একটি নতুন ক্রম নম্বর জারি করবে। যাইহোক, 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

কাফকা কীভাবে বাস্তবে পরিণত হয়েছিল

গ্যারান্টিযুক্ত ডেলিভারি এবং আরও অনেক কিছু

ঠিক একবার ডেলিভারির দিকে অগ্রসর হচ্ছে

পরিবর্তে মোটামুটি

একটি মন্তব্য জুড়ুন উত্তর বাতিল