একটি অ্যাপ্লিকেশনে এসিআইডি কীভাবে প্রয়োগ করবেন: অনুশীলন

8.1 লেনদেন আইডি

এটিকে XID বা TxID হিসাবে মনোনীত করা হয়েছে (যদি কোনও পার্থক্য থাকে তবে আমাকে বলুন)। টাইমস্ট্যাম্পগুলি টিএক্সআইডি হিসাবে ব্যবহার করা যেতে পারে, যেটি হাতে খেলতে পারে যদি আমরা কিছু সময়ে সমস্ত অ্যাকশন পুনরুদ্ধার করতে চাই। টাইমস্ট্যাম্প যথেষ্ট দানাদার না হলে সমস্যা দেখা দিতে পারে - তাহলে লেনদেন একই আইডি পেতে পারে।

অতএব, সবচেয়ে নির্ভরযোগ্য বিকল্প হল অনন্য UUID প্রোড আইডি তৈরি করা। পাইথনে এটি খুব সহজ:

>>> import uuid 
>>> str(uuid.uuid4()) 
'f50ec0b7-f960-400d-91f0-c42a6d44e3d0' 
>>> str(uuid.uuid4()) 
'd15bed89-c0a5-4a72-98d9-5507ea7bc0ba' 

লেনদেন-সংজ্ঞায়িত ডেটার একটি সেট হ্যাশ করার এবং এই হ্যাশটিকে TxID হিসাবে ব্যবহার করার একটি বিকল্পও রয়েছে।

8.2 পুনরায় চেষ্টা করুন

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

যেহেতু কোডের একটি টুকরো শব্দের পুরো পৃষ্ঠার চেয়ে বেশি বলতে পারে, আসুন একটি উদাহরণ ব্যবহার করে বোঝা যাক কিভাবে নিষ্পাপ পুনরায় চেষ্টা করার প্রক্রিয়াটি আদর্শভাবে কাজ করা উচিত। আমি টেনাসিটি লাইব্রেরি ব্যবহার করে এটি প্রদর্শন করব (এটি এত সুন্দরভাবে ডিজাইন করা হয়েছে যে আপনি এটি ব্যবহার করার পরিকল্পনা না করলেও, উদাহরণটি আপনাকে দেখাবে কিভাবে আপনি পুনরাবৃত্তি প্রক্রিয়াটি ডিজাইন করতে পারেন):

import logging
import random
import sys
from tenacity import retry, stop_after_attempt, stop_after_delay, wait_exponential, retry_if_exception_type, before_log

logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
logger = logging.getLogger(__name__)

@retry(
	stop=(stop_after_delay(10) | stop_after_attempt(5)),
	wait=wait_exponential(multiplier=1, min=4, max=10),
	retry=retry_if_exception_type(IOError),
	before=before_log(logger, logging.DEBUG)
)
def do_something_unreliable():
	if random.randint(0, 10) > 1:
    	raise IOError("Broken sauce, everything is hosed!!!111one")
	else:
    	return "Awesome sauce!"

print(do_something_unreliable.retry.statistics)

> শুধু ক্ষেত্রে, আমি বলব: \@retry(...) হল একটি বিশেষ পাইথন সিনট্যাক্স যাকে "ডেকোরেটর" বলা হয়। এটি শুধুমাত্র একটি retry(...) ফাংশন যা অন্য একটি ফাংশনকে মোড়ানো হয় এবং এটি কার্যকর করার আগে বা পরে কিছু করে।

আমরা দেখতে পাচ্ছি, পুনঃপ্রচারগুলি সৃজনশীলভাবে ডিজাইন করা যেতে পারে:

• আপনি সময় (10 সেকেন্ড) বা প্রচেষ্টার সংখ্যা (5) দ্বারা প্রচেষ্টা সীমিত করতে পারেন।
• সূচকীয় হতে পারে (অর্থাৎ, 2 ** কিছু ক্রমবর্ধমান সংখ্যা n)। বা অন্য কোনোভাবে (উদাহরণস্বরূপ, স্থির) পৃথক প্রচেষ্টার মধ্যে সময় বাড়ানোর জন্য। সূচকীয় বৈকল্পিককে "কনজেশন কোলাপস" বলা হয়।
• আপনি শুধুমাত্র নির্দিষ্ট ধরনের ত্রুটির জন্য পুনরায় চেষ্টা করতে পারেন (IOError)।
• লগে কিছু বিশেষ এন্ট্রি দ্বারা পুনঃপ্রচেষ্টার পূর্বে বা সম্পূর্ণ করা যেতে পারে।

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

