RabbitMQ

1、场景：上千万条消息在mq里积压了几个小时了还没解决 2、解决： 1 ）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉 2 ）新建一个topic，partition是原来的 10 倍，临时建立好原先 10 倍或者 20 倍的 queue 数量 3 ）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据， 消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue 4 ）接着临时征用 10 倍的机器来部署consumer，每一批consumer消费一个临时 queue 的数据 5 ）这种做法相当于是临时将 queue 资源和consumer资源扩大 10 倍，以正常的 10 倍速度来消费数据 6 ）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息 3、场景：rabbitmq设置过期时间的，就是TTL 说明： 如果消息在 queue 中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。 那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢 4、解决： 丢了大量的消息。我们可以采取一个方案，就是批量重导，这个时候我们就开始写程序， 将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去

前言 市面上消息队列中间件管理有蛮多的，如：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ，但我最先接触的可能就是 Kafka 了，不过那时候为了用，只知道部分实用性的东西，这两天稍稍花了点时间看了看。 消息队列 在我看来，消息队列的出现更多的是 解耦合 ，我们不需关心数据的来处和出处，生产者和消费者可能都不知道对方是一种什么样的存在方式，而且解决了突发的 数据剧增现象 . 我在例子中曾这样实验过 线程跑一会睡眠 20ms 线程一直在跑 实验 1 的处理速度可以跟的上生产速度，offset 一直指向 end，但实验 2 生产速度大幅上升，处理速度明显跟不上，我停止生产后，几毫秒再去看，offset 才指向 end。 例子 通过例子了解的可能会更加的快，这里我使用 docker-compose 搭建的 kafka 集群 SpringBoot 和 kafka 生产者 https://github.com/tokeneros/kafka_produce... SpringBoot 和 kafka 消费者 https://github.com/tokeneros/kafka_consumt... 最后注意 ：光理论是不够的。在此顺便送大家十套2020最新JAVA架构项目实战教程及大厂面试题库，进我扣裙 ：七吧伞吧零而衣零伞 （数字的谐音

0. 访问 hub.docker.com 主要是获得安装软件的信息及文档 #选择management版本 1. docker search 软件名称 docker search rabbitmq 2. docker pull 软件名:版本号 docker pull rabbitmq:3-management 3. docker run 主要是通过hub.docker.com提供的文档设置 docker run --name rabbitmq0 -p 5672:5672 -p 15672:15672 rabbitmq:3-management 4.docker ps -a # 查看docker的运行状态 docker ps -a 5.通过第三方软件连接软件 #通过浏览器访问管理平台 http://服务器IP地址:15672 guest:guest 来源： oschina 链接： https://my.oschina.net/u/2255699/blog/4303899

1 面试题 分布式事务了解吗？你们如何解决分布式事务问题的？ 2 考点分析 只要聊到做了分布式系统，必问分布式事务，若你对分布式事务一无所知的话，确实很坑，起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配. 你做系统肯定要用事务，那你用事务的话，分布式系统之后肯定要用分布式事务. 先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？ 比如TCC方案的网络问题、XA方案的一致性问题. 单块系统里的事务 分布式系统里的事务 3 XA方案也叫做两阶段提交事务方案. 举个例子，比如公司经常团建，然后一般会有个主席（就是负责组织团建的那个人）。 tb，team building，团建 第一个阶段，一般tb主席会提前问团队里的每个人，说，大家伙，下周六我们去滑雪+烧烤，去吗？ 这个时候tb主席开始等待每个人的回答，如果所有人都说ok，那么就可以决定一起去这次tb 如果这个阶段里，任何一个人回答说，我有事不去了，那么tb主席就会取消这次活动 第二个阶段，那下周六大家就一起去滑雪+烧烤了 这就是所谓的XA事务，两阶段提交. 有一个事务管理器，负责协调多个数据库（资源管理器）的事务，事务管理器先问各个数据库你准备好了吗？ 如果每个数据库都回复ok，那么就正式提交事务，在各个数据库上执行操作

　　一. RabbitMQ 简介 　　MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。 排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 　　RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、 安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。 　　二. RabbitMQ 使用场景 1. 解耦（为面向服务的架构（SOA）提供基本的最终一致性实现） 　　场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。 　　 　　传统模式的缺点： 　　假如库存系统无法访问，则订单减库存将失败，从而导致订单失败 　　订单系统与库存系统耦合 　　引入消息队列 　　 　　订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功 　　库存系统：订阅下单的消息，采用拉/推的方式

​ 如果想看更多技术好书，可以关注微信公众号【程序员书单】作者黄小斜，目前是阿里Java工程师，业余时间广泛读书，在公众号里除了分享程序员必读的技术书籍之外，也会推荐很多关于个人成长、投资理财等方面的书籍。你烦恼的每个问题，书中都有答案。 在这里，我们将为你推荐帮助程序员以及互联网从业者自我提升的各类好书、优质学习资源和工具，每周pick精品书单，解读经典书籍。 Java工程师往往容易忽视的一块知识点，其实就是Java网络编程，为什么呢，因为如果我想写一个Java Web项目，我只要用SSM就可以轻松搞定，写好我们的controller、service和dao就可以了，也就是只需要关心业务逻辑，不需要关心前端请求的路由、甚至是后端的负载均衡和网络请求处理，因为这些东西很多时候都被Nginx和Tomcat给吃掉了，Nginx帮我们做好了负载均衡，Tomcat则帮我们完成TCP连接的建立，HTTP请求的处理，把所有复杂的技术细节都给屏蔽了。 不过随着技术发展和更迭，大公司对于人才的要求也越来越高，对于高并发服务端编程能力的要求也在提高，比如在直播、实时通讯、游戏服务端开发等技术领域，通信协议和网络编程就成为了很重要的一个技术课题，相应的在Java领域，我们就必须要了解NIO、Linux epoll以及Netty等和网络通信相关的技术。如果你想做基础技术研发，比如消息队列

首先介绍一下rabbitmq三种模式 Direct–路由模式 任何发送到Direct Exchange的消息都会被转发到RouteKey指定的Queue。 这种模式下不需要将Exchange进行任何绑定(binding)操作。 消息传递时需要一个“RouteKey”，可以简单的理解为要发送到的队列名字。 如果vhost中不存在RouteKey中指定的队列名，则该消息会被抛弃。 Fanout–发布/订阅模式 任何发送到Fanout Exchange的消息都会被转发到与该Exchange绑定(Binding)的所有Queue上。 这种模式不需要RouteKey。 这种模式需要提前将Exchange与Queue进行绑定，一个Exchange可以绑定多个Queue，一个Queue可以同多个Exchange进行绑定。 如果接受到消息的Exchange没有与任何Queue绑定，则消息会被抛弃。 Topic–匹配订阅模式 任何发送到Topic Exchange的消息都会被转发到所有关心RouteKey中指定话题的Queue上。 就是每个队列都有其关心的主题，所有的消息都带有一个“标题”(RouteKey)，Exchange会将消息转发到所有关注主题能与RouteKey模糊匹配的队列。 这种模式需要RouteKey，也许要提前绑定Exchange与Queue。 在进行绑定时