专栏首页服务端技术杂谈支付类系统数据处理和数据中台的数据处理方式有什么不同?

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

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

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

数据备份的通用处理方式

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

其实,这个是三个问题。

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

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

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

数据强一致场景怎么搞

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

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

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

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

京东的搞法

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

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

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

美团的搞法

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

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

阿里的搞法

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

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

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

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

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

总结

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

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

本文分享自微信公众号 - 春哥叨叨(chungedaodao),作者:春哥大魔王

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 搞定中台,必须有的中控平台,业务身份和扩展点

    业务中台需要解决信息获取成本高、互联互通成本高、服务的不确定性、低水平重复建设这四个难题的。

    春哥大魔王
  • 服务治理和Service Mesh

    当系统访问量和数据量超过之前对评估预期时,涉及到对数据库重新分片。大部分场景中往往不能直接映射到新对数据分片策略中,分片策略修改需要伴随数据迁移。

    春哥大魔王
  • Spring容器和Bean加载

    IOC(控制反转):对于组件的控制权进行了转移,传统的程序设计是由客户端new出对象,是程序主动创建所依赖的对象。而IOC是专门将对象的创建交给容器处理,组件的...

    春哥大魔王
  • 如何打造运维团队不可替代的“L”型价值体系-下篇

    你也许可以听听腾讯蓝鲸对于两个问题的解答,或许能够帮你和你的团队拨云见日、一扫愁云,看清未来的方向和出路。

    嘉为科技
  • 发改委:组织实施2018年“互联网+”、人工智能创新发展和数字经济试点重大工程的通知

    人工智能/互联网+/发改委国家发展改革委办公厅关于 组织实施2018年“互联网+”、人工智能创新发展和数字经济试点重大工程的通知   发改办高技〔2017〕16...

    AI科技大本营
  • PHP与jQuery结合的功能

    获取后台填充数据没问题,但是当后台数据已失效,前台数据已获取后,这种历史遗留数据处理比较棘手,原来的数据填充和释放只针对后台所有的数据,没有把版本迭代后的状态考...

    php007
  • python GUI库图形界面开发之PyQt5状态栏控件QStatusBar详细使用方法实例

    MainWindow对象在底部保留有一个水平条,作为状态栏(QstatusBar),用于显示永久或临时的状态信息

    砸漏
  • 每周学点大数据 | No.68 Hadoop 实践案例——等值连接

    No.68 Hadoop 实践案例——等值连接 Mr. 王 :我们再来看看另一个非常常见的例子。很多时候,我们关心的数据来自多个表。比如在某学校的教务系统中,有...

    灯塔大数据
  • 大数据领域的性能测试Benchmark介绍

    一、Benchmark简介 Benchmark是一个评价方式,在整个计算机领域有着长期的应用。正如维基百科上的解释“As computer architect...

    Albert陈凯
  • 软件开发环境被感染 导致“锋彩直播”app携带病毒

    近日火绒安全团队发现,一款名为“锋彩直播”的安卓直播app中带有病毒“TrojanDropper/Ramnit.h”。

    用户6477171

扫码关注云+社区

领取腾讯云代金券