欢迎关注个人公众号：石杉的架构笔记（ID:shishan100）
周一至周五早8点半！精品技术文章准时送上！
目录
一、前情提示
二、选择性订阅部分核心数据
三、RabbitMQ的queue与exchange的绑定回顾
四、direct exchange实现消息路由
五、按需订阅数的代码实现
六、更加强大而且灵活的按需订阅
1、前情提示
上一篇文章《亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？》，我们已经给出了一整套的数据一致性的保障方案。
我们从如下三个角度，给出了方案如何实现。并且通过数据平台和电商系统进行了举例分析。
- 核心数据的监控
- 数据链路追踪
- 自动化数据链路分析
目前为止，我们的架构图大概如下所示：
并且咱们之前对于这种架构下，如何基于MQ进行解耦的实现也做了详细的说明。
有不清楚的同学，可以具体看一下之前的三篇文章：
1、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？
2、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？
3、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？
那么这篇文章，我们就基于这个架构，在数据一致性方面做进一步的说明。同样，我们以RabbitMQ这个消息中间件来举例。
2、选择性的订阅部分核心数据
首先一个基于MQ实现的细节点就在于，比如对数据监控系统而言，他可能仅仅只是要从MQ里订阅部分数据来消费罢了。
这个是啥意思呢？因为比如实时计算平台他是会将自己计算出来的所有的数据指标都投递到MQ里去的。
但是这些数据指标可能是多达几十个甚至是几百个的，这里面不可能所有数据指标都是核心数据吧？
基本上按照我们过往经验而言，对于这种数据类的系统核心数据指标，大概就占到10%左右的比例而已。
然后对于数据查询平台而言，他可能是需要把所有的数据指标都消费出来，然后落地到自己的存储里去的。
但是对于数据监控系统而言，他只需要过滤出10%的核心数据指标即可，所以他需要的是有选择性的订阅数据。
咱们看看下面的图，立马就明白是什么意思了。
3、RabbitMQ的queue与exchange的绑定
不知道大家是否还记得之前讲解基于RabbitMQ实现多系统订阅同一份数据的场景。
我们采用的是每个系统使用自己的一个queue，但是都绑定到一个fanout exchange上去，然后生产者直接投递数据到fanout exchange。
fanout exchange会分发一份数据，绑定到自己的所有queue上去，然后各个系统都会从自己的queue里拿到相同的一份数据。
大家再看看下面的图回顾一下。
在这里有一个关键的代码如下所示：
也就是说，把自己创建的queue绑定到exchange上去，这个绑定关系在RabbitMQ里有一个专业的术语叫做：binding。
4、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里去。
5、按需订阅的代码实现
首先在生产者那块，比如说实时计算平台吧，他就应该是要定义一个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这种类型，非常的灵活。
最后，再看看之前画的那幅图，大家再来感受一下即可：
6、更加强大而且灵活的按需订阅
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架构经验倾囊相授
推荐阅读：2、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？
3、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战
6、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问
7、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍
8、拜托，面试请不要再问我TCC分布式事务的实现原理坑爹呀！
9、【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？
11、【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上？
16、亿级流量系统架构之如何设计全链路99.99%高可用架构
18、大白话聊聊Java并发面试问题之volatile到底是什么？
19、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？
20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？
21、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？
22、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化
23、互联网公司的面试官是如何360°无死角考察候选人的？（上篇）
24、互联网公司面试官是如何360°无死角考察候选人的？（下篇）
25、Java进阶面试系列之一：哥们，你们的系统架构中为什么要引入消息中间件？
26、【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？
27、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历
28、【Java进阶面试系列之三】哥们，消息中间件在你们项目里是如何落地的？
29、【Java进阶面试系列之四】扎心！线上服务宕机时，如何保证数据100%不丢失？
30、一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！
31、【高并发优化实践】10倍请求压力来袭，你的系统会被击垮吗？
32、【Java进阶面试系列之五】消息中间件集群崩溃，如何保证百万生产数据不丢失？
33、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？
34、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？
35、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？
作者：石杉的架构笔记
链接：https://juejin.im/post/5c263a936fb9a049ec6b2688
来源：掘金
著作权归作者所有，转载请联系作者获得授权！