CRI 是 docker(dockershim) 运维起来方便非常多

@salmon5 按照经验来说，被多加 cloud companies 重度使用的发行版我会更信任一些，问题发现也快。我们主要用做 docker base image 大概从 jdk 14/15 开始一路用到现在，当时的 temurin 相比 liberica, 同发行版的镜像体积大很多，可选型的发行版偏少(有一个 centos 还是 alpine-musl 记不清了当时是干脆没有)。另外就是新版本 JDK GA-release 时，liberica 的 docker 镜像跟进速度是最快的，体感能比 temurin 快两周

如果用 sdkman 维护本机版本的多环境，还能观察到 liberica 会为 JavaFx 的集成(.fx 后缀) GraalVM 集成 (nik 版本)都有分别封装，在这上面投入的程度相对突出。

Liberica JDK 17/21 一起用，更新最迅速稳定，体积小。temurin 很糟糕

债基、日元、小比例生物医药(港股目前 1.5PB 那个某某生物)

hikari 的 connectionTimeout 有没有配置

今天应该企稳了，春节前会不会再踩一脚不好说。整体会慢慢向上

灵耀 16air 闭眼买

> 只想投个几千, 不用赚多少 别陪太多就行

所有人一开始都这么想，可人性是最难控制的。你扔 1000 ，幸运拿到 20cm 盈利 200 ，这时候会不会想，要是我投入的是 10000 或是 10w 呢，悲剧都是这样开始的

没提前埋伏到就算了，巨亏都发生在牛市，好好感悟这句话

哪个好用不清楚，能给你排除一个 gluster-fs ，它的 csi-driver 只能搜出两个，活跃的十分不成熟，另一个很早被弃坑

debian 好点

ubuntu 里面有个 snap 组件，在个别机器会触发持续的高 CPU 占用，只有完全卸载才能解决

极大概率是 DNS 解析导致的(遇到过走 ipv6 解析，5s timeout 后回落到 ipv4)。从请求发送端看看，尤其是用了 alpine 镜像的服务容器

针对你的困扰出发，核心就是这也许是你头一次针对 websocket 场景编程。这里跟 HTTP 的语义封装没关系，尤其是没有请求-响应的通讯模式，没有路由的概念。先定义消息类型（完全由你自行定义），把消息发跟收分开处理就好，各自独立

第二种是直接用 pb 的高阶用法，oneof 字段。参考这里 https://zhuanlan.zhihu.com/p/453913153 例子，可以避开对 bytes 的 raw byte manipulation. 有兴趣研读 pb 文档的话，我推荐第二种

抛弃路由的概念，用 pb 定义消息结构就好。举个例子

message FetchChatHistoryRequest(id, count, start, end, e.g.)
message FetchChatHistoryResponse(repeat string xxx)
message SendChatMsg(string target, string content)

在实现里收到消息，解析类型，派发给对应 Type 的逻辑做业务逻辑处理，他们的逻辑当是独立离散的。
理解这一层之后，收发两端都有个需要，就是识别一个 raw bytes 比如 Java 语言会接收到 byte[] 作为消息包，要知道它具体是什么。 这里有两种思路： 第一是像二楼这样，外层用 TCP 的 TV 或 TLV 来包装一下，就是 type-length-value 这种。前两个字段一定要定长，比如 type 是 4byte 的数字类型，自己给上述消息定义好类型 id 。lenght 是 8byte 的长整形，数值是后面 value 部分的长度。value 里就是 pb 消息，encoded pb bytes 。 自己写个简单的 encoding / decoding 逻辑

snap 这东西就很离谱，我们生产环境有一太负载飙到 40-60 毫无线索，top/ps 也看不出来。把 snap 强制删除就好了

@YIsion 这款小问题蛮多的，我的离开两米远就频繁断联，玩魂系/格斗游戏时候时不时很致命，基本处于不可用状态。不如它家低价的款稳定

人民币计价应该是 3 6

前 kotlin 重度用户。近两年综合 Java 目前的发展趋势与方向，我是认为在 Android 开发之外的服务端编程里，完全没有需要使用 kotlin 的场景