使用数据库的时候普通会使用连接池，为什么调用 REST API 的时候不去弄一个连接池呢？
final0pro · 2019-08-22 06:48:04 +08:00 · 4420 次点击这是一个创建于 1919 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据库建立连接和断开连接比较费时，所以不如一直保持连接 active 的状态。
那为什么程序要调用其他 REST API 的时候，也不去弄一个连接池呢？感觉一点都不普遍。
那为什么程序要调用其他 REST API 的时候，也不去弄一个连接池呢？感觉一点都不普遍。
 |
1
weakish 2019-08-22 07:16:02 +08:00
有啊，http 1.0 就有 keep-alive 了。
不普遍是因为很多场景下没有必要一直保持连接 active，比如论坛，把帖子、回复内容取下来慢慢看，这时候没有必要保持连接。 像 IM、游戏、协同文档这样的场景，用 websocket 保持长连接很普遍。 |
 |
2
liuzhaowei55 2019-08-22 07:17:42 +08:00 via Android
一般 C 端程序没有那么大的请求量，所以不是很必要。
另外我们不是已经有 socket 了么，算是全双工连接池？ |
 |
3
chinvo 2019-08-22 07:34:45 +08:00 via iPhone
如果的 API 只用提供给应用程序、app 等使用，那么可以做成 tcp/udp 的
如果提供给浏览器使用，交互不频繁、数据量不大的情况下没必要 当然浏览器端也可以用 keep-alive、ws 等技术 |
 |
4
Joey404 2019-08-22 09:12:04 +08:00
很同意 @weakish 说的，因为很多 C 端除了少数几个领域（除了提及的，像股票，等等，高频变动的东西），都是一次性拿完，比如看帖子啊，之类的，其实并不需要保持这个连接池来保持，而如果有这种高频变动的需求，或者说有应用里面一小部分的东西要保持实时（比如知乎的 赞 功能），也有 websocket 这个方案了。
|
 |
5
index90 2019-08-22 09:18:57 +08:00 via iPhone
数据库 client 是有限可控的，http 服务大部分情况下，client 数量是庞大的，如果滥用长连接，连接会被用完。
|
 |
6
raven64 2019-08-22 09:19:57 +08:00
有的，比如使用 okhttp 库的时候，假如每发一次请求就实例化一个 httpclient，就会出现大量 time_wait 的连接
参考：github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/internal/connection/RealConnectionPool.kt |
 |
7
Aresxue 2019-08-22 09:45:14 +08:00
1.是有 http 连接池，适用于那种频繁和外界进行 http 接口交互的场景，但不是太多，因为 http 交互是真的慢；
2.除了连接池，http 庞杂的消息头中有一个 Connection，1.1 默认使用 keep-alive 即可保持长连接； |
 |
8
LeeSeoung 2019-08-22 09:54:40 +08:00
用数据库连接池你也怕客户端建立太多连接把数据库的可用连接占光了，这还是可控的，要是 http 服务下，用连接池可能很快也能把服务打爆。。盲猜一下 两者的资源占用 性能要求不一样。如果真需要长连接 为什么不用 websocket 呢
|
 |
9
wzwwzw 2019-08-22 12:42:42 +08:00
http client 数量一般是庞大的，如果为了保持连接，不如用 ws。
|
 |
10
reus 2019-08-22 13:19:54 +08:00
谁说没有。
|
 |
11
razertory 2019-08-22 13:20:43 +08:00
池化资源是为了限制最大资源开销和减少不必要的资源创建和回收，我认为一旦有申请资源-创建资源-回收资源的场景，考虑池化都是可以的。
|
 |
12
daveze 2019-08-22 13:45:19 +08:00 via iPhone
不知道 http2 能否解答你的疑问，有个特性是多路复用，一个网站的全部请求都只建立一个 tcp 连接
|
 |
13
pubby 2019-08-22 13:57:18 +08:00 via Android
http 库已经帮你做了啊，curl，go 的 net/http 都有连接复用
|
 |
14
winglight2016 2019-08-22 17:34:27 +08:00
前面是不是都理解错了 lz 问的问题了？ lz 的场景可能是需要和第三方集成的时候，对方提供了 RESTful API，而 lz 自己的程序需要多处调用，所以这种接口风格相比内部调用略显繁琐。
第三方选择 RESTful 作为对外接口，通常都是有自己的业务和技术方面考虑的。如果是对外服务的，独立 API 方便统计 /计费 /分布式等等，如果是内部系统互相访问，也会有相同的考量，还有支持微服务、异构系统等等。 至于这种 API 是否支持连接池，那基本上不是同一个维度的问题，连接池解决的是进程内的资源优化，进程间的协议，可选项并不多，也没有连接池的应用场景。 |
 |
15
passerbytiny 2019-08-22 17:46:29 +08:00
表现层状态转换（英语：Representational State Transfer，缩写：REST ）是 Roy Thomas Fielding 博士于 2000 年在他的博士论文[1]中提出来的一种万维网软件架构风格，目的是便于不同软件 /程序在网络（例如互联网）中互相传递信息。表现层状态转换是
<<<<<根基于超文本传输协议(HTTP)之上>>>>> 而确定的一组约束和属性，是一种设计提供万维网络服务的软件构建风格。符合或兼容于这种架构风格(简称为 REST 或 RESTful)的网络服务，允许客户端发出以统一资源标识符访问和操作网络资源的请求，而与预先定义好的无状态操作集一致化。 ——来自百科 没人限制你不能使用连接池，但你弄了连接池之后就基本不符合 HTTP 规范了，从而也不再叫做 RESTful。 数据库连接（性能优先、SQL 标准）与分布式 API （逻辑优先、应用标准）是八竿子打不到一块的东西，不要随便联想。 |
 |
16
final0pro OP 谢谢大家！
总结一下： 1. http client 连接池是有的，可以去使用 2. 或者，http 请求设置 keep-alive 去保持长链接，减少 tcp 握手和断开的开销 3. 或者，使用 websocket 来进行实时通讯 3. 以上三者适用于 需要对 third party RESTful API 频繁地进行通信 的情景 4. http client 连接池可以控制对 third party RESTful API 请求的数量，从而保证不给第三方服务很大压力（个人感觉，这个应该可以由第三方来控制吧？） 先前没有表述清楚问题。 只是个人写了几年后端，发现大多数数据库连接池都是标配（无一例外），但是从来没见过 http 连接池。自己很理所当然地觉得数据库连接和 http 连接像是一类连接，都是对外部资源的请求和调用。所以会有疑问为什么没见过 http 连接池。可能数据量真的不大吧。 如今前后端分离，微服务涌现。感觉都很依赖 http 连接 :facepalm |
 |
17
Ehco1996 2019-08-23 08:19:16 +08:00  1
微服务架构下对于 http 请求还是有链接池的
只不过不是从客户端到你的服务端，而是在 gateway 到你的服务端那一层 原因楼上的老哥们说的很清楚了，主要是一个 server 只负责对接几个负载均衡所以可以上链接池做复用 而网管外面可以大把连一把就跑的奇奇怪怪的 client |
Select Language