mq

1. PushConsumer 　　推，Broker主动向Consumer推消息，它Consumer的一种，应用通常向对象注册一个Listener接口，一旦接收到消息，Consumer对象立刻回调Linstener接口方法。Push方式里,consumer把轮询过程封装了,并注册MessageListener监听器,取到消息后,唤醒MessageListener的consumeMessage()来消费,对用户而言,感觉消息是被推送过来的。 　　缺点： 　　慢消费无疑是Push模式最大的致命伤,如果消费者的速度比发送者的速度慢很多,势必造成消息在broker的堆积。假设这些消息都是有用的无法丢弃的,消息就要一直在broker端保存。当然这还不是最致命的,最致命的是broker给consumer推送一堆consumer无法处理的消息,consumer不是reject就是error,然后来回踢皮球。所以push适合于没有慢消费情况的场景下 　　前面使用的所有示例中的Consuemr都是采用的push方式，所以这里就不在具体写示例代码了。 2. PullConsumer 　　拉，Consumer主动的从Broker拉取消息，主动权由应用控制，可以实现批量的消费消息。Pull方式里,取消息的过程需要用户自己写,首先通过打算消费的Topic拿到MessageQueue的集合

mq支持表达式过滤和类过滤两种模式，其中表达式又分为TAG和SQL92.类过滤模式允许提交一个过滤类到FilterServer，消息消费者从FilterServer拉取消息，消息经过FilterServer时会执行过滤逻辑。SQL92以消息属性过滤上下文，而TAG模式就是简单为消息定义标签。 public interface MessageFilter { /** * match by tags code or filter bit map which is calculated when message received * and stored in consume queue ext. * * @param tagsCode tagsCode * @param cqExtUnit extend unit of consume queue */ boolean isMatchedByConsumeQueue(final Long tagsCode, final ConsumeQueueExt.CqExtUnit cqExtUnit); //根据ConsumeQueue判断消息是否匹配 /** * match by message content which are stored in commit log. * <br>{@code msgBuffer} and {@code

简介： rabbitMQ是一个在AMQP协议标准基础上完整的，可服用的企业消息系统。它遵循Mozilla Public License开源协议，采用 Erlang 实现的工业级的消息队列(MQ)服务器，Rabbit MQ 是建立在Erlang OTP平台上。 windows安装： Erlang快速下载： https://www.erlang-solutions.com/resources/download.html 国内加速下载 rabbitMQ server： https://www.newbe.pro/Mirrors/Mirrors-RabbitMQ/ 安装完成后添加环境变量，erlang的sbin路径和rabbitmq的bin路径 安装插件：rabbitmq-plugins.bat enable rabbitmq_management 启动rabbitmq：rabbitmq-server.bat 管理后台： http://localhost:15672 ，用户名：guest 密码：guest 来源： https://www.cnblogs.com/aaron-agu/p/12275915.html

接上文的集群模式，监听器返回RECONSUME_LATER，需要将将这些消息发送给Broker延迟消息。如果发送ack消息失败，将延迟5s后提交线程池进行消费。 入口：ConsumeMessageConcurrentlyService#sendMessageBack 命令编码：RequestCode.CONSUMER_SEND_MSG_BACK； MQClientAPIImpl#consumerSendMessageBack： public void consumerSendMessageBack( final String addr, final MessageExt msg, final String consumerGroup, final int delayLevel, final long timeoutMillis, final int maxConsumeRetryTimes ) throws RemotingException, MQBrokerException, InterruptedException { ConsumerSendMsgBackRequestHeader requestHeader = new ConsumerSendMsgBackRequestHeader(); RemotingCommand request =

假如有一个文章审核，通过后加积分的需求，审核是这个方法的主体，而加积分并不需要实时同步，这时，我们就可以将加积分的功能变为异步执行。 Spring实现异步的方法 1.AsyncRestTemplate https://blog.csdn.net/jiangchao858/article/details/86709750 2.@Async注解 https://spring.io/guides/gs/async-method/ 3.WebClient(Spring 5.0引入) https://docs.spring.io/spring/docs/5.1.8.RELEASE/spring-framework-reference/web-reactive.html#webflux-client 4.MQ 引入MQ后，生产者生产消息，然后将消息发送给MQ，消费者监听这个消息所属的topic，一旦接收到消息，就进行相关的处理。 MQ的适用场景 1.异步处理：不解释 2.流量削峰填谷：例如秒杀活动，可以用MQ控制参加人数，人数一旦达到阈值，就丢弃请求或跳转到错误页。防止应用被流量洪峰打死。 3.解耦微服务：假如A调用B，B挂了，虽然有sentinel可以保护A不被B拖死，但是依然无法正常返回，用MQ以后，A把消息发给MQ，就算B挂了也没事，后面B恢复正常会从MQ中拿消息处理，AB也解耦了。

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

常见的企业级MQ 1. RabbitMQ 是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP。 优点： 也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个代理(Broker)构架，这意味着消息在发送到客户端之前可以在中央节点上排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。 缺点： 它的可扩展性差，速度较慢，因为中央节点增加了延迟，消息封装后也比较大。 2. ZeroMQ ZeroMQ是一个非常轻量级的消息系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常可以发现它。 优点：号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列。 缺点： 与RabbitMQ相比，ZeroMQ支持许多高级消息场景，但是你必须实现ZeroMQ框架中的各个块（比如Socket或Device等）。ZeroMQ非常灵活，但是你必须学习它的80页的手册（如果你要写一个分布式系统，一定要阅读它）。 应用：Twitter的Storm中使用ZeroMQ作为数据流的传输。 3. ActiveMQ ActiveMQ居于两者之间，类似于ZemoMQ，它可以部署于代理模式和P2P模式。类似于RabbitMQ，它易于实现高级场景

面试题 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ 面试官心理分析 你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？ 所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于，举个例子，消费端每次消费之后要写 mysql，结果 mysql 挂了，消费端 hang 那儿了，不动了；或者是消费端出了个什么岔子，导致消费速度极其慢。 面试题剖析 关于这个事儿，我们一个一个来梳理吧，先假设一个场景，我们现在消费端出故障了，然后大量消息在 mq 里积压，现在出事故了，慌了。 大量消息在 mq 里积压了几个小时了还没解决 几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。 一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条

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

前两天为了玩touchBar养宠物的小游戏，更新了系统，升级到了MacOs Catalina系统，升级之前mq启动正常，升级之后开始出现各种小问题，mq启动问题是其中之一 MQ启动必须要先运行一下source ~/.bash_profile才可以 重启终端，运行服务器的时候会显示“ERROR: Please set the JAVA_HOME variable in your environment, We need java(x64)!!!” 开始以为JDK坏了，查看JDK发现版本号没问题，也能用。 然后查了好多资料，很多人说在在～/.zshrc文件里加一句 source ~/.bash_profile就行， 但在~目录下没有找到这个文件，全局搜索了一下，在/private/etc下面找到的。 在文件的底部加上了两句话： # Enable my profile source ~/.bash_profile source /etc/profile .zshrc文件就是一个配置环境变量的文件 日志文件不存在 Cannot open file /dev/shm/mq_gc_pid1127.log 这个问题不是升级系统之后出现的，而且也没有什么影响，就是缺少文件夹，手动创建一个文件夹即可。 来源： CSDN 作者： 程心 链接： https://blog.csdn.net/qq