ইতিমধ্যে ইতিমধ্যে উল্লিখিত হিসাবে সাধারণ পন্থাটি একটি বার্তার সারি । ডিজাইনের দৃষ্টিকোণ থেকে একটি বার্তার সারিটি মূলত একটি ফিফোর সারি , যা একটি মূল মৌলিক ডেটা টাইপ:
একটি বার্তা সারিটি কী বিশেষ করে তোলে তা হ'ল আপনার অ্যাপ্লিকেশনটি এন-কুইংয়ের জন্য দায়ী থাকাকালীন একটি পৃথক প্রক্রিয়া ডি-কুইংয়ের জন্য দায়ী। কুইউটিং লিংগোতে, আপনার অ্যাপ্লিকেশনটি বার্তা প্রেরণকারী (গুলি) এবং ডি-কুইং প্রক্রিয়াটি প্রাপক i এর সুস্পষ্ট সুবিধাটি হ'ল পুরো প্রক্রিয়াটি অ্যাসিক্রোনাস, প্রেরক প্রেরকের স্বতন্ত্রভাবে কাজ করে, যতক্ষণ প্রক্রিয়া করার বার্তা রয়েছে। সুস্পষ্ট অসুবিধাটি হ'ল পুরো জিনিসটি কাজ করার জন্য আপনার অতিরিক্ত উপাদান, প্রেরক দরকার।
যেহেতু আপনার আর্কিটেকচার এখন বার্তা বিনিময় দুটি উপাদানগুলির উপর নির্ভর করে, আপনি এর জন্য অভিনব শব্দটি আন্ত-প্রক্রিয়া যোগাযোগ ব্যবহার করতে পারেন।
কীভাবে একটি সারি প্রবর্তন করা আপনার অ্যাপ্লিকেশনটির নকশাকে প্রভাবিত করে?
আপনার অ্যাপ্লিকেশনটিতে কিছু ক্রিয়া ইমেল উত্পন্ন করে। একটি বার্তা সারি উপস্থাপনের অর্থ হ'ল এই ক্রিয়াগুলির পরিবর্তে এখন বার্তাগুলিকে কাতারে চাপ দেওয়া উচিত (এবং আরও কিছু নয়)। এই বার্তাগুলিতে নিখুঁত ন্যূনতম পরিমাণের তথ্য বহন করা উচিত যা আপনার রিসিভার যখন তাদের প্রক্রিয়া করতে আসে তখন ইমেলগুলি তৈরি করতে প্রয়োজনীয়।
বার্তা ফর্ম্যাট এবং বিষয়বস্তু
আপনার বার্তাগুলির ফর্ম্যাট এবং সামগ্রী সম্পূর্ণরূপে আপনার উপর নির্ভর করে তবে আপনার আরও ছোটটি মনে রাখা উচিত। আপনার সারি লিখতে এবং দ্রুত প্রক্রিয়া করার জন্য দ্রুত হওয়া উচিত, এতে প্রচুর পরিমাণে ডেটা নিক্ষেপ করা সম্ভবত একটি বাধা সৃষ্টি করবে।
অধিকন্তু বেশ কয়েকটি ক্লাউড ভিত্তিক কুইউনিং পরিষেবাদির বার্তার আকারগুলিতে বিধিনিষেধ রয়েছে এবং এটি বৃহত্তর বার্তাগুলিকে বিভক্ত করতে পারে। আপনি খেয়াল করবেন না, বিভক্ত বার্তাগুলি আপনি যখন জিজ্ঞাসা করবেন তখন সেগুলি এক হিসাবে পরিবেশন করা হবে তবে একাধিক বার্তাগুলির জন্য আপনাকে চার্জ করা হবে (ধরে নিই যে আপনি কোনও পরিষেবা ব্যবহার করছেন যা ফি প্রয়োজন requires
রিসিভার ডিজাইন
যেহেতু আমরা একটি ওয়েব অ্যাপ্লিকেশন সম্পর্কে কথা বলছি, আপনার রিসিভারের জন্য একটি সাধারণ পন্থা একটি সহজ ক্রোন স্ক্রিপ্ট হবে। এটি প্রতি xমিনিটে (বা সেকেন্ড) চলবে এবং এটি হবে:
nসারি থেকে বার্তাগুলির পপ পরিমাণ,- বার্তাগুলি প্রক্রিয়া করুন (যেমন ইমেলগুলি প্রেরণ করুন)।
লক্ষ্য করুন যে আমি পেতে বা আনার পরিবর্তে পপ বলছি, এর কারণ আপনার প্রাপক কেবল সারি থেকে আইটেমগুলি পাচ্ছেন না, এটি সেগুলি সাফও করছে (যেমন তাদের সারি থেকে সরিয়ে দেওয়া বা প্রক্রিয়াজাতকরণ হিসাবে চিহ্নিত করা)। কীভাবে এটি ঘটবে তা নির্ভর করে আপনার বার্তার সারিটি প্রয়োগ এবং আপনার অ্যাপ্লিকেশনটির নির্দিষ্ট প্রয়োজনীয়তার উপর।
অবশ্যই আমি যা বর্ণনা করছি তা মূলত একটি ব্যাচের অপারেশন , একটি সারি প্রক্রিয়াজাতকরণের সহজতম উপায়। আপনার প্রয়োজনের উপর নির্ভর করে আপনি বার্তাগুলি আরও জটিল পদ্ধতিতে প্রক্রিয়া করতে চাইতে পারেন (এটি আরও জটিল কাতারের জন্যও ডাকবে)।
ট্রাফিক
আপনার রিসিভার ট্র্যাফিকের বিষয়টি বিবেচনা করতে এবং চলার সময় ট্র্যাফিকের উপর ভিত্তি করে প্রক্রিয়াজাত বার্তাগুলির সংখ্যা সামঞ্জস্য করতে পারে। একটি সরল পদ্ধতি হ'ল অতীতের ট্র্যাফিক ডেটার উপর ভিত্তি করে আপনার উচ্চ ট্র্যাফিক সময়গুলির পূর্বাভাস দেওয়া এবং ধরে নেওয়া যে আপনি ক্রোন স্ক্রিপ্ট নিয়ে চলেছেন যা প্রতি xমিনিটে চলে আপনি এই জাতীয় কিছু করতে পারেন:
if(
now() > 2pm && now() < 7pm
) {
process(10);
} else {
process(100);
}
function process(count) {
for(i=0; i<=count; i++) {
message = dequeue();
mail(message)
}
}
একটি খুব নিষ্পাপ এবং নোংরা পদ্ধতির, কিন্তু এটি কার্যকর। যদি এটি না হয় তবে ভাল, অন্য পদ্ধতিটি হ'ল প্রতিটি পুনরাবৃত্তিতে আপনার সার্ভারের বর্তমান ট্র্যাফিকটি সন্ধান করা এবং সেই অনুসারে প্রক্রিয়া আইটেমের সংখ্যা সমন্বয় করা। এটি একেবারে প্রয়োজনীয় না হলেও মাইক্রো-অপ্টিমাইজ করবেন না, আপনি নিজের সময় নষ্ট করবেন।
সারি স্টোরেজ
যদি আপনার অ্যাপ্লিকেশনটি ইতিমধ্যে একটি ডাটাবেস ব্যবহার করে, তবে তার উপর একটি একক টেবিলই সহজ সমাধান হবে:
CREATE TABLE message_queue (
id int(11) NOT NULL AUTO_INCREMENT,
timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
processed enum('0','1') NOT NULL DEFAULT '0',
message varchar(255) NOT NULL,
PRIMARY KEY (id),
KEY timestamp (timestamp),
KEY processed (processed)
)
এটি আসলে এর চেয়ে জটিল নয়। আপনি অবশ্যই এটি আপনার প্রয়োজন হিসাবে জটিল হিসাবে তৈরি করতে পারেন, আপনি উদাহরণস্বরূপ, একটি অগ্রাধিকার ক্ষেত্র যুক্ত করতে পারেন (যার অর্থ এই যে এটি আর ফিফোর সারি নয়, তবে যদি আপনার এটির প্রয়োজন হয় তবে কে যত্নশীল?)। প্রক্রিয়াজাত ক্ষেত্রটি এড়িয়ে আপনি এটিকে আরও সহজ করে তুলতে পারেন (তবে তারপরে আপনার প্রক্রিয়া করার পরে সারিগুলি মুছতে হবে)।
ডাটাবেস সারণিতে দিন প্রতি 2000 বার্তাগুলির জন্য আদর্শ হতে পারে, কিন্তু এটা হবে সম্ভবত দৈনিক বার্তা লক্ষ লক্ষ জন্য ভাল স্কেল নয়। লক্ষ লক্ষ ফ্যাক্টর রয়েছে, আপনার অবকাঠামোগুলির সমস্ত কিছুই আপনার আবেদনের সামগ্রিক স্কেলিবিলিটিতে ভূমিকা রাখে।
যাই হোক না কেন, ধরে নিই যে আপনি ইতিমধ্যে ডাটাবেস ভিত্তিক সারিটি একটি বাধা হিসাবে চিহ্নিত করেছেন, পরবর্তী পদক্ষেপটি একটি মেঘ ভিত্তিক পরিষেবাটি দেখা উচিত। আমাজন এসকিউএস হ'ল আমি এক পরিষেবা যা ব্যবহার করেছি এবং এটি প্রতিশ্রুতি দিয়েছিল did আমি নিশ্চিত যে সেখানে বেশ কয়েকটি অনুরূপ পরিষেবা রয়েছে।
মেমরি ভিত্তিক কিউগুলিও বিবেচনা করার মতো বিষয়, বিশেষত স্বল্পজীবী সারির জন্য। মেমক্যাচ করা বার্তা সারি স্টোরেজ হিসাবে দুর্দান্ত।
আপনি যে স্টোরেজটিতে নিজের সারিটি তৈরির সিদ্ধান্ত নেন না কেন, স্মার্ট হন এবং এটি বিমূর্ত করুন। আপনার প্রেরক বা আপনার প্রাপক উভয়ই একটি নির্দিষ্ট স্টোরেজে আবদ্ধ হবেন না, অন্যথায় পরবর্তী সময়ে কোনও আলাদা স্টোরেজে স্যুইচ করা সম্পূর্ণ পিআইটিএ হবে না।
বাস্তব জীবনের পন্থা
আমি ইমেলগুলির জন্য একটি বার্তার সারি তৈরি করেছি যা আপনি যা করছেন তার সাথে খুব মিল। এটি একটি পিএইচপি প্রকল্পে ছিল এবং আমি এটি জেন্ড কুইয়ের চারপাশে তৈরি করেছি , জেন্ড ফ্রেমওয়ার্কের একটি উপাদান যা বিভিন্ন স্টোরের জন্য বেশ কয়েকটি অ্যাডাপ্টার সরবরাহ করে । আমার স্টোরগুলি যেখানে:
- ইউনিট পরীক্ষার জন্য পিএইচপি অ্যারে,
- উত্পাদন নিয়ে অ্যামাজন এসকিউএস,
- ডেভ এবং পরীক্ষার পরিবেশের উপর মাইএসকিউএল।
আমার বার্তাগুলি যতটা সহজ সেগুলি সহজ ছিল, আমার অ্যাপ্লিকেশনটি প্রয়োজনীয় তথ্য ( [user_id, reason]) দিয়ে ছোট অ্যারে তৈরি করেছে । মেসেজ স্টোরটি সেই অ্যারের সিরিয়ালাইজড সংস্করণ ছিল (প্রথমে এটি পিএইচপি এর অভ্যন্তরীণ সিরিয়ালাইজেশন ফর্ম্যাট ছিল, তারপরে জেএসওএন, কেন আমি স্যুইচ করেছিলাম তা মনে নেই)। reasonএকটি ধ্রুবক এবং অবশ্যই আমি একটি বড় টেবিল কোথাও যে মানচিত্র নেই reasonপূর্ণাঙ্গ ব্যাখ্যা (আমি রহস্যপূর্ণ সঙ্গে গ্রাহকদের ইমেল 500 সম্পর্কে পাঠাতে পরিচালনা হয়নি reasonপরিবর্তে একবার পূর্ণাঙ্গ বার্তা)।
আরও পড়া
মানক:
সরঞ্জাম:
আকর্ষণীয় পড়া: