電腦抖音如何加粉絲團(抖音怎麽加粉絲團點亮燈牌)

抖音作為國民短視頻社交應用，有數據顯示總用戶數量已超過8億，每日活躍用戶達7億，人均單日使用時長超過2小時。在這樣龐大的用戶基數下，壹個小小的功能，背後可能需要復雜的設計。以用戶服務為例，單單存儲8億用戶，已經遠遠超出單庫單表MySQL的極限。本文中我們的問題是如何在這樣的用戶基數上，實現關註列表、粉絲列表功能。

需求分析

客戶端和服務端的分界線從來都不是那麽清晰，隨著歷史的演進，

關註列表則采用稍微不同的表結構，uid是用戶ID，following_uid是被關註用戶的ID，對uid進行分片:

當然有，由於目前手機的配置普遍都比較高，很多原本在服務端的信息，都可以緩存到手機內置存儲里。隻需要壹定的更新機制，保證服務端和客戶端的數據壹致即可。不然手機端的app怎麽都這麽大呢？

憑經驗來看，每個用戶關註的用戶數是有限的，大概率不會超過5000; 壹個普通用戶的粉絲數也是有限的，能超過5000至少說明精心運營過。

取消關註

通過folloing_uid + uid，反查“粉絲列表”

查詢自己的粉絲列表，並支持搜索(關註妳的用戶)

Partition Toloerance 分區容錯性

事實上，關註列表、粉絲列表隻是需求的壹部分。抖音上人與人的關係是壹種弱關係，可以單方向進行關註，這壹點與微博、twitter類似。作為對比，微信上人與人的關係是強關係，必須是對等的。

當然，定制化壹張MySQL表隻是壹個玩笑。但壹個事實是，劉德華的粉絲數是我的100w倍；我們沒有渠道得知抖音用戶的粉絲數分布，馬太效應肯定是超級明顯。

如果選C，那麽就需要依賴分布式鎖，保證兩張表都寫入以後，才返回結果給客戶端；這里的缺點很明顯: 壹是引入外部依賴(分布式鎖)，鎖掛了怎麽兜底；而且性能差；

大學那會兒，教科書上會說瀏覽器是瘦客戶端，桌麵應用是胖客戶端。

場景1: 朋友列表

Availablity 可用性

胖客戶端的壹點聯想

持久化存儲: 關註關係存起來以後，不能丟

關註關係本質上是壹種關係，但業務上體現為兩種：粉絲列表和關註列表。朋友是粉絲列表和關註列表的交集。如果設計壹種存儲架構，需要滿足壹些條件：

上麵提到的存儲設計，或者上層的接口設計，都是服務端做的事情。抖音需要服務這麽大的用戶群體，本身已經需要很多機器。每個看起來微不足道的請求，QPS壹旦上來，需要的機器數量都不會少。那麽有沒有壹種方法，可以減少機器占用呢？

查詢自己的關註列表，並支持搜索(關註的用戶)

查詢自己的朋友列表，並支持搜索(互相關註)

Ill. 提高抖音號的影響力。

拉黑

但超級大v的粉絲數可以遠遠超出這個量級，比如在抖音上搜索“劉德華”、“鄧紫棋”、“王壹博“等，粉絲數都是千萬級別的。精心運營過的劉德華粉絲數達到了驚人的7600w，這個量級可以給他定制化壹張MySQL表了，表名就叫liudehua_followers

數據壹致性: 粉絲列表和關註列表的數據必須壹致

除了這三類讀操作之外，還有壹些寫操作:

存儲架構

按照功能拆表、對表進行分片，這兩個操作完事以後，我們滿足了持久化和高性能兩個指標，但如何保證兩張表數據的壹致性呢？

先不考慮數據量，如果用壹張MySQL表存儲關註列表，那麽結構大概是這樣的:

這兩個場景下，如果是普通用戶，基本上沒啥問題。

先找到粉絲或關註的 uid list

我們簡單聊壹下CAP理論:

在壹個大型分布式係統中，這三點不可能同時完成。我們看CAP理論如何應用到粉絲場景。

所以，粉絲列表仍然使用上麵的表結構，uid是用戶ID，follower_uid是粉絲ID，對uid進行分片;

在粉絲場景中，我們需要糾結的是C和A選哪個。

業務支持

因此，粉絲列表、關註列表這類數據對都可以緩存到App端。粉絲列表的變更從服務端定期拉取更新；關註列表的變更由App端觸發，隻需要保證服務端接口調用成功後，更新本地緩存即可。

架構簡單、資源占用可接受