存在morning-CSDN博客

原创【OLAP 学习笔记】Doris：数据湖之上的分析查询引擎

Paimon流批一体链路后，查询出口需亚秒响应。湖仓格式（如Paimon）虽列存高效，但面对Ad-hoc查询与高并发报表时，因任务调度慢、索引粒度粗而性能不足。此时OLAP引擎登场：Doris与ClickHouse均以列存、MPP、向量化执行实现快速分析。Doris出身百度广告系统，主打“高并发点查+复杂分析”双优，通过存算分离架构、多种数据模型（聚合/主键/明细）、Rollup物化视图及丰富索引体系，实现开箱即用的数仓报表能力；其核心优势在于对Ad-hoc场景的全面优化与强事务语义支持。相较之下，Clic

2026-10-09 23:05:37 281

原创【Paimon 学习笔记四】生产实战：三个场景讲透选型与参数配置

主键表 + bucket 按一年后量级定 + compaction 先默认后监控 + 快照保留 = 下游最大停机时间 + changelog 按上游来源和延迟要求选。append 表没有 LSM 版本合并，只有轻量小文件合并（不在关键路径上），配置回归朴素：定好分区字段（查询裁剪用）+ bucket 按写入并行度定，其他全默认。这也是 append 表的价值——能轻就轻。

2026-08-30 17:50:33 492

原创【Paimon 学习笔记三】工作流程：Paimon 的批写、流写、批读与流读

第二篇讲了存储架构——快照、manifest、LSM 树、bucket，是"零件"。结尾把写入/批读/流读的路径串了一遍，但每一步都是一句话带过。这篇把每一步拆开：谁负责写、谁负责提交、失败怎么办、changelog 从哪来。继续用订单场景：orders 表（主键表，2 个 bucket），order_001 在 10:00 到达、10:01 改状态。

2026-08-30 16:27:45 551

原创【Paimon 学习笔记二】存储架构：快照、manifest、LSM 树、bucket

第一篇把 Paimon 的定位说清了——“流存储上补批的能力”，起点和三剑客相反。但"LSM 树"和"快照"到底怎么落地？订单写进去之后，磁盘上是什么样子？这篇打开黑盒。

2026-08-30 12:40:51 772

原创【Paimon 学习笔记一】从 Hive 到Paimon: 大数据表发展历程

Flink SQL 系列里，订单表、城市维表、商品维表、订单宽表全都建在 Paimon 上——但一直只管用，没开过盒。第一篇先解决"为什么"。要理解 Paimon 出现的意义，得先回到它出现之前——Hive 是怎么干活的。

2026-08-29 22:23:41 459

原创【Flink SQL 学习笔记四】稳定性配置：State、Checkpoint 与生产参数

前三篇把订单链路跑通了：数据从 Kafka 进湖、按窗口聚合、关联维表出宽表。但这些都有一个前提——任务一直活着。生产上这个前提不成立：机器会宕机，大促前要扩容，改个 SQL 也得重启。窗口里算到一半的累加值、Temporal Join 存的商品历史版本，任务一停就全没了。凌晨三点挂了没人管，早上 GMV 报表就少一截。这一篇解决"活着"的问题：State 怎么存、Checkpoint 怎么拍、挂了怎么恢复、参数怎么定。

2026-08-28 23:15:43 724

原创【Flink SQL 学习笔记三】维表关联：Lookup Join、Temporal Join、窗口 Join

前两篇讲了流怎么进来、怎么聚合、怎么按窗口切分。但订单流里只有 ID——city_idproduct_id，大盘看板上总不能给运营看一堆数字吧？得把 ID 换成名称：北京、上海、iPhone 15、MacBook Pro。这就是 Join 干的事：把订单流和维表关联起来，补全业务可读的字段。

2026-08-28 22:27:20 523

原创【Flink SQL 学习笔记二】实时聚合：用窗口和 Watermark 把订单按时段统计

上一篇用做了全局聚合——从任务启动到现在，每个城市一共多少订单。但业务场景不是这么用的：大盘要看"每分钟订单量"，运营要看"近 5 分钟趋势"，日报要看"当天累计 GMV"。这些需求都有时间边界——按时段切分，而不是无限累加。这就是窗口解决的问题：把无限的数据流切成一段段有限的，每段单独聚合。

2026-08-27 23:31:31 528

原创【Flink SQL 学习笔记一】流批一体：Flink架构、动态表、第一个 SQL

