最近项目想上直播和拍卖业务,自身流量也是比较大,想问下目前业界 ws 方案下是不是更推荐 netty 或者有没有其他可以参考的方案呢?
直播推流这快准备用阿里云的,直播上会用到 ws 的也就是评论,拍卖可能就是出价和评论
 |
1
sagaxu 1 天前
不要直接用 netty ，用 vertx 或者 quarkus
|
 |
2
wxw752 1 天前
我们公司是做会议的，直播推流用阿里云再找个云服务商做备份，单一服务商遇到问题的时候哭都来不及。
ws 是用的 netty |
 |
3
cheng6563 1 天前
用 Java 21 虚拟线程同步处理一把梭，别想着那些啥响应式啥的异步啥的提高性能了。
|
 |
4
me1onsoda 1 天前
vertx 更好用
|
 |
5
Goooooos 1 天前
vertx 底层就是 netty
|
 |
6
ychost 1 天前
虚拟线程吧，响应式编程复杂度太高了，甚至比切换 kotlin 的成本都高
|
 |
7
ZZ74 1 天前
老老实实用 netty
大流量+响应式编程到时都不知道死哪里... |
 |
8
Karte 1 天前  1
虚拟线程不推荐使用.
1: 虚拟线程的出现是减少 IO 的产生, 如果是非 IO 操作使用虚拟线程只会增加应用负担. 2: 虚拟线程是通过用户态上进行上下文切换减少内核态切换. 虚拟线程使用 Continuation 实现的, 这个是个对象, 也就是会占用内存. 当你操作越多, 内存占用也会疯涨. 原有平台线程 (Thread) 则是由物理资源 (系统资源) 限制, 而虚拟线程则没有这层限制, 操作不好容易导致 OOM. |
|
9
Karte 1 天前 2
就目前的 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) |
 |
14
5261 OP 有的时候我觉得 Java 对于中小企业真是一种负担,明明可以用 Go 来做业务开发,能减少不少服务器成本!
|
 |
15
ZeroDu 1 天前
别搞 java8 了，起码 17 起步，现在各个生态配台早都跟上了。netty 是稳健的选择多少年市场验证过了
|
 |
16
halov 1 天前
https://github.com/tywo45/t-io 要不看看 tio 不过好像这个框架用的人不多 评价不高
|
|
20
5261 OP reactor netty 这玩意和上面提到的 vertx 有啥区别呢?
|
 |
22
Gress 1 天前
用 JDK24 的虚拟线程，修复 synchronized 会挂起平台线程的问题了
|
 |
23
anyele 1 天前
@Karte #9 https://openjdk.org/jeps/491 已经修复了
|
 |
24
siweipancc 1 天前 via iPhone
虚拟线程的发布文档就有提到同步关键字还没适配，要切到对应的锁实现……
|
 |
27
zoharSoul 1 天前
vertx 好用
|
 |
28
SunDShuai9797 1 天前
@halov 引用别人的评价：issues 都关了怎么用？
|
 |
29
aboutier 1 天前
java netty 没有替代品。
|
 |
30
NizumaEiji 1 天前
spring -> mq -> nodejs/go
客户端发起请求走 spring 那套 服务端下发消息走 mq + nodejs/go 那一套 |
 |
32
ebony0319 1 天前
@Karte 回复一下 8 楼 9 楼，
链接一： https://mp.weixin.qq.com/s/aoFo74SSXoaEIywu-pX-Ow 链接二： https://bugs.openjdk.org/browse/JDK-8338383 链接三： https://github.com/brettwooldridge/HikariCP/issues/2151#issuecomment-2475328765 这是我在实际使用虚拟线程，压测的效果，其中遇到了一个问题。是底层导致的，后面也修复了。 我从 21 出来就用在生产使用虚拟线程，很负责的说，这个是一个续 jdk8 后一个里程碑产品。jdk8 不是一个高并发语言。尤其在高并发情况下非常鸡肋，需要非常非常对的调优。 我说一个非常简单的场景：tomcat 承接爆发流量，在 jdk8 会遇到非常尴尬的问题，如果最小线程数设置太小，爆发流量来的时候线程创建需要时间，会造成大量流量超时。如果太大在空闲时候会浪费资源。 |
|
33
Karte 1 天前 2
@ebony0319 是的, VT 是 JDK 的里程碑. 在 HTTP 侧的确能够显著的提升响应能力. 不过在日常业务开发中也能使用, 不过需要比原有的 Thread 有更多的规范. 滥用 VT 可能并不会提升性能, 还会降低性能 (上下文 Continuation).
在没有修复 synchronize 情况下, 只建议在最贴近 IO 部分使用, 尽可能减少组建中 synchronized 所带来的影响 (没修复, 也就是 JDK-21-LTS). 在目前的 JDK-24 (non lts) 中修复了 synchronize PINED Thread 的问题, 但类似本地方法调用还是会存在 PIN. 在日常开发是可以使用了, 不过还是需要注意 VT 数量. 平台线程的数量是和计算机硬件资源对等的, 而 VT 数量则是和 JVM 内存对等的. VT 数量越多, JVM 内存占用越高, 直到 VT 任务结束释放了 Continuation. 总结: 1. 在 JDK-21-LTS 不太推荐使用. 如果使用请尽可能贴近 IO 部分. 2. JDK-21-LTS 也能使用, 前提是了解 VT 内部机制 (上下文切换, Continuation, 锁机制, 本地方法站调用). 3. 如果在业务中, 我的建议是等下一个版本的 LTS 上线. 想上也可以, 建议增加 -Djdk.tracePinnedThreads=full, 在遇到 PINNING 时会打印堆栈. |
|
34
ebony0319 23 小时 30 分钟前
@Karte 其实已经修复了。虚拟线程本来就是适合 IO 密集场景。那个问题其实解决非常简单，如果不放心： -XX:LockingMode=2 直接遇到 synchronize 就开启重锁。
https://imgur.com/a/403FceD |
|
35
ebony0319 23 小时 27 分钟前
@Karte 不好意思刚摁快了。这是我刚截图的现在生产一台 jdk21 的服务器，单机平均 QPS1000 ，https://imgur.com/a/403FceD , 这是最近 6 小时的 cpu 使用情况： https://imgur.com/4bmtPLS , 这是 6 小时内存的使用情况： https://imgur.com/YzN42Y5
|
 |
37
conn457567 21 小时 39 分钟前 via Android
反正不要用响应式编程，没有点经验写出来的代码真的非常坑。现在的虚拟线程还不成熟，反正我是不敢上生产环境的，有条件还是换语音用 go 或者 nodejs
|
Select Language