কীভাবে উদ্বেগ বন্ধ করবেন এবং মনোলিথ ছাড়াই জীবনযাপন শুরু করবেন

আমরা সবাই গল্প ভালোবাসি। আমরা আগুনের চারপাশে বসে আমাদের অতীত বিজয়, যুদ্ধ, বা কেবল আমাদের কাজের অভিজ্ঞতা সম্পর্কে কথা বলতে পছন্দ করি।

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

একসময়, আমাদের কোম্পানির কয়েকটি "মনোলিথ" এবং সবার জন্য একটি "সিলিং" ছিল, যার কাছে এই মনোলিথগুলি ধীরে ধীরে কিন্তু নিশ্চিতভাবে এগিয়ে আসছে, আমাদের কোম্পানির ফ্লাইট, আমাদের বিকাশকে সীমিত করে। এবং একটি স্পষ্ট বোঝা ছিল: একদিন আমরা এই সিলিংকে শক্তভাবে আঘাত করব।

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

আজ, CI/CD, K8S, ইত্যাদির আকারে পরিবর্তন করার জন্য প্রচুর সরঞ্জাম এবং সরঞ্জাম রয়েছে। "মনোলিথিক" সময়ে, আমাদের এতগুলি বিদেশী শব্দের প্রয়োজন ছিল না। ডাটাবেসের "স্টোরেজ" সংশোধন করার জন্য এটি যথেষ্ট ছিল।

কিন্তু সময় এগিয়ে গেল, এবং অনুরোধের সংখ্যাও এর সাথে এগিয়ে গেল, কখনও কখনও আমাদের সামর্থ্যের বাইরে আরপিএসকে গুলি করে। বাজারে সিআইএস দেশগুলির প্রবেশের সাথে সাথে, প্রথম মনোলিথের ডাটাবেস প্রসেসরের লোড 90% এর নিচে পড়েনি, এবং আরপিএস 2400-এর স্তরে রয়ে গেছে। এবং এগুলি কেবল ছোট নির্বাচকই ছিল না, বরং মোটা প্রশ্ন ছিল চেক এবং যোগদানের গুচ্ছ যা বড় IO এর পটভূমিতে প্রায় অর্ধেক ডেটা চলতে পারে।

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

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

বিভিন্ন ইভেন্টে আমি বলি: "যদি আপনি একটি মনোলিথ না দেখে থাকেন তবে আপনি বড় হননি!" আমি এই বিষয়ে আপনার মতামত আগ্রহী, মন্তব্যে এটি লিখুন.

আ সাউন্ড অফ থান্ডার

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

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

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

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

ফলস্বরূপ, আমরা একটি স্কিম নিয়ে এসেছি যা ট্যারান্টুলের সাথে ভালভাবে ফিট করে।

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

স্থাপত্য। বিকল্প 1. ব্যবহারকারী পরিষেবা

বর্তমান সময়ে, 24টি শার্ড রয়েছে, যার প্রতিটিতে 2টি দৃষ্টান্ত রয়েছে (প্রতিটি ডিসির জন্য একটি), সমস্তই মাস্টার-মাস্টার মোডে।

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

এই ক্ষেত্রে, শার্ডের প্রসঙ্গে প্রতিরূপ নির্বাচন নীতি কনফিগার করা সম্ভব। উদাহরণস্বরূপ, রাউন্ডরবিন।

স্থাপত্য। বিকল্প 2. পণ্যের চূড়ান্ত মূল্য গণনার জন্য পরিষেবা

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

পরিষেবা ডাটাবেস 4টি মাস্টার নিয়ে গঠিত যার মধ্যে সিঙ্ক্রোনাইজার ডেটা সংগ্রহ করে এবং এই প্রতিলিপি মাস্টারদের প্রত্যেকটি শুধুমাত্র পঠনযোগ্য প্রতিলিপিতে ডেটা বিতরণ করে। প্রতিটি মাস্টারের প্রায় 15টি প্রতিলিপি রয়েছে।

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

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

অনুসন্ধান এবং খুঁজে!

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

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

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

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

শেষ পর্যন্ত আমরা ট্যারান্টুলে বসতি স্থাপন করলাম।

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

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

বাস্তবায়ন একটি রুক্ষ শুরু বন্ধ পেয়েছিলাম

