پیشنهاد می کنم متن سخنرانی "Hadoop. ZooKeeper" از مجموعه "روش های پردازش توزیع شده حجم زیادی از داده ها در Hadoop" را مطالعه کنید.
ZooKeeper چیست، جایگاه آن در اکوسیستم Hadoop. نادرست در مورد محاسبات توزیع شده نمودار یک سیستم توزیع استاندارد. مشکل در هماهنگی سیستم های توزیع شده مشکلات هماهنگی معمولی اصول طراحی ZooKeeper. مدل داده ZooKeeper. پرچم های znode جلسات. Client API. بدوی (پیکربندی، عضویت در گروه، قفل های ساده، انتخاب رهبر، قفل بدون اثر گله). معماری ZooKeeper. ZooKeeper DB. ZAB. رسیدگی کننده درخواست
امروز در مورد ZooKeeper صحبت خواهیم کرد. این مورد بسیار مفید است. مانند هر محصول Apache Hadoop، یک لوگو دارد. مردی را به تصویر می کشد.
قبل از این، ما عمدتاً در مورد اینکه چگونه می توان داده ها را در آنجا پردازش کرد، چگونه آنها را ذخیره کرد، یعنی چگونه از آنها به نحوی استفاده کرد و به نوعی با آنها کار کرد صحبت کردیم. و امروز می خواهم کمی در مورد ساخت اپلیکیشن های توزیع شده صحبت کنم. و ZooKeeper یکی از مواردی است که به شما امکان می دهد این موضوع را ساده کنید. این نوعی سرویس است که برای نوعی هماهنگی تعامل فرآیندها در سیستم های توزیع شده، در برنامه های کاربردی توزیع شده در نظر گرفته شده است.
نیاز به چنین برنامه هایی هر روز بیشتر و بیشتر می شود، این چیزی است که دوره ما در مورد آن است. از یک طرف، MapReduce و این فریم ورک آماده به شما امکان می دهد تا این پیچیدگی را سطح بندی کنید و برنامه نویس را از نوشتن موارد اولیه مانند تعامل و هماهنگی فرآیندها رها کنید. اما از سوی دیگر، هیچ کس تضمین نمی کند که به هر حال این کار انجام نشود. MapReduce یا سایر فریم ورک های آماده همیشه به طور کامل جایگزین برخی مواردی که با استفاده از آن قابل پیاده سازی نیستند، نمی شود. از جمله خود MapReduce و تعدادی دیگر از پروژه های آپاچی؛ آنها در واقع برنامه های توزیع شده نیز هستند. و برای سهولت نوشتن، ZooKeeper را نوشتند.
مانند همه برنامه های مرتبط با Hadoop، این برنامه توسط Yahoo! اکنون همچنین یک برنامه رسمی آپاچی است. به اندازه HBase به طور فعال توسعه نیافته است. اگر به JIRA HBase بروید، هر روز یک دسته گزارش اشکال وجود دارد، یکسری پیشنهاد برای بهینه سازی چیزی، یعنی زندگی در پروژه دائما در جریان است. و ZooKeeper از یک طرف یک محصول نسبتا ساده است و از طرف دیگر این امر اطمینان آن را تضمین می کند. و استفاده از آن بسیار آسان است، به همین دلیل است که به یک استاندارد در برنامه های کاربردی در اکوسیستم Hadoop تبدیل شده است. بنابراین فکر کردم مفید است که آن را مرور کنم تا بفهمم چگونه کار می کند و چگونه از آن استفاده کنیم.
این تصویری است از چند سخنرانی که داشتیم. می توان گفت که متعامد به همه چیزهایی است که تاکنون در نظر گرفته ایم. و هر چیزی که در اینجا نشان داده شده است، به یک درجه یا دیگری، با ZooKeeper کار می کند، یعنی سرویسی است که از همه این محصولات استفاده می کند. نه HDFS و نه MapReduce خدمات مشابه خود را نمی نویسند که به طور خاص برای آنها کار کند. بر این اساس از ZooKeeper استفاده می شود. و این توسعه و برخی موارد مربوط به خطاها را ساده می کند.
این همه از کجا می آید؟ به نظر می رسد که ما دو برنامه را به صورت موازی در رایانه های مختلف راه اندازی کردیم، آنها را با یک رشته یا در یک مش متصل کردیم و همه چیز کار می کند. اما مشکل این است که شبکه قابل اعتماد نیست، و اگر ترافیک را استشمام کرده باشید یا به آنچه در آنجا اتفاق می‌افتد در سطح پایین، نحوه تعامل کلاینت‌ها در شبکه نگاه کنید، اغلب می‌توانید ببینید که برخی از بسته‌ها گم می‌شوند یا دوباره ارسال می‌شوند. بیهوده نیست که پروتکل های TCP اختراع شده اند که به شما امکان می دهد یک جلسه مشخص را ایجاد کنید و تحویل پیام ها را تضمین کنید. اما در هر صورت، حتی TCP همیشه نمی تواند شما را نجات دهد. هر چیزی تایم اوت دارد. شبکه ممکن است به سادگی برای مدتی از کار بیفتد. ممکن است فقط چشمک بزند. و همه اینها منجر به این واقعیت می شود که نمی توانید به قابل اعتماد بودن شبکه اعتماد کنید. این تفاوت اصلی با نوشتن برنامه های موازی است که روی یک کامپیوتر یا روی یک ابرکامپیوتر اجرا می شوند، جایی که شبکه وجود ندارد، جایی که یک گذرگاه تبادل اطلاعات قابل اطمینان تری در حافظه وجود دارد. و این یک تفاوت اساسی است.
از جمله، هنگام استفاده از شبکه، همیشه تأخیر خاصی وجود دارد. دیسک نیز دارای آن است، اما شبکه دارای تعداد بیشتری از آن است. تأخیر مقداری زمان تأخیر است که می تواند کوچک یا بسیار مهم باشد.
توپولوژی شبکه در حال تغییر است. توپولوژی چیست - این محل قرارگیری تجهیزات شبکه ما است. مراکز داده وجود دارد، قفسه هایی وجود دارد که در آنجا ایستاده اند، شمع هایی وجود دارد. همه اینها را می توان دوباره وصل کرد، جابه جا کرد، و غیره. همه اینها نیز باید در نظر گرفته شوند. نام IP تغییر می کند، مسیریابی که از طریق آن ترافیک ما طی می شود تغییر می کند. این نیز باید در نظر گرفته شود.
شبکه ممکن است از نظر تجهیزات نیز تغییر کند. از روی تمرین، می توانم بگویم که مهندسان شبکه ما واقعاً دوست دارند به طور دوره ای چیزی را روی شمع ها به روز کنند. ناگهان یک سیستم عامل جدید بیرون آمد و آنها علاقه خاصی به خوشه Hadoop نداشتند. آنها شغل خود را دارند. برای آنها، نکته اصلی این است که شبکه کار می کند. بر این اساس، آنها می خواهند دوباره چیزی را در آنجا آپلود کنند، روی سخت افزار خود فلش کنند و سخت افزار نیز به صورت دوره ای تغییر می کند. همه اینها به نوعی باید در نظر گرفته شود. همه اینها بر برنامه توزیع شده ما تأثیر می گذارد.
معمولا افرادی که بنا به دلایلی شروع به کار با حجم زیاد داده می کنند، بر این باورند که اینترنت بی حد و حصر است. اگر یک فایل چند ترابایتی وجود دارد، می توانید آن را به سرور یا رایانه خود ببرید و با استفاده از آن باز کنید گربه و ببین. یک خطای دیگر در است نیرو به سیاههها نگاه کنید هرگز این کار را نکنید زیرا بد است. از آنجا که Vim سعی می کند همه چیز را بافر کند، همه چیز را در حافظه بارگذاری کند، به خصوص زمانی که ما شروع به حرکت در این گزارش می کنیم و به دنبال چیزی می گردیم. اینها چیزهایی هستند که فراموش شده اند، اما ارزش بررسی دارند.
نوشتن یک برنامه که روی یک کامپیوتر با یک پردازنده اجرا می شود آسان تر است.
وقتی سیستم ما رشد می‌کند، می‌خواهیم همه آن را موازی کنیم و آن را نه تنها در رایانه، بلکه در یک خوشه نیز موازی کنیم. این سوال مطرح می شود: چگونه می توان این موضوع را هماهنگ کرد؟ برنامه های ما حتی ممکن است با یکدیگر تعامل نداشته باشند، اما چندین فرآیند را به صورت موازی روی چندین سرور اجرا کردیم. و چگونه می توان نظارت کرد که همه چیز برای آنها خوب پیش می رود؟ مثلاً چیزی را از طریق اینترنت می فرستند. آنها باید وضعیت خود را در جایی بنویسند، مثلاً در نوعی پایگاه داده یا گزارش، سپس این گزارش را جمع آوری کنند و سپس در جایی آن را تجزیه و تحلیل کنند. به علاوه، ما باید در نظر بگیریم که این فرآیند کار می کرد و کار می کرد، ناگهان خطایی در آن ظاهر شد یا از کار افتاد، پس چقدر سریع متوجه آن خواهیم شد؟
واضح است که همه اینها را می توان به سرعت کنترل کرد. این نیز خوب است، اما نظارت یک چیز محدود است که به شما امکان می دهد برخی چیزها را در بالاترین سطح نظارت کنید.
وقتی می‌خواهیم فرآیندهای ما شروع به تعامل با یکدیگر کنند، به عنوان مثال، برخی داده‌ها را برای یکدیگر ارسال کنند، این سؤال نیز پیش می‌آید - چگونه این اتفاق می‌افتد؟ آیا نوعی شرایط مسابقه وجود خواهد داشت، آیا آنها روی یکدیگر بازنویسی می کنند، آیا داده ها به درستی می رسند، آیا چیزی در طول راه از بین می رود؟ ما باید نوعی پروتکل و غیره ایجاد کنیم.
هماهنگی همه این فرآیندها چیز بی اهمیتی نیست. و توسعه‌دهنده را مجبور می‌کند تا به سطح پایین‌تری برود و سیستم‌ها را از ابتدا یا نه کاملاً از ابتدا بنویسد، اما این به این سادگی نیست.
اگر یک الگوریتم رمزنگاری به دست آوردید یا حتی آن را پیاده سازی کردید، بلافاصله آن را دور بیندازید، زیرا به احتمال زیاد برای شما کار نخواهد کرد. به احتمال زیاد حاوی تعدادی خطا است که فراموش کرده اید آنها را ارائه دهید. هرگز از آن برای چیزهای جدی استفاده نکنید زیرا به احتمال زیاد ناپایدار خواهد بود. زیرا تمام الگوریتم هایی که وجود دارند برای مدت بسیار طولانی توسط زمان آزمایش شده اند. توسط جامعه اشکال دارد. این یک موضوع جداگانه است. و اینجا هم همینطوره اگر ممکن است خودتان نوعی همگام سازی فرآیند را اجرا نکنید، بهتر است این کار را انجام ندهید، زیرا کاملاً پیچیده است و شما را به مسیر متزلزل جستجوی مداوم خطاها هدایت می کند.
امروز در مورد ZooKeeper صحبت می کنیم. از یک طرف یک چارچوب است، از طرف دیگر سرویسی است که زندگی را برای توسعه دهنده آسان می کند و اجرای منطق و هماهنگی فرآیندهای ما را تا حد امکان ساده می کند.
بیایید به یاد بیاوریم که یک سیستم توزیع استاندارد چگونه ممکن است به نظر برسد. این همان چیزی است که ما در مورد آن صحبت کردیم - HDFS، HBase. یک فرآیند Master وجود دارد که فرآیندهای کارگران و برده را مدیریت می کند. او مسئول هماهنگی و توزیع وظایف، راه اندازی مجدد کارگران، راه اندازی نیروهای جدید و توزیع بار است.
یک چیز پیشرفته تر، Coordination Service است، یعنی خود وظیفه هماهنگی را به یک فرآیند جداگانه منتقل کنید، به علاوه یک نوع پشتیبان یا Stanby Master را به صورت موازی اجرا کنید، زیرا ممکن است Master شکست بخورد. و اگر استاد بیفتد، سیستم ما کار نخواهد کرد. ما در حال اجرای پشتیبان هستیم. برخی بیان می‌کنند که Master برای پشتیبان‌گیری نیاز به تکرار دارد. این را می توان به خدمات هماهنگی نیز سپرد. اما در این نمودار، خود استاد مسئولیت هماهنگی کارگران را بر عهده دارد؛ در اینجا سرویس فعالیت‌های تکثیر داده‌ها را هماهنگ می‌کند.
یک گزینه پیشرفته تر زمانی است که تمام هماهنگی ها توسط سرویس ما انجام می شود، همانطور که معمولا انجام می شود. او مسئولیت اطمینان از کارکرد همه چیز را بر عهده می گیرد. و اگر چیزی کار نمی کند، ما در مورد آن مطلع می شویم و سعی می کنیم از این وضعیت عبور کنیم. در هر صورت ما با استادی می مانیم که به نوعی با Slave ها تعامل دارد و می تواند داده ها، اطلاعات، پیام ها و ... را از طریق برخی سرویس ها ارسال کند.
یک طرح حتی پیشرفته تر وجود دارد، زمانی که ما یک Master نداریم، همه گره ها برده های اصلی هستند، در رفتارشان متفاوت است. اما آنها هنوز نیاز به تعامل با یکدیگر دارند، بنابراین هنوز سرویسی برای هماهنگی این اقدامات باقی مانده است. احتمالاً کاساندرا که بر اساس این اصل کار می کند با این طرح مطابقت دارد.
دشوار است که بگوییم کدام یک از این طرح ها بهتر عمل می کند. هر کدام مزایا و معایب خاص خود را دارند.
و نیازی به ترس از برخی چیزها با استاد نیست، زیرا، همانطور که تمرین نشان می دهد، او چندان مستعد خدمت مداوم نیست. نکته اصلی در اینجا انتخاب راه حل مناسب برای میزبانی این سرویس در یک گره قدرتمند جداگانه است تا منابع کافی داشته باشد تا در صورت امکان کاربران به آنجا دسترسی نداشته باشند تا به طور تصادفی این فرآیند را از بین نبرند. اما در عین حال، در چنین طرحی مدیریت کارگران از فرآیند Master بسیار ساده تر است، یعنی این طرح از نظر اجرا ساده تر است.
و این طرح (بالا) احتمالا پیچیده تر، اما قابل اعتماد تر است.
مشکل اصلی خرابی های جزئی است. به عنوان مثال، وقتی پیامی را از طریق شبکه ارسال می کنیم، نوعی تصادف رخ می دهد و کسی که پیام را ارسال کرده است، متوجه نمی شود که آیا پیام او دریافت شده است یا خیر، متوجه نمی شود که آیا پیام به درستی پردازش شده است یا خیر. ، یعنی هیچ تاییدیه ای دریافت نخواهد کرد.
بر این اساس باید این وضعیت را پردازش کنیم. و ساده ترین کار این است که دوباره این پیام را بفرستیم و منتظر بمانیم تا پاسخی دریافت کنیم. در این مورد، تغییر وضعیت گیرنده در نظر گرفته نمی شود. ممکن است پیامی ارسال کنیم و همان داده را دو بار اضافه کنیم.
ZooKeeper راه هایی برای مقابله با چنین امتناع هایی ارائه می دهد که زندگی ما را نیز آسان تر می کند.
همانطور که کمی قبل ذکر شد، این شبیه به نوشتن برنامه های چند رشته ای است، اما تفاوت اصلی این است که در برنامه های توزیع شده ای که ما روی ماشین های مختلف می سازیم، تنها راه ارتباط شبکه است. اساسا، این یک معماری هیچ چیز مشترک است. هر فرآیند یا سرویسی که روی یک ماشین اجرا می‌شود، حافظه، دیسک، پردازنده خاص خود را دارد که با کسی به اشتراک نمی‌گذارد.
اگر یک برنامه چند رشته ای روی یک کامپیوتر بنویسیم، می توانیم از حافظه مشترک برای تبادل داده ها استفاده کنیم. ما در آنجا یک سوئیچ زمینه داریم، فرآیندها می توانند تغییر کنند. این بر عملکرد تأثیر می گذارد. از یک طرف، چنین چیزی در برنامه در یک کلاستر وجود ندارد، اما مشکلاتی در شبکه وجود دارد.
بر این اساس، مشکلات اصلی که هنگام نوشتن سیستم‌های توزیع‌شده به وجود می‌آیند، پیکربندی است. ما در حال نوشتن نوعی برنامه هستیم. اگر ساده است، پس ما انواع اعداد را در کد هاردکد می کنیم، اما این کار ناخوشایند است، زیرا اگر تصمیم بگیریم که به جای تایم اوت نیم ثانیه ای زمان یک ثانیه می خواهیم، باید برنامه را دوباره کامپایل کنیم و دوباره همه چیز را باز کنید وقتی روی یک دستگاه است، وقتی می‌توانید آن را دوباره راه‌اندازی کنید یک چیز است، اما وقتی ماشین‌های زیادی داریم، باید دائماً همه چیز را کپی کنیم. ما باید سعی کنیم برنامه را قابل تنظیم کنیم.
در اینجا ما در مورد پیکربندی استاتیک برای فرآیندهای سیستم صحبت می کنیم. این کاملاً نیست، شاید از نظر سیستم عامل، ممکن است یک پیکربندی ثابت برای فرآیندهای ما باشد، یعنی این پیکربندی است که به سادگی نمی توان آن را گرفت و به روز کرد.
همچنین یک پیکربندی پویا وجود دارد. اینها پارامترهایی هستند که می خواهیم در همان لحظه تغییر دهیم تا در آنجا جمع شوند.
مشکل اینجا چیست؟ ما پیکربندی را به روز کردیم، آن را منتشر کردیم، پس چه؟ مشکل ممکن است این باشد که از یک طرف پیکربندی را باز کردیم، اما چیز جدید را فراموش کردیم، پیکربندی در آنجا باقی ماند. ثانیا، در حالی که ما در حال انتشار بودیم، پیکربندی در برخی جاها به روز شد، اما در برخی دیگر نه. و برخی از فرآیندهای برنامه ما که روی یک دستگاه اجرا می شوند با یک پیکربندی جدید و در جایی با یک پیکربندی قدیمی مجدداً راه اندازی شدند. این می تواند منجر به ناسازگاری برنامه توزیع شده ما از منظر پیکربندی شود. این مشکل رایج است. برای یک پیکربندی پویا، بیشتر مرتبط است زیرا به این معنی است که می توان آن را در لحظه تغییر داد.
مشکل دیگر عضویت در گروه است. ما همیشه تعدادی کارگر داریم، همیشه می خواهیم بدانیم کدام یک از آنها زنده است، کدام یک از آنها مرده است. اگر استاد وجود داشته باشد، باید بفهمد که کدام کارگران را می توان به مشتریان هدایت کرد تا محاسبات را انجام دهند یا با داده ها کار کنند، و کدام نمی توانند. مشکلی که دائماً ایجاد می شود این است که ما باید بدانیم چه کسی در خوشه ما کار می کند.
یکی دیگر از مشکلات معمول انتخابات رهبران است، زمانی که می خواهیم بدانیم چه کسی مسئول است. یک مثال تکرار است، زمانی که ما یک فرآیند داریم که عملیات نوشتن را دریافت می کند و سپس آنها را در بین سایر فرآیندها تکرار می کند. او رهبر خواهد بود، بقیه از او اطاعت خواهند کرد، از او پیروی خواهند کرد. باید فرآیندی را انتخاب کرد که برای همه مبهم باشد تا دو رهبر انتخاب نشود.
همچنین دسترسی انحصاری متقابل وجود دارد. مشکل اینجا پیچیده تر است. چیزی به نام mutex وجود دارد، زمانی که شما برنامه‌های چند رشته‌ای می‌نویسید و می‌خواهید دسترسی به برخی منابع، مثلاً یک سلول حافظه، محدود شود و تنها توسط یک رشته انجام شود. در اینجا منبع می تواند چیزی انتزاعی تر باشد. و برنامه های مختلف از گره های مختلف شبکه ما فقط باید به یک منبع معین دسترسی انحصاری داشته باشند و نه به این دلیل که همه بتوانند آن را تغییر دهند یا چیزی در آنجا بنویسند. اینها به اصطلاح قفل هستند.
ZooKeeper به شما این امکان را می دهد که تمام این مشکلات را تا حدی حل کنید. و من با مثال هایی نشان خواهم داد که چگونه این امکان را به شما می دهد.
هیچ چیز اولیه مسدود کننده ای وجود ندارد. هنگامی که ما شروع به استفاده از چیزی می کنیم، این بدوی منتظر هیچ رویدادی نخواهد بود. به احتمال زیاد، این چیز به صورت ناهمزمان کار می کند و در نتیجه به فرآیندها اجازه می دهد در حالی که منتظر چیزی هستند معلق نمانند. این یک چیز بسیار مفید است.
تمام درخواست های مشتری به ترتیب صف عمومی پردازش می شوند.
و مشتریان این فرصت را دارند که قبل از اینکه مشتری خود داده های تغییر یافته را ببیند، در مورد تغییرات در برخی وضعیت ها، در مورد تغییرات در داده ها، اعلان دریافت کنند.
ZooKeeper می تواند در دو حالت کار کند. اولی مستقل، روی یک گره است. این برای آزمایش راحت است. همچنین می تواند در حالت کلاستر روی هر تعداد سرور کار کند. اگر ما یک خوشه 100 ماشینی داشته باشیم، پس لازم نیست که روی 100 ماشین کار کند. کافی است چندین ماشین را انتخاب کنید که بتوانید ZooKeeper را در آنها اجرا کنید. و اصل در دسترس بودن بالا را مدعی است. در هر نمونه در حال اجرا، ZooKeeper یک کپی کامل از داده ها را ذخیره می کند. بعداً به شما خواهم گفت که چگونه این کار را انجام می دهد. داده ها را پارتیشن بندی نمی کند. از یک طرف منهای است که نمی توانیم زیاد ذخیره کنیم، از طرف دیگر نیازی به این کار نیست. این چیزی نیست که برای آن طراحی شده است، یک پایگاه داده نیست.
داده ها را می توان در سمت مشتری ذخیره کرد. این یک اصل استاندارد است تا سرویس را قطع نکنیم و آن را با همان درخواست ها بارگذاری نکنیم. یک کلاینت هوشمند معمولاً از این موضوع اطلاع دارد و آن را در حافظه پنهان ذخیره می کند.
مثلاً اینجا چیزی تغییر کرده است. نوعی برنامه کاربردی وجود دارد. رهبر جدیدی انتخاب شد که به عنوان مثال مسئول پردازش عملیات نوشتن است. و ما می خواهیم داده ها را تکرار کنیم. یک راه حل این است که آن را در یک حلقه قرار دهید. و ما دائماً خدمات خود را زیر سوال می بریم - آیا چیزی تغییر کرده است؟ گزینه دوم بهینه تر است. این یک مکانیسم ساعت است که به شما امکان می دهد به مشتریان اطلاع دهید که چیزی تغییر کرده است. این روش از نظر منابع ارزان‌تر است و برای مشتریان راحت‌تر است.
کلاینت کاربری است که از ZooKeeper استفاده می کند.
سرور خود فرآیند ZooKeeper است.
Znode نکته کلیدی در ZooKeeper است. همه znode ها توسط ZooKeeper در حافظه ذخیره می شوند و در قالب یک نمودار سلسله مراتبی، به شکل یک درخت سازماندهی می شوند.
دو نوع عملیات وجود دارد. اولین مورد به‌روزرسانی/نوشتن است، زمانی که برخی عملیات وضعیت درخت ما را تغییر می‌دهد. درخت مشترک است.
و ممکن است که کلاینت یک درخواست را تکمیل نکند و قطع شود، اما بتواند جلسه ای ایجاد کند که از طریق آن با ZooKeeper تعامل داشته باشد.
مدل داده ZooKeeper شبیه یک سیستم فایل است. یک ریشه استاندارد وجود دارد و سپس ما به عنوان از طریق دایرکتوری هایی که از ریشه می روند رفتیم. و سپس کاتالوگ سطح اول، سطح دوم. این همه znodes است.
هر znode می تواند برخی از داده ها را ذخیره کند که معمولاً خیلی بزرگ نیستند، مثلاً 10 کیلوبایت. و هر znode می تواند تعداد معینی فرزند داشته باشد.
Znode ها انواع مختلفی دارند. می توان آنها را ایجاد کرد. و هنگام ایجاد znode، نوع آن را مشخص می کنیم که باید به آن تعلق داشته باشد.
دو نوع وجود دارد. اولین مورد پرچم زودگذر است. Znode در یک جلسه زندگی می کند. به عنوان مثال، مشتری یک جلسه ایجاد کرده است. و تا زمانی که این جلسه زنده است، وجود خواهد داشت. این لازم است تا چیزی غیر ضروری تولید نشود. این همچنین برای لحظاتی مناسب است که ذخیره داده های اولیه در یک جلسه برای ما مهم است.
نوع دوم پرچم متوالی است. شمارنده را در مسیر znode افزایش می دهد. به عنوان مثال، ما یک دایرکتوری با برنامه 1_5 داشتیم. و وقتی اولین گره را ایجاد کردیم، p_1، دومی - p_2 را دریافت کرد. و وقتی هر بار این متد را فراخوانی می کنیم، مسیر کامل را می گذرانیم که فقط بخشی از مسیر را نشان می دهد و این عدد به طور خودکار افزایش می یابد زیرا نوع گره - ترتیبی را نشان می دهیم.
znode معمولی. او همیشه زنده خواهد ماند و نامی را که ما به او می گوییم خواهد داشت.
یکی دیگر از موارد مفید پرچم ساعت است. اگر آن را نصب کنیم، مشتری می تواند در برخی رویدادها برای یک گره خاص مشترک شود. من بعداً با مثالی به شما نشان خواهم داد که چگونه این کار انجام می شود. ZooKeeper خود به مشتری اطلاع می دهد که داده های گره تغییر کرده است. با این حال، اعلان‌ها تضمین نمی‌کنند که برخی از داده‌های جدید رسیده است. آنها به سادگی می گویند که چیزی تغییر کرده است، بنابراین شما هنوز هم باید داده ها را بعدا با تماس های جداگانه مقایسه کنید.
و همانطور که قبلاً گفتم ترتیب داده ها بر اساس کیلوبایت تعیین می شود. نیازی به ذخیره داده های متنی بزرگ در آنجا نیست، زیرا یک پایگاه داده نیست، یک سرور هماهنگی عمل است.
من کمی در مورد جلسات به شما می گویم. اگر چندین سرور داشته باشیم، می‌توانیم با استفاده از شناسه جلسه به‌طور شفاف از سروری به سرور دیگر حرکت کنیم. این کاملا راحت است.
هر جلسه نوعی تایم اوت دارد. یک جلسه به این صورت تعریف می شود که آیا کلاینت در طول آن جلسه چیزی به سرور ارسال می کند یا خیر. اگر در طول تایم اوت چیزی ارسال نکرد، جلسه از بین می‌رود یا مشتری می‌تواند خودش آن را ببندد.
ویژگی های زیادی ندارد، اما می توانید کارهای مختلفی را با این API انجام دهید. آن فراخوانی که دیدیم ایجاد شد یک znode ایجاد می کند و سه پارامتر را می گیرد. این مسیر znode است و باید به طور کامل از ریشه مشخص شود. و همچنین این برخی از داده هایی است که می خواهیم به آنجا منتقل کنیم. و نوع پرچم. و بعد از ایجاد مسیر را به znode برمی گرداند.
دوم، شما می توانید آن را حذف کنید. ترفند اینجاست که پارامتر دوم، علاوه بر مسیر znode، می تواند نسخه را نیز مشخص کند. بر این اساس، آن znode حذف می شود اگر نسخه ای که ما انتقال داده ایم معادل نسخه ای باشد که در واقع وجود دارد.
اگر نمی خواهیم این نسخه را بررسی کنیم، به سادگی آرگومان "-1" را پاس می کنیم.
سوم، وجود znode را بررسی می کند. اگر گره وجود داشته باشد true و در غیر این صورت false را برمی گرداند.
و سپس ساعت پرچم ظاهر می شود، که به شما امکان می دهد این گره را نظارت کنید.
شما می‌توانید این پرچم را حتی روی یک گره که وجود ندارد تنظیم کنید و هنگامی که ظاهر شد یک اعلان دریافت کنید. این نیز می تواند مفید باشد.
چند چالش دیگر وجود دارد دریافت داده. واضح است که می توانیم داده ها را از طریق znode دریافت کنیم. همچنین می توانید از ساعت پرچم استفاده کنید. در این صورت، اگر گره ای وجود نداشته باشد، نصب نمی شود. بنابراین، باید درک کنید که وجود دارد و سپس داده ها را دریافت کنید.
نیز وجود دارد SetData. در اینجا نسخه را پاس می کنیم. و اگر این را منتقل کنیم، داده های znode یک نسخه خاص به روز می شود.
شما همچنین می توانید "-1" را برای حذف این چک مشخص کنید.
روش مفید دیگر این است بچه ها بگیر. ما همچنین می توانیم لیستی از تمام znode هایی که به آن تعلق دارند را دریافت کنیم. ما می‌توانیم این موضوع را با تنظیم ساعت پرچم نظارت کنیم.
و روش همگام اجازه می دهد تا همه تغییرات به یکباره ارسال شوند، در نتیجه اطمینان حاصل شود که آنها ذخیره شده اند و همه داده ها به طور کامل تغییر کرده اند.
اگر با برنامه نویسی معمولی قیاس هایی را ترسیم کنیم، وقتی از روش هایی مانند نوشتن استفاده می کنید که چیزی را روی دیسک می نویسد و بعد از اینکه پاسخی به شما می دهد، هیچ تضمینی وجود ندارد که داده ها را روی دیسک نوشته اید. و حتی زمانی که سیستم عامل مطمئن است که همه چیز نوشته شده است، مکانیسم هایی در خود دیسک وجود دارد که در آن فرآیند از لایه های بافر عبور می کند و تنها پس از آن داده ها روی دیسک قرار می گیرند.
بیشتر از تماس های ناهمزمان استفاده می شود. این به مشتری اجازه می دهد تا به موازات درخواست های مختلف کار کند. شما می توانید از رویکرد همزمان استفاده کنید، اما بهره وری کمتری دارد.
دو عملیاتی که در مورد آنها صحبت کردیم به روز رسانی/نوشتن هستند که داده ها را تغییر می دهند. اینها ایجاد، تنظیم داده، همگام سازی، حذف هستند. و read is exist، getData، getChildren.
اکنون چند نمونه از این که چگونه می توانید برای کار در یک سیستم توزیع شده، اولیه بسازید. به عنوان مثال، مربوط به پیکربندی چیزی است. یک کارگر جدید ظاهر شده است. ما دستگاه را اضافه کردیم و فرآیند را شروع کردیم. و سه سوال زیر وجود دارد. چگونه ZooKeeper را برای پیکربندی پرس و جو می کند؟ و اگر بخواهیم تنظیمات را تغییر دهیم، چگونه آن را تغییر دهیم؟ و بعد از اینکه آن را تغییر دادیم، کارگرانی که ما داشتیم چگونه آن را دریافت می کنند؟
ZooKeeper این کار را نسبتاً آسان می کند. به عنوان مثال، درخت znode ما وجود دارد. یک گره برای برنامه ما در اینجا وجود دارد، ما یک گره اضافی در آن ایجاد می کنیم که حاوی داده هایی از پیکربندی است. اینها ممکن است پارامترهای جداگانه باشند یا نباشند. از آنجایی که اندازه کوچک است، اندازه پیکربندی نیز معمولاً کوچک است، بنابراین ذخیره آن در اینجا کاملاً امکان پذیر است.
شما از روش استفاده می کنید دریافت داده برای دریافت پیکربندی کارگر از گره. روی true تنظیم کنید. اگر به دلایلی این گره وجود نداشته باشد، هنگام ظاهر شدن یا تغییر آن، از آن مطلع خواهیم شد. اگر بخواهیم بدانیم چیزی تغییر کرده است، آن را روی true قرار می دهیم. و اگر داده های این گره تغییر کند، از آن مطلع خواهیم شد.
SetData. ما داده ها را تنظیم می کنیم، "-1" را تنظیم می کنیم، یعنی نسخه را بررسی نمی کنیم، فرض می کنیم همیشه یک پیکربندی داریم، نیازی به ذخیره تنظیمات زیادی نداریم. اگر نیاز به ذخیره زیاد دارید، باید سطح دیگری را اضافه کنید. در اینجا ما معتقدیم که فقط یکی وجود دارد، بنابراین ما فقط آخرین نسخه را به روز می کنیم، بنابراین نسخه را بررسی نمی کنیم. در این لحظه، همه مشتریانی که قبلا مشترک شده اند، اعلانی مبنی بر تغییر چیزی در این گره دریافت می کنند. و پس از دریافت، باید دوباره داده را درخواست کنند. اعلان این است که آنها خود داده ها را دریافت نمی کنند، بلکه فقط اعلان تغییرات را دریافت می کنند. پس از این، آنها باید برای داده های جدید بپرسند.
گزینه دوم برای استفاده از primitive است عضویت در گروه. ما یک برنامه توزیع شده داریم، یک دسته کارگر وجود دارد و می خواهیم بفهمیم که همه آنها سر جای خود هستند. بنابراین، آنها باید خودشان ثبت نام کنند که در برنامه ما کار می کنند. و همچنین می‌خواهیم در مورد همه کارگران فعالی که در حال حاضر داریم، یا از فرآیند Master یا جای دیگر، اطلاعاتی در مورد آنها پیدا کنیم.
چطور این کار را انجام دهیم؟ برای برنامه، یک گره کارگر ایجاد می کنیم و با استفاده از متد ایجاد، یک زیرسطح را در آنجا اضافه می کنیم. من یک خطا در اسلاید دارم. در اینجا شما نیاز دارید متوالی مشخص کنید، سپس همه کارگران یک به یک ایجاد خواهند شد. و برنامه با درخواست تمام داده های مربوط به فرزندان این گره، تمام کارگران فعال موجود را دریافت می کند.
این یک پیاده سازی وحشتناک از نحوه انجام این کار در کد جاوا است. بیایید از آخر با روش اصلی شروع کنیم. این کلاس ماست، بیایید متد آن را ایجاد کنیم. به عنوان اولین آرگومان از میزبان استفاده می کنیم، جایی که در حال اتصال هستیم، یعنی آن را به عنوان آرگومان تنظیم می کنیم. و آرگومان دوم نام گروه است.
ارتباط چگونه اتفاق می افتد؟ این یک مثال ساده از API است که استفاده می شود. همه چیز در اینجا نسبتاً ساده است. یک ZooKeeper کلاس استاندارد وجود دارد. میزبان ها را به آن پاس می دهیم. و تایم اوت را مثلاً روی 5 ثانیه تنظیم کنید. و ما عضوی به نام connectSignal داریم. در اصل، ما یک گروه در طول مسیر انتقال ایجاد می کنیم. ما داده‌ها را در آنجا نمی‌نویسیم، اگرچه می‌توانست چیزی نوشته شود. و گره در اینجا از نوع پایدار است. در اصل، این یک گره معمولی معمولی است که همیشه وجود خواهد داشت. این جایی است که جلسه ایجاد می شود. این پیاده سازی خود مشتری است. مشتری ما پیام های دوره ای ارسال می کند که نشان می دهد جلسه زنده است. و وقتی جلسه را به پایان می‌رسانیم، نزدیک را صدا می‌زنیم و تمام، جلسه از بین می‌رود. این در صورتی است که چیزی برای ما بیفتد، تا ZooKeeper از آن مطلع شود و جلسه را قطع کند.
چگونه یک منبع را قفل کنیم؟ در اینجا همه چیز کمی پیچیده تر است. ما مجموعه‌ای از کارگران داریم، منابعی وجود دارد که می‌خواهیم قفل کنیم. برای انجام این کار، یک گره جداگانه ایجاد می کنیم، به عنوان مثال به نام lock1. اگر ما توانستیم آن را ایجاد کنیم، در اینجا یک قفل داریم. و اگر نتوانستیم آن را ایجاد کنیم، کارگر سعی می کند getData را از اینجا دریافت کند و چون گره قبلا ایجاد شده است، در اینجا یک تماشاگر قرار می دهیم و لحظه ای که وضعیت این گره تغییر می کند، از آن مطلع خواهیم شد. و ما می توانیم سعی کنیم زمانی برای بازسازی آن داشته باشیم. اگر این گره را گرفتیم، این قفل را گرفتیم، پس از اینکه دیگر به قفل نیاز نداشتیم، آن را رها می کنیم، زیرا گره فقط در جلسه وجود دارد. بر این اساس از بین خواهد رفت. و یک کلاینت دیگر در چارچوب یک جلسه دیگر می تواند قفل این گره را بگیرد یا بهتر است بگوییم اعلانی دریافت می کند که چیزی تغییر کرده است و می تواند به موقع آن را انجام دهد.
مثال دیگری از اینکه چگونه می توانید رهبر اصلی را انتخاب کنید. این کمی پیچیده تر است، اما همچنین نسبتا ساده است. اینجا چه خبره؟ یک گره اصلی وجود دارد که همه کارگران را جمع می کند. ما در حال تلاش برای به دست آوردن اطلاعات در مورد رهبر هستیم. اگر این با موفقیت اتفاق بیفتد، یعنی ما برخی از داده ها را دریافت کنیم، کارگر ما شروع به دنبال کردن این رهبر می کند. او معتقد است که در حال حاضر یک رهبر وجود دارد.
اگر رهبر به دلایلی فوت کرد، به عنوان مثال، سقوط کرد، پس ما سعی می کنیم یک رهبر جدید ایجاد کنیم. و اگر موفق شویم، کارگر ما رهبر می شود. و اگر کسی در این لحظه موفق به ایجاد یک رهبر جدید شد، ما سعی می کنیم بفهمیم که کیست و سپس او را دنبال کنیم.
در اینجا به اصطلاح اثر گله ای به وجود می آید، یعنی اثر گله ای، زیرا وقتی رهبر بمیرد، آن که در زمان اول است، رهبر می شود.
هنگام گرفتن یک منبع، می توانید سعی کنید از یک رویکرد کمی متفاوت استفاده کنید که به شرح زیر است. به عنوان مثال، ما می خواهیم یک قفل دریافت کنیم، اما بدون اثر هرت. این شامل این واقعیت است که برنامه ما لیستی از تمام شناسه گره ها را برای یک گره از قبل موجود با یک قفل درخواست می کند. و اگر قبل از آن گره ای که برای آن قفل ایجاد کرده ایم کوچکترین مجموعه ای باشد که دریافت کرده ایم، این بدان معناست که ما قفل را گرفته ایم. بررسی می کنیم که قفل دریافت کرده ایم. به عنوان چک، شرطی وجود دارد که شناسه ای که هنگام ایجاد یک قفل جدید دریافت کرده ایم حداقل باشد. و اگر آن را دریافت کردیم، بیشتر کار می کنیم.
اگر شناسه خاصی وجود داشته باشد که کوچکتر از قفل ما باشد، در این رویداد یک تماشاگر قرار می دهیم و منتظر اعلان می شویم تا چیزی تغییر کند. یعنی ما این قفل را دریافت کردیم. و تا زمانی که از بین نرود ما به حداقل شناسه تبدیل نمی شویم و حداقل قفل را دریافت نمی کنیم و به این ترتیب می توانیم وارد شویم. و اگر این شرط برآورده نشد، بلافاصله به اینجا می رویم و سعی می کنیم دوباره این قفل را بگیریم، زیرا ممکن است در این مدت چیزی تغییر کرده باشد.
ZooKeeper از چه چیزی تشکیل شده است؟ 4 چیز اصلی وجود دارد. این فرآیندهای پردازش است - درخواست. و همچنین ZooKeeper Atomic Broadcast. یک Commit Log وجود دارد که در آن همه عملیات ثبت می شود. و خود DB Replicated In-Memory، یعنی خود پایگاه داده که کل این درخت در آن ذخیره می شود.
شایان ذکر است که تمام عملیات نوشتن از طریق Request Processor انجام می شود. و عملیات خواندن مستقیماً به پایگاه داده In-memory می رود.
خود پایگاه داده کاملاً تکرار شده است. همه نمونه های ZooKeeper یک کپی کامل از داده ها را ذخیره می کنند.
برای بازیابی پایگاه داده پس از خرابی، یک گزارش Commit وجود دارد. رویه استاندارد این است که قبل از اینکه داده‌ها وارد حافظه شوند، در آنجا نوشته می‌شوند تا در صورت خراب شدن، این گزارش پخش شود و وضعیت سیستم بازیابی شود. و از عکس های فوری دوره ای پایگاه داده نیز استفاده می شود.
ZooKeeper Atomic Broadcast چیزی است که برای نگهداری داده های تکراری استفاده می شود.
ZAB به صورت داخلی یک رهبر را از نقطه نظر گره ZooKeeper انتخاب می کند. گره های دیگر پیروان او می شوند و از او انتظار برخی اقدامات را دارند. اگر ورودی دریافت کنند، همه آنها را به رهبر ارسال می کنند. او ابتدا یک عملیات نوشتن را انجام می دهد و سپس پیامی در مورد آنچه تغییر کرده است به دنبال کنندگانش می فرستد. این، در واقع، باید به صورت اتمی انجام شود، یعنی عملیات ضبط و پخش کل چیز باید به صورت اتمی انجام شود، در نتیجه ثبات داده ها را تضمین می کند.
فقط درخواست های نوشتن را پردازش می کند. وظیفه اصلی آن این است که عملیات را به یک به روز رسانی تراکنش تبدیل می کند. این یک درخواست خاص است.
و در اینجا شایان ذکر است که عدم توانایی به روز رسانی برای همان عملیات تضمین شده است. آن چیست؟ این مورد اگر دو بار اجرا شود همان حالت را خواهد داشت یعنی خود درخواست تغییر نمی کند. و این باید انجام شود تا در صورت خرابی، بتوانید عملیات را مجدداً راه اندازی کنید و در نتیجه تغییراتی را که در حال حاضر حذف شده اند به عقب برگردانید. در این صورت وضعیت سیستم یکسان می شود، یعنی نباید یک سری از همان ها، مثلاً فرآیندهای به روز رسانی، منجر به حالت های نهایی متفاوتی از سیستم شود.
منبع: www.habr.com