Palette

DefaultMQPushConsumer 核心参数与工作原理Push模型消息拉取机制 其核心关键点如下： 经过队列负载机制后，会分配给当前消费者一些队列，注意一个消费组可以订阅多个主题，正如上面 pullRequestQueue 中所示，topic_test、topic_test1 这两个主题都分配了一个队列。 轮流从 pullRequestQueue 中取出一个 PullRequest 对象，根据该对象中的拉取偏移量向 Broker 发起拉取请求，默认拉取 32 条，可通过上文中提到的 pullBatchSize 参数进行改变，该方法不仅会返回消息列表，还会返更改 PullRequest 对象中的下一次拉取的偏移量。 接收到 Broker 返回的消息后，会首先放入 ProccessQueue（处理队列），该队列的内部结构为 TreeMap，key 存放的是消息在消息消费队列（consumequeue）中的偏移量，而 value 为具体的消息对象。 然后将拉取到的消息提交到消费组内部的线程池，并立即返回，并将 PullRequest 对象放入到 pullRequestQueue 中 ...

1 问题背景线上环境和测试环境均发现过应用卡死，频繁Full GC，原因是因为Metaspace空间（JVM参数为-XX:MaxMetaspaceSize为256m）不足导致OOM，一段时间后服务自动重启，重启后服务正常。因为有配置OOM dump文件生成记录，所以获取到了当时OOM dump文件。 项目频繁发生metaspace溢出，基于相关知识毫不犹豫的想到以下几点 项目中使用过多反射 项目中使用过多的动态代理技术 项目中使用过多的lambda 2 问题分析2.1 OOM dump文件分析从MAT Leak Suspects分析来看： 不存在占用内存大的对象。 整体看下来无明显异常情况。 2.2 结合资料分析Metaspace空间使用 Metaspace 空间通过 mmap 来从操作系统申请内存，申请的内存会分成一个一个 Metachunk，以 Metachunk 为单位将内存分配给类加载器，每个 Metachunk 对应唯一一个类加载器，一个类加载器可以有多个 Metachunk。 通过监控可以发现，Metaspace空间使用率为：87%。可能的原因是给类加载器分配的 ...

Arthas 简介Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。 当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ 有什么办法可以监控到 JVM 的实时运行状态？ 怎么快速定位应用的热点，生成火焰图？ 怎样直接从 JVM 内查找某个类的实例？ 常见的故障问题排查案例启动arthas一般线上已经部署了arthas，可以直接用该命令启动 12curl -O https://arthas.aliyun.com/arthas-boot.jarjava -ja ...

初识NettyNetty 是一个 NIO 客户端服务器框架，可快速轻松地开发网络应用程序，例如协议服务器和客户端。有了Netty，你可以实现自己的HTTP服务器，FTP服务器，UDP服务器，RPC服务器，WebSocket服务器，Redis的Proxy服务器，MySQL的Proxy服务器等等。 Netty 的 I/O 模型是基于非阻塞 I/O 实现的，底层依赖的是 JDK NIO 框架的多路复用器 Selector。一个多路复用器 Selector 可以同时轮询多个 Channel，采用 epoll 模式后，只需要一个线程负责 Selector 的轮询，就可以接入成千上万的客户端。 Netty 所采用的主从 Reactor 多线程模型，所有的 I/O 事件都注册到一个 I/O 多路复用器上，当有 I/O 事件准备就绪后，I/O 多路复用器会将该 I/O 事件通过事件分发器分发到对应的事件处理器中。该线程模型避免了同步问题以及多线程切换带来的资源开销，真正做到高性能、低延迟。 NIO的特点： 一个线程可以处理多个 ...

幂等性保证对于非幂等的请求，我们在业务里要做幂等性保证。 在消息队列中的幂等性体现消息队列中，很可能一条消息被冗余部署的多个消费者收到，对于非幂等的操作，比如用户的注册，就需要做幂等性保证，否则消息将会被重复消费。可以将情况概括为以下几种: 生产者重复发送：由于网络抖动，导致生产者没有收到broker的ack而再次重发消息，实际上broker收到了多条重复的消息，造成消息重复 消费者重复消费：由于网络抖动，消费者没有返回ack给broker，导致消费者重试消费。 rebalance时的重复消费:由于网络抖动，在rebalance重分配时也可能出现消费者重复消费某条消息。 如何保证幂等性消费 mysql插入业务id作为主键，主键是唯一的，所以一次只能插入一条 使用redis或zk的分布式锁(主流的方案) 添加业务性的判断，过滤掉已修改状态的数据 消息顺序消费为什么要保证消息有序比如有这么一个物联网的应用场景，IOT中的设备在初始化时需要按顺序接收这样的消息: 设置设备名称 设置设备的网络 重启设备使配置生效 如果这个顺序颠倒了，可能就没有办法让设备的配置生效，因为只有重启 ...

一键解标功能需求分析需求说明： 1.明月AI标讯平台导航栏新增菜单“招标解读” 2.用户上传招标文件（<150页，且<10万字），文件类型限制为（docx、doc、pdf），上传完成AI输出招标文件分析结果（关键指标），每条分析结果支持反向定位到原始依据页面 3.新增招标解读Agent，后端调用该Agent获取招标文件的分析结果 4.新增招标解读历史记录模块，支持用户查询自己历史解读的标讯结果 最终产品效果图： 表设计招标文件解析表1234567891011121314CREATE TABLE `func_bid_doc_analysis` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键', `file_name` varchar(255) DEFAULT NULL COMMENT '招标文件名称', `file_url` varchar(2000) DEFAULT '' COMMENT '招标文件url', `original_ ...