curl -vv -6 https://www.zhihu.com
* About to connect() to www.zhihu.com port 443 (#0)
* Trying 240e:cf:9000:321:37::13...
* Connected to www.zhihu.com (240e:cf:9000:321:37::13) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=*.zhihu.com,O=智者四海（北京）技术有限公司,ST=北京市,C=CN
* start date: Dec 10 00:00:00 2024 GMT
* expire date: Jan 10 23:59:59 2026 GMT
* common name: *.zhihu.com
* issuer: CN=GeoTrust G2 TLS CN RSA4096 SHA256 2022 CA1,O="DigiCert, Inc.",C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.zhihu.com
> Accept: */*
>
< HTTP/1.1 525 EO errCode : SSL handshake failed
< Server: EdgeOneIS_OC
< Content-Length: 0
< Connection: keep-alive
< Date: Fri, 17 Oct 2025 02:08:16 GMT
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
< EO-LOG-UUID: 5273955530657146703
<
* Connection #0 to host www.zhihu.com left intact

都到桌子面前了， 直接人肉或者书本占座就完了，还扫啥码？

RIME

求空投，感恩站长. GO GO GO

k8s 之前学了尝试搭建自己的集群 (多台虚拟机), 结果无论如何都无法让所有 node 全部 Ready (装了 flannel 网络). 之后就放弃了.

短文小说: <长安的荔枝>

就打算买一个 Ace Pro 2 相机再加点套件. 记录下之后的自行车比赛和端午游玩.

可以戴耳塞. 耳塞很管用

合理, 主要有以下几点:

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 我知道