支付类系统数据处理和数据中台的数据处理方式有什么不同？

数据备份之后实时性如何保证

在建立数据中台的时候，数据还是来源于各个异构的业务应用系统，实现了数据的统一，但是数据实际上是多存了一份，数据存在冗余，同时数据实时性如何来保证了？针对每个业务系统都开发数据提取接口？

数据备份的通用处理方式

能用数据层的binlog方式就用，要不就业务层拉数据，不过如果可以的话，都可以针对各个数据存储开发类似binlog的东西。

其实，这个是三个问题。

第一，数据平台类似于数仓，一般就是基于binlog去同步的，异构数据库可以了解下阿里云的dts，支持多个数据库的解析。

第二，数据同步肯定存在时延，跨数据中心的同步正常情况下在几十毫秒左右，那么对于一些资金类的就要注意了，有些业务需要对数据强一致有要求，就只能读主库。

第三，数据提取接口不现实，比如rpc超时，消息消费失败都是需要考虑的，所以最后还是做到业务无侵入性。

数据强一致场景怎么搞

阿里在处理强一致场景下也是按照读写主库的方式处理的吗？这样的话数据库资源需要能承载所有的请求流量？

看场景，不考虑微服务之间的强一致性的前提下。我们就探讨时延导致的主从一致性。

比如，异地多活，整个链路调用都是单元化，那么就不会有问题，因为整个流量都在一个机房读写。如果上游单元化，下游没有单元化，这种情况，就需要所有流量走中心机房，所有读强制走主库。如果不考虑异地多活，只有一个机房，按照读写主库的方式处理。

比如订单支付或者库存这种场景，如果做了单元化之后，面对高并发场景时可能会通过缓存对DB进行一定的保护，但是引入缓存之后可能造成缓存和DB数据不一致的情况，由于系统业务对于强一致有要求所以是不是可以读写完全落到DB，这样DB就需要承载所有的流量（不能靠缓存了），不知道支付宝oceanbase是不是通过强一致方式实现了这种思路，或者说这种思路是在阿里所有部门采用的通用强一致方案。

京东的搞法

我的项目是京东自己的弹性数据库，因为数据量大采用分库分表和读写分离。但是对于实时要求高的，查询立马更新状态的，目前依然是只能读写主库。

因为主从同步的数据时延随着你的访问量越大，时延越高。如果只是为了查询实时数据的话，可以向梁老师说的那样，通过binlog异步获取数据最终状态。

但是之后数据量继续增加实时查询QPS达到很高状态，比如15k的话，那么原来16核的配置就需要继续升级配置或者不再使用mysql数据库。这样场景应该也很少吧。

美团的搞法

我们目前的处理方式类似 因为对于一致性有一定的要求 采用单元化+分库方式搞相当于都是主读主写，随着流量越来越大，资源申请也变得越来越多。

所以在考虑有没有可替代的方案（Mysql资源有限啊），公司在考虑自研类oceanbase的分布式一致性数据库，但是可用时间还比较远。

阿里的搞法

说说我的场景，也是依然是只能读写主库。例如，我们的自动化退款业务，基于强规则的，这个时候匹配可以退款出账，但是如果出现时延，可能下一秒就不匹配了，这种情况时延可能就有资损风险。

整体的业务场景。就是上游有退款的业务平台，是具体的资金出账业务，然后买家发起退款的时候会先过我们服务的一层规则引擎和风控系统，这个时候所有匹配的数据都需要强时效。

应该是定时任务需要同时判断多个库的数据，才能判定能不能执行动作并且要及时。但是为了减轻主库压力，就得读从库。从库又是存在延时的。所以强迫读主库了。

压力大时，其实应该用实时流，更为合适。

大概想到具体的业务场景了。 就是比如退款这种业务 发货的商品是不能直接退款的，假如用户发起退款申请的时候去查订单是否发货。此时刚好发货写入了主库，还没有同步到从库的时候如果查从库就会有问题。 应该是类似这种业务场景吧 。

总结

虽然面对三高系统的设计我们可以找到很多文章和思路进行佐证，但是在真正的业务实践过程中还是需要做好取舍和依据业务场景个性化设计。

面对高并发场景下，同时对于强一致性有要求的业务场景，目前业界主流互联网阿里，美团，京东公司的搞法都差不多，还是主写主读来面对因为地域，多机房，主从等同步带来的延迟，除非具有蚂蚁金服一样的研发能力自研分布式强一致的OceanBase，否则一般还是在mysql分库角度做文章。