不知不覺做了快3
年的移動社交了
, 以前是做遊戲伺服器的，轉過來還是比較平滑。最近辭職了
,在尋找工作。當然最優先的公司還是做社交軟體公司。發現多數公司問的第一句話「你這個產品併發支援多少
?」這句話或許對於任何乙個不熟悉
im伺服器的人來說是正常的
.但對於真正做過
im伺服器的人來說是特別膚淺的。
首先做個舉例在開始正題。小區暖氣！北方的同學因該比較了解，南方的同學研究下。以小區暖氣來講。如果拿冷水來測試，小區裡各家各戶的管道那叫乙個流暢。但小區供暖是取暖用的，不是給你做管道測試用的。暖不暖瓶頸在鍋爐房這個很明顯吧？
那麼im
的tcp
併發不就是這個管道嗎？客戶端可不會給伺服器發
hello world(
類似上文供暖的冷水
)做測試。併發高了，傳來的資料可不是直接丟了或者回執，能處理了嗎？
在部落格裡看到併發測試。甚至是單機20
萬連線的測試。
100mbit
的網上行和下行
100/8 = 12.5mb,
send
和recv
。而且這是理論資料。就算
6mb/s
， 不過分吧。
20萬個連線一人發
1kb就是
195mb
。網絡卡都收不過來，上層的併發就更別說了，這個測試意義何在？
cpu,
記憶體，硬碟，**等等的瓶頸我就不敘述了
,單網絡卡這關就過不了。
我們開始正題了，im
的瓶頸其實就是儲存的設計，這就是所謂的鍋爐房。在這裡主從這種分布式是沒有任何意義的
,反而更糟糕。你開啟某電商**看到的內容，和我開啟某電商**看到內容是一模一樣的。那麼場景就出來了
1.%99
的資料是讀，
2.使用者讀的資料都一樣。可
im的場景並非這樣，所有使用者都在寫，讀的內容也不一樣。
第乙個瓶頸是訊息寫。舉例：a
使用者給b
使用者發訊息。
a使用者先發訊息到伺服器
,伺服器在**給
b使用者。假如在伺服器**給
b使用者的時候，
b使用者進電梯了
,這個訊息就丟了。手機的網路環境複雜，這樣做肯定是不行的。伺服器必須先存下來這個訊息，給訊息帶上乙個唯一
id傳送給
b使用者，
b使用者收到後在回執這個唯一
id標記為已經收到。
ok。那麼過程就是：
1插入訊息
,2更新訊息狀態。更新狀態可是又讀又寫。寫入壓力非常大
,你可以想象一下成千上萬的使用者在不停的做這個寫。在想象下從c盤
copy
乙個大檔案到
d盤的進度條。而且這個寫是有時間限制的。客戶端是有定時器的，發乙個訊息是要等待回執的。假如沒有這個回執是要做斷線重連的，說明現在網路異常了。也就是說這些成千上萬的語音頻息 文字訊息 訊息
, 在有限的時間內你要存好給客戶端回執。
第二個瓶頸當然是訊息讀了。因為ios
墓碑式的設計
,客戶端程式切後台就離線了。頻繁的登入讀取離線訊息是必然的。而且這個訊息讀的只是和自己相關的。並非大家讀的資料都一樣。你可能想到的是各種索引。但不要忘了前文所提的寫入
,這是相沖的。
還沒有完，ios
的推送也會造成讀壓力。
b使用者狀態是離線，
ios裝置。這時候所有給
b使用者發的訊息都要通過蘋果推送。這個推送可不是只把和
b說的的內容推過去就可以了。要帶上未讀訊息數量。比如
ios
換句話來說，也就是給所有ios
發訊息都要做個未讀訊息數量的查詢，每一條訊息！你可以想象
ios裝置的數量。當然到現在你也會想到這些讀其實全都建立在寫壓力很大的情況下。
第三瓶頸朋友圈的寫入,
其實朋友圈就是微博，我們每乙個使用者建立的關係都不一樣。收到朋友圈動態也不一樣。那麼也就是要為每一使用者維護乙個資料集。當你發乙個朋友圈動態，你的粉絲或者是你的好友的資料集都要做寫入。
假如你有1000
個粉絲，你很隨意的發
10個朋友圈動態，伺服器就要做
10*1000
的寫入。你可以想象那些大
v很多粉絲的。你也可以想象幾十萬幾百萬愛用朋友圈動態聊天、發廣告、曬大餐的使用者。這個幾何增長
,大到算不出來的寫入資料，不細說了，可以參見「
：收發一條推文的背後」。
結束語：從來不寫博文。我們產品的架構讓我**敘述出來，很困難。所以就不列解決方案了。蒼白的文字，不知道大家能否理解。有興趣的同學可以參見下dynamo
和 consistent hashing
的思路，網上比較多這樣的博文，且**形式好理解。
IM的技術原理與發展
二 im技術原理和工作方式 從技術上來說，im的基本技術原理如下 im伺服器 登陸或登出 使用者a通過列表找到b，使用者b獲得的訊息並與之交談 通過im伺服器指引建立與b單獨的通訊通道 三 im通訊方式 使用者a與使用者b的點對點通訊由於防火牆 網路速度等原因難以建立或者速度很慢，im伺服器將會主動...
了解Instagram背後的技術
本文首發於infoq中文站 一張 上傳的過程是這樣的 採用同步的方式寫入 資料庫 如果 上有地理位置標籤，則以非同步的方式將 提交給solr進行索引 將 的id加入每個關注者的列表裡，該列表儲存在redis之中 在顯示feed時，選取一小部分 id，在memcached裡進行查詢 在設計系統時，in...
了解Instagram背後的技術
一張 上傳的過程是這樣的 採用同步的方式寫入 資料庫 如果 上有地理位置標籤，則以非同步的方式將 提交給solr進行索引 將 的id加入每個關注者的列表裡，該列表儲存在redis之中 在顯示feed時，選取一小部分 id，在memcached裡進行查詢 在設計系統時，instagram的設計哲學是簡...