الزامات عملکردی:
- چت 1 به 1
- آخرین بار
- گپ گروهی
- فقط متن (رمزگذاری E2E)
الزامات غیر عملکردی:
- پیام ها باید به سرعت به گیرنده برسند.
- ارتباطات باید در زمان واقعی باشد.
فرض
الزامات عملکردی:
- 3 میلیارد کاربر فعال ماهانه ، 2 میلیارد کاربر فعال روزانه ، با 33 دقیقه استفاده روزانه در هر کاربر.
- هر کاربر 10 بار در دقیقه وضعیت “آخرین دیده شده” را ارسال می کند.
- 5 ٪ از 2 میلیارد = 100 میلیون کاربر همزمان فعال.
- 100 میلیارد پیام در روز یا 2 کیلوبایت × 100 میلیارد = 2 × 10 kb = 200 سل در روز.
- 100 میلیارد پیام در روز = 1.16 میلیون پیام در ثانیه.
- ما برای رمزگذاری پایان تا پایان از پروتکل سیگنال استفاده خواهیم کرد
تخمین ظرفیت
- 3 میلیارد کاربر فعال ماهانه ، 2 میلیارد کاربر فعال روزانه ، با 33 دقیقه استفاده روزانه.
- 100 میلیون کاربر همزمان فعال.
- 100 میلیارد پیام در روز = 1.16 میلیون پیام در ثانیه.
حل نیازهای عملکردی
هر زمان که کاربر از برنامه استفاده کند ، هر دقیقه 10 بار پیام “آخرین دیده شده” ارسال می کند تا دیگران بتوانند وضعیت آنلاین خود را بدانند. این داده ها در یک خوشه Cassandra DB ذخیره می شوند.
ذخیره مورد نیاز = 0.1kb × 10 × 33 × 2 میلیارد = 66 سل.
این همچنین به عنوان مکانیسم ضربان قلب شناخته می شود.
اگر کسی برگه چت آن شخص را باز کند ، ما فقط وضعیت آنلاین شخص را درخواست خواهیم کرد.
مشخصات کاربر و داده های تماس در یک خوشه MySQL ذخیره می شوند.
ما از WebSockets برای ارتباطات در زمان واقعی استفاده خواهیم کرد (تمام وقت آنلاین).
حداکثر تعداد اتصالات سوکت به شدت به پشته و سخت افزار فناوری بستگی دارد.
سخت افزار سرور: رم 128 گیگابایتی ، پهنای باند 10 گیگابیت در ثانیه ، 32 VCPU – قادر به پشتیبانی از 2 میلیون سوکت.
پشته فناوری سرور:
سرور مبتنی بر Erlang: از 2 میلیون سوکت پشتیبانی می کند.
node.js ، go یا java: از سوکت 100 تا 500k پشتیبانی می کند.
بنابراین ، ما از یک سرور مبتنی بر Erlang برای کنترل همه چیز در 100 میلیون / 2 میلیون = 50 سرور استفاده خواهیم کرد.
برای ایمنی ، از 100 سرور استفاده خواهیم کرد. در غیر این صورت ، ما فقط به 500-1000 سرور فقط برای سوکت نیاز داریم.
هنگامی که گیرنده آفلاین است:
ما داده های پیام را به صف خوشه کافکا ارسال خواهیم کرد تا وقتی گیرنده آنلاین می شود ، پیام را می توان از طریق WebSocket در زمان واقعی تحویل داد. پیام ها همچنین به طور دائم در خوشه Cassandra DB ذخیره می شوند.
وقتی هر دو کاربر آنلاین هستند:
هر کاربر اطلاعات اتصال خود را در یک خوشه Redis DB ثبت می کند و نشان می دهد که به کدام سرور WebSocket متصل شده اند. هنگامی که کاربر A پیام را به کاربر B ارسال می کند ، از این اطلاعات برای یافتن سرور صحیح استفاده می شود و از یک میخانه/زیر میخانه Redis برای ارسال پیام از یک سرور WebSocket به دیگری استفاده می شود.
ما از یک صف خوشه Kafka برای پخش پیام ها به اعضای گروه دیگر به صورت آنلاین استفاده خواهیم کرد.
ردیابی که پیام را خوانده است یک عمل گران است – تصور گروهی با 1 میلیون کاربر – بنابراین ما اندازه گروه ها را برای کاهش هزینه و پیچیدگی محدود می کنیم.
