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

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

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

目录

1、前情提示

2、什么是数据一致性？

3、一个数据计算链路的梳理

4、数据计算链路的bug

5、电商库存数据的不一致问题

6、大型系统的数据不一致排查有多困难

7、下篇预告

1、前情提示

这篇文章，我们继续来聊聊以前的亿级流量架构的演进，以前对这个系列的文章已经更新到了可扩展架构的设计，若是有不太清楚的同窗，建议必定先回看一下以前的文章：

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

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

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

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

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

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

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

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

老规矩！咱们首先看一下这个复杂的系统架构演进到当前阶段，总体的架构图是什么样子的。

笔者再次友情提醒，若是各位小伙伴对下面这个复杂的架构图还有什么不理解的地方，必定要先回看以前的文章，由于系列文必须对上下文有清晰的理解和认识。

接着文本咱们来聊聊一个核心系统天天承载百亿流量的背景下，应该如何来保证复杂系统中的数据一致性？

2、什么是数据一致性？

简单来讲，在一个复杂的系统中必定会对一些数据作出很是复杂的处理，并且多是多个不一样的子系统，甚至是多个服务。

对一个数据按照必定的顺序依次作出复杂的业务逻辑的执行，最终可能就会生产出一份宝贵的系统核心数据，落地到存储里去，好比说在数据库里存储。

给你们来一张手绘彩图，感觉下这个现场的氛围：

从上图中咱们就能够看到，多个系统如何对一个数据依次进行处理，最终拿到一份核心数据，并落地到存储里去。

那么在这个过程当中，就可能会产生所谓的数据不一致的问题。

什么意思呢？给你们举一个最简单的例子，咱们原本指望数据的变化过程是：数据1 -> 数据2 -> 数据3 -> 数据4。

那么最后落地到数据库里的应该是数据4，对不对？

结果呢？不知道为啥，通过上面那个复杂的分布式系统中的各个子系统，或者是各个服务的协做处理，最后竟然搞出来一个数据87。

搞了半天，搞了一个跟数据4风马牛不相及的一个东西，最后落地到了数据库里。

而后啊，这套系统的最终用户，可能经过前台的界面看到了一个莫名其妙的数据87。

这就尴尬了，用户明显会以为这个数据有错误，就会反馈给公司的客服，此时就会上报bug到工程师团队，你们就开始吭哧吭哧的找问题。

上面说的这个场景，其实就是一种数据不一致的问题，也是咱们接下来几篇文章要讨论的一个问题。

实际上，在任何一个大规模分布式系统里，都会存在相似的问题。不管是电商，O2O，仍是本文举例的数据平台系统，都同样。

3、一个数据计算链路的梳理

那么既然已经明确了问题，接下来就来看看在数据平台这个系统里，究竟是什么问题可能会致使一个最终落地存储的数据的异常呢？

要明白这个问题，我们先回过头看看，在以前提过的数据平台这个项目里，一个最终落地的数据的计算链路是什么样的？

你们看看下面的图：

如上图所示，其实从最简单的一个角度来讲，这个数据计算的链路大概也就是上面的那个样子。

1. 首先，经过MySQL binlog采集中间件获取到数据，转发给数据接入层。
2. 而后，数据接入层会把原始数据落地到kv存储里去
3. 接着，是实时计算平台会从kv存储里提取数据进行计算
4. 最后，会将计算结果写入到数据库+缓存的集群里。数据查询平台会从数据库 + 缓存的集群里提取数据，提供用户来进行查询

看起来很简单，对吧？

可是哪怕是这个系统里，数据计算链路，也绝对不是这么简单的。

若是你们看过以前的系列文章的话，就应该知道，这个系统为了支撑高并发、高可用、高性能等场景，引入了大量的复杂机制。

因此实际上一条原始数据进入到系统，一直到最后落地到存储里，计算链路还会包含下面的东西：

