亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？【石杉的架构笔记】

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）

周一至周五早8点半！精品技术文章准时送上！

目录

1、多系统订阅数据回顾

2、核心数据的监控系统

3、电商库存数据如何监控

4、数据计算链路追踪

5、百亿流量下的数据链路追踪

6、自动化数据链路分析

7、下篇预告

上篇文章《亿级流量系统架构之如何保证百亿流量下的数据一致性（上 ）》，初步给你们分析了一下，一个复杂的分布式系统中，数据不一致的问题是怎么产生的。

简单来讲，就是一个分布式系统中的多个子系统（或者服务）协做处理一份数据，可是最后这个数据的最终结果却没有符合指望。

这是一种很是典型的数据不一致的问题。固然在分布式系统中，数据不一致问题还有其余的一些状况。

好比说多个系统都要维护一份数据的多个副本，结果某个系统中的数据副本跟其余的副本不一致，这也是数据不一致。

可是这几篇文章，说的主要是咱们上篇文章分析的那种数据不一致的问题到底应该如何解决。

一、多系统订阅数据回顾

咱们先来看一张图，是以前讲系统架构解耦的时候用的一张图。

好！经过上面这张图，咱们来回顾一下以前作了系统解耦以后的一个架构图。

其实，实时计算平台会把数据计算的结果投递到一个消息中间件里。

而后，数据查询平台、数据质量监控系统、数据链路追踪系统，各个系统都须要那个数据计算结果，都会去订阅里面的数据。

这个就是当前的一个架构，因此这个系列文章分析到这里，你们也能够反过来理解了以前为何要作系统架构的解耦了。

由于一份核心数据，是不少系统均可能会须要的。经过引入MQ对架构解耦了以后，各个系统就能够按需订阅数据了。

二、核心数据的监控系统

若是要解决核心数据的不一致问题，首先就是要作核心数据的监控。

有些同窗会觉得这个监控就是用falcon之类的系统，作业务metrics监控就能够了，可是其实并非这样。

这种核心数据的监控，远远不是作一个metrics监控能够解决的。

在咱们的实践中，必需要本身开发一个核心数据的监控系统，在里面按照本身的需求，针对复杂的数据校验逻辑开发大量的监控代码。

咱们用那个数据平台项目来举例，本身写的数据质量监控系统，须要把核心的一些数据指标从MQ里消费出来，这些数据指标都是实时计算平台计算好的。

那么此时，就须要自定义一套监控逻辑了，这种监控逻辑，不一样的系统都是彻底不同的。

好比在这种数据类的系统里，极可能对数据指标A的监控逻辑是以下这样的：

• 数据指标A = 数据指标B + 数据指标C - 数据指标D * 24。

每一个核心指标都是有本身的一个监控公式的，这个监控公式，就是负责开发实时计算平台的同窗，他们写的数据计算逻辑，是知道数据指标之间的逻辑关系的。

因此此时就有了一个很是简单的思路：

1. 首先，这个数据监控系统从MQ里消费到每个最新计算出来的核心数据指标
2. 而后根据预先定义好的监控公式，从数据查询平台里调用接口获取出来公式须要的其余数据指标
3. 接着，按照公式进行监控计算。

若是监控计算事后发现几个数据指标之间的关系竟然不符合预先定义好的那个规则，那么此时就能够立马发送报警了（短信、邮件、IM通知）。

工程师接到这报警以后，就能够立马开始排查，为何这个数据竟然会不符合预先定义好的一套业务规则呢。

这样就能够解决数据问题的第一个痛点：不须要等待用户发现后反馈给客服了，本身系统第一时间就发现了数据的异常。

一样，给你们上一张图，直观的感觉一下。

三、电商库存数据如何监控

若是用电商里的库存数据来举例也是同样的，假设你想要监控电商系统中的核心数据：库存数据。

首先第一步，在微服务架构中，你必需要收口。

也就是说，在完全的服务化中，你要保证全部的子系统 / 服务若是有任何库存更新的操做，所有走接口调用请求库存服务。只能是库存服务来负责库存数据在数据库层面的更新操做，这样就完成了收口。

收口了以后作库存数据的监控就好办了，彻底能够采用MySQL binlog采集的技术，直接用Mysql binlog同步中间件来监控数据库中库存数据涉及到的表和字段。

只要库存服务对应的数据库中的表涉及到增删改操做，都会被Mysql binlog同步中间件采集后，发送到数据监控系统中去。

