RabbitMQ

今天在使用RTM系统debug测试时，发现程序起来之后unacked就会一直持续。经过查阅资料 如果队列中 ready 状态的消息数比较多，可以认为是消费者的处理能力不足 如若处理过程中出现异常，而没有回复ack 应答。通过后台就会看到有 unacked 的数据。 程序断开于rabbitmq的链接后 unacked的消息状态会重新变为ready 等待消费。 事实上，RTM是一个多线程嵌套多线程的程序，其逻辑大致是 这样展开，峰值估计每次都能提交上千个task。 通过top -Hp PID查看开了多少task 正式环境能到达500+ 来源： oschina 链接： https://my.oschina.net/u/4394685/blog/4375973

kubernetes 服务跨命名空间访问 大家都知道namespace是作为资源隔离，用于分组，可以把我不同组件，不同服务放在不同namespace下，便于管理。那么我现在有需求，希望服务之间可以互相访问，也就是跨namespace的服务访问，应该怎么处理呢？ svc 的 4种类型 ClusterIP 默认，分配一个VIP,只能内部访问 NodePort ClusterIP基础上，在每个节点绑定一个对外访问端口 LoadBalancer 在NodePort基础上，外部负载均衡器转发到NodePort ExternalName 集群外部的服务引入到集群内部来,集群内部使用 实现上述功能，就需要使用大svc的ExternalName 这种类型。 情况：v2 namespace需要访问default namespace的rabbitmq服务 解决办法：在v2 namespace里面创建service，不指定selector, 采用type=ExternalName的方式,externalName定义成为指向namespace=default中的rabbitmq-service # vi rabbitmq.yaml apiVersion: v1 kind: Service metadata: name: rabbitmq namespace: v2 spec: ports: - port:

一、为什么要使用消息队列？ 1、 削峰 当有大并发产生的时候，数据会堆积在MQ中，消费端保持平稳的消费能力，不会给后端服务造成太大压力； 2、解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 3、异步 异步可以大大提高响应的速度； 二、使用消息队列的缺点？ 1、一定程度上降低了系统的可用性 在不使用第三方组件的情况下，只有部署服务的机器挂了，进程才会出问题； 但是使用第三方消息队列，增加了一种宕机的可能，就是消息队列服务挂了也会导致进程出问题； 2、系统复杂性增加 代码复杂：需要引入第三方服务相关代码；本来只是一个方法调用而已。 需要考虑消息队列服务的一些问题， 如何保证消息不被重复消费？如何保证保证消息可靠传输？ 三、消息队列的选型 来一个对比表： 特性 ActiveMQ RabbitMQ RocketMQ kafka 开发语言 java erlang java scala 单机吞吐量 万级 万级 10万级 10万级 时效性 ms级 us级 ms级 ms级以内 可用性 高(主从架构) 高(主从架构) 非常高(分布式架构) 非常高(分布式架构)

分享一下Rocky版本的OpenStack安装管理经验： OpenStack每半年左右更新一版，目前是版本是201808月发布的版本-R版(Rocky)，目前版本安装方法优化较好，不过依然是比较复杂 官方文档地址： https://docs.openstack.org/install-guide/openstack-services.html 本文主要分享控制节点的环境配置方法： ---------------- 完美的分割线 ------------------ 1.0.系统环境 1）生产测试应用的服务器最好是物理机，虚拟目前可以完成搭建测试体验 2）系统选择是目前的最新版本：CentOS Linux release 7.5.1804 (Core) 3）控制节点Controller ：192.168.1.81 计算节点Nova：192.168.1.82 1.1.配置域名解析 1）配置主机名 # 主机名设置好就不能修改，否则会出问题，控制节点和计算节点配置相同，且都需要配置 hostname openstack01.zuiyoujie.com hostname echo " openstack01.zuiyoujie.com " > /etc/ hostname cat /etc/hostname 2）配置主机名解析 vim /etc/ hosts ----------------

目录 为什么需要消息队列 1.异步 ：一个下单流程，你需要扣积分，扣优惠卷，发短信等，有些耗时又不需要立即处理的事，可以丢到队列里异步处理。 2.削峰 ：按平常的流量，服务器刚好可以正常负载。偶尔推出一个优惠活动时，请求量极速上升。由于服务器 Redis，MySQL 承受能力不一样，如果请求全部接收，服务器负载不了会导致宕机。加机器嘛，需要去调整配置，活动结束后用不到了，即麻烦又浪费。这时可以将请求放到队列里，按照服务器的能力去消费。 3.解耦 ：一个订单流程，需要扣积分，优惠券，发短信等调用多个接口，出现问题时不好排查。像发短信有很多地方需要用到， 如果哪天修改了短信接口参数，用到的地方都得修改。这时可以将要发送的内容放到队列里，起一个服务去消费， 统一发送短信。 高吞吐、高可用 MQ 对比分析 看了几个招聘网站，提到较多的消息队列有：RabbitMQ、RocketMQ、Kafka 以及 Redis 的消息队列和发布订阅模式。 Redis 队列是用 List 数据结构模拟的，指定一端 Push，另一端 Pop，一条消息只能被一个程序所消费。如果要一对多消费的，可以用 Redis 的发布订阅模式。Redis 发布订阅是实时消费的，服务端不会保存生产的消息，也不会记录客户端消费到哪一条。在消费的时候如果客户端宕机了，消息就会丢失。这时就需要用到高级的消息队列，如 RocketMQ

