چرا سیستم های Raft-native آینده جریان داده ها هستند؟

در حالی که آپاچی کافکا به آهستگی KRaft را برای ساده‌سازی رویکرد خود به سازگاری معرفی می‌کند، سیستم‌های ساخته شده بر روی Raft نوید بیشتری را برای بارهای کاری فرا-گیگ فردا نشان می‌دهند.

اجماع برای سیستم های منسجم و توزیع شده اساسی است. به منظور تضمین در دسترس بودن سیستم در صورت خرابی های اجتناب ناپذیر، سیستم ها به روشی نیاز دارند تا اطمینان حاصل شود که هر گره در خوشه در تراز هستند، به طوری که در صورت خرابی، کار بتواند به طور یکپارچه بین گره ها انتقال یابد. پروتکل‌های اجماع مانند Paxos، Raft و View Stamped Replication (VSR) با ارائه منطق فرآیندهایی مانند انتخاب رهبر، تغییرات پیکربندی اتمی، همگام‌سازی و موارد دیگر، به افزایش انعطاف‌پذیری برای سیستم‌های توزیع‌شده کمک می‌کنند.

همانند تمام عناصر طراحی، رویکردهای مختلف برای اجماع توزیع شده، مبادلات متفاوتی را ارائه می‌دهند. Paxos قدیمی‌ترین پروتکل اجماع در سراسر جهان است و در بسیاری از سیستم‌ها مانند Google Cloud Spanner، Apache Cassandra، Amazon DynamoDB و Neo4j استفاده می‌شود. Paxos در یک پروتکل سه مرحله ای، بدون رهبر و اکثریت برنده به اجماع دست می یابد. در حالی که Paxos در صحت رانندگی موثر است، درک، پیاده سازی و استدلال در مورد آن بسیار دشوار است. این تا حدی به این دلیل است که بسیاری از چالش‌های رسیدن به اجماع (مانند انتخاب رهبر، پیکربندی مجدد) را پنهان می‌کند و تجزیه آن را به مشکلات فرعی دشوار می‌کند.

قایق (برای قابل اعتماد، تکرار، اضافی، و تحمل خطا) را می توان به عنوان یک تکامل در نظر گرفت Paxos بر درک پذیری متمرکز شد. Raft می تواند درستی مشابه Paxos را به دست آورد، اما درک و پیاده سازی آن در دنیای واقعی آسان تر است، بنابراین اغلب می تواند تضمین های اطمینان بیشتری را ارائه دهد. به عنوان مثال، Raft از شکل پایدار رهبری استفاده می کند که مدیریت گزارش تکرار را ساده می کند و فرآیند انتخاب رهبر آن کارآمدتر است.

و از آنجایی که Raft مؤلفه های منطقی مختلف مسئله اجماع را تجزیه می کند، برای مثال با تبدیل انتخاب رهبر به مرحله ای متمایز قبل از تکرار، این یک پروتکل انعطاف پذیر برای انطباق با سیستم های توزیع شده پیچیده و مدرن است که نیاز به حفظ درستی و عملکرد دارند در حالی که

یک href=”https://research.facebook.com/publications/flexiraft-flexible-quorums-with-raft/” rel=”nofollow”>مقیاس‌سازی به PB از توان عملیاتی، در حالی که درک آن ساده‌تر است مهندسین جدید در حال هک کردن پایگاه کد هستند.

به این دلایل، Raft به سرعت برای سیستم‌های توزیع‌شده و بومی ابری امروزی مانند MongoDB، CockroachDB، TiDB، و Redpanda به منظور دستیابی به عملکرد و کارایی تراکنش‌های بیشتر مورد استفاده قرار گرفته است.

چگونه Redpanda Raft را پیاده سازی می کند

وقتی الکس گالگو، بنیانگذار Redpanda تشخیص داد که جهان به یک پلتفرم داده جریانی جدید برای پشتیبانی از نوع بار کاری GBps+ که می تواند باعث سقوط Apache Kafka شود، نیاز دارد، تصمیم گرفت کافکا را از پایه بازنویسی کنید.

شرایط لازم برای چیزی که تبدیل به Redpanda می‌شد این بود: ۱) برای کاهش پیچیدگی و ناکارآمدی اجرای خوشه‌های کافکا در مقیاس قابل اعتماد، باید ساده و سبک باشد. ۲) به حداکثر رساندن عملکرد سخت افزار مدرن به منظور ایجاد تاخیر کم برای بارهای کاری بزرگ نیاز داشت. و ۳) برای تضمین ایمنی داده ها حتی برای خروجی های بسیار بزرگ لازم بود.

