Java 的服务，支撑高并发，是部署多个进程好，还是提高虚机配置调高最大线程数好。
themostlazyman 2022-02-23 09:05:26 +08:00 5154 次点击这是一个创建于 1325 天前的主题，其中的信息可能已经有所发展或是发生改变。
有个疑问一直想不太明白，java api 服务是提高单虚拟的 cpu 核心数和内存大小，调高最大线程数。还是干脆用 tomcat 的默认配置，部署多台机器，用 nginx 负载均衡。感觉这个没有对的哪个好，只是在单个机器配置和负载的个数上。
第 1 条附言 2022-02-23 09:42:34 +08:00
目前就是两台机器在负载，考虑服务冗余的话也会至少两台。
第 2 条附言 2022-02-23 09:56:07 +08:00
目前没有部署，无法查看瓶颈，现有系统在平稳运行且未达到瓶颈，现要部署一套峰值并发是当前系统的 2.5 倍，预估需要机器的配置，为了保险起见现有部分配置提升至当前的 1-4 倍，均值在 2.5 倍左右，主数据库性能已提升四倍，由于项目原因无法部署集群，考虑后期维护问题，综合 v 友建议，保留两台机器的个数 cpu 提升 2.5 倍，内存翻倍，部署两个实例。后期若出现性能问题，优先调整 tomcat 参数，尝试单进程多线程方式解决，若效果不明显，则单机部署两个实例，增加负载个数。
 | 1 micean 2022-02-23 09:11:04 +08:00 先调查好瓶颈在哪 |
 | 2 VeryZero 2022-02-23 09:16:27 +08:00 正常来说直接集群部署，简单暴力。 单实例调优各方面都需要付出时间精力，效果也不一定显著，可能调优测试完发现提升很小，白瞎。 调优一般在实例数量较多的情况下可以考虑，因为实例越多效益提升越大。 如果就一两台实例，就算提升 50%又有何意义？多加一个实例的钱付不起吗 |
 | 4 darkengine 2022-02-23 09:24:59 +08:00 @micean 对的，如果瓶颈在单体数据库，加再多机器也白搭。 |
 | 5 bthulu 2022-02-23 09:35:21 +08:00  1 集群个屁, 累不累啊, 单机部署多爽, 并发不够加配置, 4 路 4CPU 服务器单颗 128 核总共 512 核 128T 内存, 还不够你高并发的, 你做的难道是微信消息服务? |
 | 6 learningman 2022-02-23 09:35:44 +08:00 单纯从操作系统的角度想，线程调度比进程调度代价低，而且内存的利用率也高一些 |
 | 7 fanxasy 2022-02-23 09:39:23 +08:00 建议集群，不仅是提高并发，还能确保服务的可用 |
 | 8 F281M6Dh8DXpD1g2 2022-02-23 09:44:04 +08:00 via iPhone 先做 profile 看看瓶颈在哪 盲猜在数据库 |
 | 9 msg7086 2022-02-23 09:44:20 +08:00 总算力不是一样？ |
 | 10 anonydmer 2022-02-23 10:21:15 +08:00 建议是采用集群部署，用多进程的方式，既能够满足生产环境中高可用的需求，也可以满足并发；而且根据你的需求，要达到的效果是满足峰值并发的情况，对付峰值并发有效的手段就是在短时间内自动通过伸缩机制进行更多实例的部署；如果不是峰值而是持续的高并发，那时候再进行应用内优化也不晚。 |
 | 11 chezs66 2022-02-23 10:26:40 +08:00 从概念上说虚拟机本身也有可能发生故障，单纯提升线程数会让虚拟机本身成为系统的单点故障隐患。所以还是用集群吧 |
 | 12 opengps 2022-02-23 11:18:16 +08:00 多进程优先（我是基于将来需要更大负载时候直接使用多机器负载均衡的场景角度给出的建议） |
 | 13 aitaii 2022-02-23 11:45:39 +08:00 数据落库吗？数据库性能也是一方面。 |
 | 14 Oktfolio 2022-02-23 13:39:23 +08:00 我们一个 pod 给的内存都挺小的 |
 | 16 cccssss 2022-02-23 17:31:27 +08:00 @wpyfawkes 我面试的时候有个哥们说他们公司 java 服务器就是 128T 内存，我估计一次 fullgc 能 stw 起码半小时吧…… |
 | 17 x940727 2022-02-23 18:36:49 +08:00 @wpyfawkes 128TB 怕不是大型机了吧，128G 一根的 ECC 内存，都要插 1024 根，这特么 4 路的 CPU 通道也不够啊。 |
 | 19 zeni123 2022-02-23 19:31:09 +08:00 可以集群那就集群部署 还要考虑日后升级需要 |
 | 20 Hanggi 2022-02-23 19:37:08 +08:00 无脑上 K8S 就好了，HPA 弹性扩展，一键部署，滚动更新，A/B test ，金丝雀部署，想怎么玩就怎么玩。 |
 | 22 watzds 2022-02-23 21:24:10 +08:00 这不是一个问题吧，你单机性能再好，能不用 Nginx 这类负载均衡？除非是很小的的服务 |
 | 23 exceldream 2022-02-24 02:04:56 +08:00 via Android @Hanggi 兄弟你知道太多了 -_-# |
 | 24 lamesbond 2022-02-24 10:20:21 +08:00 单点故障不及时处理容易雪崩，上集群吧 |
 | 25 byte10 2022-02-26 10:52:57 +08:00 2 https://www.bilibili.com/video/BV1FS4y1o7QB 少年你需要看看这个讲解。首先你先预定某个接口的吞吐量，比如我希望这个服务 1 秒可以处理 5000 个请求(如： /getOrder )，qps=5000/s 。然后你的本地进行测试，就用你的那个笔记本电脑测试就可以了。不要用 jmeter 它对小白不友好，你可以用 apache 的 ab 或者用我视频给你的那个 nodejs 代码进行压测，比较专业，连接数设置 1500 即可 。 1 、然后你在测试的过程中，先通过调整线程池大小，比如 200, 400, 800, 1200 ，1500 ，然后再对比吞吐量的大小，就可以知道你的这个接口 运行多少线程数才能达到最大的吞吐量。如果你测试出来的结果是 2000/S ，那么就可以通过增加相同性能的机器数量 来达到 5000 的并发。 2 、至于你想知道性能瓶颈，其实非常的简单，性能的瓶颈 90%的情况就是在网络 IO 等待上，把所有网络 IO 的代码（比如请求 mysql ，调用微服务等）调整换成 redis 返回，你再进行压测，如果性能提升非常的大，那么就是在数据库上的瓶颈了，如果提升不大，那么就是你代码的问题。刚说了 90%的情况是在网络 IO ，数据库响应慢，那么 IO 也慢，就需要优化数据库了。 千万要注意：记住前面的几万次请求是热身运动，主要为了触发 jit ，后续的测试才是比较准确的性能表现。所以每次测试就先随便跑几万次，然后再进行 2-3 次压力测试，取平均值，一般都是相差不多的了。 不用盲目增加机器，你机器也许已经可以支持现有峰值的 4 倍都不一定，最简单就是看 cpu ，cpu 没满，说明很多的性能都没释放出来。cpu 长时间在 8-90%的情况下，才考虑增加机器。 |
 | 26 themostlazyman OP @byte10 谢谢，感觉大部分平台的性能瓶颈不是网络就是磁盘。 |
Select Language