04 连接池:别让连接池帮了倒忙
你好,我是朱晔。今天,我们来聊聊使用连接池需要注意的问题。
在上一讲,我们学习了使用线程池需要注意的问题。今天,我再与你说说另一种很重要的池化技术,即连接池。
我先和你说说连接池的结构。连接池一般对外提供获得连接、归还连接的接口给客户端使用,并暴露最小空闲连接数、最大连接数等可配置参数,在内部则实现连接建立、连接心跳保持、连接管理、空闲连接回收、连接可用性检测等功能。连接池的结构示意图,如下所示:
业务项目中经常会用到的连接池,主要是数据库连接池、Redis连接池和HTTP连接池。所以,今天我就以这三种连接池为例,和你聊聊使用和配置连接池容易出错的地方。
注意鉴别客户端SDK是否基于连接池
在使用三方客户端进行网络通信时,我们首先要确定客户端SDK是否是基于连接池技术实现的。我们知道,TCP是面向连接的基于字节流的协议:
- 面向连接,意味着连接需要先创建再使用,创建连接的三次握手有一定开销;
- 基于字节流,意味着字节是发送数据的最小单元,TCP协议本身无法区分哪几个字节是完整的消息体,也无法感知是否有多个客户端在使用同一个TCP连接,TCP只是一个读写数据的管道。
如果客户端SDK没有使用连接池,而直接是TCP连接,那么就需要考虑每次建立TCP连接的开销,并且因为TCP基于字节流,在多线程的情况下对同一连接进行复用,可能会产生线程安全问题。
我们先看一下涉及TCP连接的客户端SDK,对外提供API的三种方式。在面对各种三方客户端的时候,只有先识别出其属于哪一种,才能理清楚使用方式。
- 连接池和连接分离的API:有一个XXXPool类负责连接池实现,先从其获得连接XXXConnection,然后用获得的连接进行服务端请求,完成后使用者需要归还连接。通常,XXXPool是线程安全的,可以并发获取和归还连接,而XXXConnection是非线程安全的。对应到连接池的结构示意图中,XXXPool就是右边连接池那个框,左边的客户端是我们自己的代码。
- 内部带有连接池的API:对外提供一个XXXClient类,通过这个类可以直接进行服务端请求;这个类内部维护了连接池,SDK使用者无需考虑连接的获取和归还问题。一般而言,XXXClient是线程安全的。对应到连接池的结构示意图中,整个API就是蓝色框包裹的部分。
- 非连接池的API:一般命名为XXXConnection,以区分其是基于连接池还是单连接的,而不建议命名为XXXClient或直接是XXX。直接连接方式的API基于单一连接,每次使用都需要创建和断开连接,性能一般,且通常不是线程安全的。对应到连接池的结构示意图中,这种形式相当于没有右边连接池那个框,客户端直接连接服务端创建连接。
虽然上面提到了SDK一般的命名习惯,但不排除有一些客户端特立独行,因此在使用三方SDK时,一定要先查看官方文档了解其最佳实践,或是在类似Stackoverflow的网站搜索XXX threadsafe/singleton字样看看大家的回复,也可以一层一层往下看源码,直到定位到原始Socket来判断Socket和客户端API的对应关系。
明确了SDK连接池的实现方式后,我们就大概知道了使用SDK的最佳实践:
- 如果是分离方式,那么连接池本身一般是线程安全的,可以复用。每次使用需要从连接池获取连接,使用后归还,归还的工作由使用者负责。
- 如果是内置连接池,SDK会负责连接的获取和归还,使用的时候直接复用客户端。
- 如果SDK没有实现连接池(大多数中间件、数据库的客户端SDK都会支持连接池),那通常不是线程安全的,而且短连接的方式性能不会很高,使用的时候需要考虑是否自己封装一个连接池。
接下来,我就以Java中用于操作Redis最常见的库Jedis为例,从源码角度分析下Jedis类到底属于哪种类型的API,直接在多线程环境下复用一个连接会产生什么问题,以及如何用最佳实践来修复这个问题。
首先,向Redis初始化2组数据,Key=a、Value=1,Key=b、Value=2:
@PostConstruct
public void init() {
try (Jedis jedis = new Jedis("127.0.0.1", 6379)) {
Assert.isTrue("OK".equals(jedis.set("a", "1")), "set a = 1 return OK");
Assert.isTrue("OK".equals(jedis.set("b", "2")), "set b = 2 return OK");
}
}
然后,启动两个线程,共享操作同一个Jedis实例,每一个线程循环1000次,分别读取Key为a和b的Value,判断是否分别为1和2:
Jedis jedis = new Jedis("127.0.0.1", 6379);
new Thread(() -> {
for (int i = 0; i < 1000; i++) {
String result = jedis.get("a");
if (!result.equals("1")) {
log.warn("Expect a to be 1 but found {}", result);
return;
}
}
}).start();
new Thread(() -> {
for (int i = 0; i < 1000; i++) {
String result = jedis.get("b");
if (!result.equals("2")) {
log.warn("Expect b to be 2 but found {}", result);
return;
}
}
}).start();
TimeUnit.SECONDS.sleep(5);
执行程序多次,可以看到日志中出现了各种奇怪的异常信息,有的是读取Key为b的Value读取到了1,有的是流非正常结束,还有的是连接关闭异常:
//错误1
[14:56:19.069] [Thread-28] [WARN ] [.t.c.c.redis.JedisMisreuseController:45 ] - Expect b to be 2 but found 1
//错误2
redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream.
at redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
at redis.clients.jedis.util.RedisInputStream.readLine(RedisInputStream.java:50)
at redis.clients.jedis.Protocol.processError(Protocol.java:114)
at redis.clients.jedis.Protocol.process(Protocol.java:166)
at redis.clients.jedis.Protocol.read(Protocol.java:220)
at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:318)
at redis.clients.jedis.Connection.getBinaryBulkReply(Connection.java:255)
at redis.clients.jedis.Connection.getBulkReply(Connection.java:245)
at redis.clients.jedis.Jedis.get(Jedis.java:181)
at org.geekbang.time.commonmistakes.connectionpool.redis.JedisMisreuseController.lambda$wrong$1(JedisMisreuseController.java:43)
at java.lang.Thread.run(Thread.java:748)
//错误3
java.io.IOException: Socket Closed
at java.net.AbstractPlainSocketImpl.getOutputStream(AbstractPlainSocketImpl.java:440)
at java.net.Socket$3.run(Socket.java:954)
at java.net.Socket$3.run(Socket.java:952)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.Socket.getOutputStream(Socket.java:951)
at redis.clients.jedis.Connection.connect(Connection.java:200)
... 7 more
让我们分析一下Jedis类的源码,搞清楚其中缘由吧。
public class Jedis extends BinaryJedis implements JedisCommands, MultiKeyCommands,
AdvancedJedisCommands, ScriptingCommands, BasicCommands, ClusterCommands, SentinelCommands, ModuleCommands {
}
public class BinaryJedis implements BasicCommands, BinaryJedisCommands, MultiKeyBinaryCommands,
AdvancedBinaryJedisCommands, BinaryScriptingCommands, Closeable {
protected Client client = null;
...
}
public class Client extends BinaryClient implements Commands {
}
public class BinaryClient extends Connection {
}
public class Connection implements Closeable {
private Socket socket;
private RedisOutputStream outputStream;
private RedisInputStream inputStream;
}
可以看到,Jedis继承了BinaryJedis,BinaryJedis中保存了单个Client的实例,Client最终继承了Connection,Connection中保存了单个Socket的实例,和Socket对应的两个读写流。因此,一个Jedis对应一个Socket连接。类图如下:
BinaryClient封装了各种Redis命令,其最终会调用基类Connection的方法,使用Protocol类发送命令。看一下Protocol类的sendCommand方法的源码,可以发现其发送命令时是直接操作RedisOutputStream写入字节。
我们在多线程环境下复用Jedis对象,其实就是在复用RedisOutputStream。如果多个线程在执行操作,那么既无法确保整条命令以一个原子操作写入Socket,也无法确保写入后、读取前没有其他数据写到远端:
private static void sendCommand(final RedisOutputStream os, final byte[] command,
final byte[]... args) {
try {
os.write(ASTERISK_BYTE);
os.writeIntCrLf(args.length + 1);
os.write(DOLLAR_BYTE);
os.writeIntCrLf(command.length);
os.write(command);
os.writeCrLf();
for (final byte[] arg : args) {
os.write(DOLLAR_BYTE);
os.writeIntCrLf(arg.length);
os.write(arg);
os.writeCrLf();
}
} catch (IOException e) {
throw new JedisConnectionException(e);
}
}
看到这里我们也可以理解了,为啥多线程情况下使用Jedis对象操作Redis会出现各种奇怪的问题。
比如,写操作互相干扰,多条命令相互穿插的话,必然不是合法的Redis命令,那么Redis会关闭客户端连接,导致连接断开;又比如,线程1和2先后写入了get a和get b操作的请求,Redis也返回了值1和2,但是线程2先读取了数据1就会出现数据错乱的问题。
修复方式是,使用Jedis提供的另一个线程安全的类JedisPool来获得Jedis的实例。JedisPool可以声明为static在多个线程之间共享,扮演连接池的角色。使用时,按需使用try-with-resources模式从JedisPool获得和归还Jedis实例。
private static JedisPool jedisPool = new JedisPool("127.0.0.1", 6379);
new Thread(() -> {
try (Jedis jedis = jedisPool.getResource()) {
for (int i = 0; i < 1000; i++) {
String result = jedis.get("a");
if (!result.equals("1")) {
log.warn("Expect a to be 1 but found {}", result);
return;
}
}
}
}).start();
new Thread(() -> {
try (Jedis jedis = jedisPool.getResource()) {
for (int i = 0; i < 1000; i++) {
String result = jedis.get("b");
if (!result.equals("2")) {
log.warn("Expect b to be 2 but found {}", result);
return;
}
}
}
}).start();
这样修复后,代码不再有线程安全问题了。此外,我们最好通过shutdownhook,在程序退出之前关闭JedisPool:
@PostConstruct
public void init() {
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
jedisPool.close();
}));
}
看一下Jedis类close方法的实现可以发现,如果Jedis是从连接池获取的话,那么close方法会调用连接池的return方法归还连接:
public class Jedis extends BinaryJedis implements JedisCommands, MultiKeyCommands,
AdvancedJedisCommands, ScriptingCommands, BasicCommands, ClusterCommands, SentinelCommands, ModuleCommands {
protected JedisPoolAbstract dataSource = null;
@Override
public void close() {
if (dataSource != null) {
JedisPoolAbstract pool = this.dataSource;
this.dataSource = null;
if (client.isBroken()) {
pool.returnBrokenResource(this);
} else {
pool.returnResource(this);
}
} else {
super.close();
}
}
}
如果不是,则直接关闭连接,其最终调用Connection类的disconnect方法来关闭TCP连接:
public void disconnect() {
if (isConnected()) {
try {
outputStream.flush();
socket.close();
} catch (IOException ex) {
broken = true;
throw new JedisConnectionException(ex);
} finally {
IOUtils.closeQuietly(socket);
}
}
}
可以看到,Jedis可以独立使用,也可以配合连接池使用,这个连接池就是JedisPool。我们再看看JedisPool的实现。
public class JedisPool extends JedisPoolAbstract {
@Override
public Jedis getResource() {
Jedis jedis = super.getResource();
jedis.setDataSource(this);
return jedis;
}
@Override
protected void returnResource(final Jedis resource) {
if (resource != null) {
try {
resource.resetState();
returnResourceObject(resource);
} catch (Exception e) {
returnBrokenResource(resource);
throw new JedisException("Resource is returned to the pool as broken", e);
}
}
}
}
public class JedisPoolAbstract extends Pool<Jedis> {
}
public abstract class Pool<T> implements Closeable {
protected GenericObjectPool<T> internalPool;
}
JedisPool的getResource方法在拿到Jedis对象后,将自己设置为了连接池。连接池JedisPool,继承了JedisPoolAbstract,而后者继承了抽象类Pool,Pool内部维护了Apache Common的通用池GenericObjectPool。JedisPool的连接池就是基于GenericObjectPool的。
看到这里我们了解了,Jedis的API实现是我们说的三种类型中的第一种,也就是连接池和连接分离的API,JedisPool是线程安全的连接池,Jedis是非线程安全的单一连接。知道了原理之后,我们再使用Jedis就胸有成竹了。
使用连接池务必确保复用
在介绍线程池的时候我们强调过,池一定是用来复用的,否则其使用代价会比每次创建单一对象更大。对连接池来说更是如此,原因如下:
- 创建连接池的时候很可能一次性创建了多个连接,大多数连接池考虑到性能,会在初始化的时候维护一定数量的最小连接(毕竟初始化连接池的过程一般是一次性的),可以直接使用。如果每次使用连接池都按需创建连接池,那么很可能你只用到一个连接,但是创建了N个连接。
- 连接池一般会有一些管理模块,也就是连接池的结构示意图中的绿色部分。举个例子,大多数的连接池都有闲置超时的概念。连接池会检测连接的闲置时间,定期回收闲置的连接,把活跃连接数降到最低(闲置)连接的配置值,减轻服务端的压力。一般情况下,闲置连接由独立线程管理,启动了空闲检测的连接池相当于还会启动一个线程。此外,有些连接池还需要独立线程负责连接保活等功能。因此,启动一个连接池相当于启动了N个线程。
除了使用代价,连接池不释放,还可能会引起线程泄露。接下来,我就以Apache HttpClient为例,和你说说连接池不复用的问题。
首先,创建一个CloseableHttpClient,设置使用PoolingHttpClientConnectionManager连接池并启用空闲连接驱逐策略,最大空闲时间为60秒,然后使用这个连接来请求一个会返回OK字符串的服务端接口:
@GetMapping("wrong1")
public String wrong1() {
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(new PoolingHttpClientConnectionManager())
.evictIdleConnections(60, TimeUnit.SECONDS).build();
try (CloseableHttpResponse response = client.execute(new HttpGet("http://127.0.0.1:45678/httpclientnotreuse/test"))) {
return EntityUtils.toString(response.getEntity());
} catch (Exception ex) {
ex.printStackTrace();
}
return null;
}
访问这个接口几次后查看应用线程情况,可以看到有大量叫作Connection evictor的线程,且这些线程不会销毁:
对这个接口进行几秒的压测(压测使用wrk,1个并发1个连接)可以看到,已经建立了三千多个TCP连接到45678端口(其中有1个是压测客户端到Tomcat的连接,大部分都是HttpClient到Tomcat的连接):
好在有了空闲连接回收的策略,60秒之后连接处于CLOSE_WAIT状态,最终彻底关闭。
这2点证明,CloseableHttpClient属于第二种模式,即内部带有连接池的API,其背后是连接池,最佳实践一定是复用。
复用方式很简单,你可以把CloseableHttpClient声明为static,只创建一次,并且在JVM关闭之前通过addShutdownHook钩子关闭连接池,在使用的时候直接使用CloseableHttpClient即可,无需每次都创建。
首先,定义一个right接口来实现服务端接口调用:
private static CloseableHttpClient httpClient = null;
static {
//当然,也可以把CloseableHttpClient定义为Bean,然后在@PreDestroy标记的方法内close这个HttpClient
httpClient = HttpClients.custom().setMaxConnPerRoute(1).setMaxConnTotal(1).evictIdleConnections(60, TimeUnit.SECONDS).build();
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
try {
httpClient.close();
} catch (IOException ignored) {
}
}));
}
@GetMapping("right")
public String right() {
try (CloseableHttpResponse response = httpClient.execute(new HttpGet("http://127.0.0.1:45678/httpclientnotreuse/test"))) {
return EntityUtils.toString(response.getEntity());
} catch (Exception ex) {
ex.printStackTrace();
}
return null;
}
然后,重新定义一个wrong2接口,修复之前按需创建CloseableHttpClient的代码,每次用完之后确保连接池可以关闭:
@GetMapping("wrong2")
public String wrong2() {
try (CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(new PoolingHttpClientConnectionManager())
.evictIdleConnections(60, TimeUnit.SECONDS).build();
CloseableHttpResponse response = client.execute(new HttpGet("http://127.0.0.1:45678/httpclientnotreuse/test"))) {
return EntityUtils.toString(response.getEntity());
} catch (Exception ex) {
ex.printStackTrace();
}
return null;
}
使用wrk对wrong2和right两个接口分别压测60秒,可以看到两种使用方式性能上的差异,每次创建连接池的QPS是337,而复用连接池的QPS是2022:
如此大的性能差异显然是因为TCP连接的复用。你可能注意到了,刚才定义连接池时,我将最大连接数设置为1。所以,复用连接池方式复用的始终应该是同一个连接,而新建连接池方式应该是每次都会创建新的TCP连接。
接下来,我们通过网络抓包工具Wireshark来证实这一点。
如果调用wrong2接口每次创建新的连接池来发起HTTP请求,从Wireshark可以看到,每次请求服务端45678的客户端端口都是新的。这里我发起了三次请求,程序通过HttpClient访问服务端45678的客户端端口号,分别是51677、51679和51681:
也就是说,每次都是新的TCP连接,放开HTTP这个过滤条件也可以看到完整的TCP握手、挥手的过程:
而复用连接池方式的接口right的表现就完全不同了。可以看到,第二次HTTP请求#41的客户端端口61468和第一次连接#23的端口是一样的,Wireshark也提示了整个TCP会话中,当前#41请求是第二次请求,前一次是#23,后面一次是#75:
只有TCP连接闲置超过60秒后才会断开,连接池会新建连接。你可以尝试通过Wireshark观察这一过程。
接下来,我们就继续聊聊连接池的配置问题。
连接池的配置不是一成不变的
为方便根据容量规划设置连接处的属性,连接池提供了许多参数,包括最小(闲置)连接、最大连接、闲置连接生存时间、连接生存时间等。其中,最重要的参数是最大连接数,它决定了连接池能使用的连接数量上限,达到上限后,新来的请求需要等待其他请求释放连接。
但,最大连接数不是设置得越大越好。如果设置得太大,不仅仅是客户端需要耗费过多的资源维护连接,更重要的是由于服务端对应的是多个客户端,每一个客户端都保持大量的连接,会给服务端带来更大的压力。这个压力又不仅仅是内存压力,可以想一下如果服务端的网络模型是一个TCP连接一个线程,那么几千个连接意味着几千个线程,如此多的线程会造成大量的线程切换开销。
当然,连接池最大连接数设置得太小,很可能会因为获取连接的等待时间太长,导致吞吐量低下,甚至超时无法获取连接。
接下来,我们就模拟下压力增大导致数据库连接池打满的情况,来实践下如何确认连接池的使用情况,以及有针对性地进行参数优化。
首先,定义一个用户注册方法,通过@Transactional注解为方法开启事务。其中包含了500毫秒的休眠,一个数据库事务对应一个TCP连接,所以500多毫秒的时间都会占用数据库连接:
@Transactional
public User register(){
User user=new User();
user.setName("new-user-"+System.currentTimeMillis());
userRepository.save(user);
try {
TimeUnit.MILLISECONDS.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
return user;
}
随后,修改配置文件启用register-mbeans,使Hikari连接池能通过JMX MBean注册连接池相关统计信息,方便观察连接池:
启动程序并通过JConsole连接进程后,可以看到默认情况下最大连接数为10:
使用wrk对应用进行压测,可以看到连接数一下子从0到了10,有20个线程在等待获取连接:
不久就出现了无法获取数据库连接的异常,如下所示:
[15:37:56.156] [http-nio-45678-exec-15] [ERROR] [.a.c.c.C.[.[.[/].[dispatcherServlet]:175 ] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.dao.DataAccessResourceFailureException: unable to obtain isolated JDBC connection; nested exception is org.hibernate.exception.JDBCConnectionException: unable to obtain isolated JDBC connection] with root cause
java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms.
从异常信息中可以看到,数据库连接池是HikariPool,解决方式很简单,修改一下配置文件,调整数据库连接池最大连接参数到50即可。
然后,再观察一下这个参数是否适合当前压力,满足需求的同时也不占用过多资源。从监控来看这个调整是合理的,有一半的富余资源,再也没有线程需要等待连接了:
在这个Demo里,我知道压测大概能对应使用25左右的并发连接,所以直接把连接池最大连接设置为了50。在真实情况下,只要数据库可以承受,你可以选择在遇到连接超限的时候先设置一个足够大的连接数,然后观察最终应用的并发,再按照实际并发数留出一半的余量来设置最终的最大连接。
其实,看到错误日志后再调整已经有点儿晚了。更合适的做法是,对类似数据库连接池的重要资源进行持续检测,并设置一半的使用量作为报警阈值,出现预警后及时扩容。
在这里我是为了演示,才通过JConsole查看参数配置后的效果,生产上需要把相关数据对接到指标监控体系中持续监测。
这里要强调的是,修改配置参数务必验证是否生效,并且在监控系统中确认参数是否生效、是否合理。之所以要“强调”,是因为这里有坑。
我之前就遇到过这样一个事故。应用准备针对大促活动进行扩容,把数据库配置文件中Druid连接池最大连接数maxActive从50提高到了100,修改后并没有通过监控验证,结果大促当天应用因为连接池连接数不够爆了。
经排查发现,当时修改的连接数并没有生效。原因是,应用虽然一开始使用的是Druid连接池,但后来框架升级了,把连接池替换为了Hikari实现,原来的那些配置其实都是无效的,修改后的参数配置当然也不会生效。
所以说,对连接池进行调参,一定要眼见为实。
重点回顾
今天,我以三种业务代码最常用的Redis连接池、HTTP连接池、数据库连接池为例,和你探讨了有关连接池实现方式、使用姿势和参数配置的三大问题。
客户端SDK实现连接池的方式,包括池和连接分离、内部带有连接池和非连接池三种。要正确使用连接池,就必须首先鉴别连接池的实现方式。比如,Jedis的API实现的是池和连接分离的方式,而Apache HttpClient是内置连接池的API。
对于使用姿势其实就是两点,一是确保连接池是复用的,二是尽可能在程序退出之前显式关闭连接池释放资源。连接池设计的初衷就是为了保持一定量的连接,这样连接可以随取随用。从连接池获取连接虽然很快,但连接池的初始化会比较慢,需要做一些管理模块的初始化以及初始最小闲置连接。一旦连接池不是复用的,那么其性能会比随时创建单一连接更差。
最后,连接池参数配置中,最重要的是最大连接数,许多高并发应用往往因为最大连接数不够导致性能问题。但,最大连接数不是设置得越大越好,够用就好。需要注意的是,针对数据库连接池、HTTP连接池、Redis连接池等重要连接池,务必建立完善的监控和报警机制,根据容量规划及时调整参数配置。
今天用到的代码,我都放在了GitHub上,你可以点击这个链接查看。
思考与讨论
- 有了连接池之后,获取连接是从连接池获取,没有足够连接时连接池会创建连接。这时,获取连接操作往往有两个超时时间:一个是从连接池获取连接的最长等待时间,通常叫作请求连接超时connectRequestTimeout或连接等待超时connectWaitTimeout;一个是连接池新建TCP连接三次握手的连接超时,通常叫作连接超时connectTimeout。针对JedisPool、Apache HttpClient和Hikari数据库连接池,你知道如何设置这2个参数吗?
- 对于带有连接池的SDK的使用姿势,最主要的是鉴别其内部是否实现了连接池,如果实现了连接池要尽量复用Client。对于NoSQL中的MongoDB来说,使用MongoDB Java驱动时,MongoClient类应该是每次都创建还是复用呢?你能否在官方文档中找到答案呢?
关于连接池,你还遇到过什么坑吗?我是朱晔,欢迎在评论区与我留言分享,也欢迎你把这篇文章分享给你的朋友或同事,一起交流。
- Darren 👍(69) 💬(5)
实操性比较强,收获满满!!! 自从spring boot 2.x版本后,有较大的改动: 默认的redis的链接池从JedisPool变成了LettucePool,Lettuce主要利用netty实现与redis的同步和异步通信。所以更安全和性能更好; 默认的数据库连接池也变更为HikariCP,HiKariCP 号称是业界跑得最快的数据库连接池,HiKariCP 官方网站解释了其性能之所以如此之高的秘密。微观上 HiKariCP 程序编译出的字节码执行效率更高,站在字节码的角度去优化 Java 代码,HiKariCP 的作者对性能的执着可见一斑,不过遗憾的是他并没有详细解释都做了哪些优化。而宏观上主要是和两个数据结构有关,一个是 FastList,另一个是 ConcurrentBag。 FastList是对Java List的增强,HiKariCP作者认为Java SDK的List在其使用场景下比较慢,因此在SDK提供的List(ArrayList的remove)的基础上做了增强; ConcurrentBag是对Java并发集合的增强, 通过 ThreadLocal 做一次预分配,避免直接竞争共享资源,非常适合池化资源的分配。 试着回答下课后的问题: 第一个问题: JedisPool的设置: 获取链接超时:maxWait TCP超时:JedisPool中有一个soTimeout的属性,在链接的时候,使用socket.setSoTimeout(soTimeout)控制的。 HikariCP的设置: 获取链接超时:connectionTimeout。 This property controls the maximum number of milliseconds that a client (that's you) will wait for a connection from the pool. If this time is exceeded without a connection becoming available, a SQLException will be thrown. Lowest acceptable connection timeout is 250ms. Default: 30000 (30 seconds) TCP超时:数据的库的wait_timeout属性吧 Apache HttpClient设置: 获取链接超时:connectionRequestTimeout 建立链接超时:connectionTimeout 等待响应超时:socketTimeout 第二个问题就不回答了,因为到目前为止,还没有在生产使用过Mongo,😂😂😂😂 上面有些参数感觉说的不对,请老师指点
2020-03-16 - 👽 👍(14) 💬(2)
个人总结: 1. 池化技术的核心在于,在鱼塘养好一群鱼,需要的时候就从里面拿一条,用完再放回去。而不是自己生产一条鱼,然后用完就销毁。从而减少了开销。 2. 大多已经实现的连接池,都是有线程安全处理的。通常比个人创建管理连接更加安全。 3. 使用了连接池技术,就要保证连接池能够被有效复用。频繁创建连接池比频繁创建链接更加耗费资源。 4. 连接池的参数配置要根据实际情况,并不存在多多益善 5. 连接池的主要好处:(1)减少资源消耗,(2)利用现有的线城安全实现,(3)提升并发量
2020-03-16 - Wiggle Wiggle 👍(38) 💬(1)
请问对于连接池的监控,是把监控系统直连JMX,监控、修改操作都走连接池已经实现好的JMX比较好?还是自己做一层封装,对外暴露接口,以编程方式获取、设置参数比较好?
2020-03-14 - 蚂蚁内推+v 👍(12) 💬(4)
退出程序前为什么要关闭连接池啊,程序都结束了连接不就释放了么
2020-03-14 - 每天晒白牙 👍(8) 💬(1)
干货满满,还需要慢慢消化一下
2020-03-14 - 👽 👍(6) 💬(3)
课后题2: 受限于本人英文水平,无奈与使用谷歌翻译阅读文档。从文档中得知,MongoClient 对象的正确使用姿势应该是:使用 MongoClients.create()(或者其他有参) 方法创建,并再整个应用程序中使用它。文档内容如下: MongoClient (从3.7版本开始) 一个MongoClient实例表示到数据库连接池; MongoClient即使有多个线程,您也只需要一个类的实例。 重要 通常,您只MongoClient为给定的MongoDB部署创建一个实例(例如独立实例,副本集或分片群集),并在整个应用程序中使用它。但是,如果您确实创建了多个实例: 所有资源使用限制(例如,最大连接数等)适用于每个MongoClient实例。 要处置实例,请致电MongoClient.close()以清理资源。
2020-03-16 - 👽 👍(5) 💬(3)
hikari具体配置项为application.yml 中 spring.datasource.hikari.connection-timeout 点进去可以发现是 HikariDataSource 类,继承了HikariConfig。 点进HikariConfig可看出 connectionTimeout不允许小于250毫秒,小于250ms会被强制重置为30秒。 参数connectionTimeout定义是并未赋初始值的原始类型long,初始值应该是0L; 所以,个人判断,默认的connectionTimeout数值就是30秒。 如有纰漏,欢迎指正
2020-03-16 - Husiun 👍(5) 💬(1)
每次更新都是第一时间打开,每一课都干货满满,必须给老师赞一个,http那个平时研究不多还需要好好消化一下。
2020-03-14 - justin 👍(4) 💬(2)
老师你好,看了这篇文章感觉收获满满,然后关于上面的CloseableHttpClient有个几个疑问: 1、复用同一个tcp连接的时候比每次都创建一个新的tcp连接的QPS高很多,当有大量http请求服务端时,每个http连接都共用同一个tcp连接时,这种情况下不会造成其中一些http请求的响应速度变慢吗。 2、 httpClient = HttpClients.custom().setMaxConnPerRoute(1).setMaxConnTotal(1).evictIdleConnections(60, TimeUnit.SECONDS).build(); 当我尝试去扩大setMaxConnTotal这个最大连接数时,qps反而降低了。如果线上有上千qps的话,设置连接数为1就可以了吗。
2020-03-26 - pedro 👍(4) 💬(2)
干货很多,收获很大。问老师一个问题,使用hook来关闭连接池的时候,都会创建一个线程,那如果有多个连接池,每个连接池都有一个线程来调用hook,这样做是否有点奢侈,有没有更优的办法?
2020-03-14 - boyxie 👍(3) 💬(3)
数据库连接池Druid 在数据库连接被网络中断后,需要15分钟的重连时间,这个超时时间为什么要这么久?总结网上的资料大致是获取连接的时候会去 testConnectionInternal,由于底层socket被断开,会一直被阻塞直到抛异常,老师可以帮忙分析一下吗?
2020-04-06 - 👽 👍(3) 💬(1)
课后题1: Hikari 可以再Spring的配置文件中配置各项参数。
2020-03-16 - Outside 👍(2) 💬(1)
请教一下老师,执行完 wrong2之后, client.execute阻塞住了是什么原因 线程dump如下 client.execute "http-nio-8088-exec-1" #28 daemon prio=5 os_prio=31 tid=0x00007fecb09d2000 nid=0x9a03 runnable [0x000070000d121000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.conn.LoggingInputStream.read(LoggingInputStream.java:84) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) 尝试用新启一个webserver, 用client.execute执行这个新的get请求,可以得到返回 这是什么原因呢
2020-06-09 - DZZ 👍(2) 💬(2)
如果一个应用里使用了多个mongo库,那么是否应该创建多个mongoclient去对应每一个库的使用? 举个例子:1个应用需要连接3个不同mongo库,那么该如何正确去使用mongoclient呢
2020-04-05 - z小俊、Arno 👍(2) 💬(2)
老师,说一个与本节无关的问题哈,你的git代码里面这一行,我不明白它的含义。。 <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>org.geekbang.time.commonmistakes.troubleshootingtools.jdktool.CommonMistakesApplication </mainClass> </configuration> </plugin> </plugins> 这儿的 : <mainClass>org.geekbang.time.commonmistakes.troubleshootingtools.jdktool.CommonMistakesApplication </mainClass> 有什么作用啊?
2020-03-27