RabbitMQ

事件总线知多少（1） Implementing an event bus with RabbitMQ for the development or test environment Abp EventBus 来源： oschina 链接： https://my.oschina.net/u/4407543/blog/4279398

消费端的两种处理机制: 两种机制的区别, 第一种是在消费端出现异常, 系统执行的, 如果多次重试失败, 则可以抛出指定异常拒绝该消息(等同与reject)或者将消息发送到指定队列; 第二种ack机制必须要内部catch住消费者的异常, 手动的进行ack或者nack给rabbitmq , 然后rabbitmq根据配置重新发送消息或者直接舍弃该消息 1. spring.rabbitmq.listener.retry配置的重发是在消费端应用内处理的，不是rabbitqq重发. 因为retry是消费端内部处理的，包括异常也是内部处理，对于rabbitmq是不知道的 2.消息ack a. 返回ack则表明消息被处理, rabbitmq删除消息, b. nack或者reject并且requeue=true则rabbitmq重新发送该消息,requeue=false则讲消息丢弃或放入私信队列 nack和reject区别, 前者可以批量拒绝 消息, reject只能单条消息拒绝 c. 如果rabbitmq发出的消息一直得不到服务端的相应, 则在 rabbitmq断开，连接后会自动重新推送（不管是网络问题还是宕机） 消费端应用重启，消息会自动重新推送 关于retry spring.rabbitmq.listener.simple. retry .max-attempts= 5 最大重试次数

消息队列 所谓的"消息队列"就是：在消息的传输过程中保存消息的容器。上次有朋友面试，面试官就问，redis可以用作消息队列吗？当时一懵。每当想到消息队列：我们都会想到 RabbitMQ ， ActiveMQ ，RocketMQ，等等一些专业的消息中间件。但是如果我们做的事情比较简单业务逻辑不是很复杂，只需要有一个消息队列，使用专业的消息中间件是非常麻烦的，因此我们可以使用Redis做消息队列。 如果对消息的可靠性没有较高的要求的话，那么就可以使用Redis去实现。 Redis做消息队列，可以使用List这个数据类型。List里面有两个命令， lpush/rpush 操作来实现 入队 ，然后使用 lpop/rpop 实现 出列 。 在客户端中，我们会 维护一个死循环来不停的从队列中pop读取数据 ，如果队列中有消息，则直接读取，如果没有，就会陷入死循环，直到下一次有消息进入。这种死循环会造成大量的资源浪费，这个时候我们可以使用， blpop/brpop 去处理，相当于lpop的阻塞，当没有消息到来的时候就会休眠，直到消息来临，才唤醒，pop去读取数据。 在java中可以使用while循环去实现 。 延迟消息队列 延迟消息队列，可以用zset实现，里面有 score 分数浮动数值，数据 可以根据 core 排序，zset可用于高效的检索，我们可以将时间作为score

相较传统中间件，云原生中间件更能为企业解决SLA 保障难、运维难、成本高等一系列问题。然而， 中间件技术栈复杂 ， 对专业程度要求高 ， 如果 缺少生产环境的大规模实践 ， 往往难以落地 。 作为云原生中间件的长期实践者， 轻舟中间件 经过可靠性、可扩展性、性能及稳定性测试，已历经网易严选、网易云音乐、网易传媒等 众多大规模 、 高性能业务的 生产环境实战验证。 电商：高 SLA 保障业务连续性 网易严选采用 轻舟中间件 Kafka、RocketMQ ，实现容器化分布式消息中间件，支持从环境搭建、软件安装、服务管理/配置、应用部署/配置/升级，以及监控、告警、故障恢复等端到端的自动化，为 SLA 提供了更可靠的保障。 另外，网易严选也引入了轻舟中间件 RDS MySQL，为其提供 MySQL 组复制（MGR）集群的多数据中心高可用、自动的故障检测修复以及全方位的告警监控，最大限度保障服务可用性。 音乐：节约资源成本30%以上 网易云音乐引入 轻舟中间件 Redis，以容器技术为核心，避免虚拟化开销，通过精细化编排，实现高效率、高密度混合部署、租户隔离，提高资源利用率，节约资源成本 30% 以上。并且针对极致性能场景，从计算、网络到服务层进行了全方位的优化。 传媒：轻松运维，业务不间断 网易传媒借助 轻舟中间件 Kafka、Elasticsearch

