一、億級直播的架構
1、直播整體架構
主要關注業務邏輯。
2、直播業務平台設計
3、直播電商業務設計
主播端、觀看端
1）后台添加商品
2）主播端
取消置頂、開始講解
3）觀眾端
4）高並發設計
常規4Wqps最高400W的QPS直播，電商模塊如何設計？
這是一個典型的高並發。
①存儲資源設計
存儲選型，選nosql，選redis和mc
redis存儲設計。商品列表; Key 直播id value 商品list
詳情：key 商品id value 詳情，存String 做一個壓縮，用pb，減少不少的存儲量。
用戶和商品的關系：
②容量/QPS評估
如果公司基礎設施做的比較好，通過監控、運維，通過監控大盤拉出最近半個月的QPS;
如果沒有歷史數據可以根據其它業務去評估。
一台redis扛6萬的QBS,集群部署，如果是40W，需要7台。需要1.2的buffer，主從 翻倍
③ 接口耗時
算好最低的響應是多少，耗時的地方如何優化；理清調用鏈；不能拉出所有的商品列表，拉一個置頂商品，使用拉模式；端上下發到網關，再到一些核心流量池，到達業務服務器；查redis資源，把每一步的分部耗時打出來，定位到需要優化的接口；常用的接口優化方案有以下幾種：資源層面接口承受的住；優化接口的調用鏈路，接口的模型調用不准確，優化調用模型；redis扛不住，把數據放到localcache里面；去掉非必要的業務、用並行或者異步。
④ 服務穩定性
如何保障服務的穩定性。
5）直播挑戰
① 高並發
除了上面的高並發設計，還有就是有沒有服務降級的方案，包括手動降級和自動降級。自動降級是統計QBS，上報降級服務，管理哪些模塊需要降級；
快速擴縮容，第一步申請機器，第二部：是調用鏈路經過了哪些服務，下游服務也需要擴容；
針對極端的QBS來了，可以讓有一部分訪問不了，流量限制；
如果還是控制不住，那就把redis的熱點數據放到localCache里面。放到本地緩存一種是手動，一種是自動；自動用算法，找到熱點數據。
業務層面可以做垂直拆分和水平拆分。
② 服務的穩定性
③ 業務復雜度
二、Feed流架構
1、什么是feed流業務
從廣義上講，feed是指為滿足用戶以某種形式持續得到更新信息的需求而提供的格式標准的信息出口。
微博體系中，feed是指用戶通過關注關系，聚合好友，聚合好友最新微博以供自己消費的信息服務，其中也包括分享微博。
2、億級別用戶下的feed流挑戰
① 存儲挑戰挑戰
1>如何存儲用戶發表的微博
2>如何聚合用戶關注的微博
② 高並發
3、Feed流核心模塊架構方案
feed流架構：
內網核心池：核心池是高配的，硬件資源和帶寬都很高，專門存放幾個核心接口，這些核心接口QBS比較高。
SLA服務的穩定性和高可用。
4、Feed存儲架構設計
1）設計背景（首先了解業務背景）
① 億級日活用戶
② 數據特性是寫少讀多。百億讀取每天，1億寫入每天。
③ Uid維度，200萬/s。
④ 訪問規律，熱度集中
85%集中在今天
95%集中在近兩天
98%集中在近三天
2）存儲選型（比對技術以便做出選型）
| 存儲類型 |
是否持久化 |
讀QPS |
寫QPS |
| Mysql |
是 |
單端口2000（SAS） 單端口6000（SSD） |
單端口1000（SAS） 單端口3000（SSD） |
| redis |
是 |
單實例10W |
單實例10W |
| memcached |
否 |
單實例44W |
單實例44W |
| HBase |
是 |
單端口2000 |
單端口4w |
3）存儲選型
根據背景做出選型：
持久化：redis、mysql、HBase
並發讀QPS：200W/s,采用redis和mc
最近三天熱點數據采用mc
全量存儲采用redis和mysql。
4）mysql設計
① 傳統存儲架構方案：
讀寫分離：1*master+n*slave
如果扛不住做一個水平拆分。
傳統mysql架構技術的瓶頸：
熱點事件
千萬級QPS
數十億數據存儲
② feed流Mysql架構設計
按訪問維度分庫（承載能力+擴容需求）
按訪問維度和時間維度分表（熱度+表容量）
部署形式：一主多從，讀寫分離
集群是以端口划分的；
主從機制
自動切換
Backup容災
③ 一致性hash
影響少部分數據；
Hash偏環，咱們可以做一些虛擬節點；那樣影響的數據會很小。
微博不允許數據受影響，所以微博不用一致性Hash。
微博是預估10年后的QBS，把10年后的數據全部申請下來。
5）redis設計
一般是讀多寫少，寫可以用異步rabbitMQ。
分布式緩存會存在什么問題，采用固定hash，接口宕機后會丟掉一部分數據。
5、Feed關注流的推拉模式
1）feed拉模型
優缺點：
優點：架構簡單、一致性好、寫入過程開銷小
缺點：寫少讀多，網絡開銷大，資源讀取量大。
2）Feed推模型
注：每個用戶收到的微博列表
Id0是最新的，idn是最早的。
優缺點：
優點：下行網絡開銷小，資源成本低
缺點：寫入成本高，資源寫瓶頸更高。
還有推拉模型。
微博用拉模式，推拉模式業務場景比較復雜，在存儲方面用redis和MC,包括存儲資源的序列化，存儲也包括高頻和低頻。
6、Feed推薦流的設計方案
如何把用戶留下，如何把這些數據存下來給到用戶，根據用戶畫像（包括年齡、地域等標簽）推薦給用戶相關內容；涉及到大數據分析，如：分析哪個地域的人喜歡互聯網，通過大數據分析得出結論，可以給這個地域的人推薦互聯網的相關內容。
