K8S 挺好的，从写命令行到 YAML 工程师，家用 NAS 进程管理全靠 K8S……

@dsvshx 想完全避免内存分配的话……从 mmap 把数据往外撸的地方就得下手……TCP 你还不知道读多长……unsafe malloc 难写

都知道卡 gc 了，直接的方法就是不让他参与 gc 嘛……unsafe 去 malloc 到非堆上，然后自己做对象生命周期管理就行啊……

Bare Metal 的 Ubuntu...上面跑的 K8S

Flink CDC -> Hive -> HSQL……
写代码的成本不如直接租云服务直接跑完了

Database is Log 的思路去做这个事情
第一张表记录充值的分钟数
第二张表记录暂停的时间段
那剩余分钟数=充值分钟数-区间暂停分钟数
如果你要提升性能就减少回溯长度，定每月/每周活跃用户归档表，三表联查来加快查询性能。
Session 是否存活判断就分钟级确认一下是否存在生效暂停记录且剩余分钟数>0

上线发布真正有用的不是说怎么样一个流程怎么一个 Checklist ，而是整个研发团队对于生产环境要有敬畏之心……
与其推动团队严格执行 Checklist ，不如把配套的工具能力搭建起来，不依赖于人去执行这些繁琐的事情，而是通过自动化的流水线工具，保障发布流程过程中错误能被准确及时暴露出来……

就同步的把人和货一起独占一台车送过去这个服务比较贵……返程 99%概率是空驶，所以你付钱肯定是付双向的钱……
想节约成本的话就需要找切入点，通过物流的方式一方面可以和其他同样流向的货物共享运输工具，且通常返程也有货可运，整个成本就便宜很多，缺点就是牺牲时效性……

6S Plus 使用的 A9 处理器即使到现在也不算非常拉胯，因为隔壁 Android 的低端机比他更菜……
比如 6S Plus 的 A9 处理器和某 1999 元手机的骁龙 680 能五五开……

XDR6086

这个是因为 Apple 在 iOS17 把 Carrier 信息的 API 给去掉了……

vacuum

XDR6078 两台正好

@dongpengfei1 设备网络能不能换，比如搞个啥 5G CPE 专门跑这个业务……其实相当于拉专线把高优先级业务跟低优先级业务隔离开来

客户端向服务端同时发起三个请求，任意一个请求成功了就认为成功了……
服务端向客户端下发支付成功消息，发三遍，收到任意一个消息就认为成功了……
三个请求都发生丢包的概率 = 5%^3 = 十万分之 125……

流量不够大……亿级 Key 百万 QPS 下边愁的是分片不能无限可分和节点负载不均

背景：XX 集团车辆管理模块有超过 XX 台车的运输状态跟踪需求。
问题：XX 集团的 XX 台车需要完成 XX 天 GPS 定位可追溯，如何低成本可靠实现？
方案：为了应对 IoT 上报数据流量不丢失，同时实现削峰填谷，上报 API 走 Kafka 存储。经消费到 MongoDB 后按日进行分片。为了节约成本使用冷热数据分离，冷数据定时任务转移到 HBase/Clickhouse 上。
结果：XX 台车每分钟上报 XX 个数据下，支持 XX 天内 XX 查询，资源成本 XX 元/日。

背景：以 XX 为核心业务的 XX 集团，其有 XX 台运营车辆用于 XX 业务。
问题：传统模式下，车辆依赖地面人员管理，在业务扩张过程中遇到诸多问题：车辆损坏不可用、年检到期不可用、在途情况不明等，经常导致部分地区无车可用，使得 XX 业务低效运转。
思路：XX 集团通过数字化转型，建设车辆管理模块，实现车辆信息与状态集中管理，进一步让车辆运行状态可视化，允许地面人员快速掌握车辆情况，提前做出准确的车辆调拨决策。
方案：车辆管理模块设计能够较好的服务业务开展，提供基本信息登记、维修状态登记流程、运输状态跟踪以及证件信息到期提醒等功能。
结果：车辆管理模块上线后，XX 地区无车可用情况大幅减少。承载 XX 业务下 XX 台车的日常运营工作，服务运营里程超过 XX 公里。证件到期提醒功能模块提醒次数 XX 次，减少车辆停驶 XX 日。

在用石英峡谷 i7 9850H + 64G DDR4 + 500G RC10 系统盘+ 2T PM981 数据盘
帅是真的帅 Intel AMT/vPro 是真的没法用……
拓展性上限很低，板上 2 个 M.2+底部 16x 加起来上不了几块盘，毕竟桌面级玩具……