RabbitMQ

【推荐阅读】微服务还能火多久？>>> Spring framework架构的项目就像上海中心这样的高楼大厦，一栋大厦里租用者各色各样的公司和企业为用户提供各种各样的服务。 大厦里的每间办公室都是一个容器，对应着一个docker容器，空办公室对于用户来说是没有任何意义的，只有里面入住了企业（Spring boot），跑了各种程序，才叫一个微服务结点。 房间号可以理解成容器的ip和端口，企业名理解成微服务的服务名，如果一家企业规模较大，需要租多间办公室才可以，那就是多个容器共同组成一个高可用性的微服务组群。 大厦有一本企业列表，有哪些企业提供哪些服务，对应的房间号是什么，这本列表就是Spring Cloud Eureka。 大厦的大门是所有企业的对外的gateway，用户只能通过大门进去然后进行安检后保安会帮你指路告诉你要找的企业在哪里，这里的大门和门卫就是Spring Cloud Zuul。 也不是所有的房间都是给企业准备的，也有弱点室、茶水间等为所有企业准备的公共设施，这就是Spring Cloud Hystrix的Dashboard、redis、MQ等这些独立的辅助服务。 如果要访问大厦里的某一个企业你只知道企业名，你是不知道具体在哪一楼层哪一房间的，需要去看楼层的导航图或者电梯附近的企业列表（Eureka），如果一个企业有多个房间，客户自己决定进哪一个房间去获取服务

【推荐阅读】微服务还能火多久？>>> 前言: 常常一些核心技术等我碰到的时候才发现自己忘得差不多了，甘心安于现状，等自己跟别人有了差距之后才想起来要学习，我太难了，永远不要停下自己学习的脚步，比你厉害的人真的有很多，今天给大家分享的是一份283页的Java核心知识点(PDF)特别详细，有幸得此宝典，这么详细的核心知识点怎能独吞呢，分享给各位有需要想学习的同仁朋友们,关注末尾。 由于篇幅限制，不能完整的把全部内容分享出来，如果你觉得此文档对你有帮助，你有需求的话，看到末尾会有福利 包含内容: 26个知识点 Java基础，集合，并发，多线程，JVM，设计模式 Java算法，数据结构 Spring，MyBatis，MVC，netty，tomcat 架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡 SpringBoot，SpringCloud，Dubbo，Docker 适用人群: 个人觉得都适用，不管是小白还是大牛，查漏补缺发现更厉害的你 JVM 线程 JVM内存区域 JVM运行内存 垃圾回收与算法 Java四种引用类型 GC 分代收集算法 VS 分区收集算法 GC 垃圾收集器 JAVA IO/NIO JVM类加载机制 JVM 的内存模型和 JVM 的垃圾回收机制一直是 Java 业内从业者绕不开的话题（实际调优、面试）JVM是java中很重要的一块知识

【推荐阅读】微服务还能火多久？>>> 一、引言 使用工作队列的一个好处就是它能够并行的处理队列。如果堆积了很多任务，我们只需要添加更多的工作者（workers）就可以了，扩展很简单。本例使用多线程来创建多信道并绑定队列，达到多workers的目的。 二、示例 2.1、环境准备 在NuGet上安装RabbitMQ.Client。 2.2、工厂类 添加一个工厂类RabbitMQFactory： /// <summary> /// 多路复用技术(Multiplexing)目的：为了避免创建多个TCP而造成系统资源的浪费和超载，从而有效地利用TCP连接。 /// </summary> public static class RabbitMQFactory { private static IConnection sharedConnection; private static int ChannelCount { get ; set ; } private static readonly object _locker = new object (); public static IConnection SharedConnection { get { if (ChannelCount >= 1000 ) { if (sharedConnection != null &&