সেই সময়ে, আমাদের প্রধান ডেভেলপমেন্ট স্ট্যাক ছিল .NET, যার সাথে Tarantool এর জন্য কোন সংযোগকারী ছিল না। আমরা সাথে সাথে গো-তে কিছু করতে শুরু করি। এটি লুয়ার সাথেও ভাল কাজ করেছে। সেই সময়ে প্রধান সমস্যাটি ছিল ডিবাগিং নিয়ে: .NET-এ এর সাথে সবকিছুই দুর্দান্ত, কিন্তু এর পরে এমবেডেড লুয়ার জগতে ডুবে যাওয়া কঠিন ছিল, যখন লগ ছাড়া আপনার কোনো ডিবাগিং নেই। তদতিরিক্ত, কিছু কারণে প্রতিলিপিটি পর্যায়ক্রমে আলাদা হয়ে যায়, তাই আমাকে ট্যারান্টুল ইঞ্জিনের কাঠামোর সন্ধান করতে হয়েছিল। চ্যাট এটির সাথে সাহায্য করেছে, এবং কিছু পরিমাণে, ডকুমেন্টেশন; কখনও কখনও আমরা কোডটি দেখেছি। সেই সময়ে, ডকুমেন্টেশন তাই ছিল.

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

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

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

ভাগ করো, শাসন করো. লুয়ার সাথে চুক্তি কি?

একটি গুরুতর দ্বিধা ছিল: কিছু দল লুয়াতে অনেক যুক্তি দিয়ে একটি পরিষেবাতে নির্ভরযোগ্যভাবে পরিবর্তন করতে পারেনি। এই প্রায়ই সেবা কাজ না দ্বারা অনুষঙ্গী ছিল.

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

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

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

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

সবচেয়ে গুরুত্বপূর্ণ পরিষেবাগুলির মধ্যে একটি হল ব্যবহারকারীর প্রোফাইল। অর্থাৎ, সমস্ত Wildberries ব্যবহারকারী ট্যারান্টুলে সংরক্ষিত আছে, এবং তাদের মধ্যে প্রায় 50 মিলিয়ন রয়েছে। ব্যবহারকারী আইডি দ্বারা সংরক্ষিত একটি সিস্টেম, Go পরিষেবার সাথে সংযুক্ত বেশ কয়েকটি ডিসি জুড়ে বিতরণ করা হয়।
RPS অনুযায়ী, প্রচারক একসময় নেতা ছিলেন, 6 হাজার অনুরোধে পৌঁছেছেন। এক পর্যায়ে আমাদের 50-60 কপি ছিল। এখন আরপিএস-এর লিডার হল ব্যবহারকারীর প্রোফাইল, প্রায় 12 হাজার। এই পরিষেবাটি কাস্টম শার্ডিং ব্যবহার করে, ব্যবহারকারী আইডিগুলির রেঞ্জ দ্বারা বিভক্ত। পরিষেবাটি 20টিরও বেশি মেশিন সরবরাহ করে, তবে এটি অনেক বেশি; আমরা বরাদ্দকৃত সংস্থানগুলি হ্রাস করার পরিকল্পনা করছি, কারণ 4-5টি মেশিনের ক্ষমতা এটির জন্য যথেষ্ট।

সেশন পরিষেবা vshard এবং কার্টিজে আমাদের প্রথম পরিষেবা। vshard সেট আপ করা এবং কার্টিজ আপডেট করার জন্য আমাদের কাছ থেকে কিছু প্রচেষ্টা প্রয়োজন, কিন্তু শেষ পর্যন্ত সবকিছু কার্যকর হয়েছে।

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

কিছু ক্ষেত্রে তথ্য দ্রুত দুবার চেক করার জন্য একটি গুদাম সিস্টেমে দ্রুত রেফারেন্স কার্যকারিতার জন্য Tarantool ব্যবহার করার একটি উদাহরণ রয়েছে। আমরা এর জন্য রেডিস ব্যবহার করার চেষ্টা করেছি, কিন্তু মেমরির ডেটা ট্যারান্টুলের চেয়ে বেশি জায়গা নিয়েছে।

একটি অপেক্ষমাণ তালিকা, ক্লায়েন্ট সাবস্ক্রিপশন, বর্তমানে ফ্যাশনেবল গল্প এবং বিলম্বিত পণ্যগুলির পরিষেবাগুলিও Tarantool-এর সাথে কাজ করে৷ মেমরির শেষ পরিষেবাটি প্রায় 120 জিবি নেয়। এটি উপরের সবচেয়ে ব্যাপক পরিষেবা।

উপসংহার

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

টপিক আর কি পড়া

• Tarantool ব্যবহার করে স্ক্র্যাচ থেকে একটি উচ্চ-লোড অ্যাপ্লিকেশন তৈরি করা habr.com/ru/company/mailru/blog/510440
• Tarantool কার্টিজে বিশ্বস্ত নেতা পছন্দ habr.com/ru/company/mailru/blog/513912
• টেলিগ্রাম চ্যানেল ট্যারান্টুল পণ্যের খবর নিয়ে t.me/tarantool_news
• সম্প্রদায়ের আড্ডায় ট্যারান্টুল নিয়ে আলোচনা করুন t.me/tarantoolru

উত্স: www.habr.com