Java 生态下想搞大流量下的 ws,是不是暂时只能 netty?

[5261]

最近项目想上直播和拍卖业务,自身流量也是比较大,想问下目前业界 ws 方案下是不是更推荐 netty 或者有没有其他可以参考的方案呢?

直播推流这快准备用阿里云的,直播上会用到 ws 的也就是评论,拍卖可能就是出价和评论

[sagaxu]

不要直接用 netty ，用 vertx 或者 quarkus

[wxw752]

我们公司是做会议的，直播推流用阿里云再找个云服务商做备份，单一服务商遇到问题的时候哭都来不及。

ws 是用的 netty

[cheng6563]

用 Java 21 虚拟线程同步处理一把梭，别想着那些啥响应式啥的异步啥的提高性能了。

[me1onsoda]

vertx 更好用

[Goooooos]

vertx 底层就是 netty

[ychost]

虚拟线程吧，响应式编程复杂度太高了，甚至比切换 kotlin 的成本都高

[ZZ74]

老老实实用 netty
大流量+响应式编程到时都不知道死哪里...

[Karte]

虚拟线程不推荐使用.
1: 虚拟线程的出现是减少 IO 的产生, 如果是非 IO 操作使用虚拟线程只会增加应用负担.
2: 虚拟线程是通过用户态上进行上下文切换减少内核态切换. 虚拟线程使用 Continuation 实现的, 这个是个对象, 也就是会占用内存. 当你操作越多, 内存占用也会疯涨. 原有平台线程 (Thread) 则是由物理资源 (系统资源) 限制, 而虚拟线程则没有这层限制, 操作不好容易导致 OOM.

[Karte]

就目前的 JDK-21-LTS 的虚拟线程还存在致命问题:

- 在使用 synchronized 场景下会将虚拟线程 PIN 到平台线程 (锁在了某一个线程上)
这是由于当前对 synchronized 的实现需要直到锁当前持有的线程对象. 而虚拟线程是上层包装出来的, 所以必须强绑到某一个平台线程 (Thread) 上才能实现. 如果在 IO 操作下会基本和平台线程无异.

- 在 Medium 中, Netflix 团队遇到使用虚拟线程死锁的情况.
这个问题和 synchronized 关联. 具体可以参考 [Medium Netflix Tech]( https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d)

[5261]

@sagaxu 收到

[5261]

@me1onsoda 收到

[5261]

@Goooooos 收到

[5261]

@Karte 还是哥专业啊~ 理论上我们新项目不会上新的 jdk 版本,还是继续用 Java8

[5261]

有的时候我觉得 Java 对于中小企业真是一种负担,明明可以用 Go 来做业务开发,能减少不少服务器成本!

[ZeroDu]

别搞 java8 了，起码 17 起步，现在各个生态配台早都跟上了。netty 是稳健的选择多少年市场验证过了

[halov]

https://github.com/tywo45/t-io 要不看看 tio 不过好像这个框架用的人不多 评价不高

[ychost]

@Karte #9 JDK24 修了 synchronized 问题

[5261]

@ychost 那 JDK21 的人不就是小白鼠了!

[5261]

@ZeroDu 升级 JDK 不是说我想升就能升,企业用 Java 要的是稳定!

[5261]

reactor netty 这玩意和上面提到的 vertx 有啥区别呢?