- 博客(34)
- 收藏
- 关注
RSS订阅原创 极致工程之美：Kafka 时间轮与 LevelDB LSM-Tree 的架构同构赏析
Kafka分层时间轮与LevelDB LSM-Tree虽服务于不同场景，却共享同一设计哲学：在高吞吐与有限资源的困境中，以幂次分层、局部吸收与级联下沉破局。二者均通过指数级扩张的层级结构，将高频操作限制于浅层，低频归并沉淀于深层，实现时间与空间维度的高效调度。其核心思想在于：允许局部无序以换取全局稳定，借由降频级联重构秩序，体现了系统工程中“以退为进”的极致优雅。
2026-11-05 09:53:30
150
原创 极致工程之美：Nginx 与 LevelDB 侵入式队列（Intrusive Queue）架构赏析
本文深入剖析侵入式数据结构在高并发基础设施中的核心价值，揭示其如何通过零内存分配、极致缓存局部性与天然排他性，突破传统非侵入式容器的性能瓶颈。以LevelDB的LRUHandle与Nginx的ngx_queue_t为例，展示侵入式设计在双层缓存、事件调度等场景下的高效实现；进一步探讨多重侵入式复合结构（如哈希+双向链表、红黑树+队列）如何优雅解决多维度挂载难题。文章提出生命周期对齐与正交性规划等工程准则，并推荐现代C++中使用Boost/Folly等成熟库实现安全高效的侵入式编程，为底层系统优化提供完整架构
2026-11-03 14:57:40
96
原创 关于 Redis 锁与 MySQL 锁的苏格拉底式对话
但请设想这样一个清晨：你的代码刚刚从 Redis 手中接过这把锁，正准备更改账户，却突然遭遇了 JVM 严酷的垃圾回收停顿（Full GC STW），亦或是外部网络陷入了长久的静默。告诉我，在第三十一秒的瞬间，Redis 里的锁还在吗？：老师，我彻底迷茫了。：而就在此刻，另一个等待多时的线程走上前去，看见 Redis 门扉虚掩，于是也拿到了一把崭新的锁，踏入了同一个房间。：告诉我，泰阿泰德（Theaetetus），当你给自家门庭安上一把精巧的锁时，你追求的究竟是“锁芯转动的速度”，还是“门后金银的周全”？
2026-10-09 10:48:40
39
原创 开放—封闭原则实战（下）：基于策略的流程编排与编译期多态
本文以“流程骨架固定、细节多变”为切入点，通过模板与策略设计（Policy-Based Design）实现业务内部流程的编译期无感扩展。基于ShippingFlow模板，将校验规则抽象为独立策略类，无需虚函数与接口继承，依靠编译期契约约束，实现零开销内联与即时错误检测。相比运行时多态，该方案彻底贯彻开放-封闭原则，支持新增业务时仅需定义新策略并组合，公共流程零修改，真正达成“一次编写，无限扩展”的极致灵活性。
2026-09-30 13:26:17
330
原创 从“大基类”到“接口 + 上下文”：现代 C++ 系统架构的解耦之道
该文揭示了“大基类”设计在定时任务系统中的深层缺陷：将基础设施与业务逻辑强耦合，导致依赖注入困难、测试复杂、资源浪费。通过引入“上下文对象（Context）”模式，以纯接口形式传递运行时能力，实现业务与框架的解耦。上下文由调度引擎在栈上动态创建，业务仅依赖抽象接口，无需知晓具体实现，既支持灵活注入与单元测试，又保障并发安全与性能。此设计体现了“依赖倒置”与“信息隐藏”的核心架构思想。
2026-09-30 11:13:20
406
原创 从精确排序到时间分桶：Nginx timer 红黑树、Redis跳表与Kafka时间轮
Nginx、Redis与Kafka分别采用红黑树、跳表与分层时间轮，应对高并发系统中对象按序调度的挑战。三者均通过将业务对象内嵌管理节点，实现状态与调度分离，避免线性扫描。选择依据在于核心操作：Nginx重在精确最小值查找，选红黑树；Redis需范围遍历与排名，跳表更优；Kafka面对海量高频增删，时间轮以粗粒度分桶换取稳定吞吐。本质是根据“维护秩序”的成本与收益权衡，而非单纯性能对比。
2026-09-22 14:40:56
218
原创 Little 定律与 Gateway 链路并发分析
Gateway 增加鉴权与转发链路后，平均响应时间上升，根据 Little 定律，维持相同 QPS 需提升并发量。例如从 40ms 升至 50ms，所需并发由 960 增至 1,200。但增加并发仅为必要条件，非充分条件——若 EventLoop、线程池或下游服务已达瓶颈，继续扩容只会加剧排队与延迟。压测显示，超并发后 QPS 不升反降，P99飙升，印证系统已进入饱和区。因此，必须结合平均耗时、各层资源使用率综合评估，避免以增加并发掩盖真实瓶颈。
2026-09-18 17:30:51
284
原创 Spring Cloud Gateway 的性能优化之路：鉴权调用模型的演进
跳过鉴权基准 | 分离鉴权成本和代理成本 | 纯 Netty 路径约 3,172 QPS，较 Tomcat 路径 2,226 QPS 提升约 42.5% | 纯 Netty 能降低代理层开销 || JWT 本地验签（推荐方向） | 消除每次鉴权的远程 Redis 等待 | 预计可降低鉴权延迟和 Redis 压力，需单独压测验证 | 更适合长期 Gateway 架构 |> 如何在保证“鉴权完成后才能转发”的前提下，避免同步鉴权阻塞 Gateway 的核心网络线程，并确认不同方案对吞吐和延迟的实际影响。
2026-09-17 17:58:29
162
原创 从一个成员指针找回完整对象：Nginx 中的 container_of、连接复用与定时器（总结自AI的对话）
业务对象内嵌通用节点↓队列或红黑树只管理通用节点↓处理时用 offsetof 反推出业务对象↓通过 handler 或 data 进入具体逻辑posted event 使用queue成员和；timer 使用timer成员和。它们都是标准的应用。则展示了同一种“对象自身充当节点”的侵入式思想，但链中直接保存完整连接指针，所以不需要反推地址。与之相邻的 reusable connections 队列才真正通过使用。
2026-08-11 17:45:56
363
原创 开放封闭原则的应用（上）
本文系统讲解了开放-封闭原则(OCP)在物流配送系统中的应用实践。通过配送业务扩展的案例，展示了如何通过以下设计实现OCP： 使用虚函数接口(IShippingTask)统一业务调用方式 采用工厂模式(ITaskBuilder)解耦对象创建 引入注册机制(TaskDirectory)实现运行时扩展 利用模板(ShippingFlow)封装稳定处理流程 通过模板参数(Gate)实现编译期扩展检查规则 关键点在于区分运行时扩展(业务类型)和编译期扩展(检查规则)，将变化限制在特定扩展点周围，保持核心流程稳定。设
2026-08-06 15:38:25
376
原创 消失的发布包
一次服务发布中，编译、打包目标均显示成功，但部署节点提示找不到目标可执行文件。更奇怪的是，目标发布包解压后没有对应服务，里面却装着多个其他服务的旧压缩包。
2026-07-16 18:36:36
206
原创 高一致性 Kafka 消费实现方案
本文提出了一种高一致性的Kafka消费实现方案，重点解决了消息消费过程中的重试、死信处理和Offset提交等关键问题。方案采用分层架构设计，包含消费模块和生产模块：消费模块通过Manager-Worker结构实现多线程管理，Worker负责消息拉取、业务处理、重试/死信决策及Offset提交；生产模块通过Outbox模式保证消息可靠投递。方案特色包括：1)明确的at-least-once语义；2)业务与消费逻辑解耦；3)按ConsumerGroup隔离重试队列；4)灰度环境隔离支持；5)完善的监控告警体系。
2026-07-15 11:13:25
242
原创 C++ vs Java 核心机制对比（总结自ai对话）
本文总结了Java与C++在并发编程中的关键差异，重点对比了线程安全、内存模型和类型系统的实现方式。主要内容包括： 线程安全容器的实现差异： Java提供多种线程安全容器（Vector、CopyOnWriteArrayList等） C++标准库容器非线程安全，需手动加锁或使用第三方并发库 典型并发问题分析： 详细解析ArrayList.add()的竞态条件和内存越界问题 通过时序图展示扩容场景下的并发冲突 锁机制对比： 比较C++的std::mutex和std::shared_mutex 与Java的syn
2026-06-01 11:00:25
197
原创 TCP关闭链接4次握手(总结自Ai对话)
摘要：本文解析TCP四次挥手流程中的关键状态和常见问题。重点包括：1）TIME_WAIT始终出现在主动关闭方，而非固定客户端或服务端；2）CLOSE_WAIT表示被动关闭方收到FIN但未调用close()；3）TIME_WAIT默认持续1-2分钟，用于确保可靠终止；4）大量CLOSE_WAIT通常表明应用层未正确关闭连接。文章还解释了2MSL等待时间的必要性，并区分了各状态的业务含义和调优方向。
2026-05-18 20:08:45
410
1
原创 TARS 线程模型与 Servant 生命周期(总结自AI对话)
本文深入解析了TARS框架中Servant的注册与线程模型。通过分析addServant的调用链，揭示了从业务代码注册到实际实例创建的全过程：1）注册阶段仅存储创建配方；2）Handle线程启动时才真正创建实例；3）每个线程拥有独立的Servant实例，成员变量天然线程安全。文章重点阐述了线程数与实例数的对应关系，指出常见误区，并强调只有在访问共享资源时才需考虑线程同步。最后总结了完整流程和关键数据结构，帮助开发者正确理解TARS的多线程处理机制。
2026-05-14 17:57:47
358
原创 Apollo 配置中心分布式部署指南 (v1.7.2)
highLight:apollo 配置时很容易混淆 config svr 和 eureka，他们虽然是部署在一起，都是config svr 这个包内。但是实际上是两个业务。1 config svr 内置了 eureka，所以分布式部署，eureka 集群的配置，实际是通过 config svr 的配置来实现的。2 portal 配置了eureka 的各个节点地址（实际也是 config svr 地址）来进行服务发现（发现 config svr，admin svr）。
2026-03-04 16:59:27
424
原创 ＜不是不能，而是没必要系列＞分布式锁用redis就足够了
面试官提到 Redlock 的缺陷（如 Martin Kleppmann 的著名批评），你可以这样收尾：“Redlock 确实在分布式共识理论上不够纯粹，它过于依赖系统时钟。在对数据一致性有极致要求（如资金结算、库存强扣）的场景，我会优先选择etcd，利用其强一致性的 Raft 协议和更简洁的 MVCC 模型来实现分布式锁；而在高并发、对偶发性锁丢失有一定容忍度的互联网场景下，Redis 依然是性价比最高的方案。“在处理分布式锁时，Redis 是用‘时间’来换‘可用性’，它假设时钟是基本准确的；
2026-01-06 20:10:22
1044
原创 Windows 上因大小写变更导致 Git 无法commit提交的根本原因与解决方案
Git 想提交大小写变更，但 Windows 文件系统不认为大小写不同，所以 Git 既检测到变更又无法提交。
2025-11-20 10:02:03
1100
原创 Mac M1 芯片装 linux虚拟机
mac 上使用 docker 问题太多，决定还是装个 linux 虚拟机使用 docker。1 不要使用apple 虚拟化。会导致无法进入安装页面。2 安装后重启，要退出 iso。否则还是进入安装页面。
2025-07-23 14:53:09
342
原创 tars客户端源码解析
实际上，这篇tars基金会的文章，代表了很高的水平，个人认为很难写出更好的说明了。如果想了解tars客户端逻辑，建议先读一下这篇。
2024-09-26 09:29:15
376
原创 ios抓包程序Stream安装后，无法抓取https的问题
一定要用safari浏览器下载ca证书，才能在下载证书后，在设置中展示出来。2 安装后操作界面点击开始抓包，会提示安装vpn配置。然后会提示安装证书。安装证书时，操作了多次，始终无法抓https的包。描述文件button会出现，然后点击安装就可以了。1 首先安装这个app。免费的，功能也很聚焦。
2024-03-25 10:42:10
5658
原创 librdkafka svr总体逻辑
2 每个层之间不是直接调用，而是通过内部队列的入队列和callback。不得不说，这样的确给代码阅读带来困难。在没有阅读librdkafka的源码之前并不知道，这个库简直就是一个服务svr，而不是一个sdk。1 服务分层做的不错。svr层，broker层，transport层，三层结构清晰。很少有见到一个sdk，内部包含如此多的状态机（尤其是消费者组的状态维护）。
2023-07-20 19:44:22
128
原创 librdkafka的队列rd_kafka_q_t(rd_kafka_q_s)
2 每个队列有一个rd_kafka_q_serve_cb_t结构的回调处理器，即处理callback。其核心是一个rd_kafka_op_tailq结构的rkq_q变量。1 读写分离：有一个rd_kafka_q_s类型的内部队列，用于专门用于读。当然还少不了锁相关的mtx和condition。rdkafka的内部消息都是通过这个结构传递。
2023-07-04 15:00:40
205
原创 librdkafka cgrp层源码
rdkafka_cgrp仅仅处理【消费者组】相关操作，比如join group, sync group，不处理消息的拉取和offset commit等消息相关的操作。
2023-06-29 15:12:14
151
1
原创 librdkafka transport层源码解读：
rd_kafka_transport层算是库的最底层了，主要处理网络事件。rd_kafka_transport_io_serve是其中的主要逻辑。
2023-06-29 11:45:27
169
1
原创 librdkafka的broker源码阅读
>>rd_kafka_broker_producer_serve为例（rd_kafka_broker_consumer_serve另说）>>>>>rd_kafka_toppar_producer_serve：直接推送到kafka。>>>>>>rd_kafka_broker_op_serve:处理单个op类型。>>>>rd_kafka_broker_ops_io_serve处理应答。
2023-06-28 17:46:16
185
1
原创 rd_kafka_background_thread_main都main了些啥
日志消息：当 Kafka 客户端产生日志消息时，可以通过 background_event_cb 回调函数获取这些日志消息。统计信息：当 Kafka 客户端产生统计信息时，可以通过 background_event_cb 回调函数获取这些统计信息。错误消息：当 Kafka 客户端发生错误时，可以通过 background_event_cb 回调函数获取这些错误消息。rd_kafka_background_thread_main乍一看名称，似乎也有。
2023-06-27 19:20:44
175
1
原创 rd_kafka_thread_main都main了些什么
2 如果是消费者，启动 rd_kafka_cgrp_serve.主要完成消费者的状态维护。比如JoinGroup, SyncGroup, Fetch, CommitOffset等。1 启动rd_kafka_q_serve. 主要完成op队列的消费和callback触发。不管producer还是consumer，都要调用该方法。注意：并不会处理poll消息的操作。核心代码其实就如下部分。
2023-06-27 18:51:21
181
1
原创 librdkafka源码阅读：rd_kafka_q_serve和rd_kafka_q_pop_serve
--->如果是RD_KAFKA_OP_CB 类型，则调用rd_kafka_op_call callback。-->如果有fwd_q（使用rd_kafka_q_fwd_get获取）, 那么处理fwd_q的消息并返回。1 这是一个阻塞方法。--->rd_kafka_op_handle_std标准op处理。-->否则 rd_kafka_q_deq0弹出op，--->callback特殊约定的callback。-->rd_kafka_op_handle处理。----->使用rko->rko_op_cb方法。
2023-06-21 15:14:19
511
原创 cpp kafka源码阅读：buffered_producer之同步flush
>rko->rko_op_cb（） 完成回调。->.....剩余步骤都一样。上图分析可见是同一个线程。
2023-06-15 11:18:01
261
1
原创 cpp kafka源码阅读：buffered_producer之AckMonitor
此时检查tid1的get_current_thread_pending_acks_impl会返回true。2：之后某个时刻sent_acks=101， last_acks_[tid2]=101， 此时last_acks_[tid1] = 100不变。AckMonitor的该方法判断某线程的消息是否都有ACK，只是简单比较了已发送消息计数sent_acks_的最大值。1：某个线程的last_acks_[tid1] = 100， 但是received_acks_=99。这样的实现是很精巧。
2023-06-14 15:05:31
120
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人