qq_31279701的博客

目标生产环境ActiveMQ消费慢问题始末第一次代码优化后服务线程阻塞问题排查最终问题解决生产环境ActiveMQ消费慢问题始末   公司一个系统生产环境应用ActiveMQ进行通信，由于上下层系统的特殊性，消息的对接使用的P2P的模式，上送服务需要对接上百个ActiveMQ的消息队列，下层服务的每一个实例都对接一个消息队列，并且消息量不大，所以消息生产者是一个单线程的程序，并且生产者使用同步的方式发送消息，就是说只有当消息发到达broker并刷盘成功才会发下一条数据。   突然在某一个时间

本文参考官方文档：https://activemq.apache.org/persistence博客：https://blog.csdn.net/weixin_42796626/article/details/98206384持久化方式支持目前最新版本支持的消息持久化方式有以下几种，其他版本的持久化支持情况请参考官方文档kahaDB文件持久化jdbc持久化levelDB存储levelDB主从复制AMQ持久化；（不推荐，可以用kahaDB替代）Memory内存持久化；（不推荐，容易丢失数

目标单元测试redis执行的lua脚本技术选型之embedded-redisserver我在项目单元测试中的使用单元测试redis执行的lua脚本    最近在参加开源项目soul网关时，基于redis实现了一个限流的漏桶算法，在提交pr的过程中发现soul网关的限流插件中没有对每个算法Lua脚本的单元测试，换句话说，贡献者提供了一个算法的实现，java代码我们都可以单元测试，但是真正执行限流逻辑的与与redis交互执行的lua脚本时没有单元测试的，这就导致提交的lua脚本

目标Redisson分布式锁看门狗机制源码分析Redisson分布式锁看门狗机制    我们在上篇文章中分析了Redisson加锁和解锁的流程，总体看逻辑还算清晰，主要是使用异步执行lua脚本进行加锁，但是其中有些细节，之前并没有细说，比如RedissonLock中的internalLockLeaseTime，该变量默认初始值30000毫秒，并且Config类中默认值变量的命名也很有意思lockWatchdogTimeout，字面上的意思监视锁的狗，这就引入了Redisson

目标Redisson可重入锁简单应用Redisson可重入锁加锁/解锁源码分析总结Redisson可重入锁简单应用pom依赖<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.12.0</version></dependency>可重入锁

目标我使用redis分布式锁场景客户端选型redis分布式锁流程图代码实现总结我使用redis分布式锁场景    公司一个核心交易处理服务是消费MQ进行交易入库处理，该交易在入库时会进行更新交易某一个数据值，由于该交易生产者会同时生产某一条交易的两条数据，这就导致了在不处理并发的时候更新数据产生并发问题，导致数据最终不一致，为此我们打算在不改造生产者的时候在消费者进行处理，就是同时只能有一条交易被处理更新数据，然后在获取锁失败后交给交给MQ做重试处理，并且这部分交易是批

（一）重构原则1、何谓重构对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。另一种解释是：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。重构不止是代码整理，它提供了一种高效且受控的代码整理技术2、为何重构改进软件设计：如果没有重构，程序的设计会逐渐变质，重构很像是在整理代码，你所做的就是让所有的东西回到应处的位置上。帮助找到bug：对代码进行重构，可以深入理解代码的作为，在搞清楚程序结构的同时，想不把bug揪出来都难。提高编程

Dubbo SPI核心实现Dubbo SPI实现介绍ExtensionFactory接口ExtensionLoader SPI核心实现总结Dubbo SPI实现    由于java提供的SPI实现不足，所以Dubbo自己实现了一套SPI，Dubbo的SPI的实现应用启动时候将实现了SPI接口的扩展类加载到缓存中，下面就简单的看一下Dubbo SPI实现的核心源码ExtensionFactory接口    ExtensionFactory接口，提供接

Docker搭建redis主从复制一.安装Redis1.搜索redis镜像 docker search redis2.拉取镜像 docker pull redis二.主从复制1.运行docker镜像，首先使用docker启动3个redis容器服务，分别使用到6379、6380、6381端口docker run --name redis-6379 -p 6379:6379 -d redis redis-serverdocker run --name redis-6380 -p

SpringBoot快速集成KafkaMaven依赖<!-- 启动springbootstarter支持 --><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId></dependency><dependency> <gr

