Содржина[Крие][Прикажи]
Инстаграм Feed е платформа за споделување и поврзување со луѓето и работите што ви се важни. Кога ќе го отворите Instagram или ќе го освежите вашиот довод, фотографиите и видеата за кои мислиме дека ќе ве интересираат ќе се прикажат на врвот.
Доводот на вести е збирка на ставки што содржат текст, слики или видеа создадени од други ентитети во системот што се наменети за читање. Секогаш се менува, додека другите организации прават нови објави.
Во овој пост, внимателно ќе го разгледаме системскиот дизајн на доводот на Инстаграм. Значи, да започнеме.
1. Барања
Функционална неопходност
- Информацијата за вести на корисникот е креирана од објави од други субјекти во системот што корисникот ги следел или за кои е заинтересиран.
- Текст, слики и видеа може да се најдат во објавите.
- Информацијата за вести на корисникот треба да се ажурира со нови објави создадени од други.
Нефункционален критериум
- Создавањето на вести треба да се одвива во реално време. Крајниот корисник треба да доживее само 12 секунди доцнење.
- Додавање нова објава: Не треба да поминат повеќе од 5 секунди за да се појави нова објава во барањето за вести откако ќе се достави до системот.
2. Проценка на капацитетот
- Од март 2021 година, светската популација е само 7.8 милијарди луѓе. Тоа покажува дека 21% од светската популација е Facebook DAU (Дневен активен корисник) и 32% е Facebook MAU (месечен активен корисник) (месечен активен корисник). Тоа е неверојатно.
- Ајде да се преправаме дека системот што го конструираме има 1 милијарда DAU за да ги олесниме работите.
- Да претпоставиме дека едно лице следи 500 луѓе или бизниси на Фејсбук. Група или страница може да се смета за ентитет.
Проценет сообраќај
Претпоставете дека еден корисник во просек ја презема вестите 10 пати на ден. Значи, тоа е приближно 116K QPS и 1e10 барања секој ден.
Проценки за складирање
Да претпоставиме дека одржуваме 500 објави од вестите на секој корисник во меморијата во просек за брзо пребарување, а секоја објава е со големина од 1KB. Значи 500 KB по корисник, 500 TB за сите DAU и 5000 компјутери со по 100 GB RAM.
3. API за системи
userId (GUID): корисник чиј извор на вести се презема.
Следниве полиња се достапни во параметарот опционални опции:
- afterPostId (GUID): добијте ја вестите од објавата по оваа. Ако не е одредено, добијте ги најновите објави.
- count (број): максималниот број на објави што секое барање може да го врати. Заднината поставува стандарден максимален број ако не е доставен.
- excludeReplies (boolean): спречува одговорите да бидат вклучени во вестите.
- Вратениот JSON содржи список со ставки за вести.
4. Дизајнирање на база на податоци
Субјекти
- Корисникот
- entityId, име, опис и временски печат се сите задолжителни полиња.
- Потребни се следните полиња: PostId, наслов, текст, авторски ID и временски печат.
- временски печат, url и mediaId
Односи
- Други корисници или ентитети може да бидат следени од корисник. (m:n)
- Автор-пост: и корисниците и ентитетите можат да креираат објави. Претпоставете дека само корисниците можат да креираат објави заради едноставност. (1:n; authorId може да се вградува).
- Секој пост е придружен со некој вид медиум. (1:n)
5. Дизајн на високо ниво
Архитектура
Workflows
Производство на добиточна храна
Кога Џеј ќе побара нејзин пренос на вести, системот ќе го стори следново:
- Повлечете ги личните карти на сите луѓе и работи што ги следи Џеј.
- Збирни објави: со оглед на тие лични карти, добијте ги најновите, популарни и релевантни објави.
- Рангирајте ги објавите според нивната релевантност и време.
- Кеш: зачувајте ги креираните доводи и испратете ги на Џеј првите 20 објави.
- Кога Џеј ќе заврши со читање на првите 20 објави, се испраќа уште едно барање за добивање на следните 20 објави.
Дистрибуција на добиточна храна
Да претпоставиме дека Џеј го следи Ајуш и дека Ајуш објавува нешто ново. Системот ќе треба да ги ажурира вестите на Џеј:
- Повлечете ги личните карти на следбениците на Ајуш.
- Додадете нови написи: додајте ја објавата на Ајуш во базенот за вести на следбениците на тие лични карти.
- Рангирајте ги објавите според нивната релевантност и време.
- Ажурирајте го кешот на објавата за рангирање.
- Следбениците треба да бидат известени кога се објавуваат нови објави.
Компоненти
Врските на корисниците се одржуваат од веб-сервери.
Постапките наведени погоре ги извршува серверот за апликација.
Кеш и база на податоци:
- Корисник/ентитет на релациона база на податоци
- Релациона база на податоци (објава)
- Атрибут на слика/видео: Aayush storge
- Метаподатоци за релациона база на податоци
Персонализирани услуги:
- Производство на добиточна храна
- Известување за доводи
6. Детален дизајн
Генерирање на добиточна храна
Наивна имплементација се чита со вентилатор:
Проблемите со оваа невешт имплементација вклучуваат:
- Корисниците со голем број пријатели/следбеници ќе забележат значително забавување бидејќи мораме да просејуваме, споиме и рангираме голем број објави.
- Кога корисникот ја вчитува својата страница, ние ја конструираме временската линија. Ова може да биде слабо и да има многу латентност.
- Секое ажурирање статус ќе резултира со ажурирања на храна за сите следбеници за ажурирања во живо. Ова може да предизвика значителни доцнења во нашата услуга за генерирање на вести.
Можеме однапред да ја генерираме хронологијата и да ја зачуваме во меморија за да ја зголемиме ефикасноста.
Офлајн продукција (Фан-аут пишуваат)
Можеме да имаме посветени сервери кои постојано создаваат и складираат вести на корисниците во меморијата. Можеме само да го испорачаме изворот на вести од претходно генерираната, зачувана локација секогаш кога корисникот го сака.
Колку доводни ставки треба да се складира во меморијата на доводот на корисникот?
Прилагодете се врз основа на вашето однесување при користењето.
Дали треба да направиме newsfeed за сите корисници (и да го зачуваме во меморија)?
- За луѓе кои не се најавуваат многу често.
- Кеширањето базирано на LRU е едноставен пристап.
- Подобро решение е да дознаете како корисниците се најавуваат. Кога е тоа? За кои работни денови зборуваш?
Објавување на добиточна храна
Fanout е процес на испраќање објава до сите ваши следбеници.
Читање на фанаут (влечење)
Кога барате довод на вести, системот добива барање за читање. Fanout read испраќа барање за читање до сите ваши следбеници, барајќи од нив да ја прочитаат нивната содржина.
Позитивни:
- Постапката на пишување е евтина.
- Кога читате податоци, полесно е да користите различни алгоритми за собирање.
Конс:
- За лице со многу следбеници, операцијата за читање е прилично скапа.
- Корисниците нема да гледаат свежи податоци додека не ги повлечат.
- Кога се повлекуваме за да ги добиеме најновите објави на редовна основа, тешко е да се најде соодветната каденца на влечење, а повеќето барања за повлекување ќе вратат празен одговор, трошејќи ресурси.
Фаноут пишување (туркање)
Кога испраќате нова објава, се испраќа барање за запишување до системот. Барањето за пишување е испратено до сите ваши следбеници за да го ажурираат својот вести користејќи fanout пишување.
на
- Процесот на читање е ефтин.
со
- За корисник со милиони следбеници, на пишувам постапката е премногу скапа.
Рангот на Доводот
Наместо само хронолошки да се подредуваат доводите, денешните алгоритми за рангирање дополнително се обидуваат да гарантираат дека ставките со поголема релевантност имаат приоритет.
- Изберете фактори кои можат да ви помогнат да одлучите за релевантноста на ставката на доводот, како што се бројот на допаѓања, коментари и споделувања, времето на последното ажурирање на ставката ако статијата содржи фотографии или видеа итн.
- Пресметајте го резултатот врз основа на карактеристиките.
- Користете го резултатот за рангирање на објавите.
Поставете KPI како задржување на корисници, приход од реклами и така натаму за да видите колку е ефективен нашиот систем за рангирање.
Заклучок
И покрај фактот дека Инстаграм или неговиот матичен бизнис Фејсбук е огромна корпорација, тој има подобро разбирање дизајн на системот.
Се обидов максимално да ви дадам резиме на високо ниво на доводот на Инстаграм.
Се надевам дека беше корисно и дека добро ќе го искористите.
Оставете Одговор