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

এটি একটি শক্তিশালী, উচ্চ-লোড সিস্টেম তৈরি করার জন্য আমাদের কাঁটাযুক্ত পথ সম্পর্কে একটি দীর্ঘ গল্পের ধারাবাহিকতা যা এক্সচেঞ্জের কার্যকারিতা নিশ্চিত করে। প্রথম অংশ এখানে: habr.com/en/post/444300

রহস্যময় ত্রুটি

অনেক পরীক্ষার পর, আপডেট করা ট্রেডিং এবং ক্লিয়ারিং সিস্টেম চালু করা হয়েছিল, এবং আমরা একটি বাগের সম্মুখীন হয়েছি যার সম্পর্কে আমরা একটি গোয়েন্দা-অতীন্দ্রিয় গল্প লিখতে পারি।

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

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

ত্রুটির কারণ খুঁজে পাওয়া যায়নি.

তারপর তারা হার্ডওয়্যার পরীক্ষা করা শুরু করে: তারা প্রসেসরের লোড পরীক্ষা চালায়; RAM চেক করা হয়েছে; এমনকি আমরা একটি কক্ষে মাল্টি-বিট ত্রুটির খুব অসম্ভাব্য দৃশ্যের জন্য পরীক্ষা চালিয়েছি। কোন লাভ হয়নি।

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

যেহেতু এটি ব্যর্থতার কারণ খুঁজে পাওয়া সম্ভব ছিল না, তাই "আপত্তিকর" সার্ভারটি অপারেশন থেকে সরানো হয়েছে শুধুমাত্র ক্ষেত্রে।

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

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

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

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

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

সিস্টেমের আরও উন্নয়ন

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

নিম্নলিখিত নীতিগুলি সংরক্ষণ ব্যবস্থার পরবর্তী উন্নতির ভিত্তি তৈরি করেছে:

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

বাজারে উপলব্ধ কোনো সমাধানই আমাদের উপযোগী করেনি, এবং রাফ্ট প্রোটোকল এখনও তার শৈশবকালে ছিল, তাই আমরা আমাদের নিজস্ব সমাধান তৈরি করেছি।

নেটওয়ার্কিং

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

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

লেনদেন সম্পন্ন হচ্ছে

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

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

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

সাধারণভাবে, ঝুঁকি চেকিং সিস্টেমে জটিল অ্যালগরিদম থাকে এবং এটি প্রচুর পরিমাণে খুব সম্পদ-নিবিড় গণনা করে এবং শুধুমাত্র "অ্যাকাউন্ট ব্যালেন্স" চেক করে না, যেমনটি প্রথম নজরে মনে হতে পারে।

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

কোডের একটি ছোট অভিযোজনের পরে, আমরা সমান্তরাল লেনদেন প্রক্রিয়াকরণের জন্য একটি পাইপলাইন তৈরি করেছি, যেখানে লেনদেনটি পাইপলাইনের 4টি পর্যায়ে বিভক্ত ছিল: নেটওয়ার্ক মিথস্ক্রিয়া, বৈধতা, সম্পাদন এবং ফলাফল প্রকাশ

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

এভাবেই আমরা ASTS+ সিস্টেম নিয়ে এসেছি।

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

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

• সমস্ত আগত নেটওয়ার্ক প্যাকেট বরাদ্দ পর্যায়ে প্রবেশ করে।
• আমরা সেগুলিকে একটি অ্যারেতে রাখি এবং সেগুলিকে ধাপ #1 এর জন্য উপলব্ধ হিসাবে চিহ্নিত করি৷
• দ্বিতীয় লেনদেন এসেছে, এটি আবার মঞ্চ নং 1 এর জন্য উপলব্ধ।
• প্রথম প্রসেসিং থ্রেড উপলব্ধ লেনদেনগুলি দেখে, সেগুলিকে প্রসেস করে এবং সেগুলিকে দ্বিতীয় প্রসেসিং থ্রেডের পরবর্তী পর্যায়ে নিয়ে যায়৷
• এটি তারপর প্রথম লেনদেন প্রক্রিয়া করে এবং সংশ্লিষ্ট কক্ষকে ফ্ল্যাগ করে deleted - এটি এখন নতুন ব্যবহারের জন্য উপলব্ধ।

সম্পূর্ণ সারি এই ভাবে প্রক্রিয়া করা হয়.

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