此时，数据监控系统就能够采用预先定义好的库存数据监控逻辑，来查验这个库存数据是否准确。

这个监控逻辑能够是不少种的，好比能够后台走异步线程请求到实际的C/S架构的仓储系统中，查一下实际的库存数量。

或者是根据必定的库存逻辑来校验一下，举个例子：

• 虚拟库存 + 预售库存 + 冻结库存 + 可销售库存 = 总可用库存数

固然，这就是举个例子，实际如何监控，你们根据本身的业务来作就行了。

四、数据计算链路追踪

此时咱们已经解决了第一个问题，主动监控系统中的少数核心数据，在第一时间能够本身先收到报警发现核心是护具备异常。

可是此时咱们还须要解决第二个问题，那就是当你发现核心数据出错以后，如何快速的排查问题到底出在哪里？

好比，你发现数据平台的某个核心指标出错，或者是电商系统的某个商品库存数据出错，此时你要排查数据到底为何错了，应该怎么办呢？

很简单，此时咱们必需要作数据计算链路的追踪。

也就是说，你必需要知道这个数据从最开始究竟是经历了哪些环节和步骤，每一个环节到底如何更新了数据，更新后的数据又是什么，还有要记录下来每次数据变动后的监控检查点。

好比说：

• 步骤A -> 步骤B -> 步骤C -> 2018-01-01 10:00:00

第一次数据更新后，数据监控检查点，数据校验状况是准确，库存数据值为1365；

• 步骤A -> 步骤B -> 步骤D -> 步骤C -> 2018-01-01 11:05:00

第二次数据更新后，数据监控检查点，数据校验状况是错误，库存数据值为1214

相似上面的那种数据计算链路的追踪，是必需要作的。

由于你必需要知道一个核心数据，他每次更新一次值经历了哪些中间步骤，哪些服务更新过他，那一次数据变动对应的数据监控结果如何。

此时，若是你发现一个库存数据出错了，立马能够人肉搜出来这个数据过往的历史计算链路。

你能够看到这条数据从一开始出现，而后每一次变动的计算链路和监控结果。

好比上面那个举例，你可能发现第二次库存数据更新后结果是1214，这个值是错误的。

而后你一看，发现其实第一次更新的结果是正确的，可是第二次更新的计算链路中多了一个步骤D出来，那么可能这个步骤D是服务D作了一个更新。

此时，你就能够找服务D的服务人问问，结果可能就会发现，原来服务D没有按照你们约定好的规则来更新库存，结果就致使库存数据出错。

这个，就是排查核心数据问题的一个通用思路。

五、百亿流量下的数据链路追踪

若是要作数据计算链路，其实要解决的技术问题只有一个，那就是在百亿流量的高并发下，任何一个核心数据天天的计算链路可能都是上亿的，此时你应该如何存储呢？

其实给你们比较推荐的，是用elasticsearch技术来作这种数据链路的存储。

由于es一方面是分布式的，支持海量数据的存储。

并且他能够作高性能的分布式检索，后续在排查数据问题的时候，是须要对海量数据作高性能的多条件检索的。

因此，咱们彻底能够独立出来一个数据链路追踪系统，并设置以下操做：

• 数据计算过程当中涉及到的各个服务，都须要对核心数据的处理发送一条计算链路日志到数据链路追踪系统。

• 而后，数据链路追踪系统就能够把计算链路日志落地到存储里去，按照必定的规则创建好对应的索引字段。

• 举个例子，索引字段：核心数据名称，核心数据id，本次请求id，计算节点序号，本次监控结果，子系统名称，服务名称，计算数据内容，等等。

此时一旦发现某个数据出错，就能够当即根据这条数据的id，从es里提取出来历史上全部的计算链路。

并且还能够给数据链路追踪系统开发一套用户友好的前端界面，好比在界面上能够按照请求id展现出来每次请求对应的一系列技术步骤组成的链路。

此时会有什么样的体验呢？咱们立马能够清晰的看到是哪一次计算链路致使了数据的出错，以及过程当中每个子系统 / 服务对数据作了什么样的修改。

而后，咱们就能够追本溯源，直接定位到出错的逻辑，进行分析和修改。

说了那么多，仍是给你们来一张图，一块儿来感觉一下这个过程。

六、自动化数据链路分析

到这里为止，你们若是能在本身公司的大规模分布式系统中，落地上述那套数据监控 + 链路追踪的机制，就已经能够很是好的保证核心数据的准确性了。