消息手动确认模式的几点说明 监听的方法内部必须使用channel进行消息确认，包括消费成功或消费失败 如果不手动确认，也不抛出异常，消息不会自动重新推送（包括其他消费者），因为对于rabbitmq来说始终没有接收到消息消费是否成功的确认，并且Channel是在消费端有缓存的，没有断开连接 如果rabbitmq断开，连接后会自动重新推送（不管是网络问题还是宕机） 如果消费端应用重启，消息会自动重新推送 如果消费端处理消息的时候宕机，消息会自动推给其他的消费者 如果监听消息的方法抛出异常，消息会按照listener.retry的配置进行重发，但是重发次数完了之后还抛出异常的话，消息不会重发（也不会重发到其他消费者），只有应用重启后会重新推送。因为retry是消费端内部处理的，包括异常也是内部处理，对于rabbitmq是不知道的（此场景解决方案后面有） spring.rabbitmq.listener.retry配置的重发是在消费端应用内处理的，不是rabbitqq重发 可以配置MessageRecoverer对异常消息进行处理，此处理会在listener.retry次数尝试完并还是抛出异常的情况下才会调用，默认有两个实现： RepublishMessageRecoverer：将消息重新发送到指定队列，需手动配置，如： @Bean public MessageRecoverer

　　MessageQueue，顾名思义消息队列，在系统开发中也是用的比较多的一个中间件吧。我们这里主要用它来做日志管理和订单管理的，记得老老大（恩，是的，就是老老大，因为他已经跳槽了）还在的时候，当时也是为了赶项目进度，他也参与开发了，那时候我才刚刚入职，他负责写后端这块，我来了就把他手上的任务接过来了，（接着接着……就辞职了）。 之后我们的开发仍然有条不紊的开发着，直到今年的一月份吧，才上线开始运行，然后就出现了常规状态，上线之后就开始爆炸， 这个页面打不开呀，那个内容没东西呀，第三方登录问题呀，支付问题呀，临时再改需求呀……（该来的都来了），加班、debug、测试、再debug……，然后经过几天的修复，终于完成了跟自己电脑一样稳定的运行，组员们都美滋滋的，今晚加个鸡腿才行。 都说祸不单行，古人是不会骗我们的，Bug怎么会修得完呢？天真，要是Bug能修得完还要我们来干啥，好景不长，果然，过了一周之后，组员突然群里叫喳喳， what is it ? 来了，今天的主角登场了，我也要开始加班了。 RabbitMQ 　　这个是今天要说的东西，基础概念什么的不是今天要说的重点，重点是： RabbitMQ 内存 暴 涨 ！ 使得整个服务器濒临瘫痪，远程登录服务器都差点挤不进去的状态，别看截图目前才1.3G，吃个午饭回来，就2.3G了，可怕不可怕？咋回事？ 老板喊你回来加班啦 　　先不管了

@ 目录 背景 JavaMailSender Spring集成邮件发送功能 1. 添加maven依赖 2. 添加Spring邮件配置 3. 创建邮件管理Bean并注入Spring应用上下文 4. 修改业务逻辑，调用邮件发送功能 邮件发送功能测试 Spring集成JavaMailSender实现邮件发送小结 RabbitMQ RabbitMQ的基本概念 RabbitMQ的消息路由走向 Spring集成RabbitMQ实现异步消息处理 1. 添加maven依赖 2. Spring添加RabbitMQ配置 3. 创建RabbitMQ配置类 4. 创建接收消息监听程序 5. 修改业务逻辑，实现发送消息功能 功能测试 Spring集成RabbitMQ实现异步消息处理小结 背景 《Spring的学习与实战》 在上文章中我们已经实现了一个简单的用户邮箱登记的web应用，将数据保存到mysql数据库中，并利用安全框架对web页面进行保护及实现了管理员的注册登录，又通过Spring的配置属性完成了自定义的各种配置。并了解了Spring与应用的集成的基本概念，实现集成REST API服务。 本文将继续深入Spring的集成应用，实现邮件发送及集成消息队列的功能。 JavaMailSender Spring框架提供了一种使用JavaMailSender接口发送电子邮件的简单抽象方法，而Spring

