برنامه های کاربردی آنلاین در مقیاس بزرگ در دو دهه گذشته راه طولانی را طی کرده اند. این نوآوری ها برداشت ما از توسعه نرم افزار را تغییر داده است. برای مثال فیس بوک، اینستاگرام و توییتر همگی پلتفرم های مقیاس پذیر هستند.
این سیستم ها باید به گونه ای ساخته شوند که حجم عظیمی از ترافیک و داده را مدیریت کنند زیرا میلیاردها نفر در سراسر جهان به طور همزمان از آنها استفاده می کنند. این زمانی است طراحی سیستم وارد عکس می شود
فرآیند ایجاد معماری، رابطها و دادهها برای سیستمی که معیارهای خاصی را برآورده میکند، طراحی سیستم نامیده میشود. از طریق سیستم های منسجم و کارآمد، طراحی سیستم خواسته های کسب و کار یا سازمان شما را برآورده می کند.
هنگامی که شرکت یا سازمان شما معیارهای خود را مشخص کرد، می توانید شروع به ترکیب آنها در طراحی سیستم فیزیکی کنید که خواسته های مصرف کنندگان شما را برآورده می کند.
این که آیا توسعه سفارشی، راه حل های تجاری یا ترکیبی از این دو را انتخاب می کنید، نحوه طراحی سیستم شما تعیین کننده نحوه ساخت آن است.
ما در این پست با یک آموزش کامل به طراحی سیستم تایم لاین توییتر خواهیم پرداخت. بیا شروع کنیم.
مرحله 1: موارد استفاده و محدودیت ها را ترسیم کنید
مورد استفاده
- یک کاربر یک توییت آپلود می کند.
- این سرویس اعلانها و ایمیلهایی را برای دنبالکنندگان توییتها ارسال میکند.
- جدول زمانی کاربر مشاهده می شود (فعالیت از طرف کاربر)
- کاربر به جدول زمانی خانه نگاه می کند (فعالیت افرادی که کاربر دنبال می کند)
- کلمات کلیدی توسط کاربر جستجو می شود.
- خدمات واقعا در دسترس است.
خارج از دامنه
- توییتها با استفاده از این سرویس به Twitter Firehose و سایر جریانها ارسال میشوند.
- این سرویس توییت ها را بر اساس تنظیمات دید کاربر حذف می کند.
- اگر کاربر نیز فردی را که به او پاسخ داده شده دنبال نمی کند، پاسخ را پنهان کنید.
- گزینه "مخفی کردن retweets" را مشاهده کنید.
- تجزیه و تحلیل ترافیک
محدودیت ها و مفروضات
مفروضات دولتی
- ترافیک به طور مساوی پراکنده نمی شود.
- ارسال یک توییت باید ساده باشد.
- مگر اینکه میلیون ها فالوور داشته باشید، ارسال یک توییت برای همه دنبال کنندگان شما باید سریع باشد.
- 100 میلیون کاربر فعال وجود دارد.
- 15 میلیارد توییت در هر ماه یا 500 میلیون توییت در هر روز
- هر توییت به طور متوسط 10 پیام ارسال دارد.
- هر روز، fanout 5 میلیارد توییت ارسال می کند.
- Fanout هر ماه 150 میلیارد توییت ارسال می کند.
- 250 میلیارد درخواست خواندن ماهانه
- 10 میلیارد جستجوی ماهانه
گاهشمار
- مسیر زمانی باید آسان باشد.
- توییتر بیشتر در مورد خواندن است تا نوشتن.
- بهینه سازی برای خواندن سریع توییت
- مصرف توییت وقت گیر است.
جستجو
- فرآیند جستجو باید سریع باشد.
- جستجو زمان بر است.
محاسبه میزان مصرف
اندازه هر توییت:
- شناسه توییت 8 بایتی
- شناسه کاربری 32 بایت
- 140 بایت متن
- رسانه - میانگین 10 کیلوبایت
- مجموع: 10 کیلوبایت
هر ماه 150 ترابایت محتوای توییت تازه تولید می شود.
- * 500 میلیون توییت در هر روز * 30 روز در ماه * 10 کیلوبایت در هر توییت
- در طی سه سال، 5.4 PB محتوای توییت تازه وجود داشته است.
در هر ثانیه 100,000 درخواست خواندن وجود دارد.
- * (400 درخواست در ثانیه / 1 میلیارد درخواست در ماه) 250 میلیارد درخواست خواندن در هر ماه
در هر ثانیه 6,000 توییت وجود دارد.
- * (400 درخواست در ثانیه / 1 میلیارد درخواست در ماه) 15 میلیارد توییت در هر ماه
در fanout، 60 هزار توییت در هر ثانیه ارسال می شود.
- Fanout هر ماه 150 میلیارد توییت را ارائه می دهد* (400 درخواست در ثانیه / 1 میلیارد درخواست در ماه).
4,000 درخواست اطلاعات در هر ثانیه
- * (400 درخواست در ثانیه / 1 میلیارد درخواست در ماه) 10 میلیارد جستجو در هر ماه
چند تبدیل مفید
- هر ماه 2.5 میلیون ثانیه می گذرد.
- 2.5 میلیون درخواست در ماه با 1 درخواست در ثانیه
- 100 میلیون درخواست در ماه x 40 درخواست در ثانیه
- 1 میلیارد درخواست در ماه = 400 درخواست در ثانیه
مرحله 2: نمودار سطح بالا
مرحله 3: توضیح اجزای اصلی
ما میتوانیم توییتهای خود کاربر را ذخیره کنیم تا در صورت ارسال توییت، جدول زمانی کاربر (فعالیت از کاربر) را در یک پایگاه داده رابطهای پر کنیم. ارسال توییت و توسعه جدول زمانی خانه (فعالیت افرادی که کاربر دنبال می کند) دشوارتر است.
یک پایگاه داده رابطهای معمولی با انتشار توییتها برای همه دنبالکنندگان (۶۰ هزار توییت در هر ثانیه) غرق میشود. احتمالاً میخواهیم از یک ذخیرهسازی سریع اطلاعات مانند پایگاه داده NoSQL یا حافظه پنهان استفاده کنیم.
خواندن متوالی 1 مگابایت از حافظه تقریباً 250 میکروثانیه طول می کشد، اما خواندن از SSD 4 برابر و خواندن از روی دیسک 80 برابر طول می کشد.
یک Object Store می تواند برای ذخیره داده هایی مانند تصاویر و فیلم ها استفاده شود.
- وب سرور، که به عنوان یک پروکسی معکوس عمل می کند، یک توییت از مشتری دریافت می کند.
- درخواست توسط وب سرور به سرور Write API ارسال می شود.
- Write API توییت را در پایگاه داده SQL در جدول زمانی کاربر ذخیره می کند.
Write API با سرویس Fan-out تماس می گیرد و وظایف زیر را انجام می دهد.
- فالوورهای کاربر را در حافظه پنهان با پرس و جو از سرویس نمودار کاربر پیدا می کند.
- در حافظه پنهان، توییت در تایم لاین اصلی دنبال کنندگان کاربر ذخیره می شود.
- 1,000 فالوور = 1,000 جستجو و درج = عملیات O(n).
- توییت برای جستجوی سریع در سرویس جستجوی فهرست ذخیره می شود.
- Object Store برای ذخیره رسانه ها استفاده می شود.
- هشدارهای فشاری را از طریق سرویس اطلاع رسانی به دنبال کنندگان ارسال می کند.
- برای ارسال هشدارها به صورت ناهمزمان، از یک صف استفاده می کند.
اگر حافظه پنهان ما Redis باشد، می توانیم از یک لیست Redis بومی با ساختار زیر استفاده کنیم:
جدول زمانی خانه کاربر با توییت جدید که در حافظه پنهان ذخیره می شود، به روز می شود. ما از REST API عمومی زیر استفاده خواهیم کرد:
جدول زمانی کاربر توسط کاربر مشاهده می شود.
- وب سرور درخواست خط زمانی کاربر را از مشتری دریافت می کند.
- درخواست توسط وب سرور به سرور Read API ارسال می شود.
- Read API پایگاه داده SQL را برای بازه زمانی کاربر پرس و جو می کند.
REST API مشابه تایم لاین خانه کار می کند، با این استثنا که همه توییت ها به جای افرادی که آنها را دنبال می کنند، از کاربر سرچشمه می گیرند.
کاربر کلمات کلیدی را جستجو می کند:
- وب سرور یک درخواست جستجو از مشتری دریافت می کند.
- درخواست توسط وب سرور به سرور جستجوی API ارسال می شود.
مرحله 4: جدول زمانی توییتر
ایجاد جدول زمانی کار دشواری است. یک سرور تولید کننده جدول زمانی که به وب یا سرورهای برنامه پیوند دارد مورد نیاز است.
هر بار که کاربر وارد سیستم می شود، سرویس تایم لاین جدیدترین توییت های کاربران را در جدول فالوور پیگیری می کند و تایم لاین کاربر را به روز می کند یا تازه می کند.
ما هیچ نوع سیستم رتبه بندی را در اینجا پیاده سازی نمی کنیم. در عوض، ما فرض می کنیم که 5 توییت برتر از طرفداران کاربر به ترتیب زمان ایجاد در جدول زمانی ارائه شده است. ما می توانیم یک قطع بازخوانی 50 توییتی را حفظ کنیم. ما همچنان پس از رسیدن به آن آستانه، بازخوانی یا ایجاد خط زمانی را متوقف می کنیم تا زمانی که کاربر صفحه را بازخوانی کند.
نگرانیهای مربوط به تأخیر و عملکرد بالا ناشی از ایجاد فید کاربر زنده است. درعوض، ایجاد یک جریان آفلاین که بتواند فوراً ارائه شود، بهترین راه برای بهبود عملکرد است. سرورهای اختصاصی تایم لاین را اجرا کنید که سرور برنامه را به طور منظم پینگ می کنند تا فید بر اساس زمان ایجاد آن به روز شود.
الگوریتم رتبهبندی باید سیگنالهای حیاتی را در نظر بگیرد و وزنی را برای تضمین اینکه جدول زمانی کاربر تحت سلطه مطالب یک یا چند حساب کاربری که دنبال میکنند، نباشد، ارائه دهد.
بهطور دقیقتر، میتوانیم ویژگیهای مربوط به ارتباط هر مورد فید را انتخاب کنیم، مانند تعداد لایکها، نظرات، اشتراکگذاریها و زمان بهروزرسانی. هر یک از این معیارها باید برای رتبه بندی توییت استفاده شود و سپس از آن رتبه برای نمایش توییت ها در تایم لاین استفاده شود.
آیا زمانی که محتوای جدید برای فید خبری آنها در دسترس قرار می گیرد، باید مدام به کاربران هشدار دهیم؟ وقتی دادههای جدید در دسترس قرار میگیرد، کاربران میتوانند هشدار دهند. با این حال، در دستگاه های تلفن همراه، زمانی که استفاده از داده بسیار پرهزینه است، می تواند پهنای باند را هدر دهد.
در نتیجه، میتوانیم تصمیم بگیریم که دادهها را به دستگاههای تلفن همراه فشار ندهیم و به جای آن به کاربران اجازه دهیم برای پستهای جدید «بهروزرسانی» را انجام دهند.
مرحله 5: طراحی مقیاس
یک گلوگاه بالقوه سرویس Fanout است. کاربران توییتر با میلیونها فالوور باید چند دقیقه منتظر بمانند تا توییتهایشان منتشر شود. این ممکن است باعث مسابقه ای با پاسخ به توییت شود، که می توانیم با سفارش مجدد توییت ها در زمان سرویس از آن جلوگیری کنیم.
همچنین میتوانیم از انتشار توییتهای افرادی با تعداد فالوورهای زیادی جلوگیری کنیم. در عوض، ممکن است توییتهایی را از افراد بسیار دنبالشده جستجو کنیم، نتایج جستجو را با نتایج جدول زمانی صفحه اصلی کاربر ادغام کنیم و سپس توییتها را در زمان ارائه مجدد ترتیب دهیم.
پیشرفت های اضافی عبارتند از:
- برای هر خط زمانی خانه، فقط چند صد توییت را در حافظه پنهان نگه دارید.
- در حافظه پنهان، فقط اطلاعات جدول زمانی خانه کاربران فعال ذخیره می شود.
- اگر کاربر در 30 روز قبل فعال نبوده است، میتوانیم گاهشماری را از پایگاه داده SQL بازسازی کنیم.
- برای اینکه متوجه شوید کاربر کیست، از سرویس نمودار کاربر استفاده کنید.
- توییت ها را با بازیابی آنها از پایگاه داده SQL به حافظه پنهان اضافه کنید.
- سرویس اطلاعات توییت فقط می تواند توییت های یک ماه را ذخیره کند.
- در سرویس اطلاعات کاربر، فقط کاربران فعال ذخیره می شوند.
- برای پایین نگه داشتن تاخیر، خوشه جستجو به احتمال زیاد نیاز به حفظ توییت ها در حافظه دارد.
نتیجه
اگرچه توییتر یک سازمان بزرگ است، اما بهتر است درک طراحی سیستم. من تمام تلاشم را کردم تا یک نمای کلی از جدول زمانی توییتر به شما ارائه دهم.
امیدوارم اطلاعات مفیدی از آن به دست آورده باشید و بتوانید از آن به خوبی استفاده کنید.
پاسخ دهید