上一篇
下一篇百度账号系统国际化实践
作者:北京百度推广 日期:2018/10/4 20:44:12
从产品层面，国际化账号系统需要支持同一个用户在不同的国家登录并使用百度的服务。技术角度则要求用户个人数据全球互通，且包括用户ID和用户名在内的竞争性资源分配全球唯一。而国际链路传输时延以及稳定性则是系统设计面临的关键问题。本文介绍了百度账号系统国际化架构在数据跨IDC互通和分布式提交及冲突解决方面的实践。
关键问题分析
账号系统中的用户ID和用户名是两种有严格一致性要求的资源。其中用户名由用户向系统提出申请，系统确定该资源的分配;而用户ID则对用户不可见，由系统内部分配。两者都是全局唯一，形成一对一映射，并且该映射需要在用户注册的时候实时生成。这两个资源的无冲突实时分配是需要解决的关键问题。而一旦用户注册成功，后续用户数据的修改，则天然具有按照用户划分的时序性和地域特性，不会存在严重的冲突问题。
根据CAP理论，分布式系统中强一致性和高可用性不可兼得。而在跨国IDC组成的分布式系统中，链路传输时延以及链路稳定性带来的问题比地区性的分布式系统更为严重。如果要追求用户数据资源的强一致性，则必然影响服务的可用性。因此解决该问题的关键，是在可用性和一致性方面有所取舍，然后根据业务特性采取相应的措施弥补牺牲的那一方。
解决方案
a) 可用性VS一致性
为了保证用户ID和用户名数据的一致性，一种方案是在用户提出注册申请时，采用集中提交、集中分配的方式，所有的请求都同步发送到资源分配中心节点，通过完整的ACID语义实现数据更新的强一致性，保证资源分配无冲突。但是这个方案将导致系统可用性无法满足系统需求，特别是在传输链路故障时，将导致中心节点外其他IDC的服务不可用。
在高一致性和高可用性之间，我们再一次选择了高可用性。本方案采用分布式提交和分配 + 异步互通 + 中心式异步冲突解决的方案，在各IDC内部独立完成更新提交和资源分配，保证了本地服务的高可用性;而分布式资源分配带来的冲突，则通过中心节点异步解决，实现全球化多IDC中用户数据多副本的最终一致性。
b) 用户ID分配
为了实现全局唯一的分布式用户ID无冲突分配，系统采用pre-allocated两阶段动态分配的思想。全局ID资源维护在资源分配中心，各国际化IDC按照需求先向资源中心申请批量ID资源，再由IDC向用户实时分配获得的ID资源。通过资源分配中心控制用户ID在IDC之间的无冲突分配，确保一致性。此时仍然存在中心控制节点，但由于向控制中心申请批量ID的过程独立于用户申请ID的过程，不再有实时性的要求，其时机可以按需灵活调整，实际运行时并不会影响到系统的可用性。
c) 用户名分配
用户在注册时需要实时形成ID到用户名的双向唯一映射。和用户ID不同的是，用户名资源无法由系统预先在IDC之间分配，而是在用户注册时实时分配。用户名虽然在不同的国家、不同的语言之间会有天然的分界，但是英文的用户名资源则在全球范围内存在极大可能性的冲突。
对于类似数据更新的冲突解决方案，业界有Megastore系统采用的paxos这样在提交阶段协商达成一致性的方式，也有Dynamo系统采用的读时解决冲突的方式。Paxos在提交阶段通过所有可用节点多次协商在majority节点间达成一致确保没有冲突，但是也带来了提交时延以及可用性问题，会对用户注册这样实时性要求较高的业务产生用户体验的影响。而Dynamo采用的读时解决冲突的方案则无法及时发现已经被占用的用户名资源，会增加原本可以避免的资源分配冲突。
系统采用了介于Megastore和Dynamo之间的冲突解决方案，由中心节点异步解决冲突。各IDC提交更新至本地，确保本地服务可用，然后异步将更新数据同步到中心节点，中心节点实时解决冲突，并将结果反馈给提交方。这样既确保本地服务的高可用性，同时又准实时的解决了数据冲突。如果中心节点不可用，各IDC仍然可以提供服务，在中心节点恢复后，借助可自动化数据恢复的互通中间件完成资源的冲突解决。
d) 互通中间件
互通中间件在整个架构中的作用至关重要。在IDC内部，系统支持完整的ACID语义。本地提交完成后，通过中间件异步传输到其他IDC。系统使用了百度开发的异步消息队列系统，通过write-ahead log支持更新数据的序列化、持久化和自动化数据恢复;支持多对多的消息订阅和推送，确保架构无缝扩展到多IDC;支持滑动窗口模式传输，保证长耗时链路传输时的吞吐量。通过异步消息队列系统，实现了IDC之间的系统解耦，确保在国际化链路故障时不影响本地服务，同时在链路故障恢复后完成自动化的数据恢复。
总结
本文探讨了百度账号系统国际化过程中遇到的问题，并就资源分配和冲突解决、数据互通中间件提出了解决方案，在可用性和数据一致性方面采取有效折中。该方案已经上线并长时间稳定运行。责任编辑：付丁
Tags: 北京百度关键词 相关日志: