6 消息队列在企业架构中扮演着什么角色？.docxVIP

消息队列在企业架构中扮演着什么角色？ 说到消息队列，就不得不说一下日志 。 作者批注：本质上日志与消息队列都可以笼统成 Pub/Sub 的模式 Jay Kreps (Confluent CEO，Kafka 核心作者) 在《The Log: What every software engineer should know about real-time data’s unifying abstraction》[1] 中系统性描述了日志的价值和重要性，指出了日志特定的应用目标：它记录了什么时间发生了什么事情（they record what happened and when）。而这，正是分布式系统很多问题的核心。 作者批注：《日志：每个软件工程师都应当晓得的有关实时数据的统一笼统》听说是史诗般必读文章 这个“按时间天生有序”的特性让日志处理了分布式系统中的两个重要问题：修改操作的排序和数据分发（ordering changes and distributing data），这为并发更新的全都性和副本复制供应了基础。分布式系统中为了保证各副本的全都性，协商出全都的修改操作挨次是格外关键且核心的问题，利用日志天生有序的特性可以将这个简单的问题变得简约。 我们来看一个不太严谨的例子：假设系统有三个副本，都存储着 A=1 的初始值，某一时辰，要执行一个加法乘法的操作序列对 A 的值进行修改：+1、*3 假设 Primary 收到两条指令后，对其他副本依次广播了 “+1”、*3，由于网络的不确定因素，第一个副本收到的指令为 “*3”、+1，其次个副本收到的指令为 “+1”、*3，这就会带来副本的全都性问题；如何处理这个问题呢？答案是日志，利用日志将并发更新进行排序，全部副本从日志中按挨次读取更新操作，应用到本地，就可以将这个简单的问题简约化。 如图，Primary 依次进行 “+1”、*3 的操作，并写入日志，利用日志做修改操作的“数据分发”，使得各副天性够在本地应用完全相同的操作序列，从而保证各副本数据的全都； 作者批注：本质上是是把多台机器一起执行同一件事情的问题简化为实现分布式全都性日志，通过日志的 Pub/Sub 保证多台机器对数据处理的最终全都 上面的例子能很好的说明为什么挨次是保证副本间全都性的关键，而日志为此供应了基础和载体。让我们进一步思考和联想： Primary 将各种操作通过日志序列化，各 Replica 从日志中读取并应用到本地形态，这种处理问题的模式也叫 Pub/Sub，即笼统成通用的数据订阅机制，而将这种笼统产品化，就是消息队列。 二、消息队列的应用价值 消息队列作为大型分布式系统的关键组件，在实时数据或流式数据架构中扮演着重要角色，它通常被应用在系统解耦、异步处理、流量削峰，分布式事务 / 金融电商等场景中，接下来我们分别从这几个场景浅谈消息队列的应用价值。 1. 数据集成与系统解耦 假如说日志为处理分布式全都性问题供应了基础，那么同样是 Pub/Sub 模式的消息队列，则为琳琅满目的数据系统之间协作供应了一件利器，大大简化了数据集成的简单度（O(N^2) 变为 O(N)），提升了数据流转的效率，加速了数据价值呈现； 什么是数据集成？引用 Jay Kreps 的文章：Data integration is making all the data an organization has available in all its services and systems. 数据集成即将一个组织所拥有的数据，使其在全部的服务和系统中都可用。 那么数据集成是处理什么问题？使用消息队列又是如何加速数据集成的？我们看一个案例。 不少业务都有这样的场景：随着业务量的迸发，为理解用户行为，需要收集日志保存到 Hadoop 上做离线分析；为了能便利定位问题，同时把日志导一份到 ElasticSearch 做全文检索；为了给老板查看业务情况，需要将数据汇总到数仓中供应统计报表；此外还需要进行一些实时的流式计算…一个业务系统需要同时与多个大数据系统交互，一段时间后，团队有了新的业务，新业务系统又反复上面的事情，对接各种系统，如下图，最终的结果是系统架构盘根交叉，愉快与苦痛齐飞。 可以看到，上面案例本质上是一个数据集成的需求，但数据集成的难处就在于需要面对：1）越来越多的数据；2）越来越多的数据系统； 为什么会有这种现象，只能说大数据时代下，很难有一个系统能够处理全部的事情，这就导致了业务数据由于不同用途而需要存入不同的系统，比如上面说的检索，分析，计算等；于是，数据集成的挑战就变成了不同系统间繁杂的数据同步，有多简单？M 个业务，N 个数据系统： 1）全部业务都需要关怀到每一个系统的数据导入，简单度 M*N ； 2）架构简单交叉