হাডুপ। ZooKeeper" Mail.Ru গ্রুপ টেকনোস্ট্রিম সিরিজ থেকে "হাদুপে প্রচুর পরিমাণে ডেটা বিতরণ প্রক্রিয়াকরণের পদ্ধতি"

আমি আপনাকে "Hadoop. ZooKeeper" সিরিজের বক্তৃতাটির প্রতিলিপি পড়ার পরামর্শ দিচ্ছি "হাডোপে বিপুল পরিমাণ ডেটা বিতরণ প্রক্রিয়াকরণের পদ্ধতি"

ZooKeeper কি, Hadoop ইকোসিস্টেমে এর স্থান। ডিস্ট্রিবিউটেড কম্পিউটিং সম্পর্কে অসত্য। একটি আদর্শ বিতরণ ব্যবস্থার চিত্র। বিতরণ ব্যবস্থা সমন্বয়ে অসুবিধা। সাধারণ সমন্বয় সমস্যা। ZooKeeper এর নকশা পিছনে নীতি. ZooKeeper ডেটা মডেল। znode পতাকা সেশন. ক্লায়েন্ট API। আদিম (কনফিগারেশন, গ্রুপ সদস্যপদ, সাধারণ তালা, নেতা নির্বাচন, পশুপালের প্রভাব ছাড়া লকিং)। চিড়িয়াখানার স্থাপত্য। চিড়িয়াখানার রক্ষক ডিবি। ZAB. অনুরোধ হ্যান্ডলার.

আজ আমরা ZooKeeper সম্পর্কে কথা বলব। এই জিনিস খুব দরকারী. এটি, যে কোন Apache Hadoop পণ্যের মত, একটি লোগো আছে। এটি একজন মানুষকে চিত্রিত করে।

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

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

Hadoop-সম্পর্কিত সমস্ত অ্যাপ্লিকেশনের মতো, এটি Yahoo! এটি এখন একটি অফিসিয়াল অ্যাপাচি অ্যাপ্লিকেশন। এটি HBase এর মতো সক্রিয়ভাবে বিকশিত নয়। আপনি যদি JIRA HBase-এ যান, তাহলে প্রতিদিন একগুচ্ছ বাগ রিপোর্ট, কিছু অপ্টিমাইজ করার জন্য একগুচ্ছ প্রস্তাব, অর্থাৎ প্রকল্পে জীবন ক্রমাগত চলছে। এবং ZooKeeper, একদিকে, একটি অপেক্ষাকৃত সহজ পণ্য, এবং অন্যদিকে, এটি এর নির্ভরযোগ্যতা নিশ্চিত করে। এবং এটি ব্যবহার করা বেশ সহজ, যে কারণে এটি Hadoop ইকোসিস্টেমের মধ্যে অ্যাপ্লিকেশনগুলির একটি মান হয়ে উঠেছে। তাই আমি ভেবেছিলাম এটি কীভাবে কাজ করে এবং কীভাবে এটি ব্যবহার করতে হয় তা বোঝার জন্য এটি পর্যালোচনা করা উপযোগী হবে।

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

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

অন্যান্য জিনিসের মধ্যে, নেটওয়ার্ক ব্যবহার করার সময়, সবসময় একটি নির্দিষ্ট বিলম্ব থাকে। ডিস্কেও এটি রয়েছে, তবে নেটওয়ার্কে এটি বেশি রয়েছে। লেটেন্সি হল কিছু বিলম্বের সময়, যা হয় ছোট বা বেশ তাৎপর্যপূর্ণ হতে পারে।

