Karte

合理, 主要有以下几点:

1. 一个功能一个分支：确保功能完整，便于问题回退，控制影响范围。合并到主线通过 MR ，git log 清晰记录提交范围。
2. 小提交原则：避免一次性提交完整功能。若功能开发中（已提交 5 次）遇 issue ，主线开发需选择回退（ revert ）或继续提交。前者需重新提交，后者可能因未完成功能导致主线无法运行。而一功能一分支、一 issue 一分支可快速切换修复 issue ，不受未完成功能影响。修复后，切回功能分支，rebase 解决冲突，继续开发。

假设你已经 commit (还未 push) 了 5 个 change, 功能还未开发完成. 这时突然出现一个 issue, 如果这个 feature 在主线而非分支. 那你是打算 revert 之前的提交, 还是直接修改继续提交 (6 个提交).
如果 revert, 那你得先 revert 之前的所有提交, 然后提交 issue, 之后还得重新 commit.
如果直接提交, 那你还未完成的 feature 也同步 push 到主线. 那很有可能会出现无法跑通的情况 (必尽你还未开发完成).

@recying5566 哈哈哈哈哈哈, 只要 6 万起, 能拉能运还便宜 [doge].

五菱宏光, 混动续航 1000KM +

https://www.bilibili.com/video/BV1SRo6Y2Eaf/

@heiya 首先大文件会占用过大的磁盘 IO, 如果云磁盘容量过低则 IOPS 也会很低.

在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.


对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).

说实在的, 有 OSS 不用非得自己搭. 图啥啊?

自建存在以下问题:
- 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
- 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
- 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
- 高可用 (自建没有现成的好)


PS: 如果只是出于学习的目的, 那尽管折腾.

@ebony0319 的确不错👍.

@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 时会打印堆栈.

@anyele 我知道

@ychost 我知道, 所以前面增加了 JDK-21-LTS 版本