mq

原文链接： https://zhuanlan.zhihu.com/p/55712984 01 概述 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。 实现高性能，高可用，可伸缩和最终一致性架构。 使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。 02 消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景 2.1 异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式 （1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端 （2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能

1. MQ是什么 2. MQ能做什么 3. 消息模式 4. 使用MQ的时候需要注意什么 5. 常用MQ 6. MQ的不足 7. 什么时候不适用MQ 8. MQ的组成 9. MQ的关注点 1. MQ是什么 MQ 是message queue ,消息队列，也叫消息中间件、消息总线，是一种跨进程的通信机制，用于上下游传递消息。遵守JMS（java message service）规范的一种软件。数据库因为历史原因，横向扩展是一件非常复杂的工程，所有我们一般会尽量把流量都挡在数据库之前。不管是无限的横向扩展服务器，还是纵向阻隔到达数据库的流量，都是这个思路。阻隔直达数据库的流量，缓存组件和消息组件是两大杀器。 2. MQ能做什么 1）数据驱动的任务依赖： 例如：task2在task1执行完成后才能执行，存在依赖关系 2） 解耦： 上游不关心执行结果 例如：注册成功后发邮件 3） 上游关注执行结果，但执行时间很长 例如：微信支付成功的回调 4）限流（削峰） 5）通知 6）数据分发 a. 注册后我们可能需要做很多初始化的操作，如：调用邮件服务器发送邮件、调用促销服务赠送优惠劵、下发用户数据到客户关系系统等。 那么这时候我们将这些操作去监听MQ，当用户注册成功过后，通过MQ通知其他业务进行操作。确保注册用户的性能。 b. 后台发布商品的时候，商品数据需要从数据库中转换成搜索引擎数据

消息队列activemq 首先，我们为什么需要消息队列？ 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ之后带给了你很多的好处！ 先说一下消息队列的常见使用场景吧，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰 1.解耦：现场画个图来说明一下 A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。 面试技巧 ：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ作解耦。 2.异步：现场画个图来说明一下， A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库

1、MQ的应用场景 　　优点： 　　　　a） 主要解决异步消息 　　　　b） 应用解耦 　　　　c） 流量消峰等问题 　　　　d） 日志处理（kafka） 　　缺点： 　　　　a） 系统可用性降低 :你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那 消息队列挂了 ，你的 系统不是呵呵了 。因此，系统可用性降低 　　　　b） 系统复杂性增加 :要多考虑很多方面的问题，比如一致性问题、如何保证消息不被 重复消费 ，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。 　　　　　　1、为什么会造成重复消费? 　　　　　　　　因为 网络传输等等故障 ，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。 　　　　　　2、解决重复消费的方案： 　　　　　　　　(1)比如，你拿到这个消息 做数据库的insert操作 。那就容易了，给这个消息 做一个唯一主键 ，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。   　　　　　　(2)再比如，你拿到这个消息 做redis的set的操作 ，那就容易了，不用解决， 因为你无论set几次结果都是一样的 ，set操作本来就算幂等操作。   　　　　　　(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Fixing the World How to explain ZeroMQ? Some of us start by saying all the wonderful things it does. It's sockets on steroids. It's like mailboxes with routing. It's fast! Others try to share their moment of enlightenment, that zap-pow-kaboom satori paradigm-shift moment when it all became obvious. Things just become simpler. Complexity goes away. It opens the mind. Others try to explain by comparison. It's smaller, simpler, but still looks familiar. Personally, I like to remember why we made ZeroMQ at all, because that's most likely where you, the reader,

1：为什么使用MQ? 主要是：解耦、异步、削峰。 （1）解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦。 （2）异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中

0.学习内容 了解常见的MQ产品 了解RabbitMQ的5种消息模型 会使用Spring AMQP 1.RabbitMQ 1.1.搜索与商品服务的问题 如果项目里使用了redis或者ES等索引库，我们在后台修改了关系型数据库(mysql、oracle等数据库)的数据，但是redis里与ES里都是旧数据，这显然不对。该如何解决？ 这里有两种解决方案： 方案1：每当后台对关系型数据库做增删改操作，同时要修改索引库数据及静态页面 方案2：搜索服务ES和前端页面服务对外提供操作接口，后台在增删改后，调用接口 以上两种方式都有同一个严重问题：就是代码耦合，后台服务中需要嵌入搜索和商品页面服务，违背了微服务的 独立 原则。 所以，我们会通过另外一种方式来解决这个问题：消息队列 1.2.消息队列（MQ） 1.2.1.什么是消息队列 消息队列，即MQ，Message Queue。 消息队列是典型的：生产者、消费者模型。生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入，这样就实现了生产者和消费者的 解耦 。 结合前面所说的问题： 对数据库增删改以后，无需去操作索引库或静态页面，只是发送一条消息，也不关心消息被谁接收。 搜索服务和静态页面服务接收消息，分别去处理索引库和静态页面。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1.去IBM官网下载MQ安装压缩包 www.ibm.com 2.将压缩包上传至指定目录，比如： /home/hqh/MQ7 [root@localhost 桌面]# mkdir -p /home/hqh/MQ7 [root@localho桌面]# mv MQ_7.5.0.2_TRIAL_LNX_ON_X86_64_ML.tar.gz /home/hqh/MQ7 [root@localhost桌面]# cd /home/hqh/MQ7 [root@localhost MQ7]# ls MQ_7.5.0.2_TRIAL_LNX_ON_X86_64_ML.tar.gz 3.解压 [root@localhost MQ7]# tar xf MQ_7.5.0.2_TRIAL_LNX_ON_X86_64_ML.tar.gz [root@localhost MQ7]# ls 4.同意 license ： [root@localhost MQ7]# ./mqlicense.sh -text_only 5.安装 [root@localhost MQ7]# yum -y install /home/hqh/MQ7/MQSeries*.rpm 6.检查 安装完毕。看看 /opt 和 /var 目录下面都多了个 mqm 目录。

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。 ACID 指数据库事务正确执行的四个基本要素： 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） CAP CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性 ：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 可用性 ：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 分区容忍性 ：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 BASE理论 BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是： 我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。 Basically Available（基本可用） Soft state（软状态） Eventually consistent（最终一致性）