RabbitMQ

1.RabbitMQ简介 因为RabbitMQ是基于开源的AMQP协议来实现的，所以在了解MQ时候，首先我们来了解下AMQP协议。AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端或者中间件不同产品、不同的开发语言等条件的限制，也就是说消息生产者无需知道消费者如何处理消息结果，反之亦然，解耦了组件跟组件依赖。RabbitMQ服务器端用Erlang语言编写，同时也支持多种客户端来开发跨语言消息传递，例如：Java，.NET，PHP，Python，JavaScript，Ruby，Go等。RabbitMQ还支持多种消息传递协议、消息排队、传递确认、队列的灵活路由、多种交换类型。还支持分布式集群以实现高可用性和吞吐量。适用于排队算法、秒杀活动、消息分发、异步处理、数据同步、处理耗时任务、CQRS等应用场景。还可以通过HTTP-API命令行工具和用于管理和监视RabbitMQ的UI。 2.RabbitMQ在CentOS 7安装 因为我对Linux运维知识面比较薄弱，所以在Linux上部署RabbitMQ这块暂时不想耗太多时间在这上面去（后续有时间再深入了解），这里我完全是跟着园区Net大神晓晨大佬这篇文章

一、什么是消息队列 MQ (Message Quene) : 翻译为 消息队列 ,通过典型的 ⽣产者 和 消费者 模型,⽣产者不断向消息队列中⽣产消息，消费者不断的从队列中获取消息。因为消息的⽣产和消费都是异步的，⽽且只关⼼消息的发送和接收，没有业务逻辑的侵⼊,轻松的实现系统间解耦。别名为 消息中间件 通过利⽤⾼效可靠的消息传递机制进⾏平台⽆关的数据交流，并基于数据通信来进⾏分布式系统的集成。 二、为什么要使用MQ 1.解耦 现在我有一个系统A，系统A可以产生一个userId,然后，现在有系统B和系统C都需要这个userId去做相关的操作,可以写成如下操作 如果有一天，系统B的负责人告诉系统A的负责人，现在系统B的SystemBNeed2do(String userId)这个接口不再使用了，让系统A别去调它了。那么就需要从代码的基础上去修改了。这样紧密的耦合关系会导致很多麻烦，如果使用消息中间件就不会出现以上问题。 2.异步 我们再来看看下面这种情况：系统A还是直接调用系统B、C、D 假设系统A运算出userId具体的值需要50ms，调用系统B的接口需要300ms，调用系统C的接口需要300ms，调用系统D的接口需要300ms。那么这次请求就需要50+300+300+300=950ms 并且我们得知，系统A做的是主要的业务，而系统B、C、D是非主要的业务。比如系统A处理的是订单下单

1. 消息可靠性 RabbitMQ 的消息可靠性，一般是业务系统接入消息中间件时首要考虑的问题，一般通过三个方面保障： 发送可靠性：确保消息成功发送到 Broker。 存储可靠性：Broker 对消息持久化，确保消息不会丢失。 消费可靠性：确保消息成功被消费。 1. 发送可靠性 一般消息发送可靠性分为 3 个层级： At most once：最多一次，消息可能会丢失，但绝不会重复传输。 At least once：最少一次，消息绝不会丢失，但可能会重复传输。 Exactly once：恰好一次，每条消息肯定会被传输一次且仅传输一次。 RabbitMQ 支持其中的“最多一次”和“最少一次”。 其中“最少一次”投递实现需要考虑以下这几个方面的内容： 消息生产者需要开启事务机制或者 publisher confirm 机制，以确保消息可以可靠地传输到 RabbitMQ 中。 消息生产者需要配合使用 mandatory 参数或者备份交换器来确保消息能够从交换器路由到队列中，进而能够保存下来而不被丢弃。 “最多一次”的方式无需考虑以上那些方面，生产者随意发送，不过这样很难确保消息会成功发送。 2. 消费可靠性 消费者在消费消息的同时，需要将 autoAck 设置为 false，然后通过手动确认的方式去确认已经正确消费的消息，以免在消费端引起不必要的消息丢失。 3. 代码示例 // 可靠生产

引言 如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论： 使用 标准化 流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。 和操作系统之间尽可能的 划清界限 ，在各个系统中提供 最大的可移植性 。 适合 部署 在现代的 云计算平台 ，从而在服务器和系统管理方面节省资源。 将开发环境和生产环境的 差异降至最低 ，并使用 持续交付 实施敏捷开发。 可以在工具、架构和开发流程不发生明显变化的前提下实现 扩展 。 这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。 特别声明 本文转自国外一篇文章，由Adam Wiggins所著，原文地址： https://12factor.net/ 在此文基础上增加个人的理解以及部分图解。 统一源代码管理系统 一份基准代码（Codebase），多份部署（depl o y） 在类似 SVN 这样的集中式版本控制系统中， 基准代码 就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中， 基准代码 则是指最上游的那份代码库。 基准代码和应用之间总是保持一一对应的关系： 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 最近，又重新学习了下Redis，深深被Redis的魅力所折服，我才知道Redis不仅能快还能慢（我想也这么优秀o(╥﹏╥)o），简直是个利器呀。 好了，接下来回到我们的话题，我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快。那么为何Redis又能慢呢？原来，这里说的慢是指Redis可以设置一些参数达到慢处理的结果。（这就是为什么Redis既能快又能慢啦！） 那接下来开始讲讲我们的楷模Redis在队列中如何实现延时的情况： 在我们日常生活中，我们可以发现， 在淘宝、京东等购物平台上下单，超过一定时间未付款，订单会自动取消。 打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单。 点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单。 收快递的时候，如果我们没有点确认收货，在一段时间后程序会自动完成订单。 在平台完成订单后，如果我们没有在规定时间评论商品，会自动默认买家不评论。 .......还有很多这样的场景。 这时，我们可以想想为什么要这样做？ 因为这样可以保证商品的库存可以释放给其他人购买，你可以不用一直等待打车却得不到回复，你可以及时换一家店点到外卖。

概述 消息服务中间件(如RabbitMQ)可用于异步处理、流量削峰等 RabbitMQ 运行机制 Exchange 类型 ​ 分发消息时根据其类型的不同有不同的分发策略： direct：消息中的routing key和队列的routing key一致的队列接受 fanout：广播，所有队列都能接受 topic：类似模糊匹配 RabbitMQ测试 # 安装 docker pull rabbitmq:3-management # 运行 docker run -d -p 5672:5672 -p 15672:15672 --name myrabbitmq 镜像id # 浏览器访问 服务器ip:15672 RabbitTemplate 自定义消息转换器,将数据序列化为json @Configuration public class MyAMQPConfig { @Bean public MessageConverter messageConverter(){ return new Jackson2JsonMessageConverter(); } } 测试发送和接受消息 @Autowired RabbitTemplate rabbitTemplate; @Test void send() { HashMap<String, Object> map = new HashMap<>();