ফলস্বরূপ, আমরা প্রতি সেকেন্ডে প্রায় 8 মিলিয়ন লেনদেনের কার্যক্ষমতা অর্জন করেছি। এবং আক্ষরিক অর্থে দুই মাস পরে প্রবন্ধ LMAX Disruptor সম্পর্কে আমরা একই কার্যকারিতা সহ একটি সার্কিটের বর্ণনা দেখেছি।

এখন এক পর্যায়ে মৃত্যুদণ্ডের বেশ কয়েকটি থ্রেড থাকতে পারে। সমস্ত লেনদেন একের পর এক প্রক্রিয়া করা হয়েছিল, যে ক্রমে তারা প্রাপ্ত হয়েছিল। ফলস্বরূপ, সর্বোচ্চ কর্মক্ষমতা প্রতি সেকেন্ডে 18 হাজার থেকে 50 হাজার লেনদেন বেড়েছে।

বিনিময় ঝুঁকি ব্যবস্থাপনা সিস্টেম

পরিপূর্ণতার কোন সীমা নেই, এবং শীঘ্রই আমরা আবার আধুনিকীকরণ শুরু করেছি: ASTS+ এর কাঠামোর মধ্যে, আমরা ঝুঁকি ব্যবস্থাপনা এবং সেটেলমেন্ট অপারেশন সিস্টেমগুলিকে স্বায়ত্তশাসিত উপাদানগুলিতে স্থানান্তর করতে শুরু করেছি। আমরা একটি নমনীয় আধুনিক স্থাপত্য এবং একটি নতুন শ্রেণিবিন্যাসের ঝুঁকি মডেল তৈরি করেছি এবং যেখানেই সম্ভব ক্লাসটি ব্যবহার করার চেষ্টা করেছি fixed_point পরিবর্তে double.

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

একটি নতুন সিস্টেম নির্বাচন করার সময়, আমাদের অবিলম্বে মিথস্ক্রিয়া সমস্যার সমাধান করতে হয়েছিল। একটি ডাটা বাস নির্বাচন করার সময়, এটি স্থিতিশীল জিটার এবং ন্যূনতম বিলম্বিতা নিশ্চিত করা প্রয়োজন ছিল। InfiniBand RDMA নেটওয়ার্ক এর জন্য সবচেয়ে উপযুক্ত ছিল: গড় প্রক্রিয়াকরণ সময় 4 G ইথারনেট নেটওয়ার্কের তুলনায় 10 গুণ কম। কিন্তু যা সত্যিই আমাদের মোহিত করেছিল তা হল শতাংশের পার্থক্য - 99 এবং 99,9।

অবশ্যই, InfiniBand এর চ্যালেঞ্জ আছে। প্রথমত, একটি ভিন্ন API - সকেটের পরিবর্তে ibverbs। দ্বিতীয়ত, ওপেন সোর্স মেসেজিং সলিউশন প্রায় নেই বললেই চলে। আমরা আমাদের নিজস্ব প্রোটোটাইপ তৈরি করার চেষ্টা করেছি, কিন্তু এটি খুব কঠিন বলে প্রমাণিত হয়েছে, তাই আমরা একটি বাণিজ্যিক সমাধান বেছে নিয়েছি - কনফিনিটি লো লেটেন্সি মেসেজিং (পূর্বে IBM MQ LLM)।

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

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

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

দ্বিত্ব

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

একটি ব্যাকআপ ডেটা সেন্টারের সাথে কাজ করা

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

ফলাফল

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

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

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

আমরা আমাদের প্ল্যাটফর্মের বর্তমান সংস্করণটিকে Rebus বলেছি - স্থাপত্যের সবচেয়ে লক্ষণীয় দুটি উদ্ভাবনের সংক্ষিপ্ত রূপ, রিস্ক ইঞ্জিন এবং BUS।

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

আমরা শেষ পর্যন্ত যা অর্জন করেছি:

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

সর্বোচ্চ কর্মক্ষমতা প্রতি সেকেন্ডে 50 হাজার থেকে 180 হাজার লেনদেন বেড়েছে। অর্ডার মিলের একমাত্র প্রবাহ দ্বারা আরও বৃদ্ধি বাধাগ্রস্ত হয়।

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

অবশেষে, যারা এন্টারপ্রাইজ সিস্টেম চূড়ান্ত করছেন তাদের আমি কিছু পরামর্শ দিতে পারি:

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

উত্স: www.habr.com