消息中间件

RabbitMq快速搭建及配置（Dock大法） 以前我没得选，现在有了docker我想做个懒人? 刚开始接触消息中间件RabbitMq的同学肯定都被RabbitMq的安装愁坏了，看着视频教程感觉就够麻烦了。 他要对应相应的语言版本进行安装 RabbitMq一般都是安装在Linux系统上跑，你装一个windows版的搞那么熟练也没啥用啊 Linux下安装也挺麻烦的，而且真正在生产环境中，也不需要自己安装啊。 这里给出的理由都是一些偷懒的理由，虽然安装确实可以偷懒，但是博主这里还是得说一下，虽然我们有更好的办法进行配置环境，但是我们也得知道他具体的安装步骤和具体作用哦。这里我们就不说了，百度一大推。 我们来偷个懒。。 Start 找一台Linux机器并且在机器上安装docker http://blog.51cto.com/13438667/2059926 windows安装Linux虚拟机 这里推荐centos https://www.cnblogs.com/owenma/p/6825049.html 安装docker https://baike.baidu.com/item/Xshell/5659054?fr=aladdin Linux连接工具 Xshell docker操作正式开始 因为博主也是虚拟机，所以docker没认真配置，所以需要管理员权限运行

一、什么是MQ？ MQ为Message Queue，即是“消息队列”，它是应用程序和应用程序之间的同新方法。 遵循Message Queue规则开发出来的，具有消息队列特点的产品，都可以称之为“消息中间件”(JMS消息服务器)。 目前业内有很多消息中间件产品，例如Apache出品的“ActiveMQ”和“Kafka”(分布式发布订阅消息系统)、Rabbit团队的“RabbitMQ”，以及Metamorphosis、DoNetMQ、beanstalkd等等其它消息队列中间件。 二、什么是RabbitMQ？ RabbitMQ是Rabbit团队开发的一个开源的消息队列组件，在AMQP基础上完成的，可以复用的企业消息系统。 RabbitMQ是负责消息的生产和消费，我们可以理解为，RabbitMQ是一个仓库的中转站，所有的程序消息都发送给RabbitMQ，然后由RabbitMQ来负责把这些消息来运输给消费者。 在计算机领域中，有很多协议，例如HTTP协议、TCP协议、SOAP协议、SVN协议等等。而AMQP是RabbitMQ的基础，其英文全称为“Advanced Message Queuing Protocol”，它是一个提供统一消息服务的应用层标准高级消息队列协议。 说白了AMQP就是消息队列的一个协议。 RabbitMQ是使用Erlang语言开发的

RabbitMQ的基本安装 一 docker下安装RabbitMQ 首先使用 docker search rabbitmq命令查找docker仓库是否存在rabbitmq镜像，可以发现docker仓库是存在rabbitmq的 1 [root@admin ~]# docker search rabbitmq 2 NAME DESCRIPTION STARS OFFICIAL AUTOMATED 3 rabbitmq RabbitMQ is an open source multi-protocol me… 2809 [OK] 4 bitnami/rabbitmq Bitnami Docker Image for RabbitMQ 35 [OK] 5 tutum/rabbitmq Base docker image to run a RabbitMQ server 20 6 kbudde/rabbitmq-exporter rabbitmq_exporter for prometheus 12 [OK] 7 frodenas/rabbitmq A Docker Image for RabbitMQ 12 [OK] 8 cyrilix/rabbitmq-mqtt RabbitMQ MQTT Adapter 7 [OK] 9 arm32v7/rabbitmq RabbitMQ is an

中间件 1.概述 应用场景 单体架构 如果一个模块升级，比如订单系统，整个系统都要升级 耦合度高，开发困难 分布式架构 后台由多个系统组成 多系统协同处理一个请求可以看成分布式系统 系统之间相互调用 ，用RPC远程调用的方式实现 但这样系统之间耦合度相对较高 为了解决耦合，实现更强的扩展性架构，分布式系统中引入了消息中间件 基于消息中间件的分布式系统架构 消息中间件 利用高效可靠的消息传递机制进行平台无关的数据交流 并基于数据通信来进行分布式系统的集成 通过提供消息传递和消息排队模型，可以在分布式环境下扩展进程间的通信 消息中间件的应用场景 跨系统数据传递、高并发流量削峰、数据异步处理...等等 常用的消息中间件 ActiveMQ、RabbitMQ、Kafka、RocketMQ 核心设计 本质： 一种具备 接收请求、保存数据、发送数据 等功能的 网络应用 。 和一般网络应用程序的区别是它主要负责数据的接收和传递，所以性能一般都高于普通程序。 5大核心组成： 协议 持久化机制 消息分发机制 高可用设计 高可靠设计 2.协议 协议是计算机之间通信时共同遵从的一组约定，都遵守相同的约定，计算机之间才能相互交流。 是对数据格式和计算机之间交换数据时必须遵守的规则的正式描述。 协议三要素： 语法：即数据与控制信息的结构或格式。 语义：即需要发出何种控制信息，完成何种动作以及做出何种响应。