پیاده‌سازی Raft پایه‌ای محکم برای هر سه الزام فراهم کرد:

1. سادگی. هر پارتیشن Redpanda یک گروه Raft است، بنابراین همه چیز در پلتفرم در مورد Raft استدلال می کند، از جمله مدیریت ابرداده و تکرار پارتیشن. این در تضاد با پیچیدگی کافکا است، جایی که تکثیر داده ها توسط ISR (کپی های همگام) و مدیریت ابرداده توسط ZooKeeper (یا KRaft) انجام می شود، و شما دو سیستم دارید که باید با یکدیگر استدلال کنند.
2. عملکرد. پیاده‌سازی Redpanda Raft می‌تواند مزاحمت‌هایی را برای اقلیتی از کپی‌ها تحمل کند، تا زمانی که رهبر و اکثر کپی‌ها پایدار باشند. در مواردی که اقلیتی از کپی‌ها پاسخ تأخیر دارند، رهبر مجبور نیست منتظر پاسخ‌های آن‌ها برای پیشرفت باشد، و تأثیر تأخیر را کاهش می‌دهد. بنابراین Redpanda نسبت به خطا تحمل بیشتری دارد و می تواند عملکرد قابل پیش بینی را در مقیاس ارائه دهد.
3. قابلیت اطمینان. هنگامی که Redpanda رویدادها را دریافت می کند، آنها در یک پارتیشن موضوعی نوشته می شوند و به یک فایل گزارش روی دیسک اضافه می شوند. سپس هر پارتیشن موضوعی یک گروه اجماع Raft را تشکیل می دهد که از یک رهبر به اضافه تعدادی دنبال کننده تشکیل می شود، همانطور که توسط ضریب تکرار موضوع مشخص شده است. یک گروه Redpanda Raft می تواند ƒ شکست را با توجه به ۲ƒ+۱ گره تحمل کند. به عنوان مثال، در یک خوشه با پنج گره و یک موضوع با ضریب تکرار پنج، دو گره ممکن است از کار بیفتند و موضوع عملیاتی باقی بماند. Redpanda از پروتکل اجماع مشترک Raft برای ایجاد ثبات حتی در هنگام پیکربندی مجدد استفاده می‌کند.

Redpanda همچنین عملکرد هسته Raft را به ترتیب به چند روش حیاتی گسترش می دهد برای دستیابی به مقیاس پذیری، قابلیت اطمینان و سرعت مورد نیاز یک راه حل مدرن و بومی ابری. نوآوری های آن در بالای Raft شامل تغییرات در روند انتخابات، تولید ضربان قلب، و به طور انتقادی، پشتیبانی از Apache Kafka ACKS است. این نوآوری‌ها بهترین عملکرد ممکن را در همه سناریوها تضمین می‌کنند، این همان چیزی است که Redpanda را قادر می‌سازد به طور قابل‌توجهی سریع‌تر از کافکا باشد و در عین حال ایمنی داده‌ها را تضمین کند. در واقع، تست Jepsen تأیید کرده است که Redpanda یک سیستم ایمن است بدون مشکلات سازگاری شناخته شده، و یک لایه اجماع مبتنی بر Raft.

اما KRaft چطور؟

در حالی که Redpanda رویکرد بومی Raft را در پیش می‌گیرد، پلتفرم‌های قدیمی جریان داده در اتخاذ رویکردهای مدرن برای اجماع عقب مانده‌اند. کافکا خود یک گزارش توزیع‌شده تکراری است، اما از لحاظ تاریخی برای مدیریت ابرداده و انتخاب کنترل‌کننده به گزارش توزیع‌شده تکراری دیگری – Apache ZooKeeper – تکیه کرده است. این به چند دلیل مشکل ساز بوده است:

1. مدیریت چندین سیستم باعث ایجاد بار اداری می شود؛
2. مقیاس‌پذیری به دلیل مدیریت ناکارآمد فراداده و حافظه پنهان مضاعف محدود است.
3. خوشه‌ها می‌توانند بسیار متورم شوند و منابع زیادی مصرف کنند. در واقع، دیدن خوشه هایی با تعداد مساوی گره ZooKeeper و Kafka غیر معمول نیست.

