在全球一半以上的国家成为家喻户晓的品牌,是百度重要战略目标之一。做为百度用户产品体系最重要的基础服务,百度帐号系统最先开始了国际化步伐。架构
从产品层面,国际化帐号系统须要支持同一个用户在不一样的国家登陆并使用百度的服务。技术角度则要求用户我的数据全球互通,且包括用户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