赖小明

问题描述

在最近开发过程中，遇到了一个让人疑惑的问题，现有一个 Controller ，有且只有一个私有方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@RestController
@RequestMapping("/test")
@Api(tags = "测试")
public class TestPubController {

    @Resource
    private TestService testService;

    @GetMapping("/pri")
    @ApiOperation(value = "测试私有方法")
    private String testPrivate() {
        System.out.println("private");
        testService.say();
        return "private";
    }
}

前言

在微服务架构中，服务注册和发现是核心组件之一，而 Nacos 能作为目前主流的注册中心，不仅仅是因为其功能特性、开源、成熟度等，更重要的是它在可用性方面所作的保障，确保了系统能在复杂的场景下稳定运行。本文就 Nacos 在客户端实现的一系列高可用机制，并结合相关源码一起学习下。

前言

数据库连接池是在项目开发中广泛应用的一项技术，它用于分配、管理、释放数据库连接，允许应用程序复用现有的数据库连接，而不是重新建立一个。

为什么使用数据库连接池呢？首先数据库连接的建立是一种耗时长、性能低、代价高的一个操作，频繁地建立和关闭连接会影响系统的性能，特别是高并发的情况下。另外，数据库同时支持的连接总数也是有限的，而连接池的出现则很好地避免了以上问题。

HikariCP数据库连接池是号称性能最好的一个连接池，也是Spring Boot 2.0 选择的默认数据库连接池，“快速、轻量、可靠”是其显著的特点。

本文结合 HikariCP 数据库连接池的源码，一起来学习下。

前言

在微服务架构中，能快速更新和迭代是其最大的特点之一，而在重启或更新的过程中，为了确保现有请求的完整性以及最小化对业务的影响，“优雅关闭”就显得十分重要了。

本文将结合源码一起来学习下在 Dubbo 中，“优雅关闭”是如何实现的。

前言

在 Dubbo 中，默认协议使用单一长连接进行通信，这可以避免每次调用都新建 TCP 连接，从而降低延迟、提高调用的响应速度，但长连接的稳定性受环境、服务端等影响可能会断开，所以如何及时检测连接是否可用并进行重连（保活），对于通信框架而言是非常重要的话题。

前言

在前面我们学习到 Kafka 生产者在发送时，消息会先流入到消息收集器 RecordAccumulator，随后再由另外的线程—— Sender 线程将累积的消息发往 Kafka 服务端。本篇文章一起学习下 Sender 线程的工作流程。

Sender 线程的启动可以在 KafkaProducer 的构造函数中找到：

1
2
3
4
5
6

//...
this.sender = newSender(logContext, kafkaClient, this.metadata);
String ioThreadName = NETWORK_THREAD_PREFIX + " | " + clientId;
this.ioThread = new KafkaThread(ioThreadName, this.sender, true);
this.ioThread.start();
//...

前言

前面我们提到，当通过 KafkaProducer#send 方法发送消息时，消息会先被写入到消息收集器—— RecordAccumulator 中缓存，当缓存的消息满足一定的条件后，将由 Sender 线程获取批量消息并将其发往 Kafka ，这样的好处是能够减少网络请求的次数，从而提升网络吞量。本篇文章一起来学习下 RecordAccumulator 的内部实现。

我们都知道，在使用 Kakfa 客户端发送消息时，只需要指定主题和消息的内容，再调用发送方法即可。那发送方法中具体包含了哪些逻辑呢，本文结合源码一起来看下。

1
2
3
4

// 构建消息
ProducerRecord<String, String> record = new ProducerRecord<>(topic, "value");
// 发送
producer.send(record);

前言

在使用 Dubbo 进行服务间的调用时，如果 Provider 服务端抛出了特定异常，但在 Consumer 调用端可能拿到的并不是我们预期的异常类型，那Dubbo 对于服务端的异常是如何处理的呢？如果我们希望在调用端也能获取到对应的异常信息，可以怎么做呢？本文一起来看下。

问题的出现和定位

测试环境中，有测试同学反馈说接口请求慢，超时了也没有数据返回。

首先从测试同学那里了解到具体慢的接口，排查了对应的服务的状态，确定了服务的状态是正常在线的。

进入该服务对应的容器内，用 jstat -gctil 命令查看了服务进程的 GC 情况，发现不管是内存占用，或是 GC 的频率和时间占比，都不高。

然后又通过 top 看了下 CPU 的使用率，发现服务的进程整体使用率到了 90% 以上，随即通过 top -Hp 1 指定进程，定位到了占用的的具体线程id是 196：