對(duì)于社交類APP開發(fā)后臺(tái)架構(gòu)怎樣搭建？
社交App最常見的場景是類似于微博的場景，用戶與用戶之間有關(guān)注和粉絲這兩種關(guān)系，一個(gè)用戶發(fā)表了內(nèi)容，關(guān)注了該用戶的用戶在個(gè)人主頁上都能收到最新的動(dòng)態(tài)。社交的核心功能是Feed。Feed是指用戶通過關(guān)注功能，聚合了被關(guān)注用戶的最新的內(nèi)容（同時(shí)也包括了自己的內(nèi)容）以供自己瀏覽的信息服務(wù)。按發(fā)表的時(shí)間順序把關(guān)注的用戶的內(nèi)容展現(xiàn)出來。深圳APP開發(fā)公司資深程序員根據(jù)多年的開發(fā)經(jīng)驗(yàn)整理總結(jié)下面4個(gè)方面描述Feed的架構(gòu)。
·基本表結(jié)構(gòu)
·推拉模式
·數(shù)據(jù)庫架構(gòu)
·緩存架構(gòu)
社交APP開發(fā)經(jīng)驗(yàn)之基本表結(jié)構(gòu)
常用的Feed架構(gòu)是把數(shù)據(jù)存儲(chǔ)在MySQL，熱點(diǎn)數(shù)據(jù)（一般來說是最近3天的數(shù)據(jù)）存儲(chǔ)在緩存(常見的緩存系統(tǒng)有Redis和Memcached，微博是使用Memcached)，務(wù)必讓絕大多數(shù)請(qǐng)求通過緩存直接返回(例如微博要求核心緩存命中率要達(dá)到99%)，只有少量的請(qǐng)求穿透緩存落到數(shù)據(jù)庫。
在最簡單的Feed架構(gòu)中，MySQL有下面的4張基本表
．send coutent:發(fā)送內(nèi)容表，存儲(chǔ)用戶發(fā)表的內(nèi)容，表結(jié)構(gòu)如表9-1所示
．revelve content:接收內(nèi)容表，用于推模式（推模式的描述請(qǐng)看下節(jié)）時(shí)存儲(chǔ)用戶接收的內(nèi)容，表結(jié)構(gòu)如表9-2所示。
社交APP開發(fā)后臺(tái)管理結(jié)構(gòu)表示意表9-2reveive_content接收內(nèi)容表
另外，在社交App還需要下面兩張表存儲(chǔ)用戶和用戶之間的關(guān)系。
·followings:關(guān)注表，存儲(chǔ)用戶關(guān)注的人，表結(jié)構(gòu)如表9-3所示：
社交APP開發(fā)關(guān)注表9-3 followings關(guān)注表
·followers:粉絲表，存儲(chǔ)用戶的粉絲，表結(jié)構(gòu)如表9-4所示：
社交APP開發(fā)方法示意圖表9-4followerS粉絲表
社交APP開發(fā)模式之推拉模式
用戶發(fā)表內(nèi)容后，后臺(tái)通過定的方式把獲取數(shù)據(jù)展示到該用戶的粉絲主頁，常用的兩種方式是推模式和拉模式：
1．推模式
平常郵箱中收件箱和發(fā)件箱的作用如下
·發(fā)件箱：存儲(chǔ)用戶發(fā)送的郵件。
·收件箱：存儲(chǔ)用戶收到的郵件。
推模式的數(shù)據(jù)庫設(shè)計(jì)也有收件箱和發(fā)件箱類似的概念，發(fā)件箱對(duì)應(yīng)表9-1“send content發(fā)送內(nèi)容表”，收件箱對(duì)應(yīng)表9-2“revelve content接收內(nèi)容表”。
推模式下用戶發(fā)表?xiàng)l內(nèi)容的流程如下：
(1) id為l用戶發(fā)表?xiàng)l內(nèi)容為“藍(lán)藍(lán)的天空”信息
(2)這條內(nèi)容寫入發(fā)送內(nèi)容表“send content”后內(nèi)容如下
(3)在粉絲表“followers”查找id為1用戶的粉絲，粉絲表“followers”的內(nèi)容如下。
從粉絲表可知，id為l用戶的粉絲是id為2的用戶。
(4)因?yàn)閕d為2的用戶的feed中需要顯示這條內(nèi)容，因此把內(nèi)容寫入接收內(nèi)容表“revelve content”，寫入后接收內(nèi)容表“revelve content”內(nèi)容如下。
(5)bid為2的用戶顯示Feed時(shí)，通過SQL語句“select*from reveive-content where revcive-id=2”就能查詢?cè)撚脩麸@示的數(shù)據(jù)。從推模式的流程可看出，推模式使用了空間換時(shí)間的策略，查找Feed中需要顯示的內(nèi)容很簡單，只需要條SQL語句就行同樣推模式的缺點(diǎn)也很明顯，如下所示：
·同時(shí)推給多人（例如上十萬人）不但延時(shí)嚴(yán)重，而且浪費(fèi)存儲(chǔ)空間。
·變更操作的成本而，如果某個(gè)用戶刪了一條內(nèi)容，要同時(shí)把“send_content”表和“revelve content”表中的數(shù)據(jù)刪除。
2．拉模式
拉模式下用戶發(fā)表?xiàng)l內(nèi)容的流程如下。
(1) id為1用戶發(fā)表了條內(nèi)容，內(nèi)容為“藍(lán)藍(lán)的天空”。
(2)這條內(nèi)容寫入發(fā)送內(nèi)容表“send content”，寫入后發(fā)送內(nèi)容表“send content”內(nèi)容如下。
(3)當(dāng)id為2的用戶顯示Feed時(shí)，在關(guān)注表“followings”查找id為2所關(guān)注的用戶，關(guān)注表的內(nèi)容如下。
從關(guān)注表“followiug_id“可知．id為2的用戶關(guān)注了id為l的用戶，因此需要獲取id為l的用戶發(fā)表的內(nèi)容。
（4）id為2的用戶通過SQL語句“select*from send-content where author-id in （1）”查詢所需要顯示的內(nèi)容。
由上述流程可知，拉模式采用了時(shí)間換空間的策略，用戶推送內(nèi)容時(shí)效率很高，但當(dāng)用戶顯示Feed時(shí)，需要花大量的時(shí)間在聚合運(yùn)算上。
APP開發(fā)公司關(guān)于推拉模式的總結(jié)
推模式和拉模式的特點(diǎn)總結(jié)如下。
好了，APP開發(fā)公司本文關(guān)于社交APP制作接本結(jié)構(gòu)表與模式的方法就分享到這里，希望本站此類型的文章對(duì)您的工作有所幫助，謝謝關(guān)注，博納網(wǎng)絡(luò)編輯整理。
