消息队列价值思考

本文将带给你不一样的消息队列价值思考。

往期文章回顾：一场HBase2.x的写入性能优化之旅

目录

1. 日志与消息队列

2. 消息队列的应用价值

• 数据集成与系统解耦

• 异步处理与事件驱动

• 流量削峰

• 事务消息与分布式事务的最终一致

• 从历史看消息队列的价值演化

• 小米的消息队列产品Talos与EMQ

• • Talos/EMQ 与开源产品的区别

  • Talos与EMQ的区别

• 后续文章

• 参考文献

• ---

  时常会思考消息队列的价值是什么？新人加入团队后该如何理解消息队列？又该如何理解小米的自研产品 Talos 和 EMQ？

  鉴于这些考虑，我把对消息队列的理解做一个简单总结，希望能帮助感兴趣的同学了解 Talos/EMQ 的价值和定位，以及它在企业架构中扮演着什么样的角色。 
  作者批注：思考手上的工作，找到它的价值和定位，就找到了工作的目标 — 努力将价值最大化

  一、日志与消息队列

  说到消息队列，就不得不说一下日志 
  作者批注：本质上日志与消息队列都可以抽象成 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，即抽象成通用的数据订阅机制，而将这种抽象产品化，就是消息队列。

  二、消息队列的应用价值

  消息队列作为大型分布式系统的关键组件，在实时数据或流式数据架构中扮演着重要角色，它通常被应用在系统解耦、异步处理、流量削峰，分布式事务/金融电商等场景中，接下来我们分别从这几个场景浅谈消息队列的应用价值。