মস্কো এক্সচেঞ্জের ট্রেডিং এবং ক্লিয়ারিং সিস্টেমের আর্কিটেকচারের বিবর্তন। অংশ 1

হাই সব! আমার নাম সের্গেই কোস্তানবায়েভ, এক্সচেঞ্জে আমি ট্রেডিং সিস্টেমের মূল বিকাশ করছি।

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

আমরা বিশ্বের কয়েকটি এক্সচেঞ্জের মধ্যে একটি যা সমস্ত শ্রেণীর সম্পদের লেনদেন করে এবং সম্পূর্ণ পরিসরের বিনিময় পরিষেবা প্রদান করে। উদাহরণস্বরূপ, গত বছর আমরা বন্ড ট্রেডিং ভলিউমের ক্ষেত্রে বিশ্বে দ্বিতীয় স্থানে, সমস্ত স্টক এক্সচেঞ্জের মধ্যে 25তম স্থান, পাবলিক এক্সচেঞ্জের মধ্যে মূলধনের ক্ষেত্রে 13তম স্থানে।

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

ইতিহাসের একটি বিট

1994 সালে, অস্ট্রেলিয়ান ASTS সিস্টেমটি মস্কো ইন্টারব্যাঙ্ক কারেন্সি এক্সচেঞ্জে (MICEX) চালু করা হয়েছিল এবং সেই মুহুর্ত থেকে ইলেকট্রনিক ট্রেডিংয়ের রাশিয়ান ইতিহাস গণনা করা যেতে পারে। 1998 সালে, ইন্টারনেট ট্রেডিং চালু করার জন্য এক্সচেঞ্জ আর্কিটেকচারকে আধুনিকীকরণ করা হয়েছিল। তারপর থেকে, সমস্ত সিস্টেম এবং সাবসিস্টেমগুলিতে নতুন সমাধান এবং স্থাপত্য পরিবর্তনগুলি বাস্তবায়নের গতি কেবল গতি পাচ্ছে।

সেই বছরগুলিতে, এক্সচেঞ্জ সিস্টেমটি হাই-এন্ড হার্ডওয়্যারে কাজ করেছিল - অতি-নির্ভরযোগ্য এইচপি সুপারডোম 9000 সার্ভার (নির্মিত পিএ-আরআইএসসি), যেখানে একেবারে সবকিছু সদৃশ ছিল: ইনপুট/আউটপুট সাবসিস্টেম, নেটওয়ার্ক, RAM (আসলে, RAM এর একটি RAID অ্যারে ছিল), প্রসেসর (হট-অদলবদলযোগ্য)। মেশিন বন্ধ না করেই সার্ভারের যেকোনো উপাদান পরিবর্তন করা সম্ভব ছিল। আমরা এই ডিভাইসগুলির উপর নির্ভর করেছি এবং সেগুলিকে কার্যত ব্যর্থ-নিরাপদ বলে মনে করেছি। অপারেটিং সিস্টেমটি ছিল ইউনিক্সের মতো এইচপি ইউএক্স সিস্টেম।

কিন্তু প্রায় 2010 সাল থেকে, উচ্চ-ফ্রিকোয়েন্সি ট্রেডিং (HFT), বা উচ্চ-ফ্রিকোয়েন্সি ট্রেডিং - সহজভাবে বলতে গেলে, স্টক এক্সচেঞ্জ রোবট নামে একটি ঘটনা আবির্ভূত হয়েছে। মাত্র 2,5 বছরে, আমাদের সার্ভারে লোড 140 গুণ বেড়েছে।

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

Начало

এক্সচেঞ্জ সিস্টেমের অনুরোধ দুটি প্রকারে বিভক্ত করা যেতে পারে:

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

পরিকল্পিতভাবে, সিস্টেমের মূল তিনটি স্তরে বিভক্ত করা যেতে পারে:

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

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

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

সিস্টেমের প্রথম সংস্করণে গেটওয়ের দুটি স্তর এবং ট্রেডিং সিস্টেমের একটি কেন্দ্রীয় সার্ভার রয়েছে। কাজের প্রবাহ এই মত ছিল:

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

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

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

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

SystemV IPC-তে সারি, মেমরি এবং সেমাফোর অবজেক্টের অবস্থা দেখার জন্য ইউটিলিটিগুলি অন্তর্ভুক্ত রয়েছে। একটি নির্দিষ্ট মুহুর্তে সিস্টেমে কী ঘটছে, কোথায় প্যাকেট জমা হয়েছে, কী ব্লক করা হয়েছে ইত্যাদি বুঝতে আমরা সক্রিয়ভাবে এটি ব্যবহার করেছি।

প্রথম আপগ্রেড

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

উচ্চ ফ্রিকোয়েন্সি ট্রেডিং এর প্রভাব

