早期 Java 的并没有统一的异步运行时, 所以很多都需要去自行实现处理, 而 Pekko 则是自行设计通用的异步运行时.
Pekko 异步运行时是由 Actor 模型 + 调度器 + 流处理 + 未来式(Future) 构成的完整异步运行体系, 包含有以下组件:
Scheduler/Dispatcher: 任务定时器/调度器, 底层执行核心, 负责线程分配和任务调度, 隔离不同类型的任务
Future/CompletionStage: 异步任务结果包装, 处理异步任务的返回值，避免同步阻塞等待
Stream: 支持运行时的数据流处理, 解决批量数据的异步生产 - 消费问题, 内置背压避免流量失控
Actor: 最上层的任务载体, 用 “消息队列 + 单线程执行” 的模式将并发问题收敛到"消息顺序"而非"锁"
这些组件都是能够独立使用
在 Java8 之后可以依靠 Runnable/Callable/ThreadPool 实现简单的异步运行时, 但是对比 Pekko 纯正 Actor 设计差距很大:
特性
Pekko ...
Pekko 消息交互
其他文章已经揭示过 Pekko 目前主流支持的网络流消息交互:
TCP
UDP
WebSocket
基本上需要的网络流处理, Pekko 都封装完成了, 所以也就不需要依赖第三方来处理这些.
TCP/UDP 文档我看目前没有跟进到最新强类型版本处理, 这里主要还是以 TCP 流处理为主
TCP/UDP 之类依赖只需要基础的 actor 即可, 无需其他多余依赖, 目前官网 TCP 样例如下:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081import java.net.InetSocketAddress;import org.apache.pekko.actor.ActorRef;import org.apache.pekko.actor.ActorSystem;import org.ap ...
Pekko 作为 Actor 底层框架, 其实内部自带了 Http/Https/WebSocket 扩展, 涵盖日常所需要的短连接和长连接场景.
这部分涉及到以下相关内容:
pekko-http
pekko-websocket
这里为什么推荐采用 WebSocket 做长连接服务?
主流支持非常广泛(现代代浏览器、iOS、Android、物联网设备)
抛弃以往的粘包/拆包、心跳检测、消息校验问题, 不用将心力放在数据流的验证上
CDN 厂家现在逐步有 WebSocket 的支持, 可以利用 CDN 的边缘节点就近接入客户端
当然也可以外置 WebSocket 库挂载服务, 只是采用 Actor 集成更加高效方便, 无缝贴合 Actor 处理
另外需要说明的 WebSocket 支持 text(文本流) 和 binary(二进制流) 传输模式, 这里强烈建议采用二进制流传输.
如果采用 text 文本流, 大部分数据库解析的时候都会做默认的 UTF8 编码转化成 String, 之后内部又会转换成 byte[] 交换数据.
高并发的情况下很容易直接生成大量 ...
Pekko Stream 是一套异步、非阻塞、支持背压(Backpressure)的数据流处理框架,
主要用来解决大数据/高并发场景下的资源管控问题, 避免数据加载时候的 OOM 问题.
pekko 需要依赖以下的组件(采用 Maven 来包管理):
12345678910111213141516171819202122232425262728293031323334353637383940414243444546<!-- 所需依赖 --><dependencies> <!-- Pekko Stream 核心依赖 --> <dependency> <groupId>org.apache.pekko</groupId> <artifactId>pekko-stream_${scala.binary.version}</artifactId> <version>${pekko.version} ...
作为长期使用的维护的远程 API 接口, 大部分都是用类似于 /v1/user/login 之类做版本控制管理;
但是实际上其实内部问题也很多, 比如长期运行的路由表堆积问题, 并且基于 Path 匹配导致没办法做到无感知升级.
之后接口设计我更加推崇的是 Header 版本字段控制, 请求时附加以下 Header 字段(以下字段都可以自定义, 最好做成动态配置):
X-Version: 请求的版本字段
X-Sign: 请求的字段签名
X-Authorization: 请求的授权 Token
X-App-Id: 可选配置, 如果采用多应用管理才需要, 一般单应用接口不需要用到
然后后续都是采用统一的请求接口 /user/login 之类, 而内部就是直接通过 Header 相关参数来调配转发到对应版本.
这里还是用 Quarkus 来做接口请求
按照常规的接口配置之后就编写控制器类来做接收请求:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464 ...
之前买 Orange 5Pro 来设计 NAS 的时候顺带买个 Orange 3B, 因为嫌弃性能不够一直没拆封过;
最近跨年整理的时候才发现这块开发板, 想着闲着也是闲着就看看能干点什么.
最后想着搭配手里的8寸便携式显示器直接改造成简单的小型 Steam Machine, 通过连接 XBOX 蓝牙手柄来游玩游戏.
OrangePI 3B 后面简称为 opi3
这套方案的具体配置如下:
RockChip RK3566 瑞芯微四核 64 位 ARM 处理器, 主频最高 1.8GHz
8GB LPDDR4/4X 自带内存
120GB SATA 廉价朗科固态硬盘(这是我额外购买扩展固态硬盘)
支持 Wi-Fi5/蓝牙/HDMI 方案
Armbian 系统(Debian的 iot 方案)
支持 OpenGL ES 1.1/2.0/3.2 | OpenCL 2.0 | Vulkan 1.1(Vulkan是重中之重)
需要注意: 这块开发板默认只启用的 NVME 协议, 直接接入 SATA 协议的固态是没办法识别的.
如果固态是 SATA 协议就需要修改 A ...
Steam 挂卡的核心原理是通过模拟游戏运行状态向 Steam 服务器发送 “游戏正在运行” 的心跳请求从而高效获取集换式卡牌.
注意: Steam 服务条款禁止第三方工具模拟游戏运行, 可能导致账号警告、限制市场功能或封禁, 所以本质上这种行为是带有风险
这部分功能目前已经有第三方实现并开源, 具体可以查看 ArchiSteamFarm
以下部分也是基于 ArchiSteamFarm 项目来搭建处理, 注意这里是基于 Debian 发行版搭建处理, 官方也提供更加方便的 Docker.
建议需要挂卡的账号配置 Steam 所有安全登陆配置(官方2FA), 避免挂载过程之后泄漏登陆密码或者 Token 相关
安装部署
按照官方安装指南来部署环境配置, 内部采用命令行模式而无需运行游戏界面来节约大量资源处理, 需要执行以下命令:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162# 参照文档: http ...
针对 Linux 大部分性能指标采集, 需要用到对应相关的工具集, 这里提供目前比较主流的 Linux 检测手段:
perf: CPU 性能检测采集
iperf3: 网络性能检测采集
iostat: 磁盘IO监控
sar: 全能监控数据采集
CPU 性能检测
perf 是 Linux 系统下的性能分析工具(Performance Counters for Linux), 用于针对
CPU|内存|磁盘I/O|网络|进程/线程等系统资源的使用情况进行全方位的采样和分析.
这里采用 Debian 发行版来说明, 其他发行版只需要找 perf|performance 相关包安装即可:
123456# 安装依赖, 这里有的教程说是 linux-perf 或者 perf, 可能有的版本变迁之后更改包名sudo apt install performance-tools# 查看目前监控工具版本# 需要注意: 系统性能采集本身是很高级的功能, 所以大部分情况都是需要用到 root 高级权限sudo perf --version # 这里目前版本为 perf version 6.14.11
这里之后 ...
常规上报数据需要实现以下功能:
削峰 - 避免高并发写入过载, 保证大规模数据入库的时候不会直接让存储过程崩溃, 避免瞬时高并发、流量突增造成数据写入异常
压缩 - 降低存储数据的占用, 日志数据本身属于很尴尬的数据, 过期之后很少去查询到, 但是统计要让其后续保存待用
分页 - 大量数据需要被前端做页面数据处理, 大数据分页的时候 OFFSET + LIMIT 会有大量性能问题
高并发网络流量突发请求上来的大数据会瞬间引发数据锁抢占, 直接让数据库承载不了这部分数据写入, 卡死整个数据接口
这部分最通用的方案: 消息队列 + 列数据库, 而这方面目前的通用选型就是 Kafka + ClickHouse
Kafka + ClickHouse 是经过业内验证过, 最为高效且便捷的技术栈
Kafka 和 ClickHouse 的搭建流程可以参照其他文章说明, 这里是提出可用的技术方案:
Maven: 后台的包管理方案, 后端不要搞什么 Gradle 破坏性更新频繁来做包维护
Java17: 高版本支持 record 特性, 可以节约时间避免写入样板代码(我不喜欢 lom ...
传统 MySQL/PostgreSQL 在单表动不动超过 100G 之后就会考虑用分库分表硬抗, 但是本身就是治标不治本的问题.
哪怕分表出来, 后台也是需要分页查询展示数据, 单表 100G 以上多表合并分页分页查询要CPU和内存占满都要几十秒
基于这种大规律数据日志的情况, 传统的 MySQL/PostgreSQL 已经很难负载这部分功能, 需要寻求其他数据库支持.
也是在这种情况下, 就需要了解到 列存数据库(Column-Oriented Storage) 和 行存数据库(Row-Oriented Storage) 的概念.
在此过程之中就了解到列数据库 - ClickHouse:
特性
行存数据库（MySQL/PostgreSQL）
列存数据库（ClickHouse）
存储方式
按行存储，一行的所有列数据连续存放
按列存储，一列的所有行数据连续存放
查询效率
适合整行读取（如事务、单条记录查询），但查询少量列时需加载整行数据，IO开销大
适合列投影查询（如统计、聚合、筛选少数列），仅加载需要的列，IO效率极高
压缩比
同列数据类型分散，压缩率低（通常 ...
