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

时间 2019-11-06

标签流量系统架构如何保证百亿数据一致性石杉的架构笔记栏目系统架构繁體版

原文原文链接

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

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

一、前情提示

上一篇文章《亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？》，咱们已经给出了一整套的数据一致性的保障方案。高并发

咱们从以下三个角度，给出了方案如何实现。而且经过数据平台和电商系统进行了举例分析。oop

核心数据的监控
数据链路追踪
自动化数据链路分析

目前为止，咱们的架构图大概以下所示：

而且我们以前对于这种架构下，如何基于MQ进行解耦的实现也作了详细的说明。

有不清楚的同窗，能够具体看一下以前的三篇文章：

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

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

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

那么这篇文章，咱们就基于这个架构，在数据一致性方面作进一步的说明。一样，咱们以RabbitMQ这个消息中间件来举例。

二、选择性的订阅部分核心数据

首先一个基于MQ实现的细节点就在于，好比对数据监控系统而言，他可能仅仅只是要从MQ里订阅部分数据来消费罢了。

这个是啥意思呢？由于好比实时计算平台他是会将本身计算出来的全部的数据指标都投递到MQ里去的。

可是这些数据指标多是多达几十个甚至是几百个的，这里面不可能全部数据指标都是核心数据吧？

基本上按照咱们过往经验而言，对于这种数据类的系统核心数据指标，大概就占到10%左右的比例而已。

而后对于数据查询平台而言，他多是须要把全部的数据指标都消费出来，而后落地到本身的存储里去的。

可是对于数据监控系统而言，他只须要过滤出10%的核心数据指标便可，因此他须要的是有选择性的订阅数据。

我们看看下面的图，立马就明白是什么意思了。

三、RabbitMQ的queue与exchange的绑定

不知道你们是否还记得以前讲解基于RabbitMQ实现多系统订阅同一份数据的场景。

咱们采用的是每一个系统使用本身的一个queue，可是都绑定到一个fanout exchange上去，而后生产者直接投递数据到fanout exchange。

fanout exchange会分发一份数据，绑定到本身的全部queue上去，而后各个系统都会从本身的queue里拿到相同的一份数据。

你们再看看下面的图回顾一下。

在这里有一个关键的代码以下所示：

也就是说，把本身建立的queue绑定到exchange上去，这个绑定关系在RabbitMQ里有一个专业的术语叫作：binding。

四、direct exchange实现消息路由

若是仅仅使用以前的fanout exchange，那么是没法实现不一样的系统按需订阅数据的，若是要实现容许不一样的系统按需订阅数据，那么须要使用direct exchange。

direct exchange容许你在投递消息的时候，给每一个消息打上一个routing key。同时direct exchange还容许binding到本身的queue指定一个binding key。

这样，direct exchange就会根据消息的routing key将这个消息路由到相同binding key对应的queue里去，这样就能够实现不一样的系统按需订阅数据了。

说了这么多，是否是感受有点晕，老规矩，我们来一张图，直观的感觉一下怎么回事儿：

并且一个queue是可使用多个binding key的，好比说使用“k1”和“k2”两个binding key的话，那么routing key为“k1”和“k2”的消息都会路由到那个queue里去。

同时不一样的queue也能够指定相同的ruoting key，这个时候就跟fanout exchange实际上是同样的了，一个消息会同时路由到多个queue里去。

五、按需订阅的代码实现

首先在生产者那块，好比说实时计算平台吧，他就应该是要定义一个direct exchange了。

以下代码所示，全部的数据都是投递到这个exchange里去，好比咱们这里使用的exchange名字就是“rt_data”，意思就是实时数据计算结果，类型是“direct”：

channel.exchangeDeclare(
                "rt_data", 
                "direct");
复制代码

并且，在投递消息的时候，要给一个消息打上标签，也就是他的routing key，代表这个消息是普通数据仍是核心数据，这样才能实现路由，以下代码所示：

上面第一个参数是指定要投递到哪一个exchange里去，第二个参数就是routing key，这里的“common_data”表明了是普通数据，也能够用“core_data”表明核心数据，实时计算平台根据本身的状况指定普通或者核心数据。

而后消费者在进行queue和exchange的binding的时候，须要指定binding key，代码以下所示：

上面第一行就是在消费者那里，好比数据监控系统那里，也是定义一下direct exchange。

而后第二行就是定义一个“rt_data_monitor“这个queue。

第三行就是对queue和exchange进行绑定，指定了binding key是“core_data”。

若是是数据查询系统，他是普通数据和核心数据都要的，那么就能够在binding key里指定多个值，用逗号隔开，以下所示：

channel.queueBind(
                "rt_data_query", 
                "rt_data", 
                "common_data, core_data");
复制代码

到这里，你们就明白如何对数据打上不一样的标签（也就是routing key），而后让不一样的系统按需订阅本身须要的数据了（也就是指定binding key），这种方式用到了direct exchange这种类型，很是的灵活。

最后，再看看以前画的那幅图，你们再来感觉一下便可：

六、更增强大并且灵活的按需订阅

RabbitMQ还支持更增强大并且灵活的按需数据订阅，也就是使用topic exchange，其实跟direct exchange是相似的，只不过功能更加的强大罢了。

好比说你定义一个topic exchange，而后routing key就须要指定为用点号隔开的多个单词，以下所示：

而后，你在设置binding key的时候，他是支持通配符的。 * 匹配一个单词，# 匹配0个或者多个单词，好比说你的binding key能够这么来设置：

这个product.*.* ，就会跟“product.common.data”匹配上，意思就是，可能某个系统就是对商品类的数据指标感兴趣，无论是普通数据仍是核心数据。

因此到这里，你们就应该很容易明白了，经过RabbitMQ的direct、topic两种exchange，咱们能够轻松实现各类强大的数据按需订阅的功能。

经过本文，咱们就将最近讲的数据一致性保障方案里的一些MQ中间件落地的细节给你们说明白了。

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七、亿级流量系统架构之如何保证百亿流量下的数据一致性（上）

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

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