🥇 বিতরণকৃত অ্যাপ্লিকেশনের ব্লক তৈরি করা। দ্বিতীয় আনুমানিক

ঘোষণা

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

এটি Erlang/Elixir-এ বিতরণকৃত প্রতিক্রিয়াশীল অ্যাপ্লিকেশনের সিরিজের চূড়ান্ত নিবন্ধ। ভিতরে প্রথম নিবন্ধ আপনি প্রতিক্রিয়াশীল আর্কিটেকচারের তাত্ত্বিক ভিত্তি খুঁজে পেতে পারেন। দ্বিতীয় নিবন্ধ এই ধরনের সিস্টেম নির্মাণের জন্য মৌলিক নিদর্শন এবং প্রক্রিয়াগুলিকে চিত্রিত করে।

আজ আমরা সাধারণভাবে কোড বেস এবং প্রকল্পগুলির বিকাশের সমস্যাগুলি উত্থাপন করব।

সেবা সংস্থা

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

পরিস্থিতি আরও জটিল হয়ে ওঠে যখন আমাদের একটি ত্রুটি-সহনশীল বিতরণ পরিষেবা বাস্তবায়নের প্রয়োজন হয়। আসুন কল্পনা করি যে ব্যবহারকারীদের জন্য প্রয়োজনীয়তা পরিবর্তিত হয়েছে:

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

মন্তব্য: আমরা সামঞ্জস্যপূর্ণ স্টোরেজ এবং ডেটা প্রতিলিপির বিষয়টি বিবেচনা করি না। আসুন ধরে নিই যে এই সমস্যাগুলি আগে সমাধান করা হয়েছে এবং সিস্টেমে ইতিমধ্যে একটি নির্ভরযোগ্য এবং মাপযোগ্য স্টোরেজ স্তর রয়েছে এবং হ্যান্ডলারদের এটির সাথে যোগাযোগ করার ব্যবস্থা রয়েছে।

ব্যবহারকারীদের পরিষেবার আনুষ্ঠানিক বিবরণ আরও জটিল হয়ে উঠেছে। প্রোগ্রামারের দৃষ্টিকোণ থেকে, মেসেজিং ব্যবহারের কারণে পরিবর্তনগুলি ন্যূনতম। প্রথম প্রয়োজন মেটানোর জন্য, আমাদের req-resp এক্সচেঞ্জ পয়েন্টে ভারসাম্য কনফিগার করতে হবে।

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

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

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

নেতা নির্বাচন

বিতরণ ব্যবস্থায়, নেতা নির্বাচন হল কিছু লোডের বিতরণ প্রক্রিয়াকরণের সময়সূচীর জন্য দায়ী একটি একক প্রক্রিয়া নিয়োগের পদ্ধতি।

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

এক্সচেঞ্জ পয়েন্টে শুরু এবং সংযোগ করার পরে, সমস্ত পরিষেবা একটি সিস্টেম বার্তা পায় #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. যদি LeaderPid সঙ্গে সমানুপাতিক pid বর্তমান প্রক্রিয়া, এটি নেতা হিসাবে নিয়োগ করা হয়, এবং তালিকা Servers সমস্ত নোড এবং তাদের পরামিতি অন্তর্ভুক্ত।
এই মুহুর্তে একটি নতুন উপস্থিত হয় এবং একটি কার্যকারী ক্লাস্টার নোড সংযোগ বিচ্ছিন্ন হয়, সমস্ত পরিষেবা নিয়ন্ত্রক গ্রহণ করে #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} যথাক্রমে।

এইভাবে, সমস্ত উপাদান সমস্ত পরিবর্তন সম্পর্কে সচেতন, এবং ক্লাস্টারে যে কোনও সময়ে একজন নেতা থাকার নিশ্চয়তা দেওয়া হয়।

মধ্যস্থতাকারী

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

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

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

