Redis দক্ষতা: উন্নত মেসেজিং দিয়ে মাইক্রোসার্ভিসেস ইনফ্রাস্ট্রাকচার বাড়ানো

২০১৯ সালে, আমি লিখেছিলাম কিভাবে Redis-এ একটি ইভেন্ট স্টোর তৈরি করতে হয়। আমি ব্যাখ্যা করেছিলাম যে Redis Streams একটি ইভেন্ট স্টোরের জন্য ভালো ফিট, কারণ সেগুলো আপনাকে ইভেন্ট স্টোর করতে দেয় একটি ইমিউটেবল অ্য펜্ড-অনলি মেকানিজমের মতো একটি ট্রানজ্যাকশন লগ। এখন, স্যাম্পল OrderShop অ্যাপ্লিকেশনের একটি আপডেটের সাথে যা সেই ব্লগে পরিচিত করা হয়েছিল, আমি দেখাবো কিভাবে Redis ব্যবহার করা যায় একটি মেসেজ কিউ হিসেবে, আরও Redis Enterprise-এর অনেক ইউজ কেস ক্যাশিং-এর বাইরে প্রদর্শন করে।

মাইক্রোসার্ভিসেস, ইনফ্রাস্ট্রাকচার সার্ভিস এবং ডিস্ট্রিবিউটেড সিস্টেমের একটি দ্রুত নজর

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

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

ইভেন্ট সোর্সিং, যা একটি বিজনেস এন্টিটি যেমন একটি অর্ডার বা একটি কাস্টমারের স্টেটকে স্টেট-চেঞ্জিং ইভেন্টের একটি সিকোয়েন্স হিসেবে পার্সিস্ট করে, অভেইলেবিলিটি বেছে নেয় কনসিস্টেন্সির পরিবর্তে। এটি রাইট অপারেশনকে ত্রিবিয়াল করে, কিন্তু রিড অপারেশন ব্যয়বহুল কারণ, কেসে তারা একাধিক সার্ভিস জুড়ে ছড়িয়ে থাকে, তারা একটি অডিশনাল মেকানিজম রিকোয়ার করতে পারে যেমন একটি রিড মডেল।

একটি ডিস্ট্রিবিউটেড সিস্টেমে যোগাযোগ ব্রোকারড বা ব্রোকারলেস হতে পারে। ব্রোকারলেস স্টাইলগুলো ভালো পরিচিত, HTTP এর সাথে এর সবচেয়ে বিখ্যাত উদাহরণ। ব্রোকারড পদ্ধতিতে, নামের ইমপ্লাই হোক, একটি ব্রোকার থাকে সেন্ডার এবং রিসিভারের মাঝপথে একটি মেসেজের। এটি সেন্ডার এবং রিসিভারকে ডিকাপল করে, সিনক্রোনাস এবং অ্যাসিনক্রোনাস যোগাযোগ এনাবল করে। এটি আরও রেজিলিয়েন্ট বিহেভিয়র ফলাফল দেয় কারণ মেসেজ কনসিউমারকে उस মুহূর্তে উপলব্ধ থাকতে হয় না যখন মেসেজ পাঠানো হয়। ব্রোকারড যোগাযোগ সেন্ডার এবং রিসিভারের স্বতন্ত্র স্কেলিংও অনুমতি দেয়।

(আরও ইনফরমেশনের জন্য, আমাদের পোস্ট দেখুন What to Choose for Your Synchronous and Asynchronous Communication Needs—Redis Streams, Redis Pub/Sub, Kafka, ইত্যাদি।)

OrderShop: একটি স্যাম্পল ই-কমার্স ইমপ্লিমেন্টেশন

