mq

RocketMQ简介 1.RocketMQ是一款分布式、队列模型的消息中间件，是阿里巴巴集团自主研发的专业消息中间件，借鉴参考了JMS规范的MQ实现，更参考了优秀的开源消息中间件KAFKA,实现了业务消峰、分布式事务的优秀框架。 2.其底层代码编写清晰优秀，采用 Netty NIO 框架进行数据通信 3.摒弃了Zookeeper,内部使用更轻量级的NameServer进行网络路由，提高服务性能，并且 支持消息失败重试 机制。 4.天然支持集群模型，消费者负载均衡、水平扩展能力，支持广播模式和集群模式。 5.采用零拷贝的原理、顺序写盘、支持亿级消息堆积能力。 6.提供丰富的消息机制，如顺序消息、事务消息等 MQ基本概念： Message :消息，消息队列中信息传递的载体。 Message ID :消息的全局唯一标识，由 MQ 系统自动生成，唯一标识某条消息。 Message Key :消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。 Topic :消息主题，一级消息类型，通过 Topic 对消息进行分类。 Tag :消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类。 Producer :消息生产者，也称为消息发布者，负责生产并发送消息。 Producer ID ：一类 Producer 的标识，这类 Producer

什么是 MQ Message Queue（MQ），消息队列中间件。 很多人都说： MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。 MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。 一个分布式系统中两个模块之间通讯要么是 HTTP，要么是自己开发的 TCP，但是这两种协议其实都是原始的协议。 HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上 WebServer，而且还不支持长连接（HTTP 2.0 的库根本找不到）。 TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。 MQ 所要做的就是在这些协议之上构建一个简单的“协议”—— 生产者/消费者模型。 MQ 带给我的“协议”不是具体的通讯协议，而是更高层次 通讯模型 。 它定义了两个对象——发送数据的叫生产者，接收数据的叫消费者； 提供一个 SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议。 分类： MQ，分为有Broker的MQ，和没有Broker的MQ。 Broker，代理，经纪人的意思。 无Broker的MQ 无 Broker 的 MQ 的代表是 ZeroMQ。 有Broker的MQ

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

前言 再说mq之前我们先说说背景吧，MQ(message queue简称消息队列)主要作用不是通讯，主要是用于解除子系统间的耦合，所以异构系统间的通讯实际并不是mq发挥作用的场景，那反而是RPC（remote procedure call）发挥作用的时候, mq更适合于需要更大流量和高并发的大型系统场景，可以将消息队列视为一个可靠的通道，主交易过程在处理时，遇到需时较多同时又已经确定了条件的处理就丢到消息队列里进行后续处理，这样可以将主交易过程划分为一个一个可以异步处理的更小的处理过程，减少了主交易流程的处理时间，可以提供更快的响应速度和并发速度，例如，像淘宝这样的处理逻辑非常多的系统，在处理付款时，就可以将通知买家和卖家、记日志甚至记帐流程都放到消息队列里处理，整个主流程能够快速处理完成，继续处理下一个买家的请求 1.MetaQ简介 MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，思路起源于LinkedIn的Kafka，但并不是Kafka的一个Copy。MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景 2.MetaQ使用场景 (1) 日志传输，用于高吞吐量的日志传输； (2) 消息广播，将消息放入Topic中，供所有的消费者消费； (3) 数据的顺序同步功能

MQ技术（消息队列） 消息中间件概述 消息队列技术是分布式应用间交换信息的一种技术。 消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。 通过消息队列，应用程序可独立地执行–它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。 消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。 消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。 消息队列的四大好处： 1.解耦：每个成员不必受其他成员影响，可以更独立自主，只通过一个简单的容器来联系。 2.提速 3.广播 4.削峰 消息队列的成本： 1.引入复杂度 2.暂时的不一致性 中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。 它在计算机系统中是一个关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的运行。 中间件位于用户应用和操作系统及网络软件之间，它为应用提供了公用的通信手段，并且独立于网络和操作系统。 中间件为开发者提供了公用于所有环境的应用程序接口，当应用程序中嵌入其函数调用，它便可利用其运行的特定操作系统和网络环境的功能，为应用执行通信功能。 如果没有消息中间件完成信息交换