নেটওয়ার্ক টপোলজি পরিবর্তন হচ্ছে। টপোলজি কি - এটি আমাদের নেটওয়ার্ক সরঞ্জামের বসানো। ডাটা সেন্টার আছে, র্যাক আছে যেগুলো সেখানে দাঁড়িয়ে আছে, মোমবাতি আছে। এই সব পুনঃসংযোগ করা যেতে পারে, সরানো, ইত্যাদি. এই সব অ্যাকাউন্টে নেওয়া প্রয়োজন. IP নাম পরিবর্তিত হয়, আমাদের ট্রাফিক যাতায়াতের রাউটিং পরিবর্তিত হয়। এটিও বিবেচনায় নেওয়া দরকার।

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

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

একটি প্রসেসর সহ একটি কম্পিউটারে চলে এমন একটি প্রোগ্রাম লেখা সহজ।

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

এটা স্পষ্ট যে এই সব দ্রুত নিরীক্ষণ করা যেতে পারে। এটিও ভাল, তবে পর্যবেক্ষণ একটি সীমিত জিনিস যা আপনাকে সর্বোচ্চ স্তরে কিছু জিনিস পর্যবেক্ষণ করতে দেয়।

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

এই সমস্ত প্রক্রিয়ার সমন্বয় একটি তুচ্ছ জিনিস নয়। এবং এটি বিকাশকারীকে আরও নিম্ন স্তরে যেতে বাধ্য করে, এবং স্ক্র্যাচ থেকে সিস্টেমগুলি লিখতে বাধ্য করে, বা একেবারে স্ক্র্যাচ থেকে নয়, তবে এটি এত সহজ নয়।

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

আজ আমরা ZooKeeper সম্পর্কে কথা বলছি। একদিকে, এটি একটি কাঠামো, অন্যদিকে, এটি এমন একটি পরিষেবা যা বিকাশকারীর জীবনকে সহজ করে তোলে এবং যতটা সম্ভব যুক্তির বাস্তবায়ন এবং আমাদের প্রক্রিয়াগুলির সমন্বয়কে সহজ করে তোলে।

আসুন মনে রাখা যাক একটি আদর্শ বিতরণ ব্যবস্থা কেমন হতে পারে। এই আমরা কি সম্পর্কে কথা বললাম - HDFS, HBase. একটি মাস্টার প্রক্রিয়া আছে যা শ্রমিক এবং দাস প্রক্রিয়া পরিচালনা করে। তিনি কাজের সমন্বয় ও বন্টন, কর্মীদের পুনরায় চালু করা, নতুন চালু করা এবং লোড বিতরণের জন্য দায়ী।

একটি আরও উন্নত জিনিস হল সমন্বয় পরিষেবা, অর্থাৎ, সমন্বয়ের কাজটিকে নিজেই একটি পৃথক প্রক্রিয়ায় নিয়ে যান, পাশাপাশি কিছু ধরণের ব্যাকআপ বা স্ট্যানবাই মাস্টার সমান্তরালভাবে চালান, কারণ মাস্টার ব্যর্থ হতে পারে। আর যদি মাস্টার পড়ে যায়, তাহলে আমাদের সিস্টেম কাজ করবে না। আমরা ব্যাকআপ চালাচ্ছি। কিছু স্টেট যে মাস্টারকে ব্যাকআপে প্রতিলিপি করা দরকার। এটি সমন্বয় পরিষেবার কাছেও ন্যস্ত করা যেতে পারে। কিন্তু এই চিত্রে, কর্মীদের সমন্বয়ের জন্য মাস্টার নিজেই দায়ী;

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

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

এই স্কিমগুলির মধ্যে কোনটি ভাল কাজ করে তা বলা কঠিন। প্রত্যেকের নিজস্ব সুবিধা এবং অসুবিধা আছে।

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

এবং এই স্কিম (উপরে) সম্ভবত আরো জটিল, কিন্তু আরো নির্ভরযোগ্য।

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

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

ZooKeeper এই ধরনের প্রত্যাখ্যান মোকাবেলা করার উপায় অফার করে, যা আমাদের জীবনকে আরও সহজ করে তোলে।

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

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

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

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

