মাইক্রোসার্ভেসিস: ইভেন্টের ধারাবাহিকতা পরিচালনা করা


22

ধরুন আমাদের একটি ফাংশন রয়েছে যা ব্যবহারকারীর পাসওয়ার্ড আপডেট করে।

একবার 'আপডেট পাসওয়ার্ড' বোতামটি ক্লিক করা হলে, একটি আপডেটপ্যাসওয়ার্ডএভেন্ট এমন একটি বিষয়ে প্রেরণ করা হয় যেখানে আরও 3 টি পরিষেবা সাবস্ক্রাইব করা হয়:

  1. এমন একটি পরিষেবা যা ব্যবহারকারীর পাসওয়ার্ডটি আপডেট করে
  2. এমন একটি পরিষেবা যা ব্যবহারকারীর পাসওয়ার্ডের ইতিহাস আপডেট করে
  3. এমন একটি পরিষেবা যা ব্যবহারকারীকে তার পাসওয়ার্ড পরিবর্তন করা হয়েছে তা জানিয়ে একটি ইমেল প্রেরণ করে।

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

তবে, যদি কোনও পরিষেবা ইভেন্টটি প্রক্রিয়া করতে ব্যর্থ হয়? যেমন হঠাৎ সংযোগ বিচ্ছিন্ন, ডাটাবেস ত্রুটি, ইত্যাদি ... এই লেনদেন ব্যর্থতাগুলি হ্যান্ডেল করার জন্য ভাল প্যাটার্ন / অনুশীলন কী?

আমি একটি রোলব্যাকটপিক তৈরি করার কথা ভাবছিলাম যেখানে কোনও ইভেন্ট প্রক্রিয়া করতে ব্যর্থ হলে এমন একটি বিষয়ে একটি রোলব্যাক ইভেন্ট তৈরি করা হবে যেখানে "রোলব্যাক পরিষেবাদি" এটি কাজ করবে এবং ডেটা ফিরিয়ে আনবে


11
আপনি কোনও প্রেরিত ইমেলটি পূর্বাবস্থায় ফেরাতে পারবেন না :-)
লাইভ

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

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

ই-মেইলটি কি ব্যবহারকারীকে বলে যে লেনদেনটি শেষ হয়েছে, বা ব্যবহারকারীকে বলতে কি কেউ (আশাকরি সেগুলি) পাসওয়ার্ড পরিবর্তন করেছে? "যদি এটি আপনি না হয়ে থাকেন তবে আপনার অভিনয় করা দরকার"। যদি ২ য় হয় তবে এখনই ই-মেইল প্রেরণ করুন, সেরা হিসাবে আপনি পারেন।
ctrl-alt-delor

উত্তর:


29

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

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

উদাহরণস্বরূপ, পূর্ববর্তী লেনদেনগুলি সফলভাবে শেষ না হওয়া এবং ইমেল পরিষেবাটির প্রমাণ না পাওয়া পর্যন্ত ইমেলটি প্রেরণ করা উচিত নয়। 3

তবে, যদি কোনও পরিষেবা ইভেন্টটি প্রক্রিয়া করতে ব্যর্থ হয়? যেমন হঠাৎ সংযোগ বিচ্ছিন্ন, ডাটাবেস ত্রুটি, ইত্যাদি ... এই লেনদেন ব্যর্থতাগুলি হ্যান্ডেল করার জন্য ভাল প্যাটার্ন / অনুশীলন কী?

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

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

যখন নির্দিষ্ট ডেটা অনুপস্থিত বা অসম্পূর্ণ থাকে তখন প্রত্যেকে (বিভাগ) কী করে?

আমরা উপলব্ধি করব যে বিভিন্ন বিভাগের বিভিন্ন সমাধান রয়েছে যাদের একত্রে সমাধানটি কার্যকর করা উচিত।

যাইহোক, এখানে কিছু অনুশীলন যা অনুসরণ করার কৌশলটিতে আমাদের সহায়তা করতে পারে।

