前言

之前在公司主要负责可观测性和 Pulsar 消息队列相关的内容，最近系统比较稳定，只需要做日常运维，所以就抽出时间逐步在接触 OLAP 相关的技术栈。

我们用的是 StarRocks，也是目前比较流行的 OLAP 数据库；在接触的这段时间以来，让我越发感觉到选对一个靠谱的技术方向的重要性。

今天收到球友的问题，让推荐一些值得看的开源项目，觉得 netty 这些太复杂了不太好上手。

确实如此，我们日常常用的 Spring、Netty 确实由于发展了多年，看起来比较头大。

下面我来推荐一些我看过同时觉得不错的项目(几乎都是我参与过的），由易到难，其中也会包含 Java 和 Go 的项目，包含主流的中间件和云原生项目。

前段时间给 StarRocks 的物化视图新增了一个特性，那也是我第一次接触 StarRocks，因为完全不熟悉这个数据库，所以很多东西都是从头开始了解概念。

为了能顺利的新增这个特性（具体内容可以见后文），我需要把整个物化视图的流程串联一遍，于是便有了这篇文章。

在开始之前简单了解下物化视图的基本概念：

简单来说，视图和 MySQL 这类传统数据库的概念类似，也是用于解决大量消耗性能的 SQL 的，可以提前将这些数据查询好然后放在一张单独的表中，这样再查询的时候性能消耗就比较低了。

背景

最近在排查 starrocks 线上的一个告警日志：

每隔一段时间都会打印 base-table 也就是物化视图的基表被删除了，但其实表还在，也没人去删除；我们就怀疑是否真的表被删除了（可能是 bug）。

与此同时还有物化视图 inactive 的日志，也怀疑如果视图是 inactive 之后会导致业务使用有问题。

为了确认这个日志是否对使用影响，就得需要搞清楚它出现的原因；于是我就着手从日志打印的地方开始排查。

最近业余时间花了小三个月重构了 cim，也将版本和升级到了 v2.0.0，合并了十几个 PR 同时也新增了几位开发者。

其中有两位也是咱们星球里的小伙伴🎉

前几天排查了一个业务接口执行高延迟的问题，也挺有参考意义的，分享一下排查过程。

现象是业务反馈有一个接口业务逻辑其实很简单，但是调用一次耗时，如下图所示：

SDK 设计

在之前提到了 cim 在做集成测试的时候遇到的问题，需要提供一个 SDK 来解决，于是我花了一些时间编写了 SDK，同时也将 cim-client 重构了。

背景

最近这段时间在处理一个 StarRocks 的关于物化视图优化的一个问题，在此之前其实我也没有接触过 StarRocks 这类主要处理数据分析的数据库，就更别提在这上面做优化了。

在解决问题之前我先花了一两天时间熟悉了一下 StarRocks 的一些概念和使用方法，然后又花了一些时间搭建环境然后复现了该问题。

之后便开始阅读源码，大概知道了相关代码的执行流程，但即便是反复阅读了多次代码也没有找到具体出现问题的地方。

所以便考虑在本地 Debug 源码，最终调试半天之后知道了问题所以，也做了相关修改，给社区提交了 PR，目前还在推进过程中。

最近有时间又把以前开源的 IM 消息系统捡起来继续开发了（确实这些年经常有朋友催更）。

没错，确实是这些年，因为上次发版还是再 2019 年的八月份。

这段时间比较重大的更新就是把元数据中心抽离出来了，以前是和 zookeeper 的代码强耦合在一起的，重构之后可以有多种实现了。

背景

因为公司内部在使用 PowerJob 作为我们的分布式调度系统，同时又是使用 OpenTelemetry 作为可观测的底座，但目前 OpenTelemetry 还没有对 PowerJob 提供支持，目前社区只对同类型的 XXL-JOB 有支持。

恰好公司内部也有一些开发同学有类似的需求：

于是在这个背景下我便开始着手开发 PowerJob 的 instrumentation，最终的效果如下：