আসুন কল্পনা করি যে আমাদের "সংবাদ" বিষয়ের 50000 গ্রাহক রয়েছে। 5 সার্ভার জুড়ে গ্রাহকদের সমানভাবে বিতরণ করা হয়। ফলস্বরূপ, প্রতিটি আপডেট, এক্সচেঞ্জ পয়েন্টে পৌঁছে, 50000 বার প্রতিলিপি করা হবে: প্রতিটি সার্ভারে 10000 বার, এতে থাকা গ্রাহকের সংখ্যা অনুসারে। একটি খুব কার্যকর স্কিম নয়, তাই না?
পরিস্থিতির উন্নতি করতে, আসুন একটি প্রক্সি চালু করি যার নাম বিনিময় পয়েন্টের মতো। গ্লোবাল নেম রেজিস্ট্রার অবশ্যই নাম দ্বারা নিকটতম প্রক্রিয়াটি ফেরত দিতে সক্ষম হবেন, এটি গুরুত্বপূর্ণ।

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

রাউটিং এবং ভারসাম্য

অনুরোধ-প্রতিক্রিয়া

বর্তমান মেসেজিং বাস্তবায়নে, 7টি অনুরোধ বিতরণ কৌশল রয়েছে:

default. অনুরোধটি সমস্ত নিয়ন্ত্রকদের কাছে পাঠানো হয়েছে।
round-robin. অনুরোধগুলি গণনা করা হয় এবং নিয়ন্ত্রকদের মধ্যে চক্রাকারে বিতরণ করা হয়।
consensus. সেবা প্রদানকারী নিয়ন্ত্রকগণ নেতা ও দাসদের মধ্যে বিভক্ত। অনুরোধ পাঠানো হয় শুধুমাত্র নেতার কাছে।
consensus & round-robin. গ্রুপের একজন নেতা আছে, তবে অনুরোধগুলি সমস্ত সদস্যদের মধ্যে বিতরণ করা হয়।
sticky. হ্যাশ ফাংশন গণনা করা হয় এবং একটি নির্দিষ্ট হ্যান্ডলারকে বরাদ্দ করা হয়। এই স্বাক্ষর সহ পরবর্তী অনুরোধগুলি একই হ্যান্ডলারের কাছে যায়।
sticky-fun. বিনিময় পয়েন্ট আরম্ভ করার সময়, হ্যাশ গণনা ফাংশন জন্য sticky ভারসাম্য
fun. স্টিকি-মজার অনুরূপ, শুধুমাত্র আপনি অতিরিক্তভাবে এটিকে পুনঃনির্দেশ, প্রত্যাখ্যান বা পূর্ব-প্রক্রিয়া করতে পারেন।

বন্টন কৌশল সেট করা হয় যখন বিনিময় পয়েন্ট আরম্ভ করা হয়।

ব্যালেন্সিং ছাড়াও, মেসেজিং আপনাকে সত্তা ট্যাগ করতে দেয়। আসুন সিস্টেমে ট্যাগগুলির ধরন দেখি:

সংযোগ ট্যাগ। ঘটনাগুলো কোন সংযোগের মাধ্যমে এসেছে তা আপনাকে বুঝতে দেয়। যখন একটি কন্ট্রোলার প্রক্রিয়া একই এক্সচেঞ্জ পয়েন্টের সাথে সংযোগ করে, কিন্তু বিভিন্ন রাউটিং কী সহ ব্যবহৃত হয়।
সেবা ট্যাগ. আপনাকে একটি পরিষেবার জন্য হ্যান্ডলারদেরকে গ্রুপে একত্রিত করতে এবং রাউটিং এবং ভারসাম্যের ক্ষমতা প্রসারিত করার অনুমতি দেয়। req-resp প্যাটার্নের জন্য, রাউটিং লিনিয়ার। আমরা এক্সচেঞ্জ পয়েন্টে একটি অনুরোধ পাঠাই, তারপর এটি পরিষেবাতে প্রেরণ করে। কিন্তু যদি আমাদের হ্যান্ডলারদের লজিক্যাল গ্রুপে বিভক্ত করতে হয়, তাহলে ট্যাগ ব্যবহার করে বিভক্ত করা হয়। একটি ট্যাগ নির্দিষ্ট করার সময়, অনুরোধটি নিয়ন্ত্রকদের একটি নির্দিষ্ট গ্রুপে পাঠানো হবে।
অনুরোধ ট্যাগ. আপনাকে উত্তরগুলির মধ্যে পার্থক্য করার অনুমতি দেয়। যেহেতু আমাদের সিস্টেম অ্যাসিঙ্ক্রোনাস, পরিষেবা প্রতিক্রিয়া প্রক্রিয়া করার জন্য আমাদের একটি অনুরোধ পাঠানোর সময় একটি RequestTag নির্দিষ্ট করতে সক্ষম হতে হবে। এটি থেকে আমরা বুঝতে সক্ষম হব যে আমাদের কাছে কোন অনুরোধের উত্তর এসেছে।

পাব-সাব

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

মাপযোগ্যতা এবং দোষ সহনশীলতা

সামগ্রিকভাবে সিস্টেমের মাপযোগ্যতা সিস্টেমের স্তর এবং উপাদানগুলির মাপযোগ্যতার ডিগ্রির উপর নির্ভর করে:

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

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

রিজার্ভেশন

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

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

উৎপাদনশীলতা

আসুন অন্তত মোটামুটিভাবে rabbitmq এবং আমাদের কাস্টম মেসেজিং এর কর্মক্ষমতা তুলনা করার চেষ্টা করি।
আমি খুঁজে পেয়েছি অফিসিয়াল ফলাফল Openstack টিম থেকে rabbitmq পরীক্ষা।

অনুচ্ছেদে 6.14.1.2.1.2.2। মূল নথি RPC CAST এর ফলাফল দেখায়:

আমরা OS কার্নেল বা erlang VM-এ আগে থেকে কোনো অতিরিক্ত সেটিংস করব না। পরীক্ষার জন্য শর্ত:

erl opts: +A1 +sbtu।
একটি একক এরল্যাং নোডের মধ্যে পরীক্ষাটি মোবাইল সংস্করণে একটি পুরানো i7 সহ একটি ল্যাপটপে চালানো হয়।
ক্লাস্টার পরীক্ষা একটি 10G নেটওয়ার্কের সাথে সার্ভারে করা হয়।
কোডটি ডকার পাত্রে চলে। NAT মোডে নেটওয়ার্ক।

পরীক্ষার কোড:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

দৃশ্যকল্প 1: পরীক্ষাটি একটি পুরানো i7 মোবাইল সংস্করণ সহ একটি ল্যাপটপে চালানো হয়। পরীক্ষা, বার্তাপ্রেরণ এবং পরিষেবা একটি ডকার পাত্রে একটি নোডে কার্যকর করা হয়:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

দৃশ্যপট 2: ডকার (NAT) এর অধীনে বিভিন্ন মেশিনে 3টি নোড চলছে।

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

সব ক্ষেত্রে, CPU ব্যবহার 250% এর বেশি হয়নি

ফলাফল

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

ফটোগ্রাফি @ছুটারস্ন্যাপ

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

VTrade এক্সপেরিমেন্ট সিরিজের অংশ হিসাবে আমার আরও বিস্তারিতভাবে কোন বিষয়গুলি কভার করা উচিত?

তত্ত্ব: বাজার, অর্ডার এবং তাদের সময়: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
আদেশের বই। গ্রুপিং সহ একটি বই বাস্তবায়নের তত্ত্ব এবং অনুশীলন
ট্রেডিং এর ভিজ্যুয়ালাইজেশন: টিক, বার, রেজোলিউশন। কিভাবে সংরক্ষণ এবং কিভাবে আঠালো
ব্যাকঅফিস। পরিকল্পনা ও উন্নয়ন। কর্মচারী পর্যবেক্ষণ এবং ঘটনা তদন্ত
API আসুন জেনে নেই কী কী ইন্টারফেস প্রয়োজন এবং কীভাবে সেগুলি বাস্তবায়ন করা যায়
তথ্য স্টোরেজ: পোস্টগ্রেএসকিউএল, টাইমস্কেল, ট্রেডিং সিস্টেমে ট্যারান্টুল
ট্রেডিং সিস্টেমে প্রতিক্রিয়াশীলতা
অন্যান্য আমি মন্তব্যে লিখব