新浪微博是怎麼架構的？(1)
本文系轉載，但是作者未知
新浪微博在短短一年時間內從零發展到五千萬用戶，我們的基層架構也發展了幾個版本。第一版就是是非常快的，我們可以非常快的實現我們的模組。我們看一下技術特點，微博這個產品從架構上來分析，它需要解決的是發表和訂閱的問題。我們第一版採用的是推的訊息模式，假如說我們一個明星使用者他有10萬個粉絲，那就是說使用者發表一條微博的時候，我們把這個微博訊息攢成10萬份，這樣就是很簡單了，第一版的架構實際上就是這兩行字。第一版本的技術細節，典型的LAMP架構，是使用Myisam搜尋引擎，它的優點就是速度非常快。另外一個是MPSS，就是多個埠可以佈置在伺服器上。為什麼使用MPSS？假如說我們做一個網際網路應用，這個應用裡面有三個單元，我們可以由三種部署方式。我們可以把三個單元部署在三臺伺服器上，另外一種部署模式就是這三個單元部署在每個伺服器上都有。這個解決了兩個問題，一個是負載均衡，因為每一個單元都有多個結點處理，另外一個是可以防止單點故障。如果我們按照模式一來做的話，任何一個結點有故障就會影響我們系統服務，如果模式二的話，任何一個結點發生故障我們的整體都不會受到影響的。
我們微博第一版上線之後，使用者非常喜歡這個產品，使用者數增長非常迅速。我們技術上碰到幾個問題。第一個問題是發表會出現延遲現象，尤其是明星使用者他的粉絲多。另外系統處理明星使用者發表時候的延遲，可能會影響到其他的使用者，因為其他的使用者同一時間發表的話，也會受到這個系統的影響。我們就考慮這個系統怎麼改進。首先是推模式，這肯定是延遲的首要原因，我們要把這個問題解決掉。其次我們的使用者越來越多，這個資料庫表從一百萬到一億，資料規模不一樣處理方式是有差別的。我們第一版單庫單表的模式，當用戶數量增多的時候，它不能滿足就需要進行拆分。第二個是鎖表的問題，我們考慮的是更改引擎。另外一個是發表過慢，我們考慮的是非同步模式。
第二版我們進行了模組化，我們首先做了一個層，做了拆分，最右邊的發表做了非同步模式。第二個服務層，我們把微博基礎的單元設計成服務層一個一個模組，最大是對推模式進行了改進。首先看一下投遞模式的優化，首先我們要思考推模式，如果我們做一下改進把使用者分成有效和無效的使用者。我們一個使用者比如說有一百個粉絲，我發一條微博的時候不需要推給一百個粉絲，因為可能有50個粉絲不會馬上來看，這樣同步推送給他們，相當於做無用功。我們把使用者分成有效和無效之後，我們把他們做一下區分，比如說當天登陸過的人我們分成有效使用者的話，只需要傳送給當天登陸過的粉絲，這樣壓力馬上就減輕了，另外投遞的延遲也減小了。
我們再看資料的拆分，資料拆分有很多方式，很多網際網路產品最常用的方法，比如說如可以按照使用者的UID來拆分。但是微博使用者的一個特點就是說大家訪問的都是最近的伺服器，所以我們考慮
非同步處理，發表是一個非常繁重的操作，它要入庫、統計索引、進入後臺，如果我們要把所有的索引都做完使用者需要前端等待很長的時間，如果有一個環節失敗的話，使用者得到的提示是發表失敗，但是入庫已經成功。所以我們做了一個非同步操作，就是發表成功我們就提示成功，然後我們在後臺慢慢的訊息佇列慢慢的做完。另外新浪發表了一個很重要的產品叫做MemcacheQ，我們去年做了一個對大規模部署非常有利的指令，就是stats queue，適合大規模運維。
第二版我們做了這些改進之後，微博的使用者和訪問量並沒有停止，還有很多新的問題出現。比如說系統問題，單點故障導致的雪崩，第二個是訪問速度問題因為國內網路環境複雜，會有使用者反映說在不同地區訪問圖片、js這些速度會有問題。另外一個是資料壓力以及峰值，MySql複製延遲、慢查詢，另外就是熱門事件，比如說世界盃，可能會導致使用者每秒發表的內容達到幾百條。我們考慮如何改進，首先系統方面循序任意模組失敗。另外靜態內容，第一步我們用CDN來加速，另外資料的壓力以及峰值，我們需要將資料、功能、部署儘可能的拆分，然後提前進行容量規劃。
另一方面我們還有平臺化的需求，去年11月我們就說要做開放平臺，開放平臺的需求是有差異的，Web系統它有使用者行為才有請求，但是API系統特別是客戶端的應用，只要使用者一開機就會有請求，直到他關閉電腦這種請求一直會不間斷的過來，另外使用者行為很難預測。
系統規模在持續的增大，另外也有平臺化的需求，我們新架構應該怎麼做才能滿足這些需要？我們看一下同行，比如說Google怎麼樣考慮這個問題的？Google首席科學家講過一句話，就是一個大的複雜的系統，應該要分解成很多小的服務。比如說我們在Google.com執行一個搜尋查詢的話，實際上這個操作會調動內部一百多個服務。因此，我們第三版的考慮就是先有服務才有介面最後才有應用，我們才能把這個系統做大。
現在我們看一下第三版，首先我們把底層的東西分成基礎服務，基礎服務裡面比如說分散式的儲存，還有分層，我們做了一些去中心化、自動化的操作。在基礎服務之上有平臺服務，我們把微博常用的應用做成各種小的服務。然後我們還有應用服務，這個是專門考慮平臺各種應用的需求。最上面我們有API，API就是新浪微博各種第三方應用都在上面跑。
平臺服務和應用服務是分開的，這樣實現了模組隔離，即使應用服務訪問量過大的話，平臺服務不會首先影響。另外我們把微博的引擎進行了改進，實現了一個分層關係。使用者的關注關係，我們改成一個多惟度的索引結構，效能極大的提高。第四個層面就是計數器的改進，新版我們改成了基於偏移的思路，就是一個使用者他原來讀的一個ID比如說是10000，系統最系的ID是 10002的話，我們和清楚他有兩條未讀。原來的版本是採用絕對技術的，這個使用者有幾條未讀都是用一個儲存結構的話，就容易產生一致性的問題，採用這種偏移的技術基本上不會出錯。
另外基礎服務DB冷熱分離多維度拆分，在微博裡面我們是按照時間拆分的，但是一個大型的系統裡面有很多業務需要有不同的考慮。比如說私信這個就不能按照時間來拆分，這個按照UID來拆分可能更簡單。然後我們突出儲存還做了一個去中心化，就是使用者上傳圖片的速度會極大的提高，另外檢視其他使用者的圖片速度也會極大的提高。另外是動態內容支援多IDC同時更新，這個是在國內比較新穎的。
下面給大家介紹一下新浪微博怎麼樣打造一個高效能架構。到目前為止有五千萬用戶使用新浪微博，最高發表3000條以上每秒，然後一個明星使用者發表的話，會被幾百萬使用者同時讀到。這些問題的本質是我們架構需要考慮高訪問量、海量資料的情況下三個問題。易於擴充套件、低延遲、高可用和異地分佈。我們每天有數十億次外部網頁以及API介面的需求，我們知道微博的特點是使用者請求是無法cache的。因此面對這個需求我們怎麼樣擴充套件？幾點思路。第一我們的模組設計上要去狀態，我們任意一個單元可以支援任意節點。另外是去中心化，避免單點及瓶頸。另外是可線性擴充套件。最後一個是減少模組。
相關推薦
楊衛華談新浪微博架構
在2010年的QCon北京大會上，InfoQ的編輯對楊衛華進行了採訪，其中談到了關於新浪微博系統平臺應對各種問題的解決方案，以及正在開發中的新浪雲。 楊衛華，新浪產品部技術經理，目前工作以新浪微博技術平臺為主，曾負責過新浪IM等通訊服務端架構設計。對網際網路後端技術，分散式
新浪微博是怎麼架構的？(1)
本文系轉載，但是作者未知 新浪微博在短短一年時間內從零發展到五千萬用戶，我們的基層架構也發展了幾個版本。第一版就是是非常快的，我們可以非常快的實現我們的模組。我們看一下技術特點，微博這個產品從架構上來分析，它需要解決的是發表和訂閱的問題。我們第一版採用的是推的訊息模式，假如
python 爬蟲1 開始，先拿新浪微博開始
大括號 版本 install esp con data- 定位 ble Language 剛剛開始學。 目的地是兩個。一個微博，一個貼吧 存入的話，臨時還沒想那麽多。先存到本地目錄吧 分詞和推薦後面在整合 mysql mongodb hadoop redius 後面在用
apigw鑒權分析（1-4）新浪微博開放平臺 - 鑒權分析
取消 spa 控制 server 信息 des 包含 flash poi 一、訪問入口 http://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6%E8%AF%B4%E6%98%8E 微博開放接口的
我用Django搭網站(1)-新浪微博登錄
nsh 編輯 打開 p s php 賬號 rst .py 測試 新浪微博第三方登錄使用的是OAuth2.0，開發前提已經註冊開發者帳號，是開發者。 OAuth簡介 OAuth： OAuth（開放授權）是一個開放標準，允許用戶授權第三方網站訪問他們存儲在另外的服務提供者上
新浪微博技術分享：微博實時直播答題的百萬高併發架構實踐
本文由“聲網Agora”的RTC開發者社群整理。 1、概述 本文將分享新浪微博系統開發工程師陳浩在 RTC 2018 實時網際網路大會上的演講。他分享了新浪微博直播互動答題架構設計的實戰經驗。其背後的百萬高併發實時架構，值得借鑑並用於未來更多場景中。本文正文是對演講內容的整理，請繼
1-新浪微博爬蟲-（2017-05-09）
1 爬使用者的資訊 1-1 哪裡找cookies 1-2 哪裡找使用者資訊 2 爬使用者發過的所有部落格 2
【2019新浪&微博筆試題目】判斷連結串列是否為迴文結構，空間負責度為O(1)，時間複雜度為O(n)
原題描述 判斷一個連結串列是否為迴文結構，要求額外空間複雜度為O(1)，時間複雜度為O(n) 解題思路 一、雙向連結串列 如果連結串列是雙向連結串列，那簡直不要太完美。直接從連結串列兩端向中間遍歷即可判定 可惜，這個題目肯定不會說的是這種情況，
新浪微博基於Docker的混合雲架構與應用實踐
大家好！先做一個自我介紹，我來自新浪微博，付穩，屬於微博平臺研發中心，本次分享的主題是新浪微博DCP基於Docker的混合雲架構與應用實踐。今天的主題是Swarm、Mesos、Kubernetes的三國演義，但是我可能更多講的是大型網際網路公司在排程框架選型或者它依賴的中
新浪微博圖床架構解析
微博圖床系統分析 圖床系統 ，我們先來分析下基於此類系統的一個特性 特性： 1. 小檔案數量巨多，通常為幾十k到幾百k不等。 i. 通常我們認為大小在1M
新浪微博使用者興趣建模系統架構
/*.*/ author: 張俊林/*作者注：這是2011年左右新浪微博個人興趣模型的技術架構，所以你從中是看不到目前很多流行的NoSQL平臺的，因為它們那時候還沒出生呢，
新浪微博千萬級規模高效能、高併發的網路架構經驗分享
架構以及我理解中架構的本質 在開始談我對架構本質的理解之前，先談談對今天技術沙龍主題的個人見解，千萬級規模的網站感覺數量級是非常大的，對這個數量級我們戰略上要重視它，戰術上又要藐視它。 先舉個例子感受一下千萬級到底是什麼數量級？現在很流行的優步(Uber)，從媒體
新浪微博技術架構
中國首屆微博開發者大會於2010年11月在北京舉行，這是國內微博行業的首場技術盛宴。作為國內微博市場的絕對領軍者，新浪微博將在此次大會上公佈一系列針對開發者的扶持政策，以期與第三方開發者聯手推動微博行業的整體發展。下文為微博平臺首席架構師楊衛華演講。以下為演講實錄：大家下午好
新浪微博技術架構分析-轉載
中國首屆微博開發者大會在北京舉行，這是國內微博行業的首場技術盛宴。作為國內微博市場的絕對領軍者，新浪微博將在此次大會上公佈一系列針對開發者的扶持政策，以期與第三方開發者聯手推動微博行業的整體發展。圖為微博平臺首席架構師楊衛華演講。以下為演講實錄：大家下午好，在座的大部分都是技
億級使用者下的新浪微博平臺架構解析
日誌君導讀： 1.43億的月活躍使用者，一分鐘微博達808298條，如此巨大的使用者規模和業務量，微博的後臺系統到底是什麼樣，本文帶你去看看。 【編者按】《博文共賞》是InfoQ中文站新推出的一個專欄，精選來自國內外技術社群和個人部落格上的技術文章，讓更
億級使用者下的新浪微博平臺架構
序言 新浪微博在2014年3月公佈的月活躍使用者（MAU）已經達到1.43億，2014年新年第一分鐘傳送的微博達808298條，如此巨大的使用者規模和業務量，需要高可用（HA）、高併發訪問、低延時的強大後臺系統支撐。 微博平臺第一代架構為LAMP架構，資料庫使用的是MyIsam，後臺用的是php，快取為Me
新浪微博第三方登入1:申請接入(OAuth2.0協議)
1. 微博登入OAuth2.0協議開發流程 與QQ登入略有不同 申請接入，獲取appid和appkey; 開發應用，設定協作者賬號，上線之前只有協作者才能進行第三方登入 放置微博登入按鈕(這個自己
最新python爬蟲抓取新浪微博千萬級資料，scrapy思路+架構+原始碼
1.1 爬取目標 爬取的目標是新浪微博使用者的公開基本資訊，如使用者暱稱、頭像、使用者的關注、粉絲列表以及釋出的微博等 1.2 準備工作 代理池、 Cookies 池已經實現並可以正常執行，安裝 Scrap
新浪微博首席架構師漫談微博底層架構
大家下午好，在座的大部分都是技術開發者，技術開發者往往對微博這個產品非常關心。最晚的一次，是12點多收到一個郵件說想了解一下微博底層是怎麼構架的。很多技術人員對微博的構架非常感興趣，就是一個明星他有300萬粉絲，這個技術怎麼來實現？今天在這裡跟大家分享一下微博的底層機構
[數據集]新浪微博數據集MicroblogPCU
sets learning lun epo con 新浪 摘要 get 關系 數據集下載地址：下載 摘要：MicroblogPCU是從新浪微博採集到的。它能夠被用於研究機器學習方法和社會關系研究。 這個數據集被原作者用於探索微博中的spammers（發送垃圾信息的人）。