Karte 最近的时间轴更新 Karte 最近的时间轴更新 |
KarteV2EX 第 530643 号会员，加入于 2021-01-27 09:07:54 +08:00 |
北京
Karte 最近回复了
17 天前 回复了 0littleboy 创建的主题 › 程序员 › 公司每一个功能或 bug 都要新开一个 issue，合理吗 |
合理, 主要有以下几点:
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 到主线. 那很有可能会出现无法跑通的情况 (必尽你还未开发完成).
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 到主线. 那很有可能会出现无法跑通的情况 (必尽你还未开发完成).
17 天前 回复了 inas 创建的主题 › 电动汽车 › 想换个 15 万内的纯电，有什么推荐吗？ |
@recying5566 哈哈哈哈哈哈, 只要 6 万起, 能拉能运还便宜 [doge].
17 天前 回复了 inas 创建的主题 › 电动汽车 › 想换个 15 万内的纯电，有什么推荐吗？ |
18 天前 回复了 heiya 创建的主题 › 程序员 › 对搭建 MinIO 对象存储的一些疑问 |
@heiya 首先大文件会占用过大的磁盘 IO, 如果云磁盘容量过低则 IOPS 也会很低.
在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.
对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).
在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.
对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).
18 天前 回复了 heiya 创建的主题 › 程序员 › 对搭建 MinIO 对象存储的一些疑问 |
说实在的, 有 OSS 不用非得自己搭. 图啥啊?
自建存在以下问题:
- 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
- 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
- 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
- 高可用 (自建没有现成的好)
PS: 如果只是出于学习的目的, 那尽管折腾.
自建存在以下问题:
- 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
- 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
- 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
- 高可用 (自建没有现成的好)
PS: 如果只是出于学习的目的, 那尽管折腾.
25 天前 回复了 5261 创建的主题 › Java › Java 生态下想搞大流量下的 ws,是不是暂时只能 netty? |
@ebony0319 的确不错👍.
25 天前 回复了 5261 创建的主题 › Java › Java 生态下想搞大流量下的 ws,是不是暂时只能 netty? |
@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 时会打印堆栈.
在没有修复 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 时会打印堆栈.
Select Language