এছাড়াও একটি গতিশীল কনফিগারেশন আছে। এই পরামিতি যে আমরা ফ্লাইতে পরিবর্তন করতে চাই যাতে সেগুলি সেখানে তোলা হয়।

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

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

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

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

ZooKeeper আপনাকে এই সমস্ত সমস্যাগুলি এক ডিগ্রী বা অন্যভাবে সমাধান করতে দেয়। এবং আমি উদাহরণ সহ দেখাব কিভাবে এটি আপনাকে এটি করতে দেয়।

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

সমস্ত ক্লায়েন্ট অনুরোধ সাধারণ সারির ক্রমে প্রক্রিয়া করা হয়।

এবং ক্লায়েন্টরা পরিবর্তিত ডেটা নিজেরাই দেখার আগে ক্লায়েন্টদের কিছু রাজ্যের পরিবর্তন সম্পর্কে, ডেটার পরিবর্তন সম্পর্কে বিজ্ঞপ্তি পাওয়ার সুযোগ রয়েছে।

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

ক্লায়েন্ট সাইডে ডেটা ক্যাশে করা যায়। এটি একটি আদর্শ নীতি যাতে আমরা পরিষেবাটি ব্যাহত না করি এবং একই অনুরোধের সাথে এটি লোড করি না। একজন স্মার্ট ক্লায়েন্ট সাধারণত এটি সম্পর্কে জানেন এবং এটি ক্যাশ করে।

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

ক্লায়েন্ট হল ব্যবহারকারী যিনি ZooKeeper ব্যবহার করেন।

সার্ভার নিজেই ZooKeeper প্রক্রিয়া।

Znode হল ZooKeeper এর মূল জিনিস। সমস্ত znodes ZooKeeper দ্বারা মেমরিতে সংরক্ষণ করা হয় এবং একটি গাছের আকারে একটি শ্রেণিবদ্ধ চিত্রের আকারে সংগঠিত হয়।

দুই ধরনের অপারেশন আছে। প্রথমটি হল আপডেট/রাইট, যখন কিছু অপারেশন আমাদের গাছের অবস্থা পরিবর্তন করে। গাছটি সাধারণ।

এবং এটা সম্ভব যে ক্লায়েন্ট একটি অনুরোধ সম্পূর্ণ করে না এবং সংযোগ বিচ্ছিন্ন হয়ে যায়, তবে একটি সেশন স্থাপন করতে পারে যার মাধ্যমে এটি ZooKeeper এর সাথে যোগাযোগ করে।

ZooKeeper এর ডেটা মডেল একটি ফাইল সিস্টেমের অনুরূপ। একটি স্ট্যান্ডার্ড রুট আছে এবং তারপরে আমরা গিয়েছিলাম যেন ডাইরেক্টরির মাধ্যমে যেটা রুট থেকে যায়। এবং তারপর প্রথম স্তরের ক্যাটালগ, দ্বিতীয় স্তর. এই সব znodes.

প্রতিটি znode কিছু ডেটা সংরক্ষণ করতে পারে, সাধারণত খুব বড় নয়, উদাহরণস্বরূপ, 10 কিলোবাইট। এবং প্রতিটি জোনোডে একটি নির্দিষ্ট সংখ্যক শিশু থাকতে পারে।

Znodes বিভিন্ন ধরনের আসে। এগুলো তৈরি করা যায়। এবং একটি znode তৈরি করার সময়, আমরা নির্দিষ্ট করে দিই যে এটির সাথে যুক্ত হওয়া উচিত।

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