工作中经常用到消息中间件来解决系统间的解耦问题或者高并发消峰问题，但是消息的可靠性如何保证一直是个很大的问题，什么情况下消息就不见了？如何防止消息丢失？下面通过这篇文章，我们就聊聊RabbitMQ 消息可靠性如何解决的？ 本文分三部分说明 RabbitMQ 消息丢失场景有哪些？ 如何避免消息丢失？ 如何设计部署消息中间件保证消息可靠性？ RabbitMQ 消息丢失场景有哪些？ 首先我们看下消息周期投递过程： 我们把该图分三部分，左中右，每部分都会导致消息丢失情况,下面就详细聊聊每个阶段消息是如何丢的： 1.生产者生产消息到RabbitMQ Server 消息丢失场景 1） 外界环境问题导致：发生网络丢包、网络故障等造成RabbitMQ Server端收不到消息，因为生产环境的网络是很复杂的，网络抖动，丢包现象很常见，下面会讲到针对这个问题是如何解决的。 2） 代码层面，配置层面，考虑不全导致消息丢失 事例1: 一般情况下，生产者使用Confirm模式投递消息，如果方案不够严谨，比如RabbitMQ Server 接收消息失败后会发送nack消息通知生产者，生产者监听消息失败或者没做任何事情，消息存在丢失风险； 事例2: 生产者发送消息到exchange后，发送的路由和queue没有绑定，消息会存在丢失情况，下面会讲到具体的例子，保证意外情况的发生，即使发生，也在可控范围内。 2

给RABBITMQ发送消息时，设置请求头HEADER。 消费者的请求头 生产者设置请求头 消费者的请求头 生产者设置请求头 由于消费者那里， @Payload 是接受的消息体，使用了 @Header 注解，需要请求头， 生产者 这边就要设置请求头，然后rabbitTemplate再调用convertAndSend方法发送，如下代码： 这是RabbitTemplate中的 converAndSend（exchang,routingKey,消息体,消息头） 方法。 @Override public void convertAndSend(String exchange , String routingKey , final Object message, final MessagePostProcessor messagePostProcessor) throws AmqpException { convertAndSend(exchange, routingKey, message, messagePostProcessor, null ); } 来源： oschina 链接： https://my.oschina.net/xiaominmin/blog/4488671

这份资源我自己历经三年才整理归类出来，现在免费分享给大家； 面试题有：蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初，中级，高级Java面试题集合。 面试题以及答案，已经整理成PDF电子书形式打包在网盘； 面试题领取微信扫一扫，加好友请备注“博客园面试题”； 目录 上海-携程-Java高级面试题.pdf 北京-百度-Java中级面试题.pdf 深圳-乐信-Java高级面试题.pdf 深圳-腾讯-Java高级面试题.pdf 上海-拼多多-Java高级面试题.pdf 深圳-OPPO-Java高级面试题.pdf 上海-拼多多-Java高级面试题.pdf 北京-京东-Java实习生面试题.pdf 北京-京东-Java实习生面试题.pdf 杭州-阿里云Java实习生面试题.pdf 南京-软通动力-Java初级面试题.pdf 深圳-银盛支付-Java中级面试题.pdf 深圳-中国平安-Java中级面试题.pdf 深圳-蚂蚁金服-Java高级面试题.pdf 深圳-丰巢科技-Java高级面试题.pdf 深圳-商汤科技-Java高级面试题.pdf 厦门-中软国际-Java初级面试题.pdf 杭州-蚂蚁金服-Java高级面试题.pdf 杭州-蚂蚁金服-资深工程师面试题.pdf 广州唯品会-Java大数据开发工程师面试题.pdf 上海-携程