RabbitMQ

Spring相信大家都用过，那一堆的配置，用起来就好比：你要吃饭，饭是熟的，但是你还要自己（配置）加油盐酱醋，还得搅拌均匀，然后才能吃...... 但是无奈，你的简历上还是得写“精通Spring Boot”。。。那总得大体说得上SpringBoot是个啥东西吧！ 学习会了Spring Boot之后，你总得还有一个举一反三的效果，哎说了这么多，不就是为了简历上那一句：精通Spring Boot吗？ 总结了两份SpringBoot的学习PDF，免费分享出来，希望大家可以在自己的简历上加上这句“精通Spring Boot”！加油 奥利给！ SpringBoot精髓 这份PDF系统介绍了Spring Boot2的主要技术，侧重于两个方面，一方面是极速开发一个Web应用系统，详细介绍Spring Boot框架、Spring MVC、视图技术、数据库访问技术，并且介绍多环境部署、自动装配、单元测试等高级特性。 另一方面， 当系统模块增加，性能和吞吐量要求增加时，如何平滑地用Spring Boot实现分布式架构，也会在后半部分介绍，包括使用Spring实现RESTful架构，在Spring Boot框架下使用Redis、MongoDB、 ZooKeeper、 Elasticsearch 等流行技术，使用Spring Session 实现系统水平扩展，使用Spring Cache提高系统性能。

RabbitMQ 1. RabbitMQ的使用场景有哪些？ 抢购活动，削峰填谷，防止系统崩塌。 延迟信息处理，比如10分钟之后给下单未付款的用户发送邮件提醒。解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。 2. RabbitMQ有哪些重要的角色？ RabbitMQ中重要的角色有：生产者、消费者和代理： [图片上传失败...(image-40f1e0-1604821335945)] 生产者：消息的创建者，负责创建和推送数据到消息服务器； 消费者：消息的接收方，用于处理数据和确认消息； 代理：就是RabbitMQ本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。 3. RabbitMQ有哪些重要的组件？ ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。 Channel（信道）：消息推送使用的通道。 Exchange（交换器）：用于接受、分配消息。 Queue（队列）：用于存储生产者的消息。 RoutingKey（路由键）：用于把生成者的数据分配到交换器上。 BindingKey（绑定键）：用于把交换器的消息绑定到队列上。

六种工作模式 官网介绍：https://www.rabbitmq.com/getstarted.html 简单模式：一个生产者，一个消费者 work模式：一个生产者，多个消费者，每个消费者获取到的消息唯一。 订阅模式：一个生产者发送的消息会被多个消费者获取。 路由模式：发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key topic模式：将路由键和某模式进行匹配，此时队列需要绑定在一个模式上，“#”匹配一个词或多个词，“ *”只匹配一个词。 简单模式/work模式 Channel channel = rabbitTemplate.getConnectionFactory().createConnection().createChannel( false ); channel.queueDeclare("yangsimple", false , false , false , null ); channel.basicPublish( "", "yangsimple", null , "simple message" .getBytes()); System.out.println( "basic publish" ); channel.close(); 订阅模式/路由模式 // 生产者 Connection connection =

想知道如何设计大型企业级的系统吗？在开始主要的代码开发之前，我们必须选择一种合适的体系架构，它将为我们提供所需的功能和质量属性。因此，在将它们应用到我们的设计之前，应该先了解不同的体系结构。 - 什么是架构模式 - 根据维基百科， 架构模式是在给定上下文中解决软件架构中常见问题的通用、可重用的解决方案。架构模式类似于软件设计模式，但范围更广。 在本文中，我会简单介绍下列10种常见的架构模式，及其用途、优势和劣势。 - 分层模式 - 该模式可用于构建可分解为子任务组的程序，其中每个都处于特定的抽象级别。每一次都向更高层提供服务。 一般信息系统中最常见的4层划分如下： Presentation layer 表示层（也就是UI层） Application layer 应用层（也就是服务层） Business logic layer 业务逻辑层（也就是领域层） Data access layer 数据访问层（也就是数据持久层） 应用 一般桌面应用程序 电子商务Web应用程序 - 客户端-服务器模式 - 该模式由两部分组成：一个服务端和多个客户端，服务器向多个客户端提供服务。客户端向服务器发起请求，服务器向这些客户端提供相关服务，之后，服务器继续侦听客户端的请求。 应用 在线应用程序，如电子邮件、文件共享和银行业务等 - 主从模式 - 该模式也分为两块：主模块和从模块