数据从 Kafka 来，定义一张 Source 表对接 Kafka 的orders) WITH ('scan.startup.mode' = 'latest-offset', -- 从最新 offset 开始读'format' = 'json' -- 消息格式为 JSON。

2026-08-27 22:33:43 515 1

原创【PySpark 学习笔记六】性能优化：分区、Shuffle、缓存与数据倾斜

Shuffle = 数据跨节点重新分布当某个操作需要读取其他分区的数据时（比如groupByjoindistinct），Spark 必须把相同 Key 的数据从不同节点搬到同一个节点上。为什么聚合操作必须搬数据？以为例：要算北京的订单总金额，必须看到所有北京的订单。但北京的数据散落在 100 个节点上，每个节点只有一部分。单个节点只能算出局部小计，得不到全国总额。聚合操作的定义本身就是跨数据的——sumcountavg都需要看到全部数据才能算出正确结果。相比之下，filterselectmap。

2026-08-26 00:00:35 510

原创【PySpark 学习笔记五】SQL 协作：Spark SQL、临时视图、UDF

摘要本文介绍了Spark SQL的核心功能与应用场景，通过城市销售日报案例对比DataFrame API与SQL的差异。主要内容包括：双接口设计：Spark提供DataFrame API和SQL两种操作方式，底层共享Catalyst优化器，性能一致但适用场景不同。DataFrame适合复杂ETL，SQL便于临时查询。技术实现：详细讲解临时视图、内置函数分类（字符串/日期/数学/聚合/窗口）和UDF性能优化（Pandas UDF比Python UDF更快）。实践案例：从纯DataFrame实现逐步演变

2026-08-24 23:37:55 641

原创【PySpark 学习笔记四】业务分析：聚合、窗口与复杂数据类型

用一个问题引入：每个城市消费排名第 3 的用户是谁？用 groupBy 做不到——groupBy 后每个城市只剩一行聚合结果，拿不到"第 3 名"这种组内排名信息。# 定义窗口：按城市分区，按消费金额降序排列# 给每个用户在城市内排名# |上海 |u34567 | 87654.32 | 3 |# |北京 |u12345 | 76543.21 | 3 |# |广州 |u89012 | 65432.10 | 3 |# |...窗口函数的写法有个固定模式：函数.over(窗口定义)。

2026-08-23 22:29:26 450

原创【PySpark 学习笔记三】数据清洗：DataFrame API基础操作

本文介绍了使用PySpark DataFrame API完成从数据读取到写出的完整流程。通过电商平台用户消费分析案例，演示了以下关键步骤：创建SparkSession并配置Paimon Catalog 从Paimon表读取用户和订单数据数据清洗（过滤活跃用户、有效订单）聚合计算（用户级和城市级聚合）多表关联（inner/left join选择）空值处理与去重结果写出到Paimon表和Parquet文件流程重点包括Schema裁剪优化、聚合组合操作、join类型选择等核心技巧，适用于大规模数据处

2026-08-23 17:44:19 475

原创【PySpark 学习笔记二】内核探秘：Spark 架构与执行原理

摘要 PySpark代码通过懒执行机制构建执行计划，直到遇到写入等Action操作时才触发计算。Driver将逻辑计划转化为物理计划，拆分为Job、Stage和Task层级。数据按Partition分布，Task在Executor上并行处理。Shuffle是跨节点数据重分布的关键环节，性能开销最大。生产环境优先选用DataFrame API以获得最佳性能优化。整个流程从代码解析到分布式执行，体现了Spark高效处理大数据的核心原理。

2026-08-22 18:40:07 757

原创【AI时代下的一些感悟二】近期使用AI的一些感悟

AI是能力放大器而非许愿机：它能提升已有技能但无法替代专业判断力，编程新手仍需要掌握工程思维才能交付可靠项目。技术基础与演化史知识愈发重要，这些是判断AI输出质量的底层框架，也是防止被AI"虚假能力"迷惑的关键。合理使用AI加速学习需要保持主动思考，而理解AI的基础原理（如概率生成特性）能提升协作效率。作者采用模块化AI协作工作流，强调人工验收的核心作用，对当前多Agent系统持观望态度。本文揭示了AI时代专业人才的真实竞争力：对问题的深刻理解力、系统化思维和工程判断力。

2026-08-22 15:23:57 512

原创【PySpark 学习笔记一】从零开始：PySpark 基础概念

本文为Python开发者提供PySpark的快速入门指南，涵盖以下核心内容： Spark基础分布式计算引擎，解决单机处理TB/PB级数据的瓶颈统一批处理、流处理、图计算和机器学习四大场景 PySpark架构 Python作为交互层调用JVM端的Spark核心引擎通过Py4J桥通信，优先使用内置函数减少跨进程开销关键对比 Pandas：单机内存级数据处理 PySpark：Python生态+分布式能力，适合数据科学全流程 Scala Spark：原生性能最优，多用于大数据平台开发学习建议无需学习Sc

2026-08-18 23:20:23 489

原创【Python开发实践三】Python面向对象编程

本文是为有Java经验的开发者快速上手Python面向对象编程的指南。文章通过对比Java和Python的语法差异，重点讲解Python面向对象的核心概念，包括类的定义与实例化、构造方法__init__、self关键字的作用、类属性与实例属性的区别等。Python的面向对象更灵活简洁，支持动态添加属性，实例化无需new关键字，构造方法名为__init__，且必须显式使用self参数。此外，Python通过类属性和实例属性实现类似Java静态变量和实例变量的功能。文章采用代码对照方式，帮助开发者快速理解两种语

2026-08-17 23:18:12 302

原创【Python开发实践二】Python 基础语法与进阶特性

基础语法部分详细对比了模块入口（Python顺序执行 vs Java必须main方法）、变量定义（Python动态类型 vs Java强类型）和字符串操作（Python支持f-string等简洁语法）。通过"对比总结+代码示例+执行结果"的形式，帮助开发者建立知识映射，利用既有经验高效学习新语言。特别强调Python的语法简洁性，如多变量赋值、动态类型、

2026-08-14 23:22:56 361

原创【Python 开发实践一】Python vs Go vs Java 三门语言对比

摘要：Python、Go、Java三者在设计哲学和应用场景上差异显著。运行方式：Python为解释型，灵活但慢；Java需JVM，跨平台但启动慢；Go编译为单文件，部署便捷。类型系统：Python动态灵活，Java静态严谨，Go静态但支持类型推导。并发能力：Go的Goroutine最优，Java次之，Python受GIL限制。适用领域：Python主导AI/数据科学，Java扎根企业级开发，Go领跑云原生和高并发服务。选择建议：快速开发选Python，企业应用学Java，云原生方向攻Go。三者各有所长，互补

2026-08-14 21:55:02 479

原创【CMDB 全景知识入门二】企业信息化大盘及CMDB/CSDM 定位

为了能全面的理解企业信息化的内容以及CMDB在其中的位置，我尝试从架构设计的逻辑的多个视角去看待整个信息化平台。管理视角先画出静态能力地图，知道IT要管战略、建设、运营、治理四大类十六个域，其中R4配置与资产就是CMDB要服务的主场（能力地图）。流程实践视角把能力落到ITIL流程上，看事件、变更、问题这些事怎么转，从而明确CMDB的读写触点——变更后必回写、发现自动入库、告警关联CI，这三条是硬规则（业务流）。技术域视角回到现实世界，把基础设施从业务服务到网络设备按L1到L4分层，盘点CI类型和关系（依赖于

2026-05-21 16:39:04 547

原创【AI时代下的一些感悟一】AI时代业务架构分层和开发模式迭代

在我看来，AI时代企业业务架构正从传统三层架构，逐步升级为六层全新技术架构，整个演进过程不仅新增了Agent编排治理、大模型服务两大核心层级，还推动业务能力走向原子化拆解，同时把业务交互从传统固定页面操作，升级为更灵活的自然语言对话模式。这种架构变革也直接带动了团队人员结构与工作模式转变，一线业务人员能够自主搭建轻量化业务应用，传统后台研发人员出现明显职业分流，行业也顺势催生了智能体治理、模型工程等全新技术岗位，整体人才结构随之发生明显调整。而从业务系统自身发展来看，也走完了从业务平台人机直连操作，到业务中

2026-05-21 10:54:41 538

原创【GO语言开发实践】三 GO 工程化快速上手

Go Web 与 Java Web 分层与 CRUD 模式类似，上手快。但总体而言感觉Java 依托 Spring 生态，功能会更强大，可以开箱即用的快速且稳定的支撑构建一个企业级项目且不太需要随着复杂度的上升着急拆分项目（但这也容易埋下隐患：不着急拆，发展到后面往往就挺难拆了）；Go 无注解、无自动装配，手动配置多、封装性低，但好处是让开发者清晰感知底层配置。低封装也导致 Go 做复杂单体吃力，从而倒逼拆分服务、走向微服务化，更贴近云原生分布式生态。我感觉这很可能也是语言设计者的初衷，不去设计Spring

2026-05-17 21:26:41 870

原创【GO语言开发实践】二 GO 并发快速上手

Go原生对并发的支持确实会比Java好，核心原因是内置 GMP 调度模型，可以在用户态自主完成多数协程调度切换，摆脱对操作系统原生内核线程的强依赖，减少内核态与用户态切换产生的 CPU、内存资源损耗（仅当发生真正的阻塞系统调用或 I/O 时才会进入内核态）Go 协程与 Java 线程的生命周期状态逻辑相近，但 Java 受限于历史线程模型（1:1 映射内核线程），只能通过线程池、虚拟线程等方式优化开销，无法从底层彻底抛弃内核线程调度架构（即使想实现类似 GMP 的模型，历史替换成本也极高）。此外Go

2026-05-17 17:41:43 704

原创【GO语言开发实践】一 GO 语法快速上手

Go的核心优势在于灵活性高、贴合实际开发：变量类型推导简洁高效，无需显式声明类型；error错误处理机制强制开发者主动判断，倒逼代码健壮性；原生支持多返回值，避免Java额外封装对象的冗余；结构体+组合替代继承，轻量化设计契合日常业务开发场景（其实Java日常开发也不怎么推荐继承写法了）；匿名函数与闭包无需类承载，使用更自由，对比Java Lambda限制更少，这也和Go的函数是一等公民有关；defer延迟执行写法简洁，替代Java finally更清爽。另外就目前学习的感受来看，Go在语法规范性上其实

2026-05-17 10:41:58 938

原创【业务场景设计每日一问】分库分表场景下唯一ID的解决方案

NTP（网络时间协议）同步时发现系统时间过快，进行了时间校正系统管理员手动调整了服务器时间虚拟机或容器迁移导致时间漂移当发生时钟回拨时，雪花算法会面临一个严重问题：如果时间戳回拨到之前已经使用过的时间点，那么新生成的ID可能与之前已生成的ID发生冲突。方案优点缺点适用场景UUID实现简单，无需中心化占用空间大，非递增，页分裂严重数据量小，对性能要求不高的场景数据库步长自增实现简单，单表递增跨表非严格递增，扩容困难中小规模系统，分库分表数量固定雪花算法。

2026-03-21 23:04:36 301

原创【业务场景设计每日一问】如何优雅的实现分布式事务确保数据一致性

本文针对品牌门店批量断网操作的分布式事务问题，提出两种解决方案：TCC模式和本地消息表模式。TCC模式通过Try-Confirm-Cancel三个阶段实现强一致性，精准回滚已成功的操作，适合对一致性要求高的场景。本地消息表模式通过异步处理实现最终一致性，支持重试机制和大规模并发，适合高吞吐需求但对实时性要求不高的场景。两种方案都依赖下游提供幂等接口，TCC需要同步调用，本地消息表则采用异步处理。选型建议根据业务对一致性和性能的需求权衡决定。

2026-03-21 21:53:16 525

原创【业务场景设计每日一问】使用 Redis Hash 实现令牌桶和漏桶限流

Redis分布式限流实现方案采用Redis Hash结构存储限流状态（last_time时间戳+tokens/water状态值），通过Lua脚本原子化操作实现令牌桶和漏桶两种算法。令牌桶允许突发流量（示例：30秒可积累300令牌），漏桶严格平滑流量（示例：30秒漏水300请求）。两种算法分别适用于API限流和数据库保护场景，通过HSET存储关键字段，EVAL执行计算逻辑，具有内存效率高、扩展性好的特点。实际调用时传入容量、速率等参数即可实现精准限流控制。

2026-03-21 16:07:10 495

原创【业务场景设计每日一问】如何实现一个百万骑手实时排行榜

Redis 有序集合（ZSet）是实现实时排行榜的高效方案，支持百万级骑手数据的高频读写。ZSet 通过跳跃表和哈希表的组合，提供 O(log N) 的插入、更新和排名查询操作，能够快速完成骑手分数更新、Top N 查询和个人排名获取等核心功能。对于百万数据量，单实例 Redis 完全可胜任，内存占用约几十到几百 MB。优化建议包括：配置 ziplist 编码、缩短骑手 ID 长度、采用 Redis Cluster 分片等。ZSet 的命令如 ZINCRBY、ZREVRANK 和 ZREVRANGE 完美契

2026-03-21 15:26:37 426

原创【Java设计并发信号量的使用】如何通过信号量实现三线程交替运行

本文演示了如何使用信号量（Semaphore）实现三个线程交替打印ABC。通过初始化三个信号量（A初始为1，B/C初始为0），每个线程在打印前获取自己的信号量许可，打印后释放下一个线程的信号量，形成循环控制。这种方案代码简洁，无需显式锁，通过信号量的获取/释放机制自然实现线程间同步。关键点在于初始信号量分配和线程间"令牌"的传递顺序，确保打印严格按ABCABC...的顺序执行。该方法展示了多线程协调的经典模式，具有可扩展性和面试实用价值。

2026-03-21 13:05:19 358

原创【中间件设计 Redis】Redis分布式锁是怎么设计的，Redisson有哪些能力

本文系统分析了Redis分布式锁的实现演进过程。从最基础的SETNX命令出发，逐步解决死锁风险、原子性操作、锁续期、误删锁和主从切换等关键问题。通过引入过期时间、Lua脚本、看门狗机制和Redlock算法，最终形成了完整的分布式锁解决方案。文章重点介绍了Redisson客户端对上述问题的封装实现，包括自动续期、安全解锁、可重入性等功能，为开发者提供了开箱即用的可靠分布式锁工具。理解这些底层原理有助于开发者正确使用分布式锁并有效排查相关问题。

2026-03-08 20:04:14 372

原创【中间件设计 Kafka】Kafka如何保证消息顺序投递和顺序消费

Kafka通过分区机制实现高吞吐和扩展性，但不保证全局有序。生产者通过指定消息key确保相同业务数据进入同一分区，消费者组保证分区独占消费。为处理消费者内部多线程导致的乱序，可采用内存队列按key分配单线程处理。Rebalance不影响分区顺序但可能重复消费，需配合幂等机制。这种设计在风控平台等场景中，既能保证关键业务顺序性，又能充分利用分布式系统优势。

2026-03-08 19:11:47 981

原创【中间件设计 Kafka】Kafka Exactly-Once语义，Kafka如何保证消息不重不漏

本文深入解析Kafka如何实现消息传递的三种语义（At most once、At least once、Exactly once），重点剖析Exactly-Once语义的实现机制。Kafka从0.11.0版本开始通过幂等性生产者和事务性生产者来确保消息不丢失不重复。文章采用"问题→解决方案"的结构，首先分析如何保证消息不丢失（At Least Once），包括生产者确认机制、Broker多副本配置和消费者手动提交偏移量；然后详细阐述如何避免消息重复（Exactly-Once核心），分别从

2026-03-08 14:26:05 1016

原创【知行技术人的管理之路读书笔记】技术管理全景访谈

摘要：一位初级技术管理者分享从工程师转向虚线负责人的经验，强调管理需具备热情、责任意识与灵活思维。管理规划需明确团队职能、设定SMART目标，权衡进度-质量-效果三角，并定期盘点团队。团队建设核心是持续打胜仗，通过721培养原则（实践70%、交流20%、自学10%）和三级激励（生存、物质、信仰）提升成员能力与动力。任务管理注重事前优先级评估、事中四要素执行（目标、责任、机制、沟通），确保高效交付。管理者需从技术实现者转变为架构判断者，以团队成功而非个人表现为核心。

2026-03-07 01:31:26 534

原创【Java设计并发与内存模型】一段同步代码执行看懂：JMM、JVM、线程调度过程

本文以两个线程A和B并发执行代码为主线，串联JVM运行时数据区域、类加载机制、JMM内存模型和操作系统线程调度的完整流程。当线程A触发Teacher类加载时，JVM在方法区和堆中初始化类信息，并保证线程安全的类加载过程。线程创建涉及内核线程映射，每个线程拥有独立的程序计数器、虚拟机栈等私有区域。通过synchronized锁竞争场景，展示了JMM如何通过monitor指令和内存屏障保证可见性，以及操作系统如何进行线程上下文切换。最后详细解析了JMM定义的内存交互操作，如lock/unlock、read/wr

2026-03-04 23:22:01 558

原创【Java设计并发集合与锁】Java并发集合与AQS/CAS深度解析：从HashMap演进到锁的底层实现

本文深入探讨Java并发编程中集合类的安全性与性能优化，重点分析HashMap和ConcurrentHashMap的演进历程及锁机制对比。JDK 1.7的HashMap采用头插法导致并发扩容可能形成死循环，1.8改进为尾插法和红黑树结构避免该问题。ConcurrentHashMap从1.7的分段锁演进到1.8的CAS+synchronized桶锁，大幅提升并发性能。文章还对比了synchronized和ReentrantLock的特性差异，包括可重入性、公平性、可中断性等，揭示了Java并发设计"

2026-03-04 01:18:24 734

原创【系统架构设计服务高性能设计】从内核态到锁升级，一篇文章深入理解计算机高性能关键

本文通过通俗比喻和系统视角，剖析计算机性能优化的核心思想。首先解释用户态/内核态的权限隔离机制及其切换开销，指出这是所有系统调用的底层成本。接着分析CPU和内存两大核心资源的特点，揭示性能优化的本质是减少管理开销（如上下文切换、数据拷贝）对有效计算时间的占用。文章详细梳理了各类操作（磁盘/网络IO、线程管理、锁竞争）的资源消耗模式，并通过表格关联到Kafka零拷贝、Reactor模式、线程池等优化技术。最后以Java线程状态机为例，展示线程生命周期中各状态切换时的具体开销，为理解并发编程性能问题提供系统级视

2026-03-04 00:17:42 1231

原创【数据库设计 MySQL】全面分析MySQL EXPLAIN 字段详解与优化指南

添加索引WHERE 条件字段JOIN 关联字段ORDER BY 字段组合索引顺序：WHERE → ORDER BY → JOIN更新统计信息删除冗余索引避免误导优化器调整索引列顺序选择性高的字段放前面filtered 表示 WHERE 条件过滤后剩余的行数百分比。→ 扫描 1000 行，其中 100 行（10%）符合 WHERE 条件。

2026-03-03 12:16:12 215

原创【中间件设计集群设计大横评四】ElasticSearch、Redis和Kafka—集群存储机制

本文深入剖析Elasticsearch、Redis和Kafka三大分布式系统的存储机制。Elasticsearch采用段(Segment)和事务日志(Translog)设计，通过不可变段实现高效写入和近实时搜索，利用段合并优化性能，Translog确保数据可靠性。Redis提供RDB和AOF两种持久化方式：RDB通过快照实现高效备份，AOF记录写命令保障数据安全，支持多种同步策略。Kafka采用分段日志存储，支持高吞吐消息处理。文章最后对比了Elasticsearch和Kafka的存储架构设计理念，揭示不同

2026-03-03 01:00:53 629

原创【中间件设计集群设计大横评三】ElasticSearch、Redis和Kafka—集群工作流程

本文系统梳理了ElasticSearch、Redis和Kafka三种分布式系统的工作机制。ElasticSearch详细介绍了文档路由规则、读写流程（包括写操作同步复制、读操作负载均衡）、检索两阶段查询等核心机制。Redis集群模式通过CRC计算键值槽位实现数据分布，客户端最多两次访问即可命中数据。Kafka则从生产者路由发送、Broker消息存储与副本同步、消费者组分区分配三个环节完整解析了消息队列的工作流程。三种系统虽设计目标不同，但都体现了分布式系统在数据分布、一致性保证和性能优化方面的核心思想。

2026-03-03 00:43:16 783

原创【中间件设计集群设计大横评二】ElasticSearch、Redis和Kafka—集群故障转移

本文深入分析了ElasticSearch、Redis和Kafka三大分布式系统的故障转移机制。ElasticSearch采用Raft协议进行主节点选举，通过多数派投票和自动同步机制防止脑裂；Redis集群基于Gossip协议实现主从切换，通过延迟选举和数据同步保证一致性；Kafka则依赖Controller统一管理和LEO/HW水位机制实现Leader选举和数据同步。三种系统在故障检测、选举机制和数据同步方面各有特色，体现了分布式系统在可用性与一致性之间的不同权衡。

2026-03-03 00:29:19 980

Visual Studio2015的圈复杂度检测工具code metrics

原则的详细读书笔记罗列

Java面试大全

Docker镜像中间的layer能删除么？