vlambda博客
学习文章列表

为什么要使用连接池？它有什么优点？

这个问题你真的能回答到点子上了吗？

据我所知，有不少人仅仅只是听说连接池好，就说好。至于问他连接池哪里好，他只能给你说连接复用啊，不用重复创建连接啊这种。但是看完这篇文章，你可以在别人问你连接池为什么好的时候，把这篇文章链接甩给他，不要再问我连接池怎么好了可以么？

下文以redis连接池作为案例，一步一步进行分析。

简单的redis连接操作

分析之前，先贴上一段redis的连接代码

func do() { rds, err := redis.Dial("tcp", "127.0.0.1:6379") if err != nil { panic(err.Error()) } defer rds.Close() key := random.String(10) _, _ = rds.Do("set", key, time.Now().UnixNano()) rly, err := rds.Do("get", key) _, _ = rds.Do("del", key) if err != nil { panic(err.Error()) } s, _ := redis.String(rly, err) fmt.Println(s)}

从代码上可以看出，代码连接到redis后设置一个kv，获取kv内容，然后删除这个key，最后他还关闭了这个连接。而能够完成这一整套操作，则归功于redis.Dial("tcp", "127.0.0.1:6379")建立了一个tcp连接。在tcp连接后，进行了数据传输，所以才能完成设置key的内容，获取key的内容，删除这个key一系列操作。

现在看来，代码并没有什么地方存在问题。这是一个连接的创建，使用，关闭非常标准的流程。现在，我们可以通过代码去操作redis了。

但是，如果我作为一个在线服务，每秒需要承受10000个用户的请求。每一个请求，我都要重复上面的操作，建立tcp连接，通过tcp连接传输我需要的操作，然后我要关闭tcp连接。这看上去像是在做重复的工作，并且当10000个用户同时进入，建立了10000个tcp连接，redis服务器是否可以支撑这么多的连接，也需要注意一下。

实现一个redis连接的单例

经过观察可以发现，发送N次数据这个我们是无法掌握的，根据业务他需要发送各种数据。但是连接和关闭这两个动作是一直在重复执行的，每一次的连接，我们都需要经过7次握手（3次握手连接，4次握手关闭）【1】。

我们需要想办法把创建和关闭连接的握手次数减少

在设计模式中有一个非常简单的设计模式“单例”。它可以重复使用已经实例化好的对象，这似乎可以满足我们不重复干一件事情的需求。

那我们来调整一下代码

var instance sync.Oncevar redisSingleton redis.Conn
func do() { rds := getInstance() key := random.String(10) _, _ = rds.Do("set", key, time.Now().UnixNano()) rly, err := rds.Do("get", key) _, _ = rds.Do("del", key) if err != nil { panic(err.Error()) } s, _ := redis.String(rly, err) fmt.Println(s)}
func getInstance() redis.Conn { instance.Do(func() { var err error redisSingleton, err = redis.Dial("tcp", "127.0.0.1:6379") if err != nil { panic(err.Error()) } }) return redisSingleton}

通过sync.Once来实现一个单例，似乎让上面重复的操作得到缓解。并且，因为单例的限制，连接到redis服务器的连接数始终不会超过单例的个数。

但是，这个时候1000个用户涌进来了。单例在tcp数据交换，到redis服务器响应，到完成操作这个过程需要耗时3ms。1000个用户进来后，处理掉这1000个用户的请求，起码要花掉3秒钟。后面处理的用户显然是可以感受到延迟很长。

该如何提升1000个用户同时请求的响应能力？

处理单例排队时间过长的问题

单例是在使用连接之前就准备好了这个连接，等待被调用，使一个连接可以被重复使用。那我们提前创建N个连接，等待被调用，是不是这个处理能力就可以达到N倍了呢？我们来做个小学数学题。

单例：1000 / 1 * 3 = 3000 ms

连接池：1000 / N * 3 = 3000 / N ms

从数学上看去，这个N越大，响应能力越强，好像挺不错。（N可以多大？太大redis能不能扛住？)

设计一个连接池

理论上连接池很美，那我们来设计一个。

1. 首先连接池要可以控制住数量，不能随着请求数增多无限制地扩张，否则数据服务器肯定会被打崩
2. 提前生成好连接，放入池中
3. 要让拿不到连接的请求等待，避免在连接数可调配的情况下出现请求数据操作失败的情况
4. 连接可回收，反复使用资源

根据上面的需求确定了一下接口

type Interface interface { Factory() interface{} // 用于创建连接 Get() (interface{}, error) // 获取一个连接 Release(interface{}) // 释放一个连接 ForceCloseAll() // 强制关闭所有连接}

实现这些接口后，我们可以让请求从池子中拿到连接后进行redis操作，操作完成后释放这个连接，让它重新回到池子中等待被下一次使用。

实测结果

总结

从上面的分析来看，可以得到以下结论：

1. 普通连接可以保证每一次请求的连接是可用的，但耗时过长，请求量过大，对redis的压力很大
2. 单例连接可以有效解决连接过程重复的问题，但是会使请求进入串行化，并且长时间使用一个连接无法保证连接存活
3. 连接池可以解决单例的串行化问题，提升请求响应能力，控制连接数，避免redis服务器连接数过多，但是与单例存在相同的问题，长时间使用连接无法保证连接存活

下一篇需要处理连接池的问题

1. 确认程序与redis的连接是否有时间限制
2. 如果有时间限制，超时了如何处理
3. redis重启了，连接不可用如何处理
4. 如何确认连接是否存活

引用：

【1】TCP 的特性（https://hit-alibaba.github.io/interview/basic/network/TCP.html）

【2】文章相关代码 （https://github.com/jinfeijie/blog-demo/tree/master/post-835）

下一篇还在撰写中，期待