یک سامانه قیمت‌گذاری باید بتواند دو تغییر مرتبط را ثبت کند. موجودی یک کالا کم می‌شود و رزرو همان کالا به نام مشتری نوشته می‌شود. اگر این دو کلید روی دو ماشین باشند، خرابی میان دو نوشتن می‌تواند موجودی و رزرو را ناسازگار کند. اگر هر دو روی یک ماشین بمانند، رشد سامانه و از دسترس خارج شدن آن ماشین مسئله دیگری می‌سازد. TiKV ذخیره‌سازی کلید و مقدار توزیع‌شده‌ای است که برای توزیع کلیدها، تکثیر داده و اجرای تراکنش‌ها سازوکارهای جداگانه دارد. مسیر همین دو تغییر نشان می‌دهد هر سازوکار کدام بخش مسئله را حل می‌کند.
Region بازه‌ای از کلیدها را در بر می‌گیرد
کلیدها در فضای مرتب‌شده قرار می‌گیرند و هر Region مسئول بازه‌ای از آن فضاست. این مرز بر اساس کلید تعیین می‌شود، بنابراین طراحی نام کلید می‌تواند هم بر محلی بودن داده و هم بر توزیع بار اثر بگذارد. اگر همه نوشتن‌های تازه به انتهای یک فضای مرتب وارد شوند، یک بازه ممکن است سهم بزرگی از بار لحظه‌ای را بگیرد. رشد تعداد Regionها به تنهایی تضمین نمی‌کند ترافیک روی همه آن‌ها یکنواخت است. باید توزیع نوشتن، اندازه داده و هزینه خواندن بازه‌ای را با هم سنجید. پراکنده کردن بی‌قید کلیدها ممکن است جست‌وجوی بازه‌ای مورد نیاز برنامه را گران کند.
مرز Region با رشد و تغییر داده می‌تواند عوض شود. یک بازه ممکن است شکسته شود و مسئولیت آن میان بازه‌های کوچک‌تر تقسیم شود. کلاینتی که اطلاعات مسیریابی را نگه داشته باید بتواند با تغییر مرز یا رهبر کنار بیاید. در برنامه‌ریزی ظرفیت، یک Region را معادل یک ماشین ثابت در نظر نگیرید. روی یک گره چندین Region با نقش‌های مختلف وجود دارد و جای آن‌ها در طول زمان تغییر می‌کند. این جابه‌جایی بخشی از چرخه عملیاتی خوشه است. پایش باید هم تغییرات طبیعی و هم جابه‌جایی‌هایی را که به دلیل فشار یا خرابی تکرار می‌شوند نمایان کند.
تکثیر هر بازه با گروه Raft انجام می‌شود
برای داده یک Region چند نسخه روی گره‌های مختلف نگه‌داری می‌شود. اعضای مربوط به آن بازه یک گروه Raft تشکیل می‌دهند و تغییرهای آن گروه را با سازوکار توافق ثبت می‌کنند. رهبر نقش هماهنگی نوشتن را دارد و پیشرفت کار به دسترسی به اکثریت لازم بستگی دارد. این منطق در مقیاس هر گروه عمل می‌کند. بنابراین خرابی یک گره می‌تواند روی گروه‌های متعدد اثر بگذارد، اما پیامد برای همه Regionها الزاماً یکسان نیست. باید دید در هر گروه چه اعضایی باقی مانده‌اند و آیا رهبر و اکثریت قابل دسترس وجود دارد.
در طرحی با سه نسخه رأی‌دهنده، از دست دادن یک عضو با از دست دادن دو عضو اثر متفاوتی دارد. با این حال شمار نسخه‌ها تنها بخش مسئله است. اگر اعضا در یک رک، یک منبع تغذیه یا یک محدوده شبکه مشترک متمرکز باشند، یک رخداد فیزیکی ممکن است چند عضو را همزمان از دسترس خارج کند. برچسب‌های توپولوژی و سیاست جانمایی باید خرابی‌های واقعی محیط را بازتاب دهند. آزمون تحمل خرابی نیز باید گروه‌هایی را پوشش دهد که اعضای آن‌ها در دامنه‌های مختلف مستقر شده‌اند. روشن بودن سه پردازش روی یک میزبان، همان تحمل خرابی سه میزبان مستقل را فراهم نمی‌کند.
Placement Driver چه اطلاعی نگه می‌دارد؟
Placement Driver یا PD اطلاعات مربوط به خوشه و جای Regionها را مدیریت می‌کند و در تصمیم‌های زمان‌بندی نقش دارد. کلاینت برای یافتن مسیر صحیح نیازمند اطلاعات نگاشت کلید به Region و گره مقصد است. پس از یافتن مسیر، بخشی از این اطلاعات می‌تواند در کلاینت باقی بماند تا برای هر درخواست همان کار تکرار نشود. تغییر مرز یا رهبر ممکن است اطلاعات قبلی را کهنه کند. کلاینت مناسب باید پاسخ خطا را بفهمد، اطلاعات مربوط را تازه کند و در حدود قرارداد عملیات دوباره تلاش کند. تکرار کورکورانه یک نوشتن با نتیجه نامشخص می‌تواند پیامد متفاوتی در سطح برنامه داشته باشد.
PD همچنین از گزارش وضعیت گره‌ها و Regionها برای تصمیم درباره توزیع بار و نسخه‌ها استفاده می‌کند. جابه‌جایی داده ظرفیت شبکه، دیسک و پردازنده می‌خواهد. اگر محدودیت‌های زمان‌بندی بیش از حد آزاد باشند، بازتوزیع می‌تواند با بار عادی کاربران رقابت کند. اگر بیش از حد سخت باشند، بازگشت خوشه به توزیع سالم پس از خرابی طولانی می‌شود. اپراتور باید میزان عقب‌ماندگی بازسازی، نرخ انتقال و تأخیر درخواست‌های کاربر را همزمان مشاهده کند. هدف عملیاتی فقط رسیدن سریع به تعداد نسخه مطلوب نیست. ظرفیت سرویس‌دهی در مدت تعمیر نیز جزئی از تعهد سامانه به کاربران است.
خواندن و نوشتن با نسخه‌های زمانی
در مسیر تراکنشی، چندنسخه‌ای بودن داده اجازه می‌دهد خواندن در یک دید زمانی مشخص انجام شود. نسخه‌های مختلف یک کلید با اطلاعات زمانی مربوط نگه‌داری می‌شوند. تراکنش زمان شروع می‌گیرد و تصمیم می‌گیرد کدام تغییرها را در تصویر خود ببیند. این ویژگی برای خواندن سازگار در حالی که نوشتن‌های دیگر ادامه دارند اهمیت دارد. اما هر نسخه هزینه ذخیره‌سازی و نگه‌داری دارد. تراکنش‌ها یا خواندن‌های طولانی می‌توانند با سیاست نگه‌داری نسخه‌ها ارتباط پیدا کنند. برای تحلیل رشد دیسک باید نرخ تغییر، اندازه مقدارها و وضعیت پاک‌سازی نسخه‌های قدیمی را در کنار داده زنده دید.
زمان منطقی تراکنش را با ساعت محلی یک برنامه اشتباه نگیرید. PD خدمات مرتبط با تخصیص زمان مرتب برای تراکنش‌ها را فراهم می‌کند. دو سرور برنامه نباید با مقایسه ساعت دیواری خود درباره ترتیب ثبت در ذخیره‌ساز تصمیم بگیرند. برنامه باید نتیجه و قرارداد API تراکنشی را مبنا قرار دهد. زمان کسب‌وکاری مانند موعد رزرو یا تاریخ صدور سفارش همچنان معنای جداگانه دارد. افزودن زمان کسب‌وکاری به کلید ممکن است برای جست‌وجو مفید باشد، اما جایگزین اطلاعاتی نمی‌شود که موتور برای تصمیم درباره نسخه قابل مشاهده و تعارض تراکنش به کار می‌برد.
دو کلید در دو Region چگونه تغییر می‌کنند؟
برای رزرو کالا، برنامه مقدار موجودی را می‌خواند، تغییر لازم را آماده می‌کند و رکورد رزرو را می‌نویسد. اگر کلیدها در Regionهای جدا باشند، تکثیر هر Region به تنهایی نمی‌تواند تصمیم واحد تراکنش را در تمام مقصدها تعیین کند. لایه تراکنش باید تغییرهای مرتبط را هماهنگ کند. در مدل مرسوم دو مرحله‌ای، آماده‌سازی تغییرها و ثبت تصمیم نهایی وظایف متفاوت دارند. قفل‌های تراکنشی و اطلاعات مربوط به وضعیت تراکنش به حل رقابت و بازیابی پس از خطا کمک می‌کنند. جزئیات مسیر می‌تواند با نوع تراکنش و قابلیت‌های نسخه فرق کند.
فرض کنید برنامه بعد از ارسال درخواست تعهد پاسخی دریافت نمی‌کند. قطع ارتباط ثابت نمی‌کند تراکنش شکست خورده است. اگر برنامه همان رزرو را با شناسه تازه بسازد، ممکن است یک درخواست کاربر دو اثر تجاری ایجاد کند. استفاده از شناسه ثابت برای عملیات و بررسی نتیجه قبلی، راهی برای مدیریت این ابهام است. همچنین تعارض روی کلید موجودی باید به عنوان رویداد قابل انتظار طراحی شود. فاصله میان خواندن و نوشتن هرچه طولانی‌تر باشد، فرصت رقابت بیشتر می‌شود. انجام تماس شبکه کند یا انتظار کاربر در میانه تراکنش می‌تواند نرخ تعارض و هزینه تکرار را بالا ببرد.
انتخاب RawKV یا API تراکنشی
TiKV رابط‌های متفاوتی برای کار با کلید و مقدار ارائه می‌کند. عملیات ساده در RawKV و گردش کار تراکنشی قراردادهای یکسانی ندارند. تیم باید پیش از انتخاب بررسی کند تغییر اتمی چند کلید، دید سازگار و مدیریت تعارض چه اهمیتی برای داده دارند. یک آزمایش موفق get و put روی یک کلید برای ارزیابی رزرو چندکلیدی کافی نیست. حتی اگر رابط خام برای بعضی داده‌های مستقل مناسب باشد، سبد خرید یا موجودی مشترک ممکن است به قرارداد قوی‌تری نیاز داشته باشد. ترکیب روش‌ها روی یک فضای داده نیز باید تنها مطابق قواعد نسخه و مستندات انجام شود.
در طراحی کلید، اندازه مقدارها و محدوده پیمایش را ثبت کنید. قرار دادن یک سند بزرگ در یک مقدار می‌تواند هر تغییر کوچک را به نوشتن حجیم تبدیل کند. تقسیم بیش از حد همان سند میان کلیدهای فراوان نیز تعداد عملیات و نیاز به هماهنگی را بالا می‌برد. نقطه مناسب از الگوی واقعی به دست می‌آید. برای مثال اگر برنامه همیشه جزئیات یک رزرو را با هم می‌خواند، جدا کردن هر فیلد لزوماً به صرفه نیست. اگر فیلدی داغ است و مستقل تغییر می‌کند، جدا کردن آن ممکن است تعارض و بازنویسی را کاهش دهد.
عیب‌یابی تأخیر یک محدوده کلید
میانگین تأخیر کل خوشه می‌تواند طبیعی باشد، در حالی که درخواست‌های مربوط به یک کالا پیوسته کند هستند. ابتدا کلید و Region مرتبط، رهبر فعلی و توزیع درخواست‌ها را پیدا کنید. سپس تأخیر دیسک و شبکه اعضای همان گروه را با دیگر گروه‌ها مقایسه کنید. اگر فشار فقط روی یک کلید پرترافیک است، انتقال Region به گره دیگر ممکن است موقتاً کمک کند ولی الگوی رقابت را تغییر نمی‌دهد. اگر گروه‌های متعدد روی یک گره کند شده‌اند، بررسی دیسک، شبکه یا بارهای پس‌زمینه آن گره اولویت بیشتری دارد. شواهد منطقه‌ای دامنه جست‌وجو را محدود می‌کند.
پس از خرابی یک میزبان، فقط بازگشت پاسخ موفق API را بررسی نکنید. وضعیت تعداد نسخه‌ها، توزیع رهبرها و جریان بازسازی را نیز دنبال کنید. یک خوشه ممکن است در حال خدمت‌رسانی باشد ولی هنوز حاشیه تحمل خرابی بعدی را به دست نیاورده باشد. برنامه بازگشت گره باید از افزودن ظرفیت تا پایان بازتوزیع داده را پوشش دهد. برای آزمون دوره‌ای، نمونه‌هایی از خواندن بازه‌ای، نوشتن مستقل و تراکنش چندکلیدی انتخاب کنید و رفتارشان را هنگام جابه‌جایی رهبر ثبت کنید. این نمونه‌ها سه هزینه متفاوت را آشکار می‌کنند و به تصمیم درباره طراحی کلید، جانمایی نسخه و ظرفیت عملیاتی معنا می‌دهند.
در تمرین بازیابی، یک سفارش نمونه را با شناسه از پیش ثبت‌شده انتخاب کنید و نتیجه آن را پیش و پس از تغییر رهبر بخوانید. برای سنجش درستی، همانند بودن مقدار تنها معیار نیست. بررسی کنید رزرو دوبار ثبت نشده، شمار موجودی با سوابق فروش سازگار است و برنامه در اثر پاسخ دیرهنگام شناسه تازه تولید نکرده است. سپس زمان توقف مشاهده‌شده را از زمان بازگشت تعداد نسخه‌ها جدا ثبت کنید. اولی تجربه کاربر را توصیف می‌کند و دومی مدت قرار گرفتن داده در وضعیت کم‌تحمل‌تر را. این دو عدد برای برنامه‌ریزی تعمیر و انتخاب زمان تغییر بعدی کاربرد متفاوت دارند.
