和百度的一前輩吃飯，被問陌陌服務器的idle,有無30%?我只能.....

　　前幾天和百度的一前輩吃飯，被問陌陌服務器的 idle，30%?我嘿嘿。20% 總有吧？我只能繼續嘿嘿，估計當時和東莞市長的心情差不多。

　　陌陌的高峰是晚 10 點到 12 點，部分服務器，每天晚上都是戰備狀態，同學們也都在應戰。我們碰到的問題很有挑戰性，主要為兩個方面：

　　一方面是技術，另一方面是兼容歷史，后者更難處理一些。好比我們要把一輛正在正在行使奇瑞 QQ 改裝成布加迪威航，要更快，而且整個過程絕不允許停下來、更不允許出現任何差錯，是的，是“任何“這兩個字。

　　陌陌 API 每天的請求已超過 20 億，每秒算下來大約 2.5 萬請求的樣子。傳遞給數據層的量則會更大一些，一個請求里經常會有數百次的 IO。IO 這么頻繁，性能還沒問題，第一功勞要給 redis 的作者 antirez。redis 作為一個銀彈，完美的支撐了陌陌的快速發展，超高的性能、超簡單的使用方式、無范式的靈活。redis 的各種優勢我們都體驗了，各種坑（使用與運維方面）也踩的差不多了，經驗絕對豐富，下一步估計會爭取自動化，以及比較系統的總結與分享。

　　API 用的 php，線上開啟 xhprof，相應數據進入 api-stat 平臺，通過 nginx 來隔離不同服務的 php 服務器（所以開頭說的是部分服務，以前一直會因為一個服務 down 掉整個服務），這樣客戶端用起來還是統一的。 版本也很新，是從 5.3 升到 5.5 之后的。php 和 redis 一樣，強大的靈活性支撐了產品各種需求與想法以最快的速度落實在用戶服務中。

　　但 php 與 redis 有個問題，就是 redis 的連接數。已不允許 php 再大規模的增加機器。我們調整過 redis 連接數上限，但這不是長久之計，另外，也不清楚連接數過高會不會在線上環境帶來什么附加問題。有時候，測試數據代表不了線上的真實情況。 也嘗試性的 redis 長連接改成短連接，但服務根本受不了，cpu 瞬間爆掉。也想過在中間加一層 proxy 之類的東西，但估計也和改成短連接的效果差不多。還有一個方案，就是忍受，然后加倍增加機器數量，但這個方案看起來終究有點 low。 你只能竭盡全力，做的更好。

　　附近，是陌陌一個核心要素，在產品里比比皆是。最開始的時候是直接用 mongo 的，后來 mongo 頂不住了，就分庫，再后來分庫也頂不住了。服務層的同學就做了陌陌自己的附近計算，省了不少機器。此外，我們的運維在網絡質量、反 DNS 劫持等方面也做了大量的工作。 DNS 劫持是件很可惡的事情，在這方面我們做了一些工作，但不展開了。

　　但是，按照目前的用戶增長速度，接下來我們碰到的技術問題會更棘手，就現在而言，我們要做的很多，但可做的十分有限，畢竟有各方面的資源限制，這更要求我們要做更好的產品。

　　從緊迫度上講，我覺得是這樣的：

　　首先是繼續快速的完成各種產品需求，保障各類服務質量。 

　　其次是調整技術架構，這里不允許豪爽的唱起從頭再來，只能積少成多，慢慢改進從客戶端到服務端各個方面。

　　再次則是推動手工工作的平臺、自動化，以及經驗總結、知識沉淀方面的工作。

　　最后是轉換觀念，提高管理、規范、流程化方面的工作。 

　　叨叨到最后了，該干活了......如果你能較好的解決上述任何一個問題，還望能留下大名，指教一二。

                    <span id="shareA4" class="fl">                          </span>