কোন পরিস্থিতিতে দুটি সার্ভারকে জিজ্ঞাসা করা এবং কেবল দ্রুততম প্রতিক্রিয়া গ্রহণ করা ভাল অভ্যাস?


12

আমি জিজ্ঞাসা করেছি এখন কীভাবে জাভাস্ক্রিপ্টের ব্যবহার করা হবে সে সম্পর্কে এস -ও-তে একটি মুছে ফেলা জনগোষ্ঠীর প্রশ্ন কী Promise.race, এবং একটি উচ্চ প্রতিনিধি ব্যবহারকারী এটি মন্তব্য করেছেন:

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

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


খেলনা উদাহরণ: সর্বদা কোকসোর্ট ব্যবহার না করে আপনি ডেটা অনুলিপি করেন, এটিকে একটি কুইকোর্টে এবং একটি সংযুক্তি, এবং একটি হিপসোর্ট ইত্যাদিতে প্রেরণ করেন etc. জন্য কোন ঐ, কারণ এটি না করার জন্য একটি pathalogical ক্ষেত্রে হতে হবে সব তাদের
Caleth

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

দ্বিতীয় "সার্ভার অনুরোধ" একটি জাল হতে পারে। এটি কেবল 5 সেকেন্ডের জন্য চাইবে এবং তার পরে কোনও স্থানধারক প্রতিক্রিয়া ফিরিয়ে আনবে। এটি আপনাকে আসল অনুরোধে একটি সময়সীমা দেয়।
ব্যবহারকারী 253751

একটি লিফ্ট অর্ডার করুন এবং তারপরে একটি উবার অর্ডার করুন। যেটি প্রথমে আসে তা নিন।
ব্যবহারকারী 2023861

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

উত্তর:


11

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

আমি আমার উত্তরটি চার ভাগে ভাগ করছি:

  • ঝুকি ব্যবস্থাপনা
  • কৌশলের
  • খরচ
  • স্বজ্ঞা

ঝুকি ব্যবস্থাপনা

সুতরাং, কখনও কখনও আপনার ক্লায়েন্ট সার্ভার থেকে প্রতিক্রিয়া পেতে ব্যর্থ হয়। আমি ধরে নেব এটি কোনও প্রোগ্রাম্যাটিক ত্রুটির কারণে নয় (অন্যথায় সমাধানটি এটি ঠিক করা, সুতরাং এটি করুন)। পরিবর্তে, এটি অবশ্যই আপনার নিয়ন্ত্রণের বাইরে দুর্ভাগ্যজনক পরিস্থিতির কারণে ...

তবে আপনার জ্ঞানের বাইরে নয়। তুমি অবশ্যই জানো:

  • কিভাবে প্রায়ই এটা ঘটতে পারে না.
  • এর কী প্রভাব পড়ে।

উদাহরণস্বরূপ, যদি ব্যর্থতা এবং পুনরায় চেষ্টা করা সময়ের প্রায় 2% সময় ঘটে তবে সম্ভবত এটি সম্বোধন করার উপযুক্ত নয়। যদি এটি প্রায় ৮০% সময় হয় তবে ভাল ... নির্ভর করে ...

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


কৌশলের

আমি উপরে যেমন বলেছি, এই সমস্যায় যাওয়ার আরও একাধিক উপায় রয়েছে। আমি ধরে নেব আপনার ইতিমধ্যে চেষ্টা-ব্যর্থ-পুনরায় চেষ্টা লুপ বাস্তবায়ন হয়েছে। সুতরাং, আমাদের দেখতে দিন ...

  • একটি লোডিং বার্তা রাখুন। এটি সস্তা, ব্যবহারকারী ধরে রাখতে সহায়তা করে।
  • সমান্তরালে প্রশ্ন। দ্রুত হতে পারে, এখনও ব্যর্থ হতে পারে। রিডানড্যান্ট সার্ভারের প্রয়োজন হবে (ব্যয়বহুল হতে পারে), সার্ভারের সময় এবং নেটওয়ার্ক ট্র্যাফিক নষ্ট করবে।
  • দ্রুত সার্ভারটি স্থির করার জন্য সমান্তরালভাবে জিজ্ঞাসা করুন এবং সেখান থেকে এটি ব্যবহার করুন। দ্রুত হতে পারে, এখনও ব্যর্থ হতে পারে। অপ্রয়োজনীয় সার্ভারের প্রয়োজন হবে (ব্যয়বহুল হতে পারে), সার্ভারের সময় এবং নেটওয়ার্ক ট্র্যাফিকের অপচয় করবে না।

এখন, লক্ষ্য করুন আমি বলছি এগুলি এখনও ব্যর্থ হতে পারে। যদি আমরা ধরে নিই যে কোনও সার্ভারের একটি ক্যোয়ারিতে ব্যর্থতার 80% সম্ভাবনা রয়েছে, তবে দুটি সার্ভারের সমান্তরাল ক্যোয়ারিতে ব্যর্থতার 64% সম্ভাবনা রয়েছে। সুতরাং, আপনাকে এখনও আবার চেষ্টা করতে হতে পারে।

দ্রুত সার্ভারটি বাছাই করা এবং এটি ব্যবহার চালিয়ে যাওয়ার একটি বোনাস সুবিধা হ'ল নেটওয়ার্ক সমস্যার কারণে দ্রুত সার্ভারটি ব্যর্থ হওয়ার সম্ভাবনাও কম।

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

আরো কিছু:

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

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


খরচ

চারটি খরচ আছে:

  • উন্নয়নের ব্যয় (সাধারণত খুব সস্তা)
  • স্থাপনার ব্যয় (সাধারণত উচ্চ)
  • ব্যয় রানটাইম (প্রয়োগের ধরণ এবং ব্যবসায়ের মডেলের উপর নির্ভর করে)
  • ব্যর্থতার ব্যয় (সম্ভবত কম, তবে খুব সম্ভবত নয়)

