消息队列

原文: .NET Core使用RabbitMQ RabbitMQ简介 　RabbitMQ是一个开源的,基于AMQP(Advanced Message Queuing Protocol)协议的完整的可复用的企业级消息队,RabbitMQ可以实现点对点,发布订阅等消息处理模式。 RabbitMQ是一个开源的AMQP实现,服务器端用Erlang语言编写，支持Linux,windows,macOS,FreeBSD等操作系统,同时也支持很多语言,如：Python,Java,Ruby,PHP,C#,JavaScript,Go,Elixir,Objective-C,Swift等。 RabbitMQ安装 我使用的环境是ubuntu18.04, RabbitMq需要Erlang语言的支持，在安装RabbitMq之前需要安装Erlang sudo apt-get install erlang-nox 更新源 sudo apt-get update 安装RabbitMq sudo apt-get install rabbitmq-server 添加users用户，密码设置为admin sudo rabbitmqctl add_user users admin 给添加的用户赋予权限 sudo rabbitmqctl set_user_tags users administrator 赋予virtual

什么是消息队列 把服务器比喻成一个人 当这个人的亲人，朋友，工作（一大批客户端）【生产者】同时有事情（网络请求）找他， 这个人承受不了了 就容易崩溃 那现在可以把消息队列比喻成一个管道 这个管道让消息按照 队列 数据结构（先进先出） 然后这个人再把这些消息传给可以解决的人【消费者】 消息队列的优势 应用解耦 消息队列可以使消费者和生产者直接互不干涉，互不影响，只需要把消息发送到队列即可，而且可独立的扩展或修改两边的处理过程，只要能确保它们遵守同样的接口约定，可以生产者用Node.js实现，消费者用python实现。 灵活性和峰值处理能力 当客户端访问量突然剧增，对服务器的访问已经超过服务所能处理的最大峰值，甚至导致服务器超时负载崩溃，使用消息队列可以解决这个问题，可以通过 控制消费者的处理速度 和 生产者可进入消息队列的数量 等来避免峰值问题 排序保证 消息队列可以控制数据处理的顺序，因为消息队列本身使用的是队列这个数据结构， FIFO (先进选出)，在一些场景数据处理的顺序很重要，比如商品下单顺序等。 异步通信 消息队列中的有些消息，并不需要立即处理，消息队列提供了异步处理机制，可以把消息放在队列中并不立即处理，需要的时候处理，或者异步慢慢处理，一些不重要的发送短信和邮箱功能可以使用。 可扩展性 前面提到了消息队列可以做到 解耦 ，如果我们想增强消息入队和出队的处理频率，很简单

Topic 主题，从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合。比如一个名称为trade.order.queue的Topic里面存的都是订单相关的消息。 Partition 分区。分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息。分区可能不应该出现在消息领域内，在使用消息中间件发送和消费时，实际上用户是感受不到分区这个概念的。下面这幅图便于大家去理解分区： 一个Topic存储消息时会分为多个Partition，每个Partition内消息是有顺序的。至于为什么需要将Topic划分成按照Partition存储，在以后设计和实现部分会解释。 Producer 生产者，消息的生产方，一般由业务系统负责产生消息。 Producer负责决定将消息发送到哪个Topic的那个Partition。 Consumer 消费者，消息的消费方，一般是后台系统负责异步消费消息。 Consumer订阅Topic，消费Topic内部的消息。 Broker 消息的存储者，一般也称为Server，在JMS中叫Provider，在RocketMQ（阿里开源的消息中间件）中叫Broker。 NameServer NameServer其实不是消息中间件的概念了