این محدودیت‌ها توسط مرتکبان و نگهبانان آپاچی کافکا، که در حال جایگزینی ZooKeeper با حد نصاب ابرداده‌ای خودگردان هستند، نادیده گرفته نشده است: Kafka Raft (KRaft). این طعم مبتنی بر رویداد Raft چالش‌های اداری مدیریت فراداده کافکا را کاهش می‌دهد و نشانه امیدوارکننده‌ای است که اکوسیستم کافکا در جهت رویکردهای مدرن برای توافق و قابلیت اطمینان حرکت می‌کند.

متاسفانه KRaft مشکل داشتن دو سیستم مختلف برای اجماع در یک خوشه کافکا را حل نمی کند. در پارادایم جدید KRaft، پارتیشن‌های KRaft مدیریت ابرداده و خوشه را مدیریت می‌کنند، اما تکثیر توسط کارگزاران مدیریت می‌شود، بنابراین شما همچنان این دو پلتفرم مجزا و ناکارآمدی‌های ناشی از آن پیچیدگی ذاتی را دارید.

ترکیب Raft با مهندسی عملکرد

همانطور که رهبران صنعت داده مانند CockroachDB، MongoDB، Neo4j و TiDB نشان داده‌اند، سیستم‌های مبتنی بر Raft محیط‌های داده توزیع‌شده ساده‌تر، سریع‌تر و مطمئن‌تر را ارائه می‌دهند. Raft در حال تبدیل شدن به پروتکل اجماع استاندارد برای سیستم‌های داده توزیع‌شده امروزی است، زیرا به‌ویژه با مهندسی عملکرد هماهنگ است تا توان پردازش داده را بیشتر کند.

برای مثال، Redpanda Raft را با اجزای معماری سریع ترکیب می‌کند تا حداقل ۱۰ برابر سریع‌تر از کافکا در زمان‌های تأخیر انتهایی (p99.99) هنگام پردازش حجم کاری ۱ گیگابایت در ثانیه، در یک سوم سخت‌افزار، بدون به خطر انداختن ایمنی داده، کار کند. به طور سنتی، بارهای کاری GBps+ برای آپاچی کافکا سنگین بوده است، اما Redpanda می‌تواند آنها را با تاخیرهای دو رقمی میلی‌ثانیه پشتیبانی کند، در حالی که قابلیت اطمینان تأیید شده توسط Jepsen را حفظ می‌کند.

این چگونه به دست می آید؟ Redpanda به زبان C++ نوشته شده است و از معماری نخ به ازای هسته استفاده می‌کند تا حداکثر عملکرد را از تراشه‌های مدرن و کارت‌های شبکه کاهش دهد. این عناصر با هم کار می کنند تا ارزش Raft را برای یک پلت فرم داده جریانی توزیع شده بالا ببرند.

برای مثال، چون Redpanda کش صفحه و وابستگی ماشین مجازی جاوا (JVM) کافکا را دور می‌زند، می‌تواند دانش سطح سخت‌افزار را در اجرای Raft خود تعبیه کند. به طور معمول، هر بار که در Raft می نویسید، برای تضمین ماندگاری نوشتن روی دیسک، باید فلاش کنید. در رویکرد خوش بینانه Redpanda به Raft، فلاش های متناوب کوچکتر به نفع یک فلاش بزرگتر در پایان تماس حذف می شوند. در حالی که این مقدار تاخیر اضافی در هر تماس را معرفی می کند، تاخیر کلی سیستم را کاهش می دهد و توان عملیاتی کلی را افزایش می دهد، زیرا تعداد کل عملیات شستشو را کاهش می دهد.

در حالی که راه‌های مؤثر بسیاری برای اطمینان از ثبات و ایمنی در سیستم‌های توزیع‌شده وجود دارد (بلاک‌چین‌ها این کار را با پروتکل‌های اثبات کار و اثبات سهام به خوبی انجام می‌دهند)، Raft یک رویکرد اثبات شده و به اندازه کافی انعطاف‌پذیر است که می‌تواند مانند Redpanda، برای انطباق با چالش های جدید بهبود یافته است. با ورود به دنیای جدیدی از امکانات مبتنی بر داده، که تا حدی توسط موارد استفاده از هوش مصنوعی و یادگیری ماشین هدایت می‌شود، آینده در دست توسعه‌دهندگانی که می‌توانند از جریان‌های داده هم‌زمان استفاده کنند.

سیستم‌های مبتنی بر Raft، همراه با عناصر مهندسی عملکرد مانند C++ و معماری رشته‌ای به ازای هسته، آینده جریان داده را برای برنامه‌های کاربردی حیاتی هدایت می‌کنند.

داگ فلورا رئیس بازاریابی محصول در داده‌های Redpanda است.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.