MeteorCat Blog

官方网站: Pekko 在网络开发中, Actor(参与者模型) 是一种并发编程模型, 核心思想是将程序拆分为一个个独立和自治的 Actor 实体, 每个 Actor 拥有自己的状态和行为, 仅通过异步消息传递进行通信, 互不直接共享内存, 带有以下特性: 独立性: 每个 Actor 都是独立的执行单元且有自己的私有状态, 外部无法直接修改其状态, 只能通过发送消息触发 Actor 内部逻辑来改变状态 异步消息传递: Actor 之间的通信是异步和非阻塞的( 发送方把消息丢给接收方的消息队列后就继续执行,接收方按照消息到达顺序依次处理) 单线程处理: 一个 Actor 在同一时间只会处理一条消息, 天然避免了多线程共享状态的竞态问题, 不需要加锁(如synchronized) 地址与标识: 每个 Actor 有唯一的地址, 发送消息时只需指定地址, 无需关心 Actor 的物理位置(本地或远程), 这为分布式系统提供了天然支持 传统多线程模式需要手动处理锁、线程池、资源竞争, 否则容易出现死锁、数据不一致等问题 Actor 主要解决的问题: 共享状态的并 ...

在 Java 项目开发中, 多模块(Multi-Module) 是基于 Maven|Gradle 等构建工具实现的项目结构设计模式, 主要核心是将一个大型项目拆分为多个功能独立和职责单一的子模块(Module), 通过构建工具管理模块间的依赖和打包流程. 看起来很理想, 将代码合并在共同项目下复用大量的功能逻辑从而避免重复开发, 可以减少大项目之后大量冗余代码. 但是实际操作问题点很多, 最终在大量现实问题当中只能直接放弃 Java 的多项目管理, 这里说下主要踩坑的点: 无法单独项目独立: 项目都是寄放在同个 git 仓库, 也就是代表 clone 就能把所有业务秘密全导出(加密哈希和字段检验方式) 循环交叉依赖: 有时候业务很容易出现双方模块做交叉依赖, B 项目交叉用到 A 项目的验证库, C 项目也依赖 A 项目, 升级都要跟随升级 模块编译复杂度提升: 因为归到同个 git 库(比如区分 user/pay 等业务), 某个业务增加新业务提交上去一变动就要全部检测编译 业务堆叠在相同版本库: 所有业务都集中在一个版本库, 日积月累所有人提交版本导致堆叠在一起, ...

最新版本版本的 nginx 相关源(debian 及其发行版)已经集成 Nginx 的 Lua 扩展, 不需要再去手动编译处理相关依赖就能让 Nginx 运行些简单的 Lua 服务: 123456789# 安装 nginx 和 nginx-lua 扩展sudo apt install nginx nginx-extras libnginx-mod-http-lua# 确认是否配置完成, 有输出即可ls -l /usr/lib/nginx/modules/|grep lua# 生成测试配置, 后续在此操作sudo mkdir -p /etc/nginx/lua.d/lib # 生成被 nginx 调用的目录 sudo touch /etc/nginx/conf.d/lua.conf # 测试访问 Lua 功能配置 首先必须要要提醒一下: 不要将日常需求业务在网络基建实现! 能够在 nginx 运行 lua 也就代表能够运行业务代码, 但是这种操作是具有毁灭性的; 业务代码大部分时候逻辑复杂且需要用到大量现代技术(线程池|连接池等), 而内部的 Lua 模块仅仅作为内迁脚本系统是无法实现复 ...

有时候需要提供将影视资源 影片点播 这种类似的功能, 方便将服务器的影片直接在线播放; 虽然 mp4 文件直接挂个 nginx 服务播放, 但是影片资源不止有 mp4, 还有其他主流比如 flv 等格式. 大部分资源只是按照通用格式采用 mp4, 还有其他类似 .avi/mov/wmv/mkv/flv 等, 浏览器仅能支持 mp4 所以我们需要处理的就是将资源利用 ffmpeg 推流, 可以类似于直播一样播放我们服务器的影片资源 注意: 不止播放家庭影视资源, 还能涉及到家里监控推到自己内网服务器保存, 还有其他很多种玩法 需要明确在推流过程当中的定义: 要实现全天推流需要提供 推送端(推) 和 发布端(拉), 本质上就是要构建视频流推/拉流 需要搭建支持 rtmp 等协议的 hls 流媒体网络服务(充当转发平台) 需要 ffmpeg(服务端)|OBS(桌面端) 做流推送到流转发平台 默认的源安装 Nginx 不支持 nginx-rtmp-module 相关模块, 手动编译就感觉没什么必要, 不过在 debian 系的 Linux 发行版的源追加第三方扩展方便直 ...

传统都是依靠 /etc/resolv.conf 来处理 DNS 解析, 但是新的 linux-systemd 系统转而采用 resolved.service 处理网络解析服务. 而目前如果只要不是太老的 linux 版本建议都直接采用 resolved 相关工具链来维护处理服务器 DNS 相关; resolved 实际上是一整套的工具链, 本质上其实就是在本地开启开启个小型的 DNS 服务端, 常规操作如下: 1234567891011121314151617181920# 查看目前的服务器解析路由状态, 可以看到所有网口链路sudo resolvectl status# 查看目前的DNS系统单元状态sudo systemctl status systemd-resolved.service# 上面的命令都可以看到网口对应 DNS 服务及其上游# 当然借助这个工具可以手动指定全局 DNS 公共服务器sudo resolvectl dns all 8.8.8.8 223.5.5.5# 也可以指定 eth0 网口服务采用的 DNS 服务器sudo resolvectl dns eth0 8 ...

这里以 debian 为例子, 一般能够看到为了国内源从而配置修改相关的 sources.list 等文件, 目前有以下集中源配置: sources.list: 直接源配置 DEB822: 新的安全配置源 比如下面的的源格式: 123456789# sources.list 经典的远程源配置deb http://mirrors.ustc.edu.cn/debian trixie main contrib non-free non-free-firmware# DEB822 格式远程源配置, 追加 gpg 签名做安全验证, 'SignWith: no' 代表不启用签名验证 Types: debURIs: http://mirrors.ustc.edu.cn/debianSuites: trixie trixie-updatesComponents: main contrib non-free non-free-firmwareSigned-By: /usr/share/keyrings/debian-archive-keyring.gpg 如果要自己做内网二进制打 ...

之前公司内部都是采用 Gitea 做自己平台的内网脱管, 但是自从 Gitea 被其他公司收购后为了避免后续的商业纷争, 原版本 Gitea 额外分出 Forgejo 这个开源分支. 官方网站: forgejo 这里还是需要说明下个人的 Git 自托管服务系统配置: 系统: 主流 Linux 发行版(Ubuntu 22.04/Debian 12/CentOS Stream 9 以上版本等) 硬件: 最低 1GB 内存, 1 CPU 核心, 10GB 磁盘(生产环境建议 2GB+ 内存,当然内存越大越好) 网络: 服务器需开放 22(SSH, 可以自定义端口设定), 80(HTTP)|443(HTTPS),3000(Forgejo 默认端口)端口 依赖: Git(必须), 数据库(可选，SQLite/MySQL/MariaDB/PostgreSQL), Docker(采用容器部署才需要) 这里采用 debian/ubuntu 系统搭建, redhat 系的搭建方式可能有所不同 首先是必须要的组件, 我这里采用的 MariaDB 数据库配置: 123456789 ...

这里主要讲解的是 WebDAV 服务, 主要核心作用是让客户端(电脑|手机|服务器) 通过网络远程访问/编辑/管理服务器上的文件,和传统的传输功能相比较如下: 协议类型 全称 核心用途 适用场景 特点（优势/劣势） 与 AI 部署的适配性 WebDAV Web-based Distributed Authoring and Versioning 基于 HTTP/HTTPS 的通用文件访问 跨平台（Windows/Mac/Linux/手机）、公网访问、目录挂载、实时协作 优势：无客户端依赖、支持 HTTPS 加密、穿透防火墙、可挂载为本地目录；劣势：传输速度中等、大文件断点续传支持一般 ✅ 高（跨设备共享模型/知识库、无需重复存储、安全公网访问） SMB Server Message Block 局域网文件共享（Windows 默认） 家庭/办公局域网、Windows 为主的环境、高速文件传输 优势：速度快、支持文件锁/权限控制、大文件传输稳定；劣势：公网访问不安全（需额外加密）、Linux 兼容性一般 ✅ 中高（局域网内 Windows/Mac 访问服务器模型/数据集 ...

一般来说个人部署 AI 服务是及其耗费时间和精力(还有可怕的满载电量和噪音), 但对于小规模的个人来说, 利用闲置的服务器设备部署个小型 AI 服务作为个人资料库其实也可以稍微玩玩. 而个人部署就推荐采用 ollama 来搭建, 按照官方文档来说其实最简单是采用 docker, 不过我这边本身就是闲置硬件也就是总结采用二进制安装部署就行, 不需要在套一层 docker 镜像. 注意: 本文涉及的很多网络相关可能需要 ‘工具’ 来处理, 否则网速基本上很慢没办法快捷部署 这里采用 ollama-linux 安装方式处理: 12345678910111213141516171819202122232425262728293031323334# 如果之前安装过, 需要手动先卸载清空, 执行以下命令cd /tmp # 现在临时目录, 二进制差不多2G左右sudo rm -rf /usr/lib/ollama# 下载安装 ollama 应用# 需要注意这里安装的是 amd64 的架构, 如果你是 arm64 架构需要换成 ollama-linux-arm64.tgz# 这里的安装包差不多 ...