feed 平台系統架構
cache 架構及演進
總結與展望
微博在執行過程中的資料挑戰
feed 平台系統架構
比如 web 端、客戶端、大家用的 ios 或安卓的一些客戶端，還有一些開放平台、第三方接入的一些介面。
下一層是平台接入層，
不同的池子，主要是為了把好的資源集中調配給重要的核心介面，這樣遇到突發流量的時候，就有更好的彈性來服務，提高服務穩定性。
再下面是平台服務層，
主要是 feed 演算法、關係等等。
接下來是中間層，
通過各種中間介質提供一些服務。
最下面一層就是儲存層。
feed timeline
feed cache 架構
主要是分組的一些微博，然後直接對群主的一些微博。inbox 比較少，主要是推的方式。
第二層是 outbox，
每個使用者都會發常規的微博，都會到它的 outbox 裡面去。根據存的 id 數量，實際上分成多個 cache，普通的大概是 200 多條，如果長的大概是 2000 條。
第三層是一些關係，
它的關注、粉絲、使用者。
第四層是內容，
每一條微博一些內容存在這裡。
第五層就是一些存在性判斷，
比如某條微博我有沒有讚過。之前有一些明星就說我沒有點讚這條微博怎麼顯示我點贊了，引發了一些新聞。而這種就是記錄，實際上她有在某個時候點讚過但可能忘記了。
最下面還有比較大的一層——計數，
cache 架構及演進
簡單 kv 資料型別
通過簡單 kv 資料型別的儲存，我們實際上是以 mc 為主的，層內 hash 節點不漂移，miss 穿透到下一層去讀取。
集合類資料
現在 redis 的記憶體大概有 30 個 t，每天都有 2-3 萬億的請求。
其他資料型別：計數
計數器 counter service
其他資料型別：存在性判斷
首先直接考慮能不能用 redis。單條 kv 65 個位元組，乙個 kv 可以 8 個位元組的話，value 只有 1 個 bit，這樣算下來每日新增記憶體有效率是非常低的。
到目前為止，我們關注了 cache 集群內的高可用、擴充套件性、元件高效能，還有乙個特別重要就是儲存成本，還有一些我們沒有關注到的，比如運維性如何，微博現在已經有幾千差不多上萬台伺服器等。
進一步優化
服務化總結與展望
我的微博（2023年11月11日）
1010年11月11日 2010年11月3日 2010年11月2日 2010年10月5日 2010年9月23日 2010年9月8日 2010年7月14日 2010年6月25日 2010年6月13日 2010年6月1日 2010年5月28日 2010年5月21日 最近有一句話 忘記了是在哪本書上看到的...
《永遠的七日之都》評論 微博復刻
永遠的7日之都 如果這是乙個必須查攻略才能玩下去的遊戲，如果 不研究攻略 一周目安都會離開主角 badend 對不起，我們無緣七日，網易。網易做遊戲不能說不用心，也不能說沒良心，但是他們每次拿出的產品都無一例外 怪怪的。然後 一定會喂屎。我就不舉例了，意義不大。網易最近新作頻發，但給人感覺 胃口太大...
打造百億量級 億級日活SDK的十大關鍵要點
乙個好的sdk應該具備易用性 穩定性 輕量 靈活的特點，而箇推作為國內第三方推送市場的早期進入者，一直致力於為開發者提供高效穩定的推送sdk。這期文章，我們特地採訪了個推android 資深開發敬瑜，以個推推送sdk為例，來聊聊打造大型sdk的關鍵技術點。作者 個推android 資深開發 敬瑜 0...