【SpringBoot MQ系列教程】RabbitMq 初体验 mq 在异步解耦削峰的优势非常突出，现在很多的项目都会用到，掌握 mq 的知识点，了解如何顺畅的使用 mq，可以说是一个必备的职业技能点了 接下来我们进入 rabbitmq 的学习过程 <!-- more --> I. 环境准备 在测试之前，需要安装 rabbitmq，下面分别给出 mac + centos 的安装教程 1. mac 安装 安装命令 brew install rabbitmq ## 进入安装目录 cd /usr/local/Cellar/rabbitmq/3.7.5 # 启动 brew services start rabbitmq # 当前窗口启动 rabbitmq-server 启动控制台之前需要先开启插件 ./rabbitmq-plugins enable rabbitmq_management 进入控制台: http://localhost:15672/ 用户名和密码：guest,guest 2. centos 安装 安装命令 yum install erlang wget http://www.rabbitmq.com/releases/rabbitmq-server/v3.6.15/rabbitmq-server-3.6.15-1.el6.noarch.rpm yum install

文章纲要 此次分享的缘由 目前分布式事务问题是怎么解决的 行业中有什么解决方案 这些解决方案分别有什么优缺点 别人是怎么做的 我们可以怎么来做 此次分享的缘由 支付重构 考虑支付重构的时候，自然想到原本属于一个本地事务中的处理，现在要跨应用了要怎么处理。拿充值订单举个栗子吧，假设：原本订单模块和账户模块是放在一起的，现在需要做服务拆分，拆分成订单服务，账户服务。原本收到充值回调后，可以将修改订单状态和增加金币放在一个mysql事务中完成的，但是呢，因为服务拆分了，就面临着需要协调2个服务才能完成这个事务 所以就带出来，我们今天要分享和讨论的话题是： 怎么解决分布式场景下数据一致性问题，暂且用分布式事务来定义吧。 同样的问题还存在于其他的场景： 送礼： 调用支付服务：先扣送礼用户的金币，然后给主播加相应的荔枝，确认第一步成功后，播放特效，发聊天室送礼评论等复制代码 充值成功消息： 完成充值订单，发送订单完成的kafka消息，在涉及支付交易等付费接口的时候，数据一致性的问题就显得尤为重要，因为都是钱啊 目前分布式事务是怎么解决的呢？ 问题肯定不是新问题，也就是目前已经有相应的解决方案了，那就看一下现在是怎么来解决这类问题的吧。 以购买基础商品成功后发送支付订单完成消息为例：假设支付下单购买基础商品，此刻已经收到支付回调，订单已经处理成功了，这个时候kafka服务故障，消息发送失败

面试官心理分析 只要聊到你做了分布式系统，必问分布式事务，你对分布式事务一无所知的话，确实会很坑，你起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配了。因为你做系统肯定要用事务吧，如果是分布式系统，肯定要用分布式事务吧。先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如 TCC 方案的网络问题、XA 方案的一致性问题。 面试题剖析 分布式事务的实现主要有以下 5 种方案： XA 方案 TCC 方案 本地消息表 可靠消息最终一致性方案 最大努力通知方案 两阶段提交方案/XA方案 所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。 这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 Spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。 这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下，

消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息中间件到底该如何使用，何时使用这是一个问题，胡乱地使用消息中间件增加了系统的复杂度，如果用不好消息中间件还不如不用。 消息队列通讯模式 点对点通讯 点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。 多点广播 MQ适用于不同类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即能够将消息发送到多个目标站点(DestinationList)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。 发布/订阅(Publish/Subscribe)模式 发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发

RabbitMQ 解决方案 1、生产者将消息传输给mq时丢失 A：可以使用 RabbitMQ 提供的事务功能； 生产者 发送数据之前 开启 RabbitMQ 事务 channel.txSelect ，再发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务 channel.txRollback ，然后重试发送消息；如果收到了消息，那么可以提交事务 channel.txCommit 。 // 开启事务 channel.txSelect try { // 这里发送消息 } catch (Exception e) { channel.txRollback // 这里再次重发这条消息 } // 提交事务 channel.txCommit 这样会降低吞吐量，降低性能。 B： 开启 confirm 模式； 生产者开启 confirm 模式之后，每次写的消息都会分配一个唯一的 id，如果写入了 RabbitMQ 中，RabbitMQ 会回传一个 ack 消息，表示这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调生产者 nack 接口表示消息接收失败，生产者可以重试。而且生产者可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么可以重发。 事务机制和 cnofirm