স্থাপত্যের উপরের সংস্করণটি 2010 সাল পর্যন্ত বিদ্যমান ছিল। এদিকে, আমরা আর HP সুপারডোম সার্ভারের কর্মক্ষমতা নিয়ে সন্তুষ্ট ছিলাম না। উপরন্তু, PA-RISC আর্কিটেকচার কার্যত মৃত ছিল; বিক্রেতা কোন উল্লেখযোগ্য আপডেট অফার করেনি। ফলস্বরূপ, আমরা HP UX/PA RISC থেকে Linux/x86-এ যেতে শুরু করি। এক্সেস সার্ভারগুলির অভিযোজনের মাধ্যমে রূপান্তরটি শুরু হয়েছিল।

কেন আমাদের আবার স্থাপত্য বদলাতে হলো? আসল বিষয়টি হল যে উচ্চ-ফ্রিকোয়েন্সি ট্রেডিং সিস্টেম কোরের লোড প্রোফাইলকে উল্লেখযোগ্যভাবে পরিবর্তন করেছে।

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

এই 50 ms ব্যবধানে, গড় গতি প্রতি সেকেন্ডে প্রায় 16 হাজার লেনদেন হয়। যদি আমরা উইন্ডোটিকে 20 ms-এ কমিয়ে দেই, তাহলে আমরা প্রতি সেকেন্ডে 90 হাজার লেনদেনের গড় গতি পাব, যেখানে সর্বোচ্চ 200 হাজার লেনদেন হয়। অন্য কথায়, লোড ধ্রুবক নয়, হঠাৎ বিস্ফোরণ সহ। এবং অনুরোধের সারি সবসময় দ্রুত প্রক্রিয়া করা আবশ্যক.

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

বিবর্তনের একটি নতুন রাউন্ড

ব্যাপক পরীক্ষা এবং গবেষণার পর, আমরা রিয়েল-টাইম অপারেটিং সিস্টেম কার্নেলে স্যুইচ করেছি। এর জন্য আমরা RedHat Enterprise MRG Linux বেছে নিয়েছি, যেখানে MRG মানে মেসেজিং রিয়েল-টাইম গ্রিড। রিয়েল-টাইম প্যাচগুলির সুবিধা হল যে তারা দ্রুততম সম্ভব কার্যকর করার জন্য সিস্টেমটিকে অপ্টিমাইজ করে: সমস্ত প্রক্রিয়াগুলি একটি FIFO সারিতে সারিবদ্ধ, কোরগুলিকে বিচ্ছিন্ন করা যেতে পারে, কোনও ইজেকশন নেই, সমস্ত লেনদেন কঠোর ক্রমানুসারে প্রক্রিয়া করা হয়।

লাল - একটি নিয়মিত কার্নেলে একটি সারির সাথে কাজ করা, সবুজ - একটি রিয়েল-টাইম কার্নেলে কাজ করা।

কিন্তু নিয়মিত সার্ভারে কম লেটেন্সি অর্জন করা এত সহজ নয়:

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

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

PA-RISC সার্ভার থেকে x86 এ যাওয়ার সময়, আমাদের কার্যত সিস্টেম কোডটি খুব বেশি পরিবর্তন করতে হয়নি, আমরা কেবল এটিকে অভিযোজিত এবং পুনরায় কনফিগার করেছি। একই সময়ে, আমরা বেশ কয়েকটি বাগ সংশোধন করেছি। উদাহরণস্বরূপ, PA RISC একটি বিগ এন্ডিয়ান সিস্টেম ছিল এবং x86 একটি লিটল এন্ডিয়ান সিস্টেম ছিল তার পরিণতিগুলি দ্রুত প্রকাশ পেয়েছে: উদাহরণস্বরূপ, ডেটা ভুলভাবে পড়া হয়েছিল। জটিল বাগটি ছিল যা PA RISC ব্যবহার করে ধারাবাহিকভাবে সামঞ্জস্যপূর্ণ (ধারাবাহিকভাবে সামঞ্জস্যপূর্ণ) মেমরি অ্যাক্সেস, যেখানে x86 রিড ক্রিয়াকলাপগুলিকে পুনরায় সাজাতে পারে, তাই কোড যা একটি প্ল্যাটফর্মে একেবারে বৈধ ছিল অন্যটিতে ভেঙে গেছে।

x86-এ স্যুইচ করার পরে, কার্যক্ষমতা প্রায় তিনগুণ বেড়েছে, গড় লেনদেন প্রক্রিয়াকরণের সময় কমেছে 60 μs।

আসুন এখন সিস্টেম আর্কিটেকচারে কী কী পরিবর্তন করা হয়েছে তা ঘনিষ্ঠভাবে দেখে নেওয়া যাক।

হট রিজার্ভ মহাকাব্য

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

এছাড়াও, অন্যান্য প্রয়োজনীয়তা ছিল:

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

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

ফলস্বরূপ, আমরা নিম্নলিখিত স্কিমে এসেছি:

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

  

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

স্কিমটি নিম্নরূপ কাজ করেছে।

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

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

অবিরত করা।

উত্স: www.habr.com