供稿 | Payments 贾奇
导读
Part 01
业务背景
在正式介绍架构前,先简要看下业务流程,示意图如下:
图 1(点击可查看大图)
系统收到请求后,查看当前两个账号的余额,分别为100元和50元;
A账号有足够的余额,转账开始,系统从A账号扣除100元,并在B账号加上100元。
服务高可用:作为一项互联网服务,交易每时每刻都在发生,秒级别的不可用也将损害用户体验。
处理高吞吐:面对ebay主站百万卖家时刻都在产生的支付流量,要求系统能在短时间内处理大量请求。
数据高安全:必须具有防盗防篡改的数据保护机制(本文暂不作介绍)。
Part 02
架构演进:从1.0到5.0
架构1.0
图 2(点击可查看大图)
图 4(点击可查看大图)
架构2.0
图 5(点击可查看大图)
架构3.0
当发生failover时,新leader的状态(账户余额)必须和上任leader下台前达到完全一致,才能开始处理新的请求。
图 6(点击可查看大图)
架构4.0
Apply:根据事件更新状态。
公式 1
我们首先使用快照(Snapshot)来缩短时间。系统定期把当前状态做成快照写到本地磁盘,恢复时,先加载最近一次快照,接着Apply后面的事件。优化后状态恢复所需时间为:
公式 2
架构5.0
架构4.0基本上能满足本文刚开始提到的所有需求,也确实在预生产环境中跑了相当长一段时间……直到我们在数据迁移过程中遇到了内存问题(图11)。
CPL所Apply的事件包含尚未成功提交到事件仓库的部分,产生的状态属于临时状态,不会写入RocksDB,而是留在内存中。一来可以提高查询速度,二来如果换主导致事件无法写入仓库,状态可以直接丢弃。
CPL在查询时,会先看内存中是否有相关数据,只有当不存在时才会查询RocksDB。
图 14(点击可查看大图)
Part 03
未来工作
Part 04
结语
目前架构5.0已经在生产环境下稳定运行超过7个月。对上游,它就像单进程一样对外提供服务,却具有单进程所缺少的工业级的数据防丢失、服务高可用、高吞吐等特性。我们认为在不久的将来,在金融、医疗等领域,这类应用会成为一种新常态,我们也已对该项目开源[6](业务逻辑除外),希望可以为同类应用的开发带来帮助。
[1]https://raft.github.io/
您可能还感兴趣:
eBay大量优质职位,等的就是你