আপনি তাদের ভারসাম্য বজায় রাখতে হবে।

উদাহরণস্বরূপ, আমাদের বলুন যে আপনি সন্তুষ্ট ব্যবহারকারী প্রতি এক ডলার উপার্জন করেন। যে আপনার প্রতিদিন 3000 ব্যবহারকারী আছে। অনুরোধগুলি প্রায় 50% সময় ব্যর্থ হয়। এবং অনুরোধটি ব্যর্থ হলে 2% ব্যবহারকারী প্রদান ছাড়াই চলে যান। এর অর্থ হ'ল আপনি প্রতিদিন (3000 * 50% * 2%) 30 ডলার হারাচ্ছেন। এখন, আসুন আমরা বলি যে নতুন বৈশিষ্ট্যটি বিকাশ করতে আপনার 100 ডলার খরচ হবে এবং সার্ভারগুলি স্থাপন করতে আপনার 800 ডলার ব্যয় করতে হবে - এবং রানটাইম ব্যয় উপেক্ষা করে - এর অর্থ আপনার ((100 + 800) / 30 এ বিনিয়োগের ফিরতি হবে ) 30 দিন. এখন, আপনি আপনার বাজেট পরীক্ষা করে সিদ্ধান্ত নিতে পারেন।

এই মানগুলি বাস্তবতার প্রতিনিধি হিসাবে বিবেচনা করবেন না, আমি তাদের গণিতের প্রত্যয় হিসাবে বেছে নিয়েছি।

Addendums:

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

বিষয়টি হ'ল, যদি আপনি ব্যালেন্সিং ব্যয়ের ক্ষেত্রে সমস্যাটি বিবেচনা করেন তবে আপনি যে কৌশলগুলি বিবেচনা করছেন তার জন্য ব্যয়ের একটি প্রাক্কলন তৈরি করতে পারেন এবং সিদ্ধান্তটি নির্ধারণ করতে এই বিশ্লেষণটি ব্যবহার করতে পারেন।


স্বজ্ঞা

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

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

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

আমি প্রত্যেকটি অনুরোধে নেটওয়ার্ক ট্র্যাফিক এবং সার্ভারের সময় নষ্ট করার পরিবর্তে এটি করার পরামর্শ দিচ্ছি, এছাড়াও জেনে রাখুন যে অপ্রয়োজনীয় সার্ভারের পরেও ব্যর্থতা ঘটতে পারে।


2
আমি এটি বলার দরকার নেই বলে মনে করি তবে এটি একটি দুর্দান্ত উত্তর :) আমি জানতাম আমি এটি প্রথম 10 লাইনে গ্রহণ করব তবে আমি আপনাকে এখনও ব্যর্থ হয়ে শেষ পর্যন্ত পড়ার সুযোগ দিয়েছি। আপনি করেন নি
আদেলিন

9

এটি গ্রহণযোগ্য, যদি ক্লায়েন্টের সময়টি সার্ভারে থাকা সময়ের চেয়ে মূল্যবান হয়।

যদি ক্লায়েন্টের দ্রুত এবং নির্ভুল হওয়া প্রয়োজন। আপনি বেশ কয়েকটি সার্ভারের অনুসন্ধানকে ন্যায়সঙ্গত করতে পারেন। এবং কোনও বৈধ উত্তর পেলে অনুরোধটি বাতিল করে দেওয়া ভাল।

এবং অবশ্যই সার্ভারগুলির মালিক / পরিচালকদের সাথে পরামর্শ করা সর্বদা বুদ্ধিমানের কাজ।


আপনার কেন অনুরোধটি বাতিল করা দরকার ? অবশ্যই এটি বিষয়গত।
JᴀʏMᴇᴇ

@ জ্যামি, এটি প্যারানয়েয়ার মধ্যে নির্মিত। আমি একবার এমন সিস্টেমের সাথে কাজ করেছি যা এর সারিটি সাফ করে নি এবং ক্রোটি পূর্ণ হয়ে গেলে এটি ক্র্যাশ হয়ে যায় (হ্যাঁ এটি পেশাদার সফ্টওয়্যার ছিল)।
টুন ক্রিজেতে

4

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

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

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


2

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

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

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


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

1
জাভাস্ক্রিপ্টের প্রতিশ্রুতিগুলি আগ্রহের সাথে শুরু করা হয়, কখন new Promiseডাকা হয় এবং যখন Promise.race()ডাকা হয় তখন পুনরায় চালু করা হয় না । কিছু প্রতিশ্রুতি বাস্তবায়ন অলস, কিন্তু আগ্রহী আরও সাধারণ। আপনি কনসোলে একটি প্রতিশ্রুতি তৈরি করে যা পরীক্ষা করে দেখতে পারেন যা কনসোলে লগ হয়। আপনি এখনই এটি লগ দেখতে পাবেন। তারপর যে প্রতিশ্রুতি পাস Promise.race()। আপনি দেখতে পাবেন এটি আবার লগ হয় না।
কার্ল বিলেফেল্ট

আহ যে সত্য। কিন্তু প্রথম এক ছাড়া প্রতিশ্রুতি বাকি ফেরত মান আমি যতদূর জানি promise.race সঙ্গে বিস্মৃত হয়,
Adelin

এ কারণেই আমি বলেছিলাম যে এপিআই আদর্শভাবে ডিজাইন করা হয়নি। আপনাকে কার্যের আসল সেটটি কোনও ভেরিয়েবলের বাইরে রেখে দিতে হবে।
কার্ল বিলেফেল্ট

1

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

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.