1.概述 本篇文章会尽力全面的介绍RocketMQ和Kafka各个关键点的比较，希望大家读完能有所收获。 RocketMQ前身叫做MetaQ, 在MeataQ发布3.0版本的时候改名为RocketMQ，其本质上的设计思路和Kafka类似，但是和Kafka不同的是其使用Java进行开发，由于在国内的Java受众群体远远多于Scala，所以RocketMQ是很多以Java语言为主的公司的首选。同样的RocketMQ和Kafka都是Apache基金会中的顶级项目，他们社区的活跃度都非常高，项目更新迭代也非常快。 2.入门实例 2.1 生产者 public class Producer { public static void main(String[] args) throws MQClientException, InterruptedException { DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName"); producer.start(); for (int i = 0; i < 128; i++) try { { Message msg = new Message("TopicTest", "TagA", "OrderID188", "Hello world".getBytes

这节课我们来学习消息队列中像队列、主题、分区等基础概念。这些基础的概念，就像我们学习一门编程语言中的基础语法一样，你只有搞清楚它们，才能进行后续的学习。 如果你研究过超过一种消息队列产品，你可能已经发现，每种消息队列都有自己的一套消息模型，像队列（Queue）、主题（Topic）或是分区（Partition）这些名词概念，在每个消息队列模型中都会涉及一些，含义还不太一样。 为什么出现这种情况呢？因为没有标准。曾经，也是有一些国际组织尝试制定过消息相关的标准，比如早期的 JMS 和 AMQP。但让人无奈的是，标准的进化跟不上消息队列的演进速度，这些标准实际上已经被废弃了。 那么，到底什么是队列？什么是主题？主题和队列又有什么区别呢？想要彻底理解这些，我们需要从消息队列的演进说起。 主题和队列有什么区别？ 在互联网的架构师圈儿中间，流传着这样一句不知道出处的名言，我非常认同和喜欢：好的架构不是设计出来的，而是演进出来的。 现代的消息队列呈现出的模式，一样是经过之前的十几年逐步演进而来的。 最初的消息队列，就是一个严格意义上的队列。在计算机领域，“队列（Queue）”是一种数据结构，有完整而严格的定义。在维基百科中，队列的定义是这样的： 队列是先进先出（FIFO, First-In-First-Out）的线性表（Linear List）。在具体应用中通常用链表或者数组来实现

一说起事务，你可能自然会联想到数据库。的确，我们日常使用事务的场景，绝大部分都是在操作数据库的时候。像 MySQL、Oracle 这些主流的关系型数据库，也都提供了完整的事务实现。那消息队列为什么也需要事务呢？ 其实很多场景下，我们“发消息”这个过程，目的往往是通知另外一个系统或者模块去更新数据，消息队列中的“事务”，主要解决的是消息生产者和消息消费者的数据一致性问题。 依然拿我们熟悉的电商来举个例子。一般来说，用户在电商 APP 上购物时，先把商品加到购物车里，然后几件商品一起下单，最后支付，完成购物流程，就可以愉快地等待收货了。 这个过程中有一个需要用到消息队列的步骤，订单系统创建订单后，发消息给购物车系统，将已下单的商品从购物车中删除。因为从购物车删除已下单商品这个步骤，并不是用户下单支付这个主要流程中必需的步骤，使用消息队列来异步清理购物车是更加合理的设计。 对于订单系统来说，它创建订单的过程中实际上执行了 2 个步骤的操作： 在订单库中插入一条订单数据，创建订单； 发消息给消息队列，消息的内容就是刚刚创建的订单。 购物车系统订阅相应的主题，接收订单创建的消息，然后清理购物车，在购物车中删除订单中的商品。 在分布式系统中，上面提到的这些步骤，任何一个步骤都有可能失败，如果不做任何处理，那就有可能出现订单数据与购物车数据不一致的情况，比如说： 创建了订单，没有清理购物车；

简单介绍： 因为Kafka集群是把状态信息保存在Zookeeper中的，并且Kafka的动态扩容是通过Zookeeper来实现的，所以需要优先搭建Zookeerper集群，建立分布式状态管理。开始准备环境，搭建集群： zookeeper是基于Java环境开发的所以需要先安装Java 然后这里使用的zookeeper安装包版本为zookeeper-3.4.14，Kafka的安装包版本为kafka_2.11-2.2.0。 AMQP协议：Advanced Message Queuing Protocol （高级消息队列协议）是一个标准开放的应用层的消息中间件协议。AMQP定义了通过网络发送的字节流的数据格式。因此兼容性非常好，任何实现AMQP协议的程序都可以和与AMQP协议兼容的其他程序交互，可以很容易做到跨语言，跨平台。 一、首先做好kafka 1、准备三台服务器,推荐每台2个G，记得关闭防火墙 server1：10.0.0.41 server2：10.0.0.42 server3：10.0.0.43 2、三台都得配置jdk环境，1.8以上，修改主机名并且配置主机名 10.0.0.41 hostname kafka01 10.0.0.42 hostname kafka02 10.0.0.43 hostname kafka03 cat /etc/hosts 10.0.0.41

Spring整合RabbitMQ 注意一点，在发送消息的时候对template进行配置mandatory=true保证监听有效 生产端还可以配置其他属性，比如发送重试，超时时间、次数、间隔等 消费端核心配置 a、首先配置手工确认模式，用于ACK的手工处理，这样我们可以保证消息的可靠性送达，或者在消费端消费失败的时候可以做到重回队列、根据业务记录日志等处理 b、可以设置消费端的监听个数和最大个数，用于控制消费端的并发情况 @RabbitListener注解的使用 消费端监听@RabbitListener注解，这个对于在实际工作中非常的好用 @RabbitListener是一个组合注解，里面可以注解配置（@QueueBinding、@Queue、@Exchange）直接通过这个组合注解一次性搞定消费端交换机、队列、绑定、路由、并且配置监听功能等 注：由于类配置写在代码里非常不友好，所以强烈建议大家使用配置文件配置 新建项目 rabbitmq-common、rabbitmq-springcloud-consumer、rabbitmq-springcloud-producer rabbitmq-common 主要就是存放公共代码 这里只有一个实体类 Order package com.wsy.rabbitmqcommon.entity; import java.io

RabbitMQ使用以及原理解析 RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue)的开源实现;在RabbitMQ官网上主要有这样的模块信息, Work queues消息队列,Publish/Subscribe发布订阅服务,Routing, Topics, RPC等主要应用的模块功能. 几个概念说明: Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输, Exchange：消息交换机,它指定消息按什么规则,路由到哪个队列。 Queue:消息的载体,每个消息都会被投到一个或多个队列。 Binding:绑定，它的作用就是把exchange和queue按照路由规则绑定起来. Routing Key:路由关键字,exchange根据这个关键字进行消息投递。 vhost:虚拟主机,一个broker里可以有多个vhost，用作不同用户的权限分离。 Producer:消息生产者,就是投递消息的程序. Consumer:消息消费者,就是接受消息的程序. Channel:消息通道,在客户端的每个连接里,可建立多个channel. RabbitMQ的流程图 AMQP(高级消息队列协议 Advanced Message Queue Protocol)

请说明什么是传统的消息传递方法? 传统的消息传递方法包括两种： ·排队：在队列中，一组用户可以从 服务器 中读取消息，每条消息都发送给其中一个人。 ·发布-订阅：在这个模型中，消息被广播给所有的用户。 为什么要使用 kafka，为什么要使用消息队列 缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。 解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。 冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。 健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。 异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 kafka 为什么那么快 Cache Filesystem Cache PageCache缓存 顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。 Zero-copy