চূড়ান্ত ঐক্য

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

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

সমস্ত অপারেশন বাতিল

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

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

আমরা যদি জন্য যেতে লেনদেন পুষিয়ে , আমরা পাবেন সার্কিট ব্রেকার নকশা প্যাটার্ন খুব দরকারী হতে - এবং বাধ্যতামূলক আমি বলতে সাহস করবে -

বিতরণ লেনদেন

লেনদেন পরিচালক হিসাবে পরিচিত সামগ্রিক পরিচালনা পদ্ধতির মাধ্যমে একক লেনদেনের মধ্যে একাধিক লেনদেন বিস্তৃত করার ধারণাটি । বিতরণ লেনদেন পরিচালনার জন্য একটি সাধারণ অ্যালগরিদম হ'ল দ্বি-পর্যায়ের কমিট

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

যদি লেনদেন পরিচালনাকারীরা আপস হয়ে যায়, তবে আমরা বিভিন্ন লক দিয়ে বিভিন্ন বাউন্ডেড প্রসঙ্গটি জুড়ে শেষ করতে পারি, বার্তাগুলি সরিয়ে দেওয়ার কারণে অপ্রত্যাশিত আচরণের ফলস্বরূপ। 2

ক্রমবর্ধমান অপারেশন। কেন?

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

স্যাম নিউম্যান

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

যদি আমরা নির্দিষ্ট অপারেশনগুলিকে দুই বা ততোধিক লেনদেনে বিভক্ত করতে না পারি, তবে সম্ভবত এটি বলা যেতে পারে - এই লেনদেনগুলি একই সীমাবদ্ধ প্রসঙ্গে, বা - কমপক্ষে - মডেল করা অবধি একটি ক্রস কাটিয়া প্রসঙ্গে।

উদাহরণস্বরূপ, আমাদের ক্ষেত্রে, আমরা বুঝতে পেরেছি যে # 1 এবং # 2 লেনদেন একে অপরের সাথে দৃ related়ভাবে সম্পর্কিত এবং সম্ভবত উভয়ই একই সীমানা প্রসঙ্গে থাকা অ্যাকাউন্টগুলির , ব্যবহারকারীদের , নিবন্ধভুক্ত হতে পারে ...

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


1: আপনি যে ধরণের অর্কেস্টেশন মনে করেন তা নয়। আমি ইএসবির অর্কেস্টেশন নিয়ে কথা বলছি না। আমি পরিষেবাগুলি সঠিক ইভেন্টে প্রতিক্রিয়া তৈরি করার বিষয়ে বলছি।

2: আপনি আকর্ষণীয় হতে পারে বিতরণ লেনদেন সম্পর্কে স্যাম নিউম্যানের মতামত

3: এই বিষয়ে ডেভিড পার্কারের উত্তরটি পরীক্ষা করে দেখুন।


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

7

আপনার ক্ষেত্রে আপনি কেবল একবারে তিনটি জিনিসই প্রক্রিয়া করতে পারবেন না। আপনার যা প্রয়োজন তা একটি প্রক্রিয়া। এখানে একটি অত্যন্ত সরল উদাহরণ রয়েছে:

কমান্ড এবং ইভেন্ট অর্কেস্টেশন

রাষ্ট্রের পরিবর্তনমূলক ক্রিয়াকলাপগুলি সর্বদা একটি সামঞ্জস্যপূর্ণ সত্তায় তৈরি হওয়া উচিত তা জেনে রাখা গুরুত্বপূর্ণ। গ্যারান্টি দিতে না পারলে strong় ধারাবাহিকতা পারলে এটি মাস্টার রেকর্ডে তৈরি করতে হবে।

