RabbitMQ

过程 虚拟机时 centos6 版本 安装的rabbitmq是 3.4.1 安装过程是使用rpm指令执行 rpm -ivh rabbitmq-server-3.4.1-1.noarch.rpm 安装之后 在使用 service rabbitmq-server start 启动时，显示启动成功 出现启动成功但服务未开启的现象 在安装后的log文件下 /var/log/rabbitmq/ 查看 在这里插rabbitmq@localhost.log 文件 报badmatch的错 { could_not_start , rabbit , { bad_return , { { rabbit , start , [ normal , [ ] ] } , { 'EXIT' , { rabbit , failure_during_boot , { boot_step , recovery , { badmatch , { error , { { { badmatch , { error , { "/var/lib/rabbitmq/mnesia/rabbit@localhost/msg_store_transient/0.rdq" , eacces } } } , [ { rabbit_msg_store , init , 1 , [ ] } , { gen_server2 , init_it ,

基于 RabbitMQ 的实时消息推送 俞 超 2016 年 4 月 11 日发布 Weibo Google+ 用电子邮件发送本页面 2 实现服务器端推送的几种方式 Web 应用都是基于 HTTP 协议的请求/响应模式，无法像 TCP 协议那样保持长连接，因此 Web 应用就很难像手机那样实现实时的消息推送。就目前来看，Web 应用的消息推送方式主要有以下几种： 1.Ajax 短轮询 Ajax 轮询主要通过页面端的 JS 定时异步刷新任务来实现数据的加载，但这种方式实时效果较差，而且对服务端的压力也较大。 2. 长轮询 长轮询主要也是通过 Ajax 机制，但区别于传统的 Ajax 应用，长轮询的服务器端会在没有数据时阻塞请求直到有新的数据产生或者请求超时才返回，之后客户端再重新建立连接获取数据，具体实现方式见图 1 所示。但长轮询服务端会长时间地占用资源，如果消息频繁发送的话会给服务端带来较大的压力。 图 1. 长轮询实现方式 3.WebSocket 双向通信 WebSocket 是 HTML5 中一种新的通信协议，能够实现浏览器与服务器之间全双工通信。如果浏览器和服务端都支持 WebSocket 协议的话，该方式实现的消息推送无疑是最高效、简洁的。并且最新版本的 IE、Firefox、Chrome 等浏览器都已经支持 WebSocket 协议，Apache Tomcat 7.0

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Multipart messages How to post a Multipart http message to a web service in C# and handle it with Java RabbitMQ .NET Messaging with RabbitMQ and .NET C# part 1: foundations and setup Messaging with RabbitMQ and .NET C# part 2: persistence Messaging with RabbitMQ and .NET C# part 3: message exchange patterns Messaging with RabbitMQ and .NET C# part 4: routing and topics Messaging with RabbitMQ and .NET C# part 5: headers and scatter/gather RabbitMQ in .NET: data serialisation RabbitMQ in .NET: data serialisation II RabbitMQ in .NET: handling large messages

前言 前一阵开发过程遇到的问题，用的 rabbitmq template 发送消息，消息body里的时间是比当前时间少了8小时的，这种一看就是时区问题了。 就说说为什么出现吧。 之前的配置是这样的： @Bean public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) { RabbitTemplate template = new RabbitTemplate(connectionFactory); template.setMessageConverter(new Jackson2JsonMessageConverter()); template.setMandatory(true); ... return template; } 要发送出去的消息vo是这样的： @Data public class TestVO { @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") private Date testDate; } 然后，出现的问题就是，消息体里，时间比当前时间少了8个小时。 {"testDate":"2019-12-27 05:45:26"} 原因 我们是这么使用rabbitmq template的： @Autowired private

erlang和RabbitMq装好后我的centos7里也要和windous一样配置一下环境变量呀，我没有配置， 我的解决方法： 配置Erlang环境变量,vi /etc/profile文件（这文件要root权限，不然是只读文件，给用户加权限也可以），增加下面的环境变量: #set erlang environment export PATH=$PATH:/opt/erlang/bin 配置rabbitmq环境变量,vi /etc/profile文件，增加下面的环境变量: #set rabbitmq environment export PATH=$PATH:/opt/rabbitmq/sbin 然后在rabbitmq-plugins enable rabbitmq_management 然后在localhost:15672 来源： https://www.cnblogs.com/lhh666/p/12108047.html

目标 1、消息如何保证100%的投递？ 2、幂等性概念 3、Confirm确认消息 4、Return返回消息 5、自定义消费者 消息100%的投递 消息如何保障100%的投递成功？ 什么是生产端的可靠性投递？ 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点（Broker）确认应答 完善的消息进行补偿机制 BAT/TMD互联网大厂的解决方案： 消息落库，对消息状态进行打标 消息的延迟投递，做二次确认，回调检查 幂等性概念 幂等性是什么？ 我们可以借鉴数据库的乐观锁机制 比如我们执行一条更新库存的SQL语句 Update t_repository set count = count -1,version = version + 1 where version = 1 Elasticsearch也是严格遵循幂等性概念，每次数据更新，version+1（博主博客前面有提到） 消费端-幂等性保障 在海量订单产生的业务高峰期，如何避免消息的重复消费问题？ 消费实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息 业界主流的幂等性操作 唯一ID+指纹码机制，利用数据库主键去重 利用Redis的原子性去实现 唯一ID+指纹码 机制 唯一ID+指纹码机制，利用数据库主键去重 Select count(1) from T_order

快速开始 spring boot应用 官方向导搭建 boot应用 地址： http://start.spring.io/ 设置项目属性： 　　 3.解压，拷贝到工作空间，导入 maven项目 4.写 Controller： HelloController.java 5.启动 Spring Boot入口类：DemoApplication 普通 maven工程搭建boot应用 1.新建一个普通的 maven工程，选择quickstart 【注意： Spring boot是web工程，但是我们这里只需要建立quickstart即可，因为spring boot内嵌了servlert容器】 2.查看官方文档： https://projects.spring.io/spring-boot/ 点击quick start 选择版本【 1.5.10.RELEASE】,建议： 生产环境中选择稳定的版本 拷贝依赖的父 pom到自己的工程pom文件中： <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.10.RELEASE</version> </parent> <dependencies> <dependency>

centos7安装rabbitmq-3.7.17 准备 访问rabbitmq官网下载页面: https://www.rabbitmq.com/download.html ： 安装erlang 找到安装erlang: https://www.rabbitmq.com/install-rpm.html#install-from-esl-repository : 即： https://www.erlang-solutions.com/resources/download.html : 安装： wget https://packages.erlang-solutions.com/erlang/rpm/centos/7/x86_64/esl-erlang_22.0.7-1~centos~7_amd64.rpm rpm -ivh esl-erlang_22.0.7-1~centos~7_amd64.rpm 安装过程中出现如下错误 error: Failed dependencies: libGL.so.1()(64bit) is needed by esl-erlang-19.3-1.x86_64 libGLU.so.1()(64bit) is needed by esl-erlang-19.3-1.x86_64 libodbc.so.2()(64bit) is needed by esl

1、RabbitMQ （（消息队列工具，在celery中扮演broker的角色，broker是消息代理，或者叫做消息中间件） 2、使用Celery （异步任务的调度工具） 简单来说，rabbitmq是一个采用Erlang写的强大的消息队列工具。在celery中可以扮演broker的角色。那么什么是broker？ broker是一个消息传输的中间件，可以理解为一个邮箱。每当应用程序调用celery的异步任务的时候，会向broker传递消息，而后celery的worker将会取到消息，进行对于的程序执行。好吧，这个邮箱可以看成是一个消息队列。那么什么又是backend，通常程序发送的消息，发完就完了，可能都不知道对方时候接受了。为此，celery实现了一个backend，用于存储这些消息以及celery执行的一些消息和结果。对于 brokers，官方推荐是rabbitmq和redis，至于backend，就是数据库啦。为了简单起见，我们都用redis。 （1）celery 的架构 celery beat： 任务调度器，beat进程会读取配置文件的内容，周期性的将配置中到期需要执行的任务发送给任务队列。 celery worker： 执行任务的消费者，通常会在多台服务器运行多个消费者 来提高执行效率。 broker： 消息代理，或者叫做消息中间件，接受任务生产者发送过来的任务消息

1、吞吐量 kafka吞吐量更高： 　　1）Zero Copy机制，内核copy数据直接copy到网络设备，不必经过内核到用户再到内核的copy，减小了copy次数和上下文切换次数，大大提高了效率。 　　2）磁盘顺序读写，减少了寻道等待的时间。 　　3）批量处理机制，服务端批量存储，客户端主动批量pull数据，消息处理效率高。 　　4）存储具有O(1)的复杂度，读物因为分区和segment，是O(log(n))的复杂度。 　　5）分区机制，有助于提高吞吐量。 2、可靠性 rabbitmq可靠性更好： 　　1）确认机制（生产者和exchange，消费者和队列）； 　　2）支持事务，但会造成阻塞； 　　3）委托（添加回调来处理发送失败的消息）和备份交换器（将发送失败的消息存下来后面再处理）机制； 3、高可用 　　1）rabbitmq采用mirror queue，即主从模式，数据是异步同步的，当消息过来，主从全部写完后，回ack，这样保障了数据的一致性。 　　2）每个分区都可以有一个或多个副本，这些副本保存在不同的broker上，broker信息存储在zookeeper上，当broker不可用会重新选举leader。 　　kafka支持同步负责消息和异步同步消息（有丢消息的可能），生产者从zk获取leader信息，发消息给leader，follower从leader