নিবন্ধটির অনুবাদ: দূত থ্রেডিং মডেল - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

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

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

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

থ্রেডিং ওভারভিউ

দূত তিনটি ভিন্ন ধরনের স্ট্রিম ব্যবহার করে:

• প্রধান: এই থ্রেডটি প্রক্রিয়া শুরু এবং সমাপ্তি নিয়ন্ত্রণ করে, XDS (xDiscovery Service) API-এর সমস্ত প্রক্রিয়াকরণ, যার মধ্যে DNS, স্বাস্থ্য পরীক্ষা, সাধারণ ক্লাস্টার এবং রানটাইম ব্যবস্থাপনা, পরিসংখ্যান রিসেট, প্রশাসন এবং সাধারণ প্রক্রিয়া পরিচালনা - লিনাক্স সংকেত। হট রিস্টার্ট ইত্যাদি সবকিছু। এই থ্রেডে ঘটে অসিঙ্ক্রোনাস এবং "নন-ব্লকিং"। সাধারণভাবে, প্রধান থ্রেড সমস্ত গুরুত্বপূর্ণ কার্যকারিতা প্রক্রিয়াগুলিকে সমন্বয় করে যেগুলি চালানোর জন্য প্রচুর পরিমাণে CPU প্রয়োজন হয় না। এটি বেশিরভাগ নিয়ন্ত্রণ কোডকে এমনভাবে লেখার অনুমতি দেয় যেন এটি একক থ্রেডেড।
• কর্মী: ডিফল্টরূপে, দূত সিস্টেমে প্রতিটি হার্ডওয়্যার থ্রেডের জন্য একটি কর্মী থ্রেড তৈরি করে, এটি বিকল্পটি ব্যবহার করে নিয়ন্ত্রণ করা যেতে পারে --concurrency. প্রতিটি কর্মী থ্রেড একটি "নন-ব্লকিং" ইভেন্ট লুপ চালায়, যা প্রতিটি শ্রোতার কথা শোনার জন্য দায়ী; লেখার সময় (জুলাই 29, 2017) শ্রোতার কোন অংশ নেই, নতুন সংযোগ গ্রহণ করা, একটি ফিল্টার স্ট্যাক ইনস্ট্যান্টিয়েটিং সংযোগ, এবং সংযোগের জীবদ্দশায় সমস্ত ইনপুট/আউটপুট (IO) অপারেশন প্রক্রিয়াকরণ। আবার, এটি বেশিরভাগ সংযোগ হ্যান্ডলিং কোড লেখার অনুমতি দেয় যেন এটি একক থ্রেডেড।
• ফাইল ফ্লাশার: প্রতিটি ফাইল যা এনভয় লেখেন, প্রধানত লগ অ্যাক্সেস করেন, বর্তমানে একটি স্বাধীন ব্লকিং থ্রেড রয়েছে। এটি ব্যবহার করার সময়ও ফাইল সিস্টেম দ্বারা ক্যাশে করা ফাইলগুলিতে লেখার কারণে O_NONBLOCK কখনও কখনও অবরুদ্ধ হতে পারে (দীর্ঘশ্বাস)। যখন কর্মী থ্রেডগুলিকে একটি ফাইলে লেখার প্রয়োজন হয়, তখন ডেটা আসলে মেমরির একটি বাফারে সরানো হয় যেখানে এটি শেষ পর্যন্ত থ্রেডের মাধ্যমে ফ্লাশ করা হয় ফাইল ফ্লাশ. এটি কোডের একটি ক্ষেত্র যেখানে প্রযুক্তিগতভাবে সমস্ত কর্মী থ্রেড মেমরি বাফার পূরণ করার চেষ্টা করার সময় একই লক ব্লক করতে পারে।

সংযোগ হ্যান্ডলিং

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

এটির বেশ কয়েকটি গুরুত্বপূর্ণ পরিণতি রয়েছে:

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

নন-ব্লকিং মানে কি?

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

দূত বেশ কয়েকটি দীর্ঘ প্রক্রিয়া লক ব্যবহার করে:

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

থ্রেড স্থানীয় স্টোরেজ

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


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

দূতের TLS (থ্রেড লোকাল স্টোরেজ) সিস্টেম নিম্নরূপ কাজ করে:

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

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

দূত এটি দুটি ভিন্ন উপায়ে ব্যবহার করে:

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

ক্লাস্টার আপডেট থ্রেডিং

এই বিভাগে, আমি বর্ণনা করব কিভাবে একটি ক্লাস্টার পরিচালনা করতে TLS (থ্রেড লোকাল স্টোরেজ) ব্যবহার করা হয়। ক্লাস্টার ব্যবস্থাপনায় xDS API এবং/অথবা DNS প্রক্রিয়াকরণ, সেইসাথে স্বাস্থ্য পরীক্ষা অন্তর্ভুক্ত রয়েছে।


ক্লাস্টার প্রবাহ ব্যবস্থাপনা নিম্নলিখিত উপাদান এবং পদক্ষেপ অন্তর্ভুক্ত:

1. ক্লাস্টার ম্যানেজার হল দূতের মধ্যে একটি উপাদান যা সমস্ত পরিচিত ক্লাস্টার আপস্ট্রিম, ক্লাস্টার ডিসকভারি সার্ভিস (সিডিএস) এপিআই, সিক্রেট ডিসকভারি সার্ভিস (এসডিএস) এবং এন্ডপয়েন্ট ডিসকভারি সার্ভিস (ইডিএস) এপিআই, ডিএনএস, এবং সক্রিয় বাহ্যিক পরীক্ষা পরিচালনা করে। স্বাস্থ্য পরীক্ষা। এটি প্রতিটি আপস্ট্রিম ক্লাস্টারের একটি "অবশেষে সামঞ্জস্যপূর্ণ" দৃষ্টিভঙ্গি তৈরি করার জন্য দায়ী, যার মধ্যে আবিষ্কৃত হোস্টের পাশাপাশি স্বাস্থ্যের অবস্থা অন্তর্ভুক্ত রয়েছে।
2. স্বাস্থ্য পরীক্ষক একটি সক্রিয় স্বাস্থ্য পরীক্ষা করে এবং ক্লাস্টার ম্যানেজারের কাছে স্বাস্থ্যের অবস্থার পরিবর্তনগুলি রিপোর্ট করে।
3. CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS ক্লাস্টার সদস্যপদ নির্ধারণের জন্য সঞ্চালিত হয়। রাজ্য পরিবর্তন ক্লাস্টার ম্যানেজারের কাছে ফেরত দেওয়া হয়।
4. প্রতিটি কর্মী থ্রেড ক্রমাগত একটি ইভেন্ট লুপ চালায়।
5. যখন ক্লাস্টার ম্যানেজার নির্ধারণ করে যে ক্লাস্টারের অবস্থা পরিবর্তিত হয়েছে, তখন এটি ক্লাস্টারের অবস্থার একটি নতুন পঠনযোগ্য স্ন্যাপশট তৈরি করে এবং প্রতিটি কর্মী থ্রেডে পাঠায়।
6. পরবর্তী শান্ত সময়ের মধ্যে, কর্মী থ্রেড বরাদ্দকৃত TLS স্লটে স্ন্যাপশট আপডেট করবে।
7. একটি I/O ইভেন্টের সময় যা হোস্টকে ব্যালেন্স লোড করার জন্য নির্ধারণ করার কথা, লোড ব্যালেন্সার হোস্ট সম্পর্কে তথ্য পাওয়ার জন্য একটি TLS (থ্রেড লোকাল স্টোরেজ) স্লটের অনুরোধ করবে। এর জন্য তালার প্রয়োজন নেই। এছাড়াও নোট করুন যে TLS আপডেট ইভেন্টগুলিকেও ট্রিগার করতে পারে যাতে লোড ব্যালেন্সার এবং অন্যান্য উপাদানগুলি ক্যাশে, ডেটা স্ট্রাকচার ইত্যাদি পুনঃগণনা করতে পারে। এটি এই পোস্টের সুযোগের বাইরে, কিন্তু কোডের বিভিন্ন জায়গায় ব্যবহার করা হয়।

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

অন্যান্য সাবসিস্টেম যা TLS ব্যবহার করে

TLS (থ্রেড লোকাল স্টোরেজ) এবং RCU (Read Copy Update) এনভয়-এ ব্যাপকভাবে ব্যবহৃত হয়।

ব্যবহারের উদাহরণ:

• কার্যকর করার সময় কার্যকারিতা পরিবর্তন করার প্রক্রিয়া: সক্রিয় কার্যকারিতার বর্তমান তালিকা মূল থ্রেডে গণনা করা হয়। RCU শব্দার্থবিদ্যা ব্যবহার করে প্রতিটি কর্মী থ্রেডকে একটি শুধুমাত্র পঠনযোগ্য স্ন্যাপশট দেওয়া হয়।
• রুট টেবিল প্রতিস্থাপন: RDS (রুট ডিসকভারি সার্ভিস) দ্বারা প্রদত্ত রুট টেবিলগুলির জন্য, রুট টেবিলগুলি মূল থ্রেডে তৈরি করা হয়। RCU (Read Copy Update) শব্দার্থবিদ্যা ব্যবহার করে প্রতিটি কর্মী থ্রেডকে পরবর্তীতে শুধুমাত্র পঠনযোগ্য স্ন্যাপশট প্রদান করা হবে। এটি রুট টেবিল পরিবর্তনকে পারমাণবিকভাবে দক্ষ করে তোলে।
• HTTP হেডার ক্যাশিং: দেখা যাচ্ছে, প্রতিটি অনুরোধের জন্য HTTP শিরোনাম গণনা করা (কোর প্রতি ~25K+ RPS চলাকালীন) বেশ ব্যয়বহুল। দূত কেন্দ্রীয়ভাবে প্রায় প্রতি অর্ধ সেকেন্ডে শিরোনামটি গণনা করে এবং এটি TLS এবং RCU এর মাধ্যমে প্রতিটি কর্মীকে প্রদান করে।

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

পরিচিত কর্মক্ষমতা ক্ষতি

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

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

উপসংহার

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

কোড লিঙ্ক

এই পোস্টে আলোচনা করা ইন্টারফেস এবং হেডার বাস্তবায়ন সহ ফাইলগুলির লিঙ্ক:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

উত্স: www.habr.com