谈淘宝的异地多活架构

业务需求推动技术进步

前言

简介

异地多活的前身是单元化架构,本质上是让业务具备单元化的部署能力,避免集群过于巨大使得管理难度激增。
异地多活则是在单元化基础上的扩展。就好像MySQL数据库,我们把一个节点看做一个单元,可以做成一主一备,也可以多备库,实现一写多读,这就是MySQL的单元化。而异地多活,则需要让每个节点都可读写,即全主的架构。
另外,同城多机房的容灾已经是成熟的技术,所以异地多活的异地,指得是跨城市的部署能力。

业务

阿里集团有不同的业务,不同业务的异地多活架构也并不相同。
本文描述的是淘宝这种电商业务的异地多活架构。阿里云和支付宝的技术架构由于业务不同,架构也并不一样。

分析

如果用一句话来描述淘宝的异地多活,就是按买家维度来切分数据,做单元内封闭。相当于我们对买家做一个应用级的分库分表。比如,将买家id10000取模,然后根据范围分散到各个单元中。
因为相对卖家而言,买家更多,自然是整个系统的瓶颈。
电商系统的流程,基本是扣减库存然后下单,之后的赠送积分,通知商家之类的操作可异步完成。
此外,为了保证数据的安全,也会将数据同步到其它单元备份,有些类似Kafka的容灾方式。

另一个问题

用户订单的创建,本质上是一个新增记录的操作,只要正常打散,不会存在数据一致性问题。
但卖家的库存却不同,库存扣减是需要保证原子性的。因此,所有的扣减操作都要回调到中心单元,但查询可以在单元内完成,做数据同步即可。
当然,商品也可以做数据分片,或引入分布式一致性协议,只不过远程通信的成本依然存在。我们会看到有的热门商品的库存会和位置有关,这是将库存进行分仓处理,这也不失为一个解决库存热点问题不错的办法。
不过其实我们买东西下单时,等个几秒好像也还好,虽然比以前的淘宝慢了些,或许就是因为扣减的动作调用了异地吧。

其它

除了需要用于交易的关键服务,其它服务差不多是随便放了。通常是和库存这个中心化的服务放在一起。

优点

一个架构,总是为了业务需要而存在。异地多活就是因淘宝业务需要而诞生。
1. 更灵活的扩容和缩容。
2. 跨城市的容灾能力。
3. 隔离故障影响面。

总结

技术总是万变不离其综,异地多活的本质,就是个大型分库分表。但实现它的难度,只有做了才知道。

© 版权声明
THE END
广告
喜欢就支持一下吧
点赞1 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情

    暂无评论内容