"Hello World" একটি মাইক্রোসার্ভিস আর্কিটেকচারের হলো OrderShop, একটি ইভেন্ট-ভিত্তিক পদ্ধতিতে একটি সহজ ই-কমার্স সিস্টেম ইমপ্লিমেন্টেশন। এই স্যাম্পল অ্যাপ্লিকেশন একটি সহজ ডোমেইন মডেল ব্যবহার করে, কিন্তু এটি অ্যাপ্লিকেশনের উদ্দেশ্য পূরণ করে।

OrderShop Docker Compose ব্যবহার করে অর্কেস্ট্রেট করা হয়। সকল নেটওয়ার্ক কমিউনিকেশন gRPC-র ওপর করা হয়। কেউנד্রাল কম্পোনেন্টগুলো হলো ইভেন্ট স্টোর এবং মেসেজ কিউ: প্রতিটি সার্ভিস সংযুক্ত থাকে শুধু এবং শুধু সেগুলোর সাথে gRPC-র ওপর। OrderShop Python-এ একটি স্যাম্পল ইমপ্লিমেন্টেশন। আপনি OrderShop সোর্স কোড GitHub-এ দেখতে পারেন।

(নোট: এই কোড নয় প্রোডাকশন-রেডি এবং শুধু ডেমো উদ্দেশ্যে!)

রান এবং ফান

• GitHub রিপোজিটরি ক্লোন করুন: https://github.com/redis-demos/ordershop-v2
• OrderShop v2 রান করুন একটি সহজ পাঁচ-স্টেপ প্রসেসে:

1. অ্যাপ্লিকেশন শুরু করুন docker-compose up
2. আপনার ব্রাউজার খুলুন এবং যান https://localhost:5000/
   1. ইভেন্ট দেখুন এবং স্টেট ব্রাউজ করুন
3. ক্লায়েন্ট রান করুন python -m unittest tests/unit.py
4. আপনার ব্রাউজারে আরেকটি ট্যাব খুলুন https://localhost:8001/
   1. redis:6379 ব্যবহার করুন টেস্ট ডেটাবেসের সাথে সংযোগ করতে
5. অ্যাপ্লিকেশন বন্ধ করুন docker-compose down

OrderShop v2 আর্কিটেকচার

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

কমান্ড এবং কোয়েরি কমিউনিকেট করা হয় মেসেজ কিউ কম্পোনেন্টের মাধ্যমে, যখন ইভেন্টগুলো কমিউনিকেট করা হয় ইভেন্ট স্টোর কম্পোনেন্টের মাধ্যমে, যা একটি ইভেন্ট বাস হিসেবেও কাজ করে।

ইনফ্রাস্ট্রাকচার সার্ভিস

OrderShop v2-এ, সকল ইউনিকাস্ট কমিউনিকেশন হয় মেসেজ কিউ কম্পোনেন্টের ওপর। এর জন্য, আমি Redis Lists ব্যবহার করব, এবং বিশেষভাবে, দুটি লিস্ট একসাথে কম্বাইন করা হয় একটি所謂 "রিলায়েবল কিউ"। এটি সিম্পল কমান্ড (যেমন সিঙ্গেল এন্টিটি অপারেশন) সিনক্রোনাসলি প্রসেস করে, কিন্তু লং-রানিং वाले (যেমন ব্যাচ, মেইল) অ্যাসিনক্রোনাসলি এবং সিনক্রোনাস মেসেজের রেসপন্স সাপোর্ট করে আউট-অফ-দ্য-বক্স।

ইভেন্ট স্টোর Redis Streams-ভিত্তিক। ডোমেইন সার্ভিস (যারা শুধু OrderShop-এর ফাংশনালিটি ডেমো করার জন্য ডামি) ইভেন্ট স্ট্রিমে সাবস্ক্রাইব করা থাকে যেগুলো ইভেন্ট টপিক (অর্থাৎ এন্টিটি নাম) অনুযায়ী নামকরণ করা হয়েছে এবং এই স্ট্রিমগুলোতে ইভেন্ট পাবলিশ করে। প্রতিটি ইভেন্ট একটি স্ট্রিম-এন্ট্রি যার ইভেন্ট টাইমস্ট্যাম্প আইডি হিসেবে কাজ করে। স্ট্রিমগুলোর পাবলিশড ইভেন্টগুলোর সমষ্টি পুরো সিস্টেমের স্টেট ফলাফল দেয়।

অ্যাপ্লিকেশন সার্ভিস

রিড মডেল ডিডাসিড এন্টিটি ক্যাশ করে ইভেন্ট স্টোর- থেকে Redis-এ ডোমেইন মডেল ব্যবহার করে। ক্যাশকে উপেক্ষা করলে, এটি স্টেটলেস।

API গেটওয়েও স্টেটলেস, এবং REST-API সার্ভ করে পোর্ট ৫০০০-এ। এটি HTTP সংযোগ টার্মিনেট করে এবং সেগুলো রাউট করে হয় রিড মডেলের দিকে স্টেট পড়ার জন্য (কোয়েরি) অথবা ডেডিকেটেড ডোমেইন সার্ভিসের দিকে স্টেট লেখার জন্য (কমান্ড)। রিড এবং রাইট অপারেশন এই কনসেপচুয়াল сеপারেশন একে Command Query Responsibility Segregation (CQRS) বলে।

ডোমেইন সার্ভিস

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

CRM সার্ভিস (Customer Relation Management service) স্টেটলেস—এটি ডোমেইন ইভেন্টে সাবস্ক্রাইব করা থাকে ইভেন্ট স্টোর থেকে এবং ইমেইল পাঠায় কাস্টমারদের মেইল সার্ভিস ব্যবহার করে।

কেউন্ড্রাল ডোমেইন এন্টিটি হলো অর্ডার। এর একটি ফিল্ড আছে যাকে 'status' বলা হয় যার ট্রানজিশন একটি স্টেট মেশিন ব্যবহার করে পারফর্ম করা হয়, নিচের ডায়াগ্রামে দেখানো যেন:

এই ট্রানজিশনগুলো অনেক ইভেন্ট হ্যান্ডলারের মাধ্যমে করা হয়, যারা ডোমেইন ইভেন্টে সাবস্ক্রাইব করা থাকে (SAGA প্যাটার্ন), উদাহরণস্বরূপ:

ক্লায়েন্টরা

ক্লায়েন্টরা সিমুলেট করা হয় Python-এর Unit testing framework ব্যবহার করে। বর্তমানে ১০টি ইউনিট টেস্ট ইমপ্লিমেন্ট করা আছে। আরও ডিটেলের জন্য tests/unit.py দেখুন।

একটি সিম্পল UI সার্ভ করা হয় পোর্ট ৫০০০-এ ইভেন্ট দেখতে এবং স্টেট ব্রাউজ করতে (WebSockets ব্যবহার করে)।

একটি RedisInsight কন্টেইনারও উপলব্ধ Redis ইনস্ট্যান্স ইন্সপেক্ট করতে। ওয়েব ব্রাউজার খুলুন https://localhost:8001/ এবং ব্যবহার করুন redis:6379 টেস্ট ডেটাবেসের সাথে সংযোগ করতে।

উপসংহার

Redis শুধু একটি পাওয়ারফুল টুল নয় ডোমেইন লেয়ারে (যেমন একটি ক্যাটালগ সার্চ) এবং অ্যাপ্লিকেশন লেয়ারে (যেমন একটি HTTP সেশন স্টোর) বরং ইনফ্রাস্ট্রাকচার লেয়ারেও (যেমন একটি ইভেন্ট স্টোর বা মেসেজ কিউ)। এই লেয়ার জুড়ে Redis ব্যবহার করা অপারেশনাল ওভারহেড কমিয়ে দেয় এবং ডেভেলপারদের তাদের যেন জানা টেকনোলজি পুনরায় ব্যবহার করতে দেয়।

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

টুইটারে @martinez099-এ জানান কীভাবে গেলো।