দ্বিতীয় প্রকার ক্রমিক পতাকা। এটি জনোডের পথে কাউন্টারকে বৃদ্ধি করে। উদাহরণস্বরূপ, আমাদের 1_5 অ্যাপ্লিকেশন সহ একটি ডিরেক্টরি ছিল। এবং যখন আমরা প্রথম নোড তৈরি করি, তখন এটি p_1 পেয়েছে, দ্বিতীয়টি - p_2। এবং যখন আমরা এই পদ্ধতিটিকে প্রতিবার কল করি, তখন আমরা সম্পূর্ণ পাথটি পাস করি, পাথের শুধুমাত্র অংশ নির্দেশ করে এবং এই সংখ্যাটি স্বয়ংক্রিয়ভাবে বৃদ্ধি পায় কারণ আমরা নোডের ধরন নির্দেশ করি - অনুক্রমিক।

নিয়মিত znode. তিনি সবসময় বেঁচে থাকবেন এবং তার নাম থাকবে যা আমরা তাকে বলি।

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

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

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

প্রতিটি সেশনের কোনো না কোনো সময় শেষ হয়। সেশনের সময় ক্লায়েন্ট সার্ভারে কিছু পাঠায় কিনা তা দ্বারা একটি সেশন সংজ্ঞায়িত করা হয়। যদি তিনি টাইমআউটের সময় কিছু প্রেরণ না করেন তবে সেশনটি বন্ধ হয়ে যায় বা ক্লায়েন্ট নিজেই এটি বন্ধ করতে পারে।

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

দ্বিতীয়ত, আপনি এটি মুছে ফেলতে পারেন। এখানে কৌশলটি হল যে দ্বিতীয় প্যারামিটার, znode এর পথ ছাড়াও, সংস্করণটি নির্দিষ্ট করতে পারে। তদনুসারে, সেই znode মুছে ফেলা হবে যদি আমরা স্থানান্তরিত এর সংস্করণটি আসলে বিদ্যমানটির সমতুল্য হয়।

যদি আমরা এই সংস্করণটি পরীক্ষা করতে না চাই, তাহলে আমরা কেবল "-1" যুক্তিটি পাস করি।

তৃতীয়ত, এটি একটি জনোডের অস্তিত্ব পরীক্ষা করে। নোড বিদ্যমান থাকলে সত্য প্রদান করে, অন্যথায় মিথ্যা।

এবং তারপর পতাকা ঘড়ি প্রদর্শিত হবে, যা আপনাকে এই নোড নিরীক্ষণ করতে অনুমতি দেয়।

আপনি এই পতাকাটি এমনকি অস্তিত্বহীন নোডেও সেট করতে পারেন এবং এটি প্রদর্শিত হলে একটি বিজ্ঞপ্তি পেতে পারেন। এটিও উপকারী হতে পারে।

আরও কয়েকটি চ্যালেঞ্জ রয়েছে তথ্য সংগ্রহ করো. এটা স্পষ্ট যে আমরা znode এর মাধ্যমে ডেটা গ্রহণ করতে পারি। আপনি পতাকা ঘড়ি ব্যবহার করতে পারেন। এই ক্ষেত্রে, কোন নোড না থাকলে এটি ইনস্টল হবে না। অতএব, আপনাকে বুঝতে হবে যে এটি বিদ্যমান, এবং তারপরে ডেটা গ্রহণ করুন।

এছাড়াও আছে সেট ডেটা. এখানে আমরা সংস্করণ পাস. এবং যদি আমরা এটি পাস করি তবে একটি নির্দিষ্ট সংস্করণের znode-এর ডেটা আপডেট করা হবে।

আপনি এই চেকটি বাদ দিতে "-1" নির্দিষ্ট করতে পারেন।

আরেকটি দরকারী পদ্ধতি হল বাচ্চাদের পান. আমরা এটির অন্তর্গত সমস্ত জোনোডের একটি তালিকাও পেতে পারি। আমরা পতাকা ঘড়ি সেট করে এটি নিরীক্ষণ করতে পারি।

এবং পদ্ধতি সিঙ্ক সমস্ত পরিবর্তন একবারে পাঠানোর অনুমতি দেয়, যার ফলে সেগুলি সংরক্ষণ করা হয়েছে এবং সমস্ত ডেটা সম্পূর্ণরূপে পরিবর্তিত হয়েছে তা নিশ্চিত করে।

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

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

আমরা যে দুটি অপারেশন সম্পর্কে কথা বলেছি তা হল আপডেট/রাইট, যা ডেটা পরিবর্তন করে। এগুলো হলো তৈরি, সেট ডাটা, সিঙ্ক, ডিলিট। এবং পড়া বিদ্যমান, getData, getChildren.

এখন একটি বিতরণ সিস্টেমে কাজ করার জন্য আপনি কীভাবে আদিম তৈরি করতে পারেন তার কয়েকটি উদাহরণ। যেমন কোনো কিছুর কনফিগারেশন সম্পর্কিত। একজন নতুন কর্মী হাজির হয়েছে। আমরা মেশিন যোগ এবং প্রক্রিয়া শুরু. এবং নিম্নলিখিত তিনটি প্রশ্ন আছে. কিভাবে এটি কনফিগারেশনের জন্য ZooKeeper কে জিজ্ঞাসা করে? এবং যদি আমরা কনফিগারেশন পরিবর্তন করতে চাই, আমরা কিভাবে এটি পরিবর্তন করব? এবং আমরা এটি পরিবর্তন করার পরে, কিভাবে আমরা এটি পেতে যারা শ্রমিকরা?

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

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

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

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

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

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

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

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

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

যদি কোনও কারণে নেতা মারা যান, উদাহরণস্বরূপ, পড়ে গেলে, আমরা একটি নতুন নেতা তৈরি করার চেষ্টা করি। আর আমরা সফল হলেই আমাদের কর্মী নেতা হয়ে যায়। এবং যদি এই মুহুর্তে কেউ একজন নতুন নেতা তৈরি করতে সক্ষম হন, তবে আমরা এটি কে তা বোঝার চেষ্টা করি এবং তারপরে তাকে অনুসরণ করি।

এখানে তথাকথিত পশুর প্রভাব দেখা দেয়, অর্থাৎ পশুপালের প্রভাব, কারণ যখন একজন নেতা মারা যায়, তখন যিনি প্রথম হবেন তিনিই নেতা হবেন।

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

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

ZooKeeper কি নিয়ে গঠিত? 4টি প্রধান জিনিস রয়েছে। এটি প্রক্রিয়াকরণ প্রক্রিয়া - অনুরোধ. এছাড়াও ZooKeeper Atomic Broadcast. একটি কমিট লগ আছে যেখানে সমস্ত ক্রিয়াকলাপ রেকর্ড করা হয়। এবং ইন-মেমরি প্রতিলিপিকৃত ডিবি নিজেই, অর্থাৎ ডাটাবেস নিজেই যেখানে এই সম্পূর্ণ গাছটি সংরক্ষণ করা হয়।

এটি লক্ষণীয় যে সমস্ত লেখার ক্রিয়াকলাপ অনুরোধ প্রসেসরের মাধ্যমে যায়। এবং রিড অপারেশন সরাসরি ইন-মেমরি ডাটাবেসে যায়।

ডাটাবেস নিজেই সম্পূর্ণরূপে প্রতিলিপি করা হয়. ZooKeeper-এর সমস্ত উদাহরণ ডেটার একটি সম্পূর্ণ অনুলিপি সংরক্ষণ করে।

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

ZooKeeper Atomic Broadcast এমন একটি জিনিস যা প্রতিলিপিকৃত ডেটা বজায় রাখতে ব্যবহৃত হয়।

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

এটি শুধুমাত্র লেখার অনুরোধ প্রক্রিয়া করে। এর প্রধান কাজ হল এটি অপারেশনটিকে একটি লেনদেন সংক্রান্ত আপডেটে রূপান্তরিত করে। এটি একটি বিশেষভাবে উত্পন্ন অনুরোধ.

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

উত্স: www.habr.com