Apache Airflow 重新唤起我的注意力是因为 Airflow 3.0 在近日 April 22, 2025 发布了，其二则是我们一直都有计划任务的需求，以下几种方案都太简陋- 用 Windows 的计划任务或 Linux 的 Cron 都不易管理，且有单点故障问题
- 在 Java Spring 项目中使用集群模式的 Quartz 有些麻烦，且对于 AutoScaling 也不怎么友好
- AWS 上用 CloudWatch Rule + AWS Lambda 的方案可靠性没有问题，但不适于监控
因此还有必要再次尝试 Apache Airflow, 它有集中管理的界面，各个部件都是可伸缩的，如 WebServer, Workers 等。特别是刚出的 Apache Airflow 3.0 带来以下主要新特性- 新的服务化架构，各个部件间耦合度降低
- 多语言支持，借助了 Task SDK, 可望用 Java, JavaScript, TypeScript 等语言写 DAG
- DAG 支持版本控制，可回溯历史
- 支持事件驱动，即 DAG 可响应外部事件，如文件到达，消息队列等
- 引入了资产驱动调度功能，可根据数据资产的变化 进行触发，可以说是事件驱动的一类
- 全新的 React UI 界面
Read More
继续 TLS(或 SSL, HTTPS) 的话题。在我们诊断 HTTP 请求时，为了验证代码中发送了什么样的请求，会用 curl 或 Postman 的辅助，但它们都可能会带上额外的请求头等信息，最为可靠的办法是用网络抓包工具如 Wireshark, 从中看到的 HTTP 文本协议内容才是真正往外发送的内容。可是对于 HTTPS 的协议数据用 Wireshark 抓取到了也没用，因为它是加密了的，作为 TLS 的 Payload, 如果不知道加密算法或密钥是解不开来的。客户端与服务端的密钥交换是采用非对称方式加密的，只通过抓网络包是不可能知道最终确定的密钥是什么，除非像 Zscaler 那样堂而皇之地作为中间人攻击(man in the middle attack)。
但既然是本地浏览器能理解的网页内容，只要浏览器留了口子的话，也是有办法在 WireShark 中显示出抓取到的 HTTPS 的内容，那就是设置环境变量 SSLKEYLOGFILE, 然后启动浏览器(FireFox 或 Chrome), 就会把通信过程中的密钥记录到文件中，WireShark 中引用该 SSLKEY 文件就能显示出确切的 HTTP 请求的内容。 Read More
本人近十来年来本地用 Mac OS 开发, 服务器为 Linux, 为什么又要涉及到 Windows 的 GCC 呢？因为有个跨平台的东西用的是 C++, 需要分别编译出目标平台为 Linux 和 Windows 的二进制文件. 然而 C++ 并没有像 Rust 那样一出生就含着 Cargo 那样的工具链，完美的支持跨平台开发，构建。对于 C++ 代码不得不在 Linux 下用 GCC 编译器(Makefile), 而 Windows 下使用的 Visual Studio 的 MSBuild, 为了能统一用 Makefile 文件 + GCC 的方式编译 C++ 项目, 可选择 Windows 平台下也安装 GCC。
GCC 又是什么呢？它是 GNU 的编译工具集，包括对 C, C++, Objective-C, Foratran, Ada, Go 和 D 等一众语言的支持， 和它类似的工具集有 LLVM。GCC 支持多操作系统平台，怎么找到它的各种二进制安装包呢？我们循着官网去找, 打开 GCC 首页 https://gcc.gnu.org/，从页面的右边栏可找到 Read More
Rust 的 Ownership 感觉仍然很复杂，但 Rust 官方文档 The Rust Programming Language - Understanding Ownership 所费篇幅似乎并不多。下面就阅读该文档并记录下来对 Rust Ownership 的理解，相信官方的文档会表述的比准确而清晰。
本文中对 Ownership, Move, Reference, Dereference, Mutable, Immutable, Borrow, Owner, Stack, Heap, Scope 等词不进行翻译，以免走样。同时在阅读过程中不进行过度的联想，不与 C/C++ 的引用, 指针, 指针的指针进行关联，力求做一个完全不会 C/C++ 的 Rust 初学者。
Ownership 是 Rust 独一无二的特性。内存管理一般是两种，显式分配与释放和 GC, 这两种的弊端无需多说。Rust 另辟溪径，用 Owership 的一系列的规则来指导怎么管理内存，编译期保证程序运行期的内存安全性，不影响运行时性能。学习 Rust 的过程中需要很长时间去适应 Ownership, 从 Rust 开发者(Rustacean) 的经验来说是：随着对 Ownership 的掌握，越来轻松自然的写出安全高效的代码(希望如此)。 Read More
有好长一段时间没使用 Redis 了，之前用的都是 AWS 上的 Elastic Cache 的 Redis, 那时候还是用的版本还是 4 和 5。在新的项目由于觉得 Elastic Cache Redis 太贵而未曾使用，在去年的 AWS re:Invent 2023 上发布了 Elastic Cache Serverless，对于非长时间大数据的缓存可以考虑使用。而且还可以使用 Redis 的功能对服务进行解耦合，或作为一致性的协调中心。
此文是作为正式研究使用 Redis Stream (Redis 5.0 新特性) 的一个铺垫，探索在 Redis Stream 之前，可以何种方式把 Redis 当成一个消息队列，后面将会具体讲到如何用 Redis Stream 作为一个支持消费者组，能确认消息的更为完备的消息队列。
如以下几种方式- Pub/Sub 订阅模式
- 基于 List 的 LPUSH + BRPOP 的实现
- SortedSet, 使用消息 Score 排序功能进行消费
Pub/Sub 订阅模式
它就像 AWS 的 SNS 一样，只有在线的订阅者才能收到消息，每个消费者会收到相同的消息。相关的 Redis 命令是 *sub*, *pub*, 参考 Redis Command group Pub/Sub。订阅的时候可以直接指定 Channel 名称，或用模式匹配，还可关注某些 Key 的事件。 Read More
开源虚拟机软件 VirtualBox 从当初不可一世的 Sun 易手到 Oracle 之间，变得不那么被许多公司信任了。之前一直是用 Vagrant 搭配 VirtualBox 在 Mac 下使用 Linux 虚拟机，因为不需要用到 Linux 桌面，用 Vagrant 操作虚拟机非常方便。但现在不得不要考虑别的方式，那就是 Vagrant + Qemu。Vagrant 的默认 Provider 是 VirtualBox, 我们搜索 Vagrant Box https://app.vagrantup.com/boxes/search 的时候，注意到 Vagrant 其实支持的 Provider 是一个很长的列表:aws, cloudstack, digitalocean, docker, google, hyperv, libvirt, lxc, openstack, parallels, qemu, rackspace, softlayer, veertu, virtubalbox, vmware, vmware_desktop, vmware_fusion, vmware_ovf, vmware_workstation, vsphere, xenserver
有些尚未听说过，还有一些虽说支持，但别人提供的相应的 box 不多，Qemu 还算不错的 virtualbox 的替代品。Qemu 也是一款开源的虚拟机软件，它支持 Linux, macOS 和 Windows 平台，但它本身未提供友好的 UI 工具，所以创建一个 Qemu 虚拟机的命令会让人畏而却步。在 macOS 下有一个 Qemu 的 UI 工具 UTM Read More
使用 JDK 5 的线程池实现有近 20 年的时间了，快速创建一个线程池经常是调用 Executors 中的工厂方法。但是涉及过更精细的线程池管理控制时不得不用 ThreadPoolExecutor 的构造方法，这也就是为什么有些公司不建议用 Executors 的工厂方法创建线程池，而应该直接创建 ThreadPoolExecutor 或 ForkJoinPool 实例。
例如代码ExecutorService threadPool = Executors.newFixedThreadPool(10);
实际上调用的是new ThreadPoolExecutor(nThreads, nThreads,
前两个参数 corePoolSize 和 maximumPoolSize 是一样的; OL, TimeUnit.MILLISECONDS 表示线程创建后只要线程池还在就是永生的; workQueue 是一个大小为 Integer.MAX_VALUE 的队列， 几乎可以无限提交任务，耗尽内存
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
不建议用 Executors 的工厂方法的原因大致有二： Read More
为了紧跟 Spring 6 的步伐，Spring Boot 在 2022 年 11 月 24 日释放了 3.0.0. 当前版本是 3.0.1(2022-12-23)。Spring 6 要求用 JDK 17+, Spring Boot 3 自然也要上 JDK 17+ 才能使用，对于一直死死抱住 JDK 8 不放的要升级到 Spring Boot 3 就是个比较大的挑战。
Spring Boot 到底带来了什么显著的特性呢？- 依赖于 Spring 6, 最低 Java 17, 兼容 Java 19
- 支持生成 GraalVM 本地映像，取代实验性的 Spring Native 项目
- 最低 Java EE 9 和支持 Jakarta EE 10
- 依赖从 Java EE 迁移到 Jakarta EE API
- 升级到 Tomcat 10
从 Spring Boot 2.x 升级到 Spring Boot 3 的指南请阅官方的文档 Spring Boot 3.0 Migration Guide。Spring Boot 1 的项目还得老老实实的先升级到 Spring Boot 2，如果是早期的 Spring Boot 2，第一步是升级到 Spring Boot 2.7.x， 一步步来，免得步子大了扯到X。再到是把 JDK 换成 17 或更新的版本，编译，运行，有问题就改代码。 Read More
一谈到 Docker 容器，按照以往的惯性思维，那就是 Linux 容器(LXC)，和 Windows 没多大关系，顶多也就是在 Windows 的 Linux 虚拟机中跑 Docker 容器。
不过自从 Windows Server 2016 开始，出现了 Windows 原生的 Docker 容器，它再也不只是 Linux 下的专利了。Docker 容器中可以运行 Windows 系统了, 每个 Windows 容器共享宿主机的 Windows 内核(--isolation=process,)，或使用一个高度优化虚拟机中的 Windows 内核(--isolation=hyperv)。
我们说自 Windows Server 2016 开始，包括现在的 Windows Server 2019, Windows Server 2022, 还有桌面系统的 Windows 10 和 11 上 借助于 Docker Desktop 也能跑 Windows 容器。
原本在 Windows 桌面版上安装 Docker Desktop 就能用来运行 Linux 容器，由此可知在 Windows 桌面版上(如 Windows 7, 10, 11) 可运行两种类型的容器- Linux 容器: 每个容器运行的是 Linux 实例，用 cgcroups 命名空间隔离资源。默认的，使用 Docker Desktop 的 LinuxEngine
- Windows 容器：容器中运行的是 Windows 实例，进程隔离模式是容器共享主 机的 Windows 内核，Hyper-V 隔离模式是容器使用高度优化虚拟机的内核。需启用 Windows 的 Hyper-V 特性，并切换 Docker Desktop 使用 WindowsEngine
Read More