业务需求推动技术进步

前言

简介

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

业务

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

分析

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

另一个问题

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

其它

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

优点

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

总结

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