該文章來自阿裡巴巴技術協會（ata）精選集
随着2015雙促落下帷幕，igraph線上圖存儲和查詢服務也在全力支撐各項業務的過程中經曆了近乎瘋狂的成長。随着大家逐漸從 關系的視角來審視我們的資料和業務，igraph服務所提供的 基于關系的查詢服務也開始被大家大量應用到業務邏輯中。igraph團隊也很興奮地看到igraph服務中所承載的業務呈現出了爆發式的增長，其中不乏集團的核心業務，比如搜尋業務和推薦業務。在這裡，我們igraph團隊向所有信任我們的使用者，表示最衷心的感謝，是你們的信任和優異的成績彰顯了igraph團隊工作的價值。這一篇文章首先向大家整體介紹igraph服務目前的發展狀況，然後向大家介紹我們在支撐雙十一大促業務過程中所做的相關工作。希望這些介紹能夠讓大家進一步了解igraph，并能夠給我們提出寶貴的意見。
雖然igraph服務上目前承載了衆多業務，但是對igraph服務造成巨大壓力的還是集團兩大核心業務—— 搜尋和 推薦。這兩項業務平時的體量已經足夠大，雙十一他們的流量更是難以預估。尤其是推薦業務，由于今年是個性化推薦元年，業務呈現出爆發式增長，更是讓整個容量評估過程難上加難。
其實對于igraph服務來講，不但通路壓力大，實時更新壓力也非常巨大。因為，使用者實時行為（比如點選行為、購買行為、加購行為、收藏行為等）回報對算法效果至關重要，這些實時行為回報通過pora實時流計算平台實時更新到igraph服務中。由于雙十一當天使用者行為數激增，是以實時行為回報對igraph服務造成了巨大的更新壓力。
很幸運，在各團隊的通力合作下，igraph在雙十一大促過程中平穩地支撐了這兩條重要的業務，也迎來了igraph各項系統名額的峰值。
系統核心名額（出于安全考慮，請原諒我們不能給出精确絕對值）：
1. proxy流量接入層峰值qps達到幾百萬的，searcher叢集峰值qps超過千萬。
2. proxy接入層在qps達到幾百萬峰值qps時，服務響應保持在3ms以内。
3. 實時更新消息峰值達到幾百萬qps每秒，雙十一當天更新消息總量更是超過五百億條。
目前，igraph服務在上海、杭州以及深圳三個機房進行了單元化部署，為近千份關系資料提供線上服務，資料規模約250t。日常通路igraph服務接入層峰值qps在 110w左右。
由于大家對于igraph團隊的信任，igraph服務的客戶也在不斷增長，包括（排名不分先後）：
1. 個性化推薦業務
2. 淘系商品個性化搜尋業務
3. 1688搜尋業務
4. 蝦米音樂推薦業務
5. 集團安全使用者指紋業務
7. 拍立淘業務
8. 航旅業務
9. b2b icbu推薦業務
10. 螞蟻金服天羅地網業務
11. ...
igraph團隊主要從兩個方向來備戰2015雙十一。首先，需要讓igraph支撐更多的業務，這就需要我們不斷豐富igraph的功能，并且提升業務團隊使用igraph服務的效率；其次，需要不斷提升我們自身的運轉效率，這就需要我們提升igraph服務的性能同時降低維護igraph服務的運維成本。于是我們主要做了一下幾件事情：
對于個性化搜尋和個性化推薦來講，都離不開使用者的行為資料，通常這些資料都要求比較高的實時性（通常是秒級）。因為igraph服務能夠支援高并發低延遲的通路，并且支援大量消息實時更新，于是我們聯合pora實時流式處理平台以及igraph服務打造了使用者基礎資料服務（如下圖所示）。這個服務既可以提供最近一段時間内使用者的曆史行為資料也可以提供實時的使用者行為。基礎資料服務為集團各條業務的實時個性化提供支撐。基礎服務提供的實時資料包括：
1. 使用者點選行為
2. 使用者購買行為
3. 使用者收藏行為
4. 使用者收藏商品行為
5. 使用者收藏店鋪行為
6. 使用者加購行為
7. 使用者profile（購買力、偏好等）。
基礎資料服務為業務方在雙十一提供 126w峰值qps，雙十二 170w 峰值qps的使用者實時行為通路，給業務名額帶來了巨大的提升。搜尋離線團隊提供的pora 實時流式計算平台在處理使用者實時日志方面也非常給力。
為了能夠讓業務進行快速疊代，我們igraph團隊提供了一個igraph服務自助接入web服務。使用者隻需在web頁面上（如下圖所示）簡單填寫相關資訊，igraph服務就可以自動托管整個資料的回流，并且使用者可以在自助服務頁面上檢視到資料回流具體狀态。隻要自助服務頁面上顯示資料回流成功，那麼使用者就可以通過igraph client或者igraph http服務查詢自己的資料。
随着igraph服務承接的業務不停增長，igraph叢集的規模不停增長，叢集的線上部署和異常處理占用了我們大量時間。為了能夠自動化地進行線上叢集部署以及智能的異常處理，我們給igraph線上叢集添加了一個自動化排程角色，我們稱之為igraph admin。
有了igraph admin角色之後，使我們應對igraph叢集部署和異常處理變得輕松自如。叢集部署隻需要保證有足夠的空閑機器資源，igraph admin可以自動申請機器資源并部署上igraph服務，整個過程不需要人工幹預；對于叢集中經常出現的機器異常，igraph admin會自動把對應的igraph服務遷移到正常的機器上。
為了能夠讓igraph服務支撐更高的通路量，我們将原先igraph proxy的線程模型進行了異步化改造。之前proxy采用同步通路模型，使得proxy服務的單機服務能力在1w qps左右就上不去了，因為這時候同步服務模型所帶來的線程切換代價太高，導緻cpu system非常高，而此時整體cpu使用率僅僅在40%左右。為了解決這個問題，我們把proxy的服務模型進行異步化改造，讓proxy的整體服務能力提升了2.5倍，proxy極限cpu可以壓到90%以上。如果查詢傳回結果稍大，這時千兆網絡帶寬會成為制約單機proxy服務能力的瓶頸。
因為igraph中所有資料都存放在ssd上，熱點資料會被cache在記憶體中。這樣如果某一張表進行資料全量切換時，會造成記憶體中所有cache的資料都失效。這時候所有對該表的通路都會落在ssd上，如果通路量比較大，會把ssd的iops打滿，這時候會對整體服務的穩定性造成巨大的影響。為了降低這種影響，我們在資料切換時采用漸進式引流的資料切換方式，這樣可以減輕ssd的iops壓力，同時能夠讓該表的熱點資料逐漸cache到記憶體中，最終我們可以在資料切換過程中實作線上服務的穩定性。
其實在igraph服務性能優化方面，我們做了非常多優化，這些優化瑣碎但是非常有收益，比如提供batch通路接口、優化網絡中斷平衡、調整核心記憶體回收參數等等，由于篇幅所限，我們不能一一深入說明，還請諒解。
這篇文章給大家簡單介紹了igraph在準備2015雙十一大促過程中所做的一些工作以及igraph在大促過程中的相關資料表現。由于篇幅有限，無法深入闡述每一項工作的細節。最後，感謝大家一直以來對igraph團隊的信任，我們會更加努力地将igraph打造成更加高效、易用的關系查詢服務。