什么是消息中间件？ 消息中间件(MQ)的定义 其实并没有标准定义。一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成。 高效： 对于消息的处理处理速度快。 可靠： 一般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。 异步： 指发送完一个请求，不需要等待返回，随时可以再发送下一个请求，既不需要等待。 一句话总结，我们消息中间件不生产消息，只是消息的搬运工。 为什么要用消息中间件？ 假设一个电商交易的场景，用户下单之后调用库存系统减库存，然后需要调用物流系统进行发货，如果交易、库存、物流是属于一个系统的，那么就是接口调用。但是随着系统的发展，各个模块越来越庞大、业务逻辑越来越复杂，必然是要做服务化和业务拆分的。这个时候就需要考虑这些系统之间如何交互，一般的处理方式就是 RPC（Remote Procedure Call）（具体实现 dubbo,SpringCloud）。系统继续发展，可能一笔交易后续需要调用几十个接口来执行业务，比如还有风控系统、短信服务等等。这个时候就需要消息中间件登场来解决问题了。 所以消息中间件主要解决分布式系统之间消息的传递，同时为分布式系统中其他子系统提供了松耦合的架构，同时还有以下好处： 　　低耦合 　　低耦合，不管是程序还是模块之间

消息中间件随着分布式系统的发展变得越来越火，下面就学习课程过程对消息中间件进行解释 概念 ：（部分内容引用自：享学课堂课件） 　　其实并没有标准定义。一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布 式系统中的其余各个子系统进行集成。 　　 高效 ：对于消息的处理处理速度快。 　　 可靠 ：一般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。 　　 异步 ：指发送完一个请求，不需要等待返回，随时可以再发送下一个请求，既不需要等待。 　　一句话总结，我们消息中间件不生产消息，只是消息的搬运工 为什么要用消息中间件？ 　　最初系统设计都是一个整体，业务相对简单，一个war 就可以部署使用，不涉及系统之间通信问题， 　　但是随着计算机技术的发展， 系统数据量越来越大，业务越来越复杂，一个系统就变得越来越臃肿，难以维护，所以出现了分布式概念，将一个大系统根据业务模块 　　拆分成多个子系统，每个子系统分别负责不同的业务职能，这时就出现了系统与系统之间的数据频繁交互情况，RPC 就是用来做系统间数据交互，但是由于系统之间直接数据交互依赖性太强，一个子系统出现问题， 　　它对应的数据交互就会出现问题进而整个系统的出现问题，而且随着系统的不断拓展，子系统越来越多，不同系统之间数据进行交互，越来越混乱，难以管理和维护 　

1：分布式事物的理解： 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，分布式事务需要保证这些小操作要么全部成功，要么全部失败;本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2：分布式失误产生的原因： a）数据库分库分表; 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 b)应用SOA化； 就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心等,对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息,如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了。 3）分布式的使用场景： 支付：一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败，并且卖家账户对应卖家数据库

就MQ而言， MQ长期不看不用或者习惯套用很容易让人淡忘他的原理和基础，所以我在此开一篇写关于消息中间件的原理与案例帮助自己巩固基础。 注：对于MQ的文章，我会将原理和代码案例放进github中，案例搭建我会放进博客中 。 入口：点击进入 来源： https://www.cnblogs.com/kongliuyi/p/11512576.html

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。 主流消息中间件比较： 对比之总结如下： 一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高； 现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择； 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄

什么是WAL？ https://www.cnblogs.com/hzmark/p/wal.html 原来数据库与消息中间件 用的是相同的模式 都是基于 顺序写的性能优于 离散写 series 强于scatter 在写完上一篇《Pull or Push》之后，原本计划这一片写《存储层设计》，但是临时改变主意了，想先写一篇介绍一下消息中间件最最基础也是最核心的部分：write-ahead logging(WAL)。 什么是WAL "In computer science, write-ahead logging (WAL) is a family of techniques for providing atomicity and durability (two of the ACID properties) in database systems."——维基百科 在计算机领域，WAL（Write-ahead logging，预写式日志）是数据库系统提供原子性和持久化的一系列技术。 在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中。通常包含redo和undo两部分信息。 为什么需要使用WAL，然后包含redo和undo信息呢？举个例子，如果一个系统直接将变更应用到系统状态中，那么在机器掉电重启之后系统需要知道操作是成功了，还是只有部分成功或者是失败了