在全球一半以上的國家成爲家喻戶曉的品牌,是百度重要戰略目標之一。做爲百度用戶產品體系最重要的基礎服務,百度帳號系統最先開始了國際化步伐。架構
從產品層面,國際化帳號系統須要支持同一個用戶在不一樣的國家登陸並使用百度的服務。技術角度則要求用戶我的數據全球互通,且包括用戶ID和用戶名在內的競爭性資源分配全球惟一。而國際鏈路傳輸時延以及穩定性則是系統設計面臨的關鍵問題。本文介紹了百度帳號系統國際化架構在數據跨IDC互通和分佈式提交及衝突解決方面的實踐。異步
帳號系統中的用戶ID和用戶名是兩種有嚴格一致性要求的資源。其中用戶名由用戶向系統提出申請,系統肯定該資源的分配;而用戶ID則對用戶不可見,由系統內部分配。二者都是全局惟一,造成一對一映射,而且該映射須要在用戶註冊的時候實時生成。這兩個資源的無衝突實時分配是須要解決的關鍵問題。而一旦用戶註冊成功,後續用戶數據的修改,則自然具備按照用戶劃分的時序性和地域特性,不會存在嚴重的衝突問題。分佈式
根據CAP理論,分佈式系統中強一致性和高可用性不可兼得。而在跨國IDC組成的分佈式系統中,鏈路傳輸時延以及鏈路穩定性帶來的問題比地區性的分佈式系統更爲嚴重。若是要追求用戶數據資源的強一致性,則必然影響服務的可用性。所以解決該問題的關鍵,是在可用性和一致性方面有所取捨,而後根據業務特性採起相應的措施彌補犧牲的那一方。ide
爲了保證用戶ID和用戶名數據的一致性,一種方案是在用戶提出註冊申請時,採用集中提交、集中分配的方式,全部的請求都同步發送到資源分配中心節點,經過完整的ACID語義實現數據更新的強一致性,保證資源分配無衝突。可是這個方案將致使系統可用性沒法知足系統需求,特別是在傳輸鏈路故障時,將致使中心節點外其餘IDC的服務不可用。設計
在高一致性和高可用性之間,咱們再一次選擇了高可用性。本方案採用分佈式提交和分配 + 異步互通 + 中心式異步衝突解決的方案,在各IDC內部獨立完成更新提交和資源分配,保證了本地服務的高可用性;而分佈式資源分配帶來的衝突,則經過中心節點異步解決,實現全球化多IDC中用戶數據多副本的最終一致性。中間件
爲了實現全局惟一的分佈式用戶ID無衝突分配,系統採用pre-allocated兩階段動態分配的思想。全局ID資源維護在資源分配中心,各國際化IDC按照需求先向資源中心申請批量ID資源,再由IDC向用戶實時分配得到的ID資源。經過資源分配中心控制用戶ID在IDC之間的無衝突分配,確保一致性。此時仍然存在中心控制節點,但因爲向控制中心申請批量ID的過程獨立於用戶申請ID的過程,再也不有實時性的要求,其時機能夠按需靈活調整,實際運行時並不會影響到系統的可用性。隊列
用戶在註冊時須要實時造成ID到用戶名的雙向惟一映射。和用戶ID不一樣的是,用戶名資源沒法由系統預先在IDC之間分配,而是在用戶註冊時實時分配。用戶名雖然在不一樣的國家、不一樣的語言之間會有自然的分界,可是英文的用戶名資源則在全球範圍內存在極大可能性的衝突。內存
對於相似數據更新的衝突解決方案,業界有Megastore系統採用的paxos這樣在提交階段協商達成一致性的方式,也有Dynamo系統採用的讀時解決衝突的方式。Paxos在提交階段經過全部可用節點屢次協商在majority節點間達成一致確保沒有衝突,可是也帶來了提交時延以及可用性問題,會對用戶註冊這樣實時性要求較高的業務產生用戶體驗的影響。而Dynamo採用的讀時解決衝突的方案則沒法及時發現已經被佔用的用戶名資源,會增長本來能夠避免的資源分配衝突。資源
系統採用了介於Megastore和Dynamo之間的衝突解決方案,由中心節點異步解決衝突。各IDC提交更新至本地,確保本地服務可用,而後異步將更新數據同步到中心節點,中心節點實時解決衝突,並將結果反饋給提交方。這樣既確保本地服務的高可用性,同時又準實時的解決了數據衝突。若是中心節點不可用,各IDC仍然能夠提供服務,在中心節點恢復後,藉助可自動化數據恢復的互通中間件完成資源的衝突解決。開發
互通中間件在整個架構中的做用相當重要。在IDC內部,系統支持完整的ACID語義。本地提交完成後,經過中間件異步傳輸到其餘IDC。系統使用了百度開發的異步消息隊列系統,經過write-ahead log支持更新數據的序列化、持久化和自動化數據恢復;支持多對多的消息訂閱和推送,確保架構無縫擴展到多IDC;支持滑動窗口模式傳輸,保證長耗時鏈路傳輸時的吞吐量。經過異步消息隊列系統,實現了IDC之間的系統解耦,確保在國際化鏈路故障時不影響本地服務,同時在鏈路故障恢復後完成自動化的數據恢復。
本文探討了百度帳號系統國際化過程當中遇到的問題,並就資源分配和衝突解決、數據互通中間件提出瞭解決方案,在可用性和數據一致性方面採起有效折中。該方案已經上線並長時間穩定運行。
by Zhoujun&Fanmengzhe