আপনার সিস্টেমে গ্যারান্টি দেওয়া উচিত যে আপনার সিস্টেমে কোনও ইভেন্ট উত্থাপিত হওয়ার আগে প্রথমে লেনদেনের সুরক্ষার সাথে জোর করা উচিত। এটি নিশ্চিত করার জন্য যে উত্থাপিত ইভেন্টটি সত্যই ঘটেছে তা নিশ্চিতকরণ।

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

  • হ্যান্ডলিং বার্তা সদৃশ,
  • হ্যান্ডলিং ইমেইল প্রেরণ।

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

পিও যখন কোনও স্থানে থাকে Newএবং প্রক্রিয়াজাত হয় UserPasswordHasBeenUpdated, তখন এটি তার রাজ্যে পরিবর্তন করে UserPasswordHasBeenUpdated(বা যে কোনও রাজ্যের নাম আপনার পক্ষে কাজ করে)। পিও যদি এখনও থাকে UserPasswordHasBeenUpdatedএবং অন্যটি উপস্থিত হয় UserPasswordHasBeenUpdated, পিও বার্তাটিকে সম্পূর্ণরূপে উপেক্ষা করবে এটি জেনে এটি একটি নকল। অন্যান্য রাজ্যগুলিতেও অনুরূপ প্রক্রিয়া প্রয়োগ করা হবে।

ই-মেইলের প্রকৃত প্রেরণ পরিচালনা করা কিছুটা জটিল bit এখানে আপনার কাছে দুটি বিকল্প রয়েছে:

  1. এটি একবারে পাঠান,
  2. অন্তত একবার এটি প্রেরণ করুন।

এটি একবারে পাঠান

এই বিকল্পের সাহায্যে, যখন পিও UserPasswordHistoryHasBeenSavedরাজ্যে পৌঁছেছে তখন রাষ্ট্রীয় পরিবর্তনের প্রতিক্রিয়া হিসাবে একটি ইমেল প্রেরণের জন্য একটি আদেশ পাঠানো হয়। আপনার সিস্টেমটি নিশ্চিত UserPasswordHistoryHasBeenSavedকরবে যে ই-মেইল প্রেরণের আগে রাজ্যটি বজায় থাকবে, অর্থাৎ নকল বার্তা আবার ইমেল প্রেরণাকে ট্রিগার করবে না sending এই পদ্ধতির সাহায্যে আপনি নিশ্চিত করে নিন যে সঠিক রাষ্ট্রটি পিওর জন্য সংরক্ষণ করা হয়েছে তবে নিম্নলিখিত কোনও ক্রিয়াকলাপের গ্যারান্টি দিতে পারে না।

এটি কমপক্ষে একবার পাঠান

এই জন্য আমি যেতে হবে।

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

আপনার ক্ষেত্রে আপনি নিশ্চিত করতে চান যে ব্যবহারকারী আসলে ই-মেইলটি পেয়েছে। এই কারণেই আমি প্রথমটির চেয়ে দ্বিতীয় বিকল্পটি বেছে নেব।


2

কুইউিং সিস্টেমগুলি আপনার মনে হতে পারে তেমন ভঙ্গুর নয়।

আমরা যদি তিনটি প্রক্রিয়াটি একটি সম্পর্কিত ডিবিতে লিখতে থাকি তবে আমরা কোনও মাঝারি প্রক্রিয়া ব্যর্থতা পরিচালনা করতে কোনও লেনদেন ব্যবহার করতে পারি।

চূড়ান্ত প্রতিশ্রুতি ছাড়া আংশিক কাজ ফেলে দেওয়া হবে।

মাঝারি প্রক্রিয়া ব্যর্থতাগুলি হ্যান্ডেল করার জন্য সারি থেকে কোনও বার্তা পড়ার সময় একটি সারি বেস সিস্টেমে আপনার অনুরূপ বিকল্প থাকবে।

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

আপনি সফল প্রক্রিয়াকরণের নিশ্চয়তা না পাওয়া অবধি মেসেজের অনুলিপি ধরে বিভিন্ন উপায়ে অনুরূপ 'লেনদেন' বাস্তবায়ন করতে পারেন। যদি সময় মতো নিশ্চিততা না পাওয়া যায়। আপনি বার্তাটি আবার পাঠাতে বা ম্যানুয়াল মনোযোগের জন্য রাখতে পারেন।

