crossoverJie的内卷小课堂

Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。 我个人觉得再忙的团队 Code Review

最近我们在使用 StarRocks 的时候碰到了一些小问题： 重启物化视图的时候会导致视图全量刷新，大量消耗资源。

前段时间升级了生产环境的 StarRocks，从 3.3.3 升级到了 3.3.9，期间还是踩了不少坑所以在这里记录下。 因为我们的集群使用的是存算分离的版本，也是使用官方提供的 operator 部

这些年我一直都是按照农历新年来写年终总结的，都说不出正月都是年，前些年一直都比较规律，今年确实是时间超了一些。 主要原因还是年末接了个活，需要在年初上线，导致这段时间都没太多时间写内容。 最近事情终于

最近这段时间一直在做服务网格（Istio）相关的工作，背景是我们准备自建 Istio，首先第一件事情就是要安装。 我这里直接使用官网推荐的 istioctl 进行安装： 这里我使用的

今天在 HackNews 上看到一个帖子：你们是否很难回忆起在工作中做了哪些贡献？ 我觉得挺多人都有类似的问题，通常都是在需要面试或者内部晋升的时候才开始思考这些问题，这时候在想的话难免会有遗漏。 结

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

今天收到球友的问题，让推荐一些值得看的开源项目，觉得 netty 这些太复杂了不太好上手。 确实如此，我们日常常用的 Spring、Netty 确实由于发展了多年，看起来比较头大。 下面我来推荐一些我

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

前几天排查了一个业务接口执行高延迟的问题，也挺有参考意义的，分享一下排查过程。 现象是业务反馈有一个接口业务逻辑其实很简单，但是调用一次耗时，如下图所示： 排查应用运行状态 首先第一步需要查看当时的应

最近在排查 starrocks 线上的一个告警日志： 每隔一段时间都会打印 base-table 也就是物化视图的基表被删除了，但其实表还在，也没人去删除；我们就怀疑是否真的表被删除了（可能是

本文介绍了IM通信SDK的重构与优化，包括集成测试、动态URL调用和客户端重连机制。通过简化API和引入Builder模式，提高了代码的易用性和维护性。同时，支持了集群版测试，确保服务高可用性。

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

最近有时间又把以前开源的 IM 消息系统捡起来继续开发了（确实这些年经常有朋友催更）。 这段时间比较重大的更新就是把元数据中心抽离出来了，以前是和 zookeeper 的代码强耦合在一起的，重构之后可

因为公司内部在使用 PowerJob 作为我们的分布式调度系统，同时又是使用 OpenTelemetry

可观测性概念 当一个软件或系统出于运行状态时，如果我们不对他加以观测，那它的运行状态对我们来说就是一个黑盒。

在前面两篇实战文章中： OpenTelemetry 实战：从零实现分布式链路追踪 OpenTeleme

最近在给 opentelemetry-java-instrumentation 提交了一个 PR，是关

在上一篇文章：OpenTelemetry 实战：从零实现分布式链路追踪讲解了链路相关的实战，本次我们继

之前写过一篇 从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅的文章，主要是从概