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

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

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

数据备份的通用处理方式

能用数据层的binlog方式就用，要不就业务层拉数据，不过若是能够的话，均可以针对各个数据存储开发相似binlog的东西。

其实，这个是三个问题。

第一，数据平台相似于数仓，通常就是基于binlog去同步的，异构数据库能够了解下阿里云的dts，支持多个数据库的解析。

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

第三，数据提取接口不现实，好比rpc超时，消息消费失败都是须要考虑的，因此最后仍是作到业务无侵入性。

数据强一致场景怎么搞

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

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

好比，异地多活，整个链路调用都是单元化，那么就不会有问题，由于整个流量都在一个机房读写。若是上游单元化，下游没有单元化，这种状况，就须要全部流量走中心机房，全部读强制走主库。若是不考虑异地多活，只有一个机房，按照读写主库的方式处理。

好比订单支付或者库存这种场景，若是作了单元化以后，面对高并发场景时可能会经过缓存对DB进行必定的保护，可是引入缓存以后可能形成缓存和DB数据不一致的状况，因为系统业务对于强一致有要求因此是否是能够读写彻底落到DB，这样DB就须要承载全部的流量（不能靠缓存了），不知道支付宝oceanbase是否是经过强一致方式实现了这种思路，或者说这种思路是在阿里全部部门采用的通用强一致方案。

京东的搞法

个人项目是京东本身的弹性数据库，由于数据量大采用分库分表和读写分离。可是对于实时要求高的，查询立马更新状态的，目前依然是只能读写主库。

由于主从同步的数据时延随着你的访问量越大，时延越高。若是只是为了查询实时数据的话，能够向梁老师说的那样，经过binlog异步获取数据最终状态。

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

美团的搞法

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

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

阿里的搞法

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

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

应该是定时任务须要同时判断多个库的数据，才能断定能不能执行动做而且要及时。可是为了减轻主库压力，就得读从库。从库又是存在延时的。因此强迫读主库了。

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

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

总结

虽然面对三高系统的设计咱们能够找到不少文章和思路进行佐证，可是在真正的业务实践过程当中仍是须要作好取舍和依据业务场景个性化设计。

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

更多细节欢迎关注【春哥叨叨】，更多真实架构案例分享：