首先 Sink 的中文释义为： 下沉; 下陷; 沉没; 使下沉; 使沉没; 倒下; 坐下; 所以，对应 Data sink 意思有点把数据存储下来（落库）的意思； Source 数据源 ---- > Compute 计算 -----> sink 落库 如上图，Source 就是数据的来源，中间的 Compute 其实就是 Flink 干的事情，可以做一系列的操作，操作完后就把计算后的数据结果 Sink 到某个地方。（可以是 MySQL、ElasticSearch、Kafka、Cassandra 等）。 这里我说下自己目前做告警这块就是把 Compute 计算后的结果 Sink 直接告警出来了（发送告警消息到钉钉群、邮件、短信等），这个 sink 的意思也不一定非得说成要把数据存储到某个地方去。 其实官网用的 Connector 来形容要去的地方更合适，这个 Connector 可以有 MySQL、ElasticSearch、Kafka、Cassandra RabbitMQ 等。 Data Source 介绍了 Flink Data Source 有哪些，这里也看看 Flink Data Sink 支持的有哪些： 看下源码有哪些呢？ 可以看到有 Kafka、ElasticSearch、Socket、RabbitMQ、JDBC、Cassandra POJO、File、Print 等

一、选择消息队列产品的基本标准 在消息队列的技术选型上，并不存在说哪个消息队列就是“最好的”。常用的几个消息队列，每个产品都有自己的优势和劣势，需要根据现有系统的情况，选择最适合的那款产品。 技术产品的及格标准： 必须是 开源产品 ：如果遇到Bug至少有机会通过修改源代码迅速修复或规避，解决燃眉之急。 必须是近年来 比较流行 并且有一定 社区活跃度 的产品：流行的好处是，只要使用的场景不太冷门，遇到的Bug都可以找到解决办法。 流行的产品与 周边生态系统 会有一个比较好的集成和兼容：比如kafka和Flink就有比较好的兼容性，Flink内置了kafka的Data Sourse，使得你不用自己开发一个Flink的Data Source。 消息队列产品的及格标准： 消息的可靠传递：确保 不丢消息 。 Cluster：支持 集群 ，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息。 性能：具备足够好的性能，能 满足绝大多数场景 的性能要求。 二、可供选择的消息队列产品 1、RabbitMQ 介绍： 使用 Erlang语言编写 ，最早是为电信行业系统之间的可靠通讯性设计的，也是少数几个 支持AMQP 协议的消息队列。 轻量级 、迅速，开箱即用，非常容易部署和使用。 有一个特色的功能是支持非常 灵活的路由配置 。它在生产者和队列之间增加了一个 Exchange模块

在高并发业务场景下，消息队列在流量削峰、解耦上有不可替代的作用。当前使用较多的消息队列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、Pulsar 等。 消息队列这么多，到底该选择哪款消息队列呢？ 选择消息队列的基本标准 虽然这些消息队列在功能和特性方面各有优劣，但我们在选择的时候要有一个基本标准。 首先，必须是开源的产品。开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug，至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统的问题，而不是等待开发者发布的下一个版本来解决。 其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品。流行的好处是，只要使用场景不太冷门，遇到 Bug 的概率会非常低，因为大部分遇到的 Bug，其他人早就遇到并且修复了。在使用过程中遇到的一些问题，也比较容易在网上搜索到类似的问题，然后很快的找到解决方案。还有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容。 最后，作为一款及格的消息队列，必须具备的几个特性包括： 消息的可靠传递：确保不丢消息； Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息； 性能：具备足够好的性能，能满足绝大多数场景的性能要求。 接下来看一下有哪些符合上面这些条件，可供选择的开源消息队列。 RabbitMQ