1. 接入层的限流处理
2. 实时计算层的失败重试
3. 实时计算层的本地内存存储的降级机制
4. 数据分片的聚合与计算，单条数据在这里可能会进入一个数据分片里
5. 数据查询层的多级缓存机制

上面只不过是随便列举了几条。然而哪怕只是上述几条，均可以把一个数据的计算链路变得复杂不少倍了。

4、数据计算链路的bug

既然你们已经明白了，在一个复杂系统里，一份核心数据多是通过一个极为复杂的计算链路的处理，中间百转千回，任何可能的状况都会发生。

那么就能够理解在大型分布式系统中，数据不一致的问题是如何产生的了。

其实缘由很是的简单，说白了，就是数据计算链路的bug。

也就是说，在数据的计算过程当中，某个子系统出现了bug，并无按照咱们预期的行为去处理，致使最终产出去的数据变得错误了。

那么，为何会在数据计算链路中出现这种bug呢？

缘由很简单，若是你们曾经参与过上百人协做的大型分布式系统，或者是主导过上百人协做开发的大型分布式系统的架构设计，应该对核心数据的异常和错误很是熟悉，而且会感到头疼不已。

大规模分布式系统中，动辄上百人协做开发。极可能某个子系统或者是某个服务的负责人，对数据的处理逻辑理解误差了，代码里写了一个隐藏的bug。

而这个bug，轻易不会触发，而且在QA测试环境还没测出来，结果带着一颗定时炸弹，系统上线。

最后在线上某种特殊的场景下，触发了这个bug，致使最终的数据出现问题。

5、电商库存数据的不一致问题

接触过电商的同窗，可能此时脑子里就能够快速的想到一个相似的经典场景：电商中的库存。

在大规模的电商系统中，库存数据绝对是核心中的核心。可是实际上，在一个分布式系统中，不少系统可能都会采用必定的逻辑来更新库存。

这就可能致使跟上述说的场景相似的问题，就是多个系统都更新库存，但就是某个系统对库存的更新出现了bug。

这多是由于那个系统的负责人没理解到底应该如何更新库存，也或者是他更新的时候采用的逻辑，没有考虑到一些特殊状况。

这样致使的结果就是，系统里的库存和仓库中实际的库存，死活对不上。但就是不知道到底哪一个环节出了问题，致使库存数据出错。

这个，其实就是一个典型的数据不一致的问题。

6、大型系统的数据不一致排查有多困难

当面对一个大型分布式系统时，若是你以前压根儿没考虑过数据不一致的问题，那么我敢打赌，当你负责的系统在线上被客服反馈有某个核心数据不一致的时候，你绝对会一脸蒙圈。

由于一个核心数据的处理，少则涉及几个系统的协做处理，多则涉及十个以上的系统的协做处理。

若是你没有留存任何日志、或者仅仅就是有部分日志，而后基本就只能全部人干瞪眼，你们大眼对小眼，都盯着本身的代码看。

你们根据一个数据最后的错误结果，好比数据87。10多我的对着本身的代码，反复的思考，左思右想。

而后每一个人都在大脑中疯狂的模拟本身代码的运行，可是就是想不明白，为何原本应该是数据4的，结果出来了一个数据87？

因此现实问题就是这样，这种数据不一致的问题，大概有如下几个痛点：

1. 本身基本没法主动提早感知到数据问题，要被动等待用户发现，反馈给客服，这极可能致使你的产品被大量投诉，老板很生气，后果很严重。
2. 即便客服告诉了你数据错了，可是大家无法还原现场，没有留存证据，基本就是一群工程师对着代码想象，猜想。
3. 即便你解决了一次数据不一致的问题，可是之后也许还有下一次，这样搞下去，会致使团队里好几个能干的小伙儿时间都搭在这种破事儿上。

7、下篇预告

因此针对本文描述的大型分布式系统数据不一致的问题，下篇文章咱们将给出：在百亿流量的场景下，一套复杂系统咱们是如何构建整套核心数据保证方案的。

敬请期待：

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

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六、亿级流量架构第二弹：你的系统真的无懈可击吗？

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