【推荐阅读】微服务还能火多久？>>> 这份面试清单是做了 TeamLeader 之后开始收集的，一方面是给公司招聘用，另一方面是想用它来挖掘在 Java 技术栈中，还有那些知识点是不知道的，想找到这些技术盲点，然后修复它，以此来提高自己的技术水平。 虽然从 2009 年就开始参加编程工作了，但依旧觉得自己现在要学的东西很多，并且学习这些知识，很有成就感和满足感，那所以何乐而不为呢？ 说回面试的事，这份面试清单本来是只有内部使用的，可到后来有很多朋友在微信上联系到，帮他们找一些面试方面的资料，而且这些关系也不太好拒绝: 一呢，是因为这些找我的人要么是朋友的弟弟妹妹，要么是表弟表妹们； 二呢，也不想马马虎虎的对付，俗话说的好“受人之事忠人之命”，不能辜负这份信任。 ** 但最后就有了这么一个想法，要不要把整理的这 200 多道 Java 面试题分享出去，去帮助更多的人。 说实话刚开始的时候是比较犹豫的，首先这么做会不会有点帮人“作弊”的嫌疑，最后我终于想通了，觉得这未必是一件坏事。 第一：有更多的人因此而学到了更多的知识，这不算是一件坏事，恰好相反。 第二：这只是一种经验的高度提炼，让那些有技术能力的人，学会如何表达自己所掌握的知识，这也是一件好事。 第三：如果只是死记硬背这些面试题，如果面试官能再深入问纠一些细节，也可识破之中的“玄机”。 第四：学习有很多种方式

【推荐阅读】微服务还能火多久？>>> 背景 最近项目有个需求需要动态更新规则，当时脑中想到的第一个方案是利用zk的监听机制，管理人员更新完规则将状态写入zk，集群中的机器监听zk的状态，当有状态变更后，集群中的机器开始拉取最新的配置。但由于公司技术选型，没有专门搭建zk集群，因此也不可能为这一个小需求去搭建zk集群。图为使用zk监听状态变化的流程。 最后只好退而求其次，想到了使用redis的队列来做规则的更新 消息队列 首先做简单的引入。 队列（来自百度百科）：是一种特殊的线性表，特殊之处在于它只允许在表的前端（front）进行删除操作，而在表的后端（rear）进行插入操作，和栈一样，队列是一种操作受限制的线性表。进行插入操作的端称为队尾，进行删除操作的端称为队头。 消息队列（来自百度百科）：是在消息的传输过程中保存消息的容器。 从队列和消息队列的定义看来，看不出什么相似之处。但我理解它们的作用是相似的，只是使用环境不同。队列和消息队列 本质上都可以用于解决“生产者”和“消费者”问题，在二者这间建立桥梁，it中专业术语是对“生产者”和“消费者”进行解耦。可以动态的通过调整“生产者”和“消费者”线程数或服务器实例数，在正常情况使消费和生产到达一个平衡；在高峰情况下（生产者大于消费者）可以保护消费者不被拖垮的同时，还可以对把积压的数据保存下来，消费者可以延迟消费这些数据进行处理。 队列

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

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

一、引言 日常生活中，很多的APP都有延迟队列的影子。比如在手机淘宝上，经常遇到APP派发的限时消费红包，一般有几个小时或24小时不等。假如在红包倒计时的过程中，没有消费掉红包的话，红包会自动失效。假如上述行为使用RabbitMQ延时队列来理解的话，就是在你收到限时消费红包的时候，手机淘宝会自动发一条延时消息到队列中以供消费。在规定时间内，则可正常消费，否则依TTL自动失效。 在RabbitMQ中，有两种方式来实现延时队列：一种是基于队列方式，另外一种是基于消息方式。 二、示例 2.1、发送端(生产端) 新建一个控制台项目Send，并添加一个类RabbitMQConfig。 class RabbitMQConfig { public static string Host { get ; set ; } public static string VirtualHost { get ; set ; } public static string UserName { get ; set ; } public static string Password { get ; set ; } public static int Port { get ; set ; } static RabbitMQConfig() { Host = " 192.168.2.242 " ; VirtualHost