线程池连接数设置多少合适？

PostgreSQL 提供的适用于大多数数据库的公式：

连接数 =  核心数*2 + 有效磁盘数

有效磁盘数 = 0（热点数据全部被缓存） /  1 *实际磁盘数（缓存命中率降低 有效磁盘数接近真实的磁盘数）

适用于机械硬盘 实际的连接池大小还是根据业务，可能会有长事务，短事务，不能只根据公式；

---

在一核cpu上运行一个线程顺序执行AB，和开启俩个线程并发执行AB哪个更快？

       如果线程执行过程中不存在阻塞，单线程更快；如果线程存在大量的阻塞等待，则并发执行要快；因为前者的优势是减少线程切换过程中的消耗（保存切换前线程状态，加载重新切回的线程状态）；后者的优势是在阻塞的过程中提升cpu利用率。

为什么连接池大小不是越多越好？

      连接池数目超过上面公式的个数后，性能呈下降趋势；因为cpu物理核心就这么多，逻辑核心再多，实际使用还是这么多；只会增加cpu切换线程上下文的时间消耗；（因为线程数目多，cpu分片时间就会变短，就会出现频繁切换概率变大）

 

并发请求访问数据库瓶颈：

CPU   磁盘IO  网络IO

CPU ：在尽可能减少上下文切换带来的消耗时，又要着手提高cpu利用率

       问题：提高利用率肯定是使用多增加线程；减少上下文切换肯定是减少线程数目；就好像是cpu做有用功和无用功一样；要找到一个平衡点；

磁盘IO：如果使用机械硬盘，那么要考虑旋转耗时和寻址耗时，因为同一时刻读/写磁头只能出现在一个位置，为了尽快完成寻址，读出或写入数据；可以增加机械硬盘转速；（固态硬盘不存在这种问题）

因此如果采用SSD，其实连接数应该设置的更少，因为IO阻塞更少。就像nginx只采用四个进程却能保证高性能和承载高并发，因为它的IO是异步非阻塞的多路复用IO；

网络IO：通过以太网口读写数据会有阻塞，可以考虑增大网络带宽；

 

---

Nginx如何承载高并发？（5w 左右的 TPS）

异步事件驱动：当遇到需要阻塞的地方，往上游upstream注册事件：当你处理好返回结果通知我；于是就可以继续做其他事情了；因此nginx不同于apache的httpd（同一时刻只能处理一个请求），nginx同一时刻可以处理的请求只会收到内存限制；

一个master和多个worker模式，master负责分发和监控，保证高可靠；worker使用进程而非线程：因为进程之间独享资源，不存在上下文切换；

nginx反向代理：正向代理代理客户端，反向代理代理服务器；通过分发让某个服务器处理请求，客户端不清楚哪个服务器处理的请求；