背景
-
背景&北京
-
腐朽大本营
-
无数次喷了，脑瘫甲方会毁了一切该有的流程评审
-
赶鸭子上架的推广期：暴雷maxActive导致的acquire不到连接，连接超了
分析下吧
- 我们每个人刚毕业都背过八股文
Druid连接池是监控赋能的xxxxx…………maxActive参数是最大连接池数量
- 但是如果没有对应的场景实践，只背八股文就到此为止了。
此次问题我们想的是，什么会占用/申请一个连接呢？
不要去想什么多线程复用，本质上的线性执行的，每个核心
易得DB连接是必然和线程绑定的，然后如果不开启事务各类线程池都可以做select复用优化。
这里可以挖坑了，数据库连接池，是怎么判断可不可以borrow的呢，他们的设计模式/实现方式的可取处学习
那就可以有个总结：
1、没做好的：应用需要评估 独占连接的事务业务接口，和，可共享连接的只读业务接口的比例；并需要评估使用用户对于不同接口的使用比例/频率/峰值。
以综合评估数据库连接池参数配置！
并和数据库供应方沟通确定性能如何承载，如分布式常见的CN数量/负载。
为什么没做好1：看背景，他们甚至连需求都是摇摆的讨好上级是一切，模型根本不确定
为什么没做好2：形式主义，数据库容量评估、性能评估都是时间倒反的，没法先知评估。
是什么决定的线程量
现在没评估接口量、不同接口类型的比例/峰值。
但可以先不考虑，只考虑线程量导致的最大连接需求可能是多少，视作全是需要独占连接的DMLSQl的业务。
那就是土味tomcat连接数了
tomcat配置参数与硬件又是坑，一般来说这样默认就可以了，1C2G的主机，1核抗200线程（tomcat默认maxThreads最大并发处理），如果一直满载每1秒都吃200请求，业务最好耗时5ms内，剩下时间让出cpu去做db或其它io
再深些说就要评估cpu频率和一个业务接口调用涉及的指令数了，差不多得了，现在云云云加机器就完事了。 真有极限场景，那单独服务化大批部署且代码上极限缩减cost了。
至于JVM怎么知道你在io然后让出cpu，那必然有机制，但有些太发散或者八股了，底层的C怎么实现的了。可以之后水一水
server:
tomcat:
accept-count: 100
max-threads: 200
max-connections: 8192
最大8192连接，另外2个是排队执行和执行线程数
BIO/NIO八股文多路复用，是（网络）连接这一层的，和JAVA线程执行不是一回事，要独立看待
一般来说吧，业务接口都是要走数据库的，考虑到缓存那还行，8192打个100对折才是真实需要的数据库连接数，差不多maxActive给个100就顶天了，实际可能需求/不得不配置的更低，因为数据库CN节点可能扛不住压。 ···记得考虑冷启动的问题，别被击穿咯，不过平台都有配置流控的能力，好办···
但业务模型毕竟不确定，无法根据DB占用/业务逻辑占比估算对应核心数的容器最大处理多少请求并发，只能等准生产找运维统计峰值调用数据来调流量限制和maxActive了。
做完了自己的事，对端数据库呢？
这个分布式厂商，唉，美国，都是关系户。
他们的CN性能不太行，比不过几年前的AntDB，还要拉会找他们评CN承载的需求条件。。。。。麻烦死了8886
总结
- 尽量提前评估各类资源/并发/用户模型，如果前置需求/设计没法做也就是其实没法评估，一定要把利害锅甩清楚咯。
- 尤其是罪恶之源局方别想脱干系，邮件都给他留好，会议纪要必须要求我方也有一份