SPI介绍    SPI ，全称为 Service Provider Interface，是一种服务发现机制，是Java提供的一套用来被第三方实现或者扩展的接口，它可以用来启用框架扩展和替换组件。 SPI的作用就是为这些被扩展的API寻找服务实现。<<高可用可伸缩微服务架构>> 第3章 Apache Dubbo 框架的原理与实现 中有这样的一句定义.SPI是 JDK 内置的一种服务提供发现功能, 一种动态替换发现的机制. 举个例子, 要想在运行时动态地给一个接口

示例LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) .removalListener(MY_LISTENER) .build( new CacheLoader<Key, Graph>() {

Google Guava Cache在项目中应用目标使用缓存背景技术选型使用Guava Cache构建缓存缓存测试使用缓存背景    接入缓存的项目是一个交易处理服务，主要流程就是从RocketMQ中消费初始交易，并根据业务规则进行交易的处理；原本，交易中的用户相关信息都是没有校验的，以交易中的数据为准的，但是随着交易量的增加，以及第三方商户的接入，交易中的用户数据变得不再可靠，面对此问题就需要进行用户信息校验，由于我们架构是微服务，用户信息在用户中心，最直观的方式就是

目标soul网关应用spingwebfluxsoul网关使用subscribeOn巧妙设计分析总结起因​ 起因是群里一个小伙伴问到soul网关在webHandler中配置Scheduler是为啥，我想这位小伙伴一定是深有研究后才发起的话题，顺着这个话题我也打算一探究竟。soul网关应用spingwebflux​ 经过了这段时间对soul网关的研究，我们已经知道了，soul网关是集成了spirng webflux用来接收请求的，核心的代码是SoulWebHandler，该类实现了

目标soul网关集成并配置熔断插件测试不通熔断参数的熔断结果分析soul网关熔断插件的原理总结soul网关集成病配置熔断插件​ soul网关的hystrix插件是网关用来对流量进行熔断的核心实现，使用信号量的方式来处理请求soul网关集成hystrix插件 <dependency> <groupId>org.dromara</groupId> <artifactId>s

转：Hystrix原理与实战 背景 分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。 雪崩效应常见场景 硬件故障：如服务器宕机，机房断电，光纤被挖断等。...

目标集成限流（rate_limiter）插件压测接口触发限流soul网关限流插件源码分析总结简介Soul网关限流插件​ soul网关的限流插件是对流量管控的核心，soul网关的限流粒度可以是接口或者参数级别，soul网关的限流插件是基于redis实现的令牌桶算法，所以在集成soul网关之前要搭建一个redis。网关集成限流插件pom <dependency> <groupId>org.dromara</groupId>

目标集成使用sofa插件soul网关完成sofa调用源码分析总结##网关集成 sofa插件pom <dependency> <groupId>com.alipay.sofa</groupId> <artifactId>sofa-rpc-all</artifactId> <version>5.7.6</version> &

目标divide插件底层原理，负载均衡，ip端口探活介绍负载均衡原理分析ip端口探活端口分析总结divide插件底层原理，负载均衡，ip端口检测介绍    divide插件是网关处理http协议请求的核心处理插件，divide插件是进行http正向代理的插件，所有http类型的请求，都是由该插件进行负载均衡的调用，所说的负载均衡就是divide插件根据负责均衡算法将请求转发到具体的一台后端机器上。soul-admin提供ip+端口的检测功能，在soul-admin 会有一

目标何为数据同步soul网关数据同步方式总结soul网关同步数据的类型总结soul网关数据同步流程总结soul网关数据同步核心处理接口总结何为数据同步    在具体总结之前，先来说一下，什么是soul网关的数据同步，soul网关又是同步的什么数据，我们知道soul网关实现了插件热插拔的方式，插件的数据，插件的选择器数据，规则数据可以选择持久化存储到数据库，但是对于网关来说，如果，每一次匹配数据的时候都要去数据库捞，那显然是不合适的，既然网关要做到高性能，那肯定不能每次都

目标分析soul网关使用nacos的数据同步源码总结soul-admin与soul网关配置nacos数据同步soul-admin的yml配置soul:database: dialect: mysql init_script: "META-INF/schema.sql"sync: nacos: url: localhost:8848 namespace: 1c10d748-af86-43b9-8265-75f487d20c6c acm:

目标分析soul网关使用zookeeper的数据同步源码总结soul-admin与soul网关配置zookeeper数据同步soul-admin的yml配置关闭websocket同步方式，开启zk同步方式，配置zksoul:database: dialect: mysql init_script: "META-INF/schema.sql"sync:# websocket:# enabled: true zookeeper: url

Spring WebFlux对比Spring MVC压测对比目标50 100 200 300 并发分别压测基于Spring WebFlux和Spring MVC的程序总结准备工作准备一个基于Spring WebFlux和一个基于Spring MVC的工程apache-jmeter-3.3.2：压测工具jvisualVM：JVM指标监控开始压测指标1：50 并发，压测1分钟Spring MVCjmeter压测报告JVM监控Spring WebF

目标基于soul网关源码分析之一个请求如何被网关代理分析下被soul网关代理的接口是如何匹配插件，选择器以及规则总结分析背景    上篇文章简单分析了下一个被soul网关代理的接口请求是如何被转发的，先来回顾一下，soul网关是通过实现Spring WebFlux提供的WebHandler接口，来实现对外提供Web服务，接收请求的；重写的handle方法来处理请求，处理请求时使用责任链模式来链式的执行插件，上篇是主要分析的一个代理Http 接口的处理流程， 所以就直接看了一遍

目标分析一个被soul网关代理的http接口的处理流程总结soul网关代理的http接口的处理流程准备工作    启动soul-admin和soul网关，然后启动一个springMvc的rest服务，并且rest服务所暴露的接口有soul网关代理，具体的搭建网关和soul-admin流程可以参考往期文章或者直接去soul官网测试soul网关代理和直连通过soul网关代理直连可以看到都能够获取到想要的结果，下面我们就看一下soul网关是怎样完成请求转发和响

soul网关源码分析之发布接口到网关目标Http API发布到soul网关源码分析Dubbo API发布到soul网关源码分析总结概述    业务系统在接口方法上加类似于@SoulSpringMvcClient``@SoulDubboClient注解，就能够将需要被soul网关代理的接口发布到soul-admin和soul网关，本篇文章主要分析soul网关是如何做到的自动发布API。Http API发布到soul网关源码分析pom依赖及yml配置 <

soul网关源码分析之soul-gateway缓存刷新目标soul-gateway本地缓存刷新总结概述    上篇讲了soul-admin与soul-gateway通过websocket的方式进行数据的同步，本篇将详细介绍soul-gateway如果将内存中的缓存刷新的。架构图    从架构图中能够看出，数据变更会通过pull模式或者push模式到soul-web模块，上篇文档提到了soul-web模块负责接收代理请求，各种filter，实际上sou

ActiveMQActiveMQ介绍ActiveMQ是Apache软件基金下的一个开源软件，它遵循JMS1.1规范（Java Message Service），是消息驱动中间件软件（MOM）。它为企业消息传递提供高可用，出色性能，可扩展，稳定和安全保障。ActiveMQ的消息传递模式P2P （点对点）消息域使用 queue 作为 Destination，消息可以被同步或异步的发送和接收，每个消息只会给一个 Consumer 传送一次。Pub/Sub（发布/订阅，Publish/Subscri

Soul网关源码分析之soul-admin与soul-gateway数据同步目标soul网关项目结构介绍soul-admin和soul网关数据同步总结soul网关项目结构从GitHub下载项目从soul网关的github仓库下载soul项目，你也可以fork到你的GitHub仓库git clone https://github.com/dromara/soul.gitsoul项目目录介绍soul-admin：soul网关管理后台服务，提供了插

Kafka消息中间件Kafka概念与入门什么是Kafka Kafka是一个消息系统，由LinkedIn于2011年设计开发，用作LinkedIn的活动流（ActivityStream）和运营数据处理管道（Pipeline）的基础。Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：1.以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。2.高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的出传输

Soul网关进阶使用目标dubbo集成Soul网关springcloud集成Soul网关总结Alibaba Dubbo + SpringBoot用户集成Soul网关Soul网关加入dubbo插件pom <!--soul alibaba dubbo plugin start--> <dependency> <groupId>org.dromara</groupId>

Soul网关初探目标Soul网关简介Soul网关特点Soul网关架构图本地搭建Soul网关环境使用Soul代理Http接口总结Soul网关简介   这是一个异步的,高性能的,跨语言的,响应式的API网关。我希望能够有一样东西像灵魂一样，保护您的微服务。参考了Kong，Spring-Cloud-Gateway等优秀的网关后，站在巨人的肩膀上，Soul由此诞生！Soul网关特点支持各种语言(http协议)，支持 dubbo，springcloud协议。插件