8.3 লেনদেন প্রেমীদের জন্য উন্নত সরঞ্জাম

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

দুই-ফেজ কমিট (2pc) । 2pc এর দুটি পর্যায় রয়েছে: একটি প্রস্তুতি পর্ব এবং একটি কমিট ফেজ। প্রস্তুতি পর্বের সময়, সমস্ত মাইক্রোসার্ভিসকে কিছু ডেটা পরিবর্তনের জন্য প্রস্তুত করতে বলা হবে যা পারমাণবিকভাবে করা যেতে পারে। একবার তারা সব প্রস্তুত হয়ে গেলে, কমিট ফেজ প্রকৃত পরিবর্তন করবে। প্রক্রিয়াটি সমন্বয় করার জন্য, একটি বিশ্বব্যাপী সমন্বয়কারীর প্রয়োজন, যা প্রয়োজনীয় বস্তুগুলিকে লক করে দেয় - অর্থাৎ, সমন্বয়কারী তাদের আনলক না করা পর্যন্ত তারা পরিবর্তনের জন্য অপ্রাপ্য হয়ে পড়ে। যদি একটি নির্দিষ্ট মাইক্রোসার্ভিস পরিবর্তনের জন্য প্রস্তুত না হয় (উদাহরণস্বরূপ, সাড়া না দেয়), সমন্বয়কারী লেনদেন বাতিল করবে এবং রোলব্যাক প্রক্রিয়া শুরু করবে।

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

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

সাগার সুবিধা হল কোন অবজেক্ট ব্লক করা হয় না। কিন্তু, অবশ্যই, খারাপ দিক আছে।

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

এই দুটি কৌশলের বর্ণনা থেকে আমরা কী দেখতে পাচ্ছি? সত্য যে বিতরণ করা সিস্টেমে, পারমাণবিকতা এবং বিচ্ছিন্নতার দায়িত্ব প্রয়োগের সাথে থাকে। ACID গ্যারান্টি প্রদান করে না এমন ডেটাবেস ব্যবহার করার সময় একই জিনিস ঘটে। অর্থাৎ, বিরোধের সমাধান, রোলব্যাক, কমিট এবং জায়গা খালি করার মতো জিনিসগুলি বিকাশকারীর কাঁধে পড়ে৷

8.4 আমার যখন এসিআইডি গ্যারান্টি দরকার তখন আমি কীভাবে জানব?

যখন একটি উচ্চ সম্ভাবনা থাকে যে একটি নির্দিষ্ট সেট ব্যবহারকারী বা প্রক্রিয়া একই সাথে একই ডেটাতে কাজ করবে ।

অস্বাভাবিকতার জন্য দুঃখিত, কিন্তু একটি সাধারণ উদাহরণ হল আর্থিক লেনদেন।

কখন কোন ক্রমে লেনদেন সম্পাদিত হয় তা গুরুত্বপূর্ণ।

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

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

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

যখন আপনি একটি ব্যবহারকারী বা বাসি তথ্য প্রক্রিয়া করতে পারবেন না।

এবং আবার - আর্থিক লেনদেন। সত্যি বলতে, আমি অন্য কোনো উদাহরণের কথা ভাবতে পারিনি।

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

8.5 কখন আমার ACID লাগবে না?

যখন ব্যবহারকারীরা তাদের ব্যক্তিগত কিছু ডেটা আপডেট করে।

উদাহরণস্বরূপ, একজন ব্যবহারকারী একটি ওয়েব পৃষ্ঠায় মন্তব্য বা স্টিকি নোট ছেড়ে দেয়। অথবা কোনো পরিষেবা প্রদানকারীর সাথে ব্যক্তিগত অ্যাকাউন্টে ব্যক্তিগত ডেটা সম্পাদনা করে।

যখন ব্যবহারকারীরা মোটেও ডেটা আপডেট করেন না, তবে শুধুমাত্র নতুনের সাথে পরিপূরক করেন (সংযোজন)।

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

যখন ব্যবসায়িক যুক্তি একটি নির্দিষ্ট আদেশের প্রয়োজনীয়তা নির্ধারণ করে না যেখানে লেনদেন করা হয়।

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

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

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

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