消息代理(Message Broker): 一种消息验证、传输、路由的架构模式，实现应用程序之间消息传递的解耦 RabbitMQ:实现高级消息队列协议(AMQP)的开源消息代理中间件 AMQP特性：消息方向、消息队列、消息路由（PTP/SB）、可靠性、安全性 1. RabbitMQ基本概念: Broker:消息队列服务器的实体，负责接收生产者的消息，然后将消息发送到消息接收者或者其他Broker Exchange:消息交换机，消息第一个到达的地方，消息通过它指定的路由规则，分发到不同的消息队列(类似路由器) Queue:消息队列：消息通过发送和路由之后达到的地方，到达Queue的消息即进入逻辑上的等待消费状态，每个消息都会发送到一个或多个队列。 Binding：绑定：将Exchange和Queue按照路由规则绑定起来，是Exchange\Queue的虚拟连接 Routing Key:路由关键字，Exchange根据关键字进行消息投递 Virtual host:虚拟主机，对Broker进行虚拟划分，将消费者、生产者和依赖的AMQP相关结构进行隔离，一个Broker可设置多个虚拟主机，对不同的用户进行权限隔离。 Connection：连接，代表生产者、消费者、Broker之间进行通信的物理网络 Channel:消息通道，用于连接生产者、消费者的逻辑结构，每个连接可创建多个Channel

1. 单体架构 2. 分布式系统架构 3. 基于消息中间件的分布式系统架构 4. 消息中间件概述 1. 什么是消息中间件 利用高效可靠的消息传递机制进行平台无关的数据交流。 并基于数据通信来进行分布式系统的集成。 通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 2. 消息中间件的应用场景 跨系统数据传递。 高并发流量削峰。 数据异步处理。 ... 3. 常用的消息中间件 ActiveMQ RabbitMQ Kafka RocketMQ 5. 消息中间件核心设计 1. 本质 一种具有接收数据、保存数据、发送数据等功能的网络应用。 和一般网络应用程序的区别是它主要负责数据的接收和传递，所以性能一般都高于普通程序。 2. 5 大核心组成 协议 持久化机制 消息分发机制 高可用设计 高可靠设计 6. 协议 1. 协议是什么 协议是计算机之间通信时共同遵守的一组约定，都遵守相同的约定，计算机之间才能相互交流。 是对数据格式和计算机之间交互数据时必须遵守的规则的正式描述。 协议三要素： 语法：即数据与控制信息的结构或格式； 语义：即需要发出何种控制信息，完成何种动作以及做出何种响应； 时序（同步）：即事件实现顺序的详细说明。 2. 常见协议 HTTP 三要素举例： 语法：http 规定了请求报文和响应报文的具体格式。 语义：客户端主动发起的操作称为请求。 时序

本文基于当前 Spring Security 5.3.4 来分析，为什么要强调最新版呢?因为在在 5.0.11 版中，角色继承配置和现在不一样。旧版的方案我们现在不讨论了，直接来看当前最新版是怎么处理的。 1.角色继承案例 我们先来一个简单的权限案例。 创建一个 Spring Boot 项目，添加 Spring Security 依赖，并创建两个测试用户，如下： @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication() .withUser("javaboy") .password("{noop}123").roles("admin") .and() .withUser("江南一点雨") .password("{noop}123") .roles("user"); } 然后准备三个测试接口，如下： @RestController public class HelloController { @GetMapping("/hello") public String hello() { return "hello"; } @GetMapping("/admin/hello") public String

一、Celery 核心模块 1. Brokers brokers 中文意思为中间人，在这里就是指 任务队列本身 ，接收生产者发来的消息即Task，将任务存入队列。任务的消费者是Worker，Brokers 就是生产者和消费者存放/拿取产品的地方(队列)。Celery 扮演生产者和消费者的角色。 常见的 brokers 有 rabbitmq、redis、Zookeeper 等。推荐用Redis或RabbitMQ实现队列服务。 2. Workers 就是 Celery 中的 工作者 ，执行任务的单元，类似与生产/消费模型中的消费者。它实时监控消息队列，如果有任务就从队列中取出任务并执行它。 3. Backend / Result Stores 用于存储任务的执行结果 。队列中的任务运行完后的结果或者状态需要被任务发送者知道，那么就需要一个地方储存这些结果，就是 Result Stores 了。 常见的 backend 有 redis、Memcached 甚至常用的数据库都可以。 4. Tasks 就是 想在队列中进行的任务 ，有异步任务和定时任务。一般由用户、触发器或其他操作将任务入队，然后交由 workers 进行处理。 5. Beat 定时任务调度器 ，根据配置定时将任务发送给Brokers。 二、Celery 基本使用 1.创建一个celery application

由于插件得实现方式不一样，会出现这种情况，如果不用插件则不会出现这种情况。 rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() { @Override public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) { //如果是延迟队列则忽略，使用插件延迟队列不管成功都会调用 if(Constants.DELAY_EXCHANGE.equals(exchange)) { return; } // 异步通知 log.error("ReturnCallback MQ消息发送失败，replyCode:{}, replyText:{}，exchange:{}，routingKey:{}，消息体:{} 消息属性:{}", replyCode, replyText, exchange, routingKey, new String(message.getBody()), message.getMessageProperties()); } }); 插件形式交换器 交换器 注：用代码是创建一个：CustomExchange自定义交换器