Java开发手册！查看mysql连接数命令

开篇闲扯

打工人，打工魂，我们生而人上人。当“资本主义”逐渐禁锢我们人（大）上（韭）人（菜）肉体的时候，那一刻我才明白那个日不落帝国·资本主义收割机·瑞民族之光幸·瑞幸咖啡是多么的了不起，尽管我不懂咖啡，但还是要说一声谢谢！说到咖啡，喝完就想上厕所，对写bug的我来说太不友好了，毕竟我不（很）喜欢带薪上厕所。

回归本次的不正经Java文章。上篇文章末尾处已经提到了，主要会把我对Synchronized的理解进行一次全方位的梳理，如果能帮助到大家吊打面试官，万分荣幸。

ES 集群架构演进之路

1、初始阶段

订单中心ES初始阶段如一张白纸，架设方案基本没有，很多配置都是保持集群默认配置。整个集群部署在集团的弹性云上，ES集群的节点以及机器部署都比较混乱。同时按照集群维度来看，一个ES集群会有单点问题，显然对于订单中心业务来说也是不被允许的。

2、集群隔离阶段

和很多业务一样，ES集群采用的混布的方式。但由于订单中心ES存储的是线上订单数据，偶尔会发生混布集群抢占系统大量资源，导致整个订单中心ES服务异常。

显然任何影响到订单查询稳定性的情况都是无法容忍的，所以针对于这个情况，先是对订单中心ES所在的弹性云，迁出那些系统资源抢占很高的集群节点，ES集群状况稍有好转。但随着集群数据不断增加，弹性云配置已经不太能满足ES集群，且为了完全的物理隔离，最终干脆将订单中心ES集群部署到高配置的物理机上，ES集群性能又得到提升。

3、节点副本调优阶段

ES的性能跟硬件资源有很大关系，当ES集群单独部署到物理机器上时，集群内部的节点并不是独占整台物理机资源，在集群运行的时候同一物理机上的节点仍会出现资源抢占的问题。所以在这种情况下，为了让ES单个节点能够使用最大程度的机器资源，采用每个ES节点部署在单独一台物理机上方式。

但紧接着，问题又来了，如果单个节点出现瓶颈了呢？我们应该怎么再优化呢？

ES查询的原理，当请求打到某号分片的时候，如果没有指定分片类型（Preference参数）查询，请求会负载到对应分片号的各个节点上。而集群默认副本配置是