经过这套机制，核心数据出错时，第一时间能够收到报警，并且能够立马拉出数据计算链路，快速的分析数据为什么出错。

可是，若是要更进一步的节省排查数据出错问题的人力，那么能够在数据链路追踪系统里面加入一套自动化数据链路分析的机制。

你们能够反向思考一下，假如说如今你发现数据出错，并且手头有数据计算链路，你会怎么检查？

不用说，固然是你们坐在一块儿唾沫横飞的分析了，人脑分析。

好比说，步骤A按理说执行完了应该数据是X，步骤B按理说执行完了应该数据是Y，步骤C按理说执行完了应该数据是Z。

结果，诶！步骤C执行完了怎么数据是ZZZ呢？？看来问题就出在步骤C了！

而后去步骤C看看，发现原来是服务C更新的，此时服务C的负责人开始吭哧吭哧的排查本身的代码，看看到底为何接收到一个数据Y以后，本身的代码会处理成数据ZZZ，而不是数据Z呢？

最后，找到了代码问题，此时就ok了，在本地再次复现数据错误，而后修复bug后上线便可。

因此，这个过程的前半部分，是彻底能够自动化的。也就是你写一套自动分析数据链路的代码，就模拟你人脑分析链路的逻辑便可，自动一步步分析每一个步骤的计算结果。这样就能够把数据监控系统和链路追踪系统打通了。

一旦数据监控系统发现数据出错，立马能够调用链路追踪系统的接口，进行自动化的链路分析，看看本次数据出错，究竟是链路中的哪一个服务bug致使的数据问题。

接着，将全部的信息汇总起来，发送一个报警通知给相关人等。

相关人员看到报警以后，一目了然，全部人立马知道本次数据出错，是链路中的哪一个步骤，哪一个服务致使的。

最后，那个服务的负责人就能够立马根据报警信息，排查本身的系统中的代码了。

七、下篇预告

到这篇文章为止，咱们基本上梳理清楚了大规模的负责分布式系统中，如何保证核心数据的一致性。

那么下篇文章，咱们再就技术实现中涉及到的一些MQ技术的细节，基于RabbitMQ来进行更进一步的分析。

敬请期待：

亿级流量系统架构之如何保证百亿流量下的数据一致性（下）？

end

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授

推荐阅读：

一、拜托！面试请不要再问我Spring Cloud底层原理

二、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

三、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

四、微服务架构如何保障双11狂欢下的99.99%高可用

五、兄弟，用大白话告诉你小白都能听懂的Hadoop架构原理

六、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

七、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

八、拜托，面试请不要再问我TCC分布式事务的实现原理坑爹呀！

九、【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？

十、拜托，面试请不要再问我Redis分布式锁的实现原理！

十一、【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提高10倍以上？

十二、亿级流量系统架构之如何支撑百亿级数据的存储与计算

1三、亿级流量系统架构之如何设计高容错分布式计算系统

1四、亿级流量系统架构之如何设计承载百亿流量的高性能架构

1五、亿级流量系统架构之如何设计每秒十万查询的高并发架构

1六、亿级流量系统架构之如何设计全链路99.99%高可用架构

1七、七张图完全讲清楚ZooKeeper分布式锁的实现原理

1八、大白话聊聊Java并发面试问题之volatile究竟是什么？

1九、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？

20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？

2一、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？

2二、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化

2三、互联网公司的面试官是如何360°无死角考察候选人的？（上篇）

2四、互联网公司面试官是如何360°无死角考察候选人的？（下篇）

2五、Java进阶面试系列之一：哥们，大家的系统架构中为何要引入消息中间件？

2六、【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？

2七、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历

2八、【Java进阶面试系列之三】哥们，消息中间件在大家项目里是如何落地的？

2九、【Java进阶面试系列之四】扎心！线上服务宕机时，如何保证数据100%不丢失？

30、一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！

3一、【高并发优化实践】10倍请求压力来袭，你的系统会被击垮吗？

3二、【Java进阶面试系列之五】消息中间件集群崩溃，如何保证百万生产数据不丢失？

3三、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？

3四、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？

3五、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？

3六、亿级流量架构第二弹：你的系统真的无懈可击吗？

3七、亿级流量系统架构之如何保证百亿流量下的数据一致性（上）

做者：石杉的架构笔记 连接：https://juejin.im/post/5c263a936fb9a049ec6b2688 来源：掘金 著做权归做者全部，转载请联系做者得到受权！