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

灵耀 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 的场景

可以看看功能比较聚焦的库，我个人强推 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 直接搞搞就好