“耿總你好。”
廖軍也連忙起身，伸手握手，但感覺對方的手勁有些大。
耿直鬆開手後，坐在廖軍對面，沒有任何客套，沒有寒暄，甚至都沒有禮貌地先介紹自家專案，便直接開始：
“廖總，我知道你在企鵝後臺團隊待了八年，從普通工程師做到T3-3，QQ訊息系統、好友系統、QQ郵箱你都深度參與過。說實話，整個網際網路圈，比你更懂IM後臺的人，並不多。”
廖軍微微點頭，這些話他聽得多了。
他剛想先問耿直，找他來要做的專案是什麼，卻被耿直搶了先。
“所以，我們直接聊技術。”耿直說著，便丟擲了今天的第一個問題。
“陌陌現在日活快200萬了，每天訊息量四五千萬條。我們的聊天系統是基於開源框架改的，現在扛不住了。”
“如果讓你從頭設計一套IM系統，支撐2000萬日活、5億條訊息/天，你會怎麼做？”
噗嗤……
廖軍聽到耿直一下子就把日活拉高到10倍，差點沒忍住。覺得眼前的這位年輕老闆，過於誇張了。
他靠在椅背上，嘴角微微揚起。
雖然很狂，但這個量級，在QQ面前依舊只是個零頭……
他輕咳一聲，開始講道：
“架構上，分三層：接入層、邏輯層、儲存層。接入層用LVS做負載均衡，邏輯層無狀態設計，可以水平擴充套件，儲存層分庫分表，按使用者ID做Hash。”
他越說越順，從TCP長連線說到心跳機制，從訊息同步說到離線儲存，從推拉結合說到多終端同步。
廖軍沒有因為耿直是外行，就敷衍，相反，他說得很認真。
得意地說了幾分鐘，然後停下來，等耿直的反應。
耿直沒有點頭，也沒有記錄，只是安靜地聽著。
等他說完，問了一個問題：“你剛才說，訊息同步用推拉結合。具體怎麼推？怎麼拉？什麼時候推？什麼時候拉？”
廖軍一愣。
這個問題，確實比剛才的[架構設計]要細。
而且，耿直似乎的確聽懂了自己剛才的回答了？
“線上使用者推，離線使用者拉。推的話，通過長連線直接下發。拉的話，使用者上線時從離線庫拉取……”
耿直追問：“那如果使用者線上的瞬間，訊息量很大，比如積壓了一百條，長連線推送會不會把客戶端撐爆？”
廖軍皺眉。
這個問題，確實需要想一下。
“可以做訊息分頁，一次只推20條，剩下的使用者主動拉。”
耿直微微頷首，準備問深入一些：“好。那第二個問題——”
“使用者A給使用者B發訊息。A顯示[已傳送]，B顯示[已接收]。這兩個狀態，怎麼保證一致性？如果訊息丟了，怎麼定位問題？”
廖軍的表情開始認真起來。
“A傳送訊息，接入層收到後，先落庫，再返回[已傳送]。然後邏輯層找到B所在的接入節點，通過長連線下發。B的客戶端收到後，返回ACK，服務端更新訊息狀態為[已接收]。”
耿直：“如果B的ACK丟了怎麼辦？服務端以為沒收到，客戶端以為收到了。”
廖軍：“客戶端定期上報訊息狀態，服務端做對賬。如果發現不一致，客戶端重新上報。”
耿直：“上報的週期是多少？”
廖軍：“30秒。”
耿直：“那這30秒裡，使用者看到的狀態是什麼？”
廖軍沉默了幾秒。
“看到[已傳送]。但使用者感知不到的，30秒很短。”
耿直搖頭：
“30秒不短。如果使用者發了一條重要訊息，看到[已傳送]，以為對方收到了，但對方其實沒收到。30秒後狀態才更新，這30秒裡使用者可能已經在等回覆了。”
他頓了頓：“有沒有辦法把這個時間縮短到3秒以內？”
廖軍思索了好一會兒，才回答：
“那就要做即時ACK+本地快取。客戶端收到ACK後立即更新狀態，同時快取一份，定期和服務端對賬。這樣使用者看到的狀態是即時的，即使服務端資料丟了，客戶端也能補報。”
耿直點頭：“這個思路對。”
廖軍看著他，眼神變了。這個耿直，是真的很懂技術啊！
會議室裡陷入短暫的沉默。
“下一個問題：”耿直開始問起前瞻性問題來：
“如果我們想讓陌陌支援語音訊息，使用者按住說話，鬆手傳送。語音檔案大概幾十KB到幾百KB。怎麼做？”
“語音訊息？”廖軍皺了皺眉。
這個需求