সম্ভবত আপনি একটি 'রোলব্যাক পরিষেবা' তৈরি করতে পারেন যা এই ভুল বার্তাগুলি পর্যবেক্ষণ করে, সম্পর্কিত বার্তাগুলি এবং অতীত অবস্থা সম্পর্কে জানত এবং একটি রোলব্যাক সম্পাদন করেছিল।

যাহোক! ভুল হওয়া বার্তাগুলি পুনরায় পাঠানো সাধারণত ভাল। এই সব পরে প্রান্ত মামলা হতে থাকে। হয় কোনও সার্ভার বিপর্যয়করভাবে ব্যর্থ হয়েছে বা কোনও নির্দিষ্ট বার্তার ধরণের হ্যান্ডলিংয়ে একটি বাগ রয়েছে।

ত্রুটি সম্পর্কে একবার সতর্কতার সাথে পরিষেবাটি মেরামত করা যায় এবং বার্তাগুলি সফলভাবে প্রক্রিয়া করা যায়। সিস্টেমটিকে পুরোপুরি সুসংগত অবস্থায় ফিরিয়ে আনা।


2

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

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

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

  • অন্তত একবার

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

  • Idempotence

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

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


1

আমি অনেক উত্তর সাথে একমত।

  1. এখনই ইমেলটি প্রেরণ করুন “কেউ আপনার পাসওয়ার্ড পরিবর্তন করেছে। এটি যদি আপনি হয়ে থাকেন তবে আপনাকে কিছু করার দরকার নেই। যদি আতঙ্কিত না হন। "এটি পৌঁছলে এটি পৌঁছে যাবে।
  2. পাসওয়ার্ড পরিবর্তন করুন। যদিও আপনার চূড়ান্ত ধারাবাহিকতা রয়েছে। আপনি নিশ্চিত করতে চান যে এই সেশনটি ব্যবহারকারী দ্বারা করা পরিবর্তনগুলি দেখে।

এছাড়াও অন্যান্য ধারাবাহিক প্রতিশ্রুতি রয়েছে যা আপনি যুক্ত করতে পারেন।

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

এই অতিরিক্ত ধারাবাহিকতা প্রয়োগের কাজের উপর নির্ভর করে প্রয়োগ করা দরকার।


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


আপনি যদি শুরুতে ইমেলটি প্রেরণ করতে পারেন তবে আপনার পন্থা ভাল। যদি আপনাকে ইমেলের পাশাপাশি কিছু পাঠাতে হয়। হতে পারে এক ধরণের লিঙ্ক / ডেটা যা কেবলমাত্র ধারাবাহিকতা অর্জনের পরে পাওয়া যায়, তবে আপনি প্রথমে ইমেলটি প্রেরণ করতে পারবেন না। এটাই আমি মন্তব্য করেছি consider asking the organization first.। আপনি সম্ভবত সঠিক। যাইহোক, আমি যে ইভেন্টগুলি পূর্বাবস্থায় ফেরাতে পারি না তা শর্তযুক্ত করা আমার কাছে গুরুত্বপূর্ণ মনে হয়েছে। উদাহরণস্বরূপ শেষ ব্যবহারকারীর জন্য বিজ্ঞপ্তি। ব্যবহারকারীর উপাত্তের প্রকৃত স্থানে থাকা বিজ্ঞপ্তিটি একটি খারাপ ছাপের কারণ হতে পারে।
লাইভ

এটি বলেছে, এই নির্দিষ্ট দৃশ্যের জন্য (পাসওয়ার্ড পরিবর্তন বিজ্ঞপ্তি), আমি এই পদ্ধতির সাথে একমত হয়েছি। যত তাড়াতাড়ি এটি প্রয়োজনীয়তা স্যুট হিসাবে।
লাইভ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.