针对你的困扰出发，核心就是这也许是你头一次针对 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 的场景

可以看看功能比较聚焦的库，我个人强推 lettuce

这里可以考虑做个线程读写分离。没接触过 .Net 我会用 Java 的 type 与 API 描述，自行对应一下:

首先把成员 devices 与相关的操作都封装到一个类型里面，对外暴露一个 public 的阻塞队列成员变量，Java 的话我会用有阻塞语义的 ArrayBlockingQueue. 这个类型在构建的时候(onCreation)，启动一个单线程去 poll 这个 Queue. devices 的更新逻辑都由这个单线程完成

外面的异步操作获取到设备信息后，以 ImmutableEvent 的形式把必要的信息封装描述好，放入队列. 形如 ArrayBlockingQueue<DeviceUpdatedEvent> 这样子，里面的单线程 poll 到事件直接更新 Dictionary 即可。

最后剩下这个“多个监控线程每隔 100 毫秒读取一次所有设备状态” ，这里简单起见可以将 devices 也设置成 public ，直接在外面访问 devices 成员（重点是：一定要约定好，在 poll 的线程之外的逻辑，全部只能 read 这个 ConcurrentDictionary ）。因为 Dictionary 本身使用了线程安全的 ConcurrentDictionary ，对它的 CRUD 是线程安全的，只需要防止外面监控程序获取到某个尚未更新完成的某个 Device 实例（有点像 DB 的脏读），这里给 Device 每个属性设置 volatile 肯定是不合适的：可以考虑前面提到的，在负责 poll 的单线程，获取到更新事件后，不要就地改变 device 对象本身的属性值，而是以 deepCopy 的方式创建个全新的 Device 实例。然后用 ConcurrentDictionary.put(key, value) 的 API 直接更新整个 Device 对象，规避外部监控线程在 scan 的时候，获取到属性更新不完整的 stale state

这种迹象很典型，多是要换环境的信号
如果自己也有心收拾下现在这种混乱，可以一点点的把这些建设起来。
如果有心，只需要个方向和方案的提示就好

https://github.com/prometheus-operator/kube-prometheus

没一个人说明白。。。。 利用 kubernetes 的 operator 机制，监听到带特定 meta 的 svc 描述，operator 会自动抓取和拉取监控数据

service.yaml 开头形如下面这坨

apiVersion: v1
kind: Service
metadata:
annotations:
prometheus.io/path: /metrics
prometheus.io/port: "8080"
prometheus.io/scheme: http
prometheus.io/scrape: "true"


综述：
1. 如果是自有服务，按前面说的来定义 service meta 部分
2. 如果是非 kubernetes 托管的外部服务，比如中间件，一般是部署对应的 exporter 服务。然后自定义一组同上的 service + 指向具体 IP 的 endpoint.

tick 先处理成 snapshot. snapshot 携带日内的累计性质数值，最关键的是成交量与成交额

对于日级别以上的 K ，用 snapshot 触发最新一根周期 K 线的数值变更（最高、最低价、成交量、成交额），这里带一点日期逻辑，比如周 K 线里面，归属于当周就是处理归并到最近一根周 K 线，周一当天这种新的一周开始，就创建全新一根周 K.

分钟级别的没弄过，粗看用 tick 直接搞搞就好

@ovtfkw 您可以心里想想就好，大可不必张开肛门泄出来

工作必须装的话，新建一个单独的桌面，把这个窗口拖拽过去，或者小心拖放到最右下角，只会漏出一个不起眼的边框。

否则 recovery mode + rm -rf 伺候

fluent-bit C 语言编写，主流用途的插件丰富，基准内存占用个位数 MB

@paranoiagu 可能是容器的 jdk 版本不认容器平台 CRI 的 cgroupV2. 要检查并升级 jdk 到支持 cgroupV2 的小版本

就个人经验，95% 的场景都用途不大，pre-loom 时期 reactive 框架解决的主要是针对 request-per-thread 这种场景造成的线程开销过多问题。

比如说，你的应用恰好是一个并发请求量偏大的场景，下层又恰好是一个可以异步的东西比如某些云数据商的异步 SDK （而非 block JDBC 为主的调用），使用 webflux 是一个合适的选择。除此之外可以说都不太适合，因为引入这套框架在带来一点线程资源开销的节省之外，会引入代码风格的巨变。这很像在 js 工程写一个 async 函数，会从调用点起在整个调用链路上做一个比较大的“类型污染/风格污染”，下层调用也充斥着 Mono<T> / Flux<T> 的情况，个别场景比如针对自己无法改造的 block API 还需要对线程与调度器更深一层理解，在合适的时候通过 publishOn() 函数切换 Scheduler

不久的将来 loom 成熟后，reactive 框架唯一的好处就剩下上一段后半段表述的：一套强类型与显示的声明式逻辑处理链路风格。这个见仁见智，在我的经验下全司几乎所有的后端研发都比较反感这一套东西，其中绝大多数人是因为不懂也不想去理解里面的设计思路。可能有一定 FP 经验接触过比如接触过 scala 里面 ZIO/Cat Effect3 那种 effect system 的人会舒适些

准备明年 2-3 月份搞个 win 的游戏本，在看 ROG

@QiShine 就是你说的后面那种写法，这是业务的固有复杂度，躲不开的。看的不顺眼就抽象个 dispatcher 的逻辑

// data-flow-in:

while(true) {
bytes = await io.recv()
// 反序列化
data = decode(bytes)
// 派发
xxxhandler.process(data); // 再里面可以 if else
}