存在morning-CSDN博客

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

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

2026-03-07 01:31:26 300

原创【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 580

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

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

2026-03-04 00:17:42 1132

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

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

2026-03-03 12:16:12 115

原创【中间件设计集群设计大横评零】MySQL、Elasticsearch、Kafka、Redis 集群设计深度解析

本文分析了四种分布式系统的设计哲学：MySQL采用主从架构实现读写分离，优先可用性(AP)；Elasticsearch通过同步副本保证强一致性(CP)；Kafka的单Leader设计确保消息顺序(CP)；Redis集群通过分片扩展写能力(AP)。系统设计受事务支持、顺序要求、读写比例、一致性容忍度和数据模型复杂度等因素影响。不同系统在CAP理论下做出不同权衡：支持事务的系统往往牺牲写扩展性，追求强一致性的系统则会降低可用性。这些设计差异都源于对核心业务场景的精准适配。

2026-03-01 20:50:43 615

原创【系统架构设计高可用架构】如何应对接口级故障：降级，熔断，限流，排队

接口级故障应对不是单一策略，而是一个多层次的防御体系。我们需要根据不同的场景（读/写、依赖强弱、流量特征）选择合适的策略，并让它们协同工作。降级保证核心功能可用，熔断防止故障传导，限流控制流量入口，排队平滑处理写请求，监控与自动伸缩让系统具备动态适应能力。只有把这些策略融会贯通，才能真正打造一个高可用的系统。

2026-02-28 20:27:52 525

原创【系统架构设计高可用架构】高可用分布式系统的设计与选型

高可用分布式系统架构设计本文系统探讨了高可用分布式系统的计算和存储架构设计。在计算架构部分，分析了双机架构（主备、主从）和集群架构（对称/非对称）的优缺点及适用场景，强调任务分配、故障检测和迁移策略。存储架构部分深入比较了主备、主从、主主复制模式，以及集群架构中数据副本和分片的设计权衡，指出在一致性、可用性和性能之间的平衡要点。文章结合Kafka、MySQL等典型案例，为不同业务场景提供了架构选型参考，揭示了高可用系统设计背后的核心思想和技术折衷。

2026-02-27 23:48:04 632

原创【系统架构设计高可用架构】深入理解CAP理论：核心概念、实践权衡与适用边界

摘要：CAP理论阐述了分布式系统在网络分区时必须在一致性(C)和可用性(A)间取舍。其适用于共享数据的互联集群，包括对称（如Elasticsearch）和非对称（如HDFS）架构。文章通过银行转账(CP)和社交改名(AP)的案例对比，揭示了不同业务场景的权衡策略，并指出CAP主要适用于有状态存储系统，无状态计算架构不受直接约束。现代系统常采用混合设计，根据数据重要性灵活选择CP或AP策略，同时强调ACID的C（数据合法性）与CAP的C（副本同步）的本质区别。

2026-02-27 22:08:42 377

原创【系统架构设计高性能架构】高性能架构负载均衡怎么做的，有什么分配算法

本文系统介绍了负载均衡技术及其在分布式系统中的应用。首先阐述了负载均衡的核心职责和三大实现方式：DNS负载均衡（地理级别）、硬件负载均衡（高性能）和软件负载均衡（灵活）。重点分析了典型的三级负载均衡分层架构设计，以及轮询、加权轮询、最少连接、哈希等多种负载均衡算法的适用场景和选择考量。文章指出，合理的负载均衡设计需要结合业务特性，通过分层架构和算法组合实现流量调度、故障转移和弹性伸缩等关键能力，是构建高性能、高可用分布式系统的核心组件。

2026-02-26 23:24:49 237

原创【系统架构设计高性能架构】为什么有了MySQL还要有NoSQL

NoSQL 类型解决的问题适用场景代表产品KV 存储高性能读写，简单数据结构缓存、计数器、Session、排行榜文档型数据库表结构约束，灵活存储复杂数据电商商品、游戏数据、CMS列式数据库海量数据存储，高性能分析查询离线分析、数据仓库、时序数据全文搜索引擎全文搜索能力弱，复杂条件查询站内搜索、日志分析没有银弹，选型时根据业务场景权衡一致性与性能，就能在实际项目中做出合理决策。类型核心优势不可替代的原因典型场景KV 存储 (Redis)内存级速度、丰富数据结构。

2026-02-26 23:12:29 831

原创【系统架构设计高性能架构】如何压榨单机高性能，BIO与NIO

摘要：网络连接处理从传统阻塞模型（PPC/TPC）演进到非阻塞I/O和多路复用技术，通过Reactor模式实现I/O与业务分离。单Reactor单线程发展为单Reactor多线程，最终形成多Reactor多线程模型：MainReactor负责接收连接，SubReactor处理I/O事件，工作线程池执行业务。不同系统（如Nginx、Netty）根据业务特点采用不同实现。这种演进通过线程池化、快慢任务分离、资源弹性分配等优势，显著提升了单机性能、系统稳定性和故障隔离能力，成为现代高并发系统的核心设计。

2026-02-26 22:47:11 584

原创【俞军产品方法论读书笔记一】产品经理定位及企业、用户、产品的关系

产品=需求×生产×销售x协调，其中需求和生产是决定产品生死的，所以产品经理的职责重心可能是前两个，销售可能更多的是和运营专家协同来做，协调可能是和PMO协同来做。但是随着AI时代的到来，人机协同的模式下，个人的能力扩张一定会更快的覆盖这四个关键点，在AI的加持下产品经理的能力边界必然会被延伸的更宽，例如基于AI做数据查询进行运营反馈驱动，基于AI制作前端页面提升生产效率，基于AI辅助分析需求等等；企业和用户的价值是通过产品交换的，产品经理的工作就是提升交换效率，降低交换成本，扩大交换规模。

2025-12-25 00:25:55 510

原创【俞军产品方法论读书笔记二】如何理解用户

用户行为模型与决策机制分析文章通过"外卖点餐"案例生动阐释了用户行为的五大属性：异质性（用户差异）、自利性（效用最大化）、有限理性（认知局限）、情境性（环境依赖）和可塑性（偏好可变）。核心提出了一个动态循环的用户决策模型：偏好认知：用户基于先天和后天经验形成初始偏好情境刺激：具体环境触发决策需求效用评估：通过感知→解读→选择→推演→判断的认知流程（常被简化或扭曲）行为输出：选择期望效用最高的选项反馈循环：行为结果反哺修正原有偏好该模型揭示了产品设计的三个关键：情境设计（触发

2025-12-25 00:09:14 1105

原创【人工智能学习笔记三】 AI教学之前端跨栈一：React整体分层架构

本文提供了一份为Java程序员设计的React 18快速入门指南，通过组件层、Hooks层和服务层的分层讲解，帮助开发者快速掌握React关键概念。主要内容包括：1) 页面效果与组件对照，将UI元素映射为React组件；2) 状态管理逻辑，展示useState和useEffect的使用；3) 数据获取与业务逻辑处理。特别提供了Java与React关键概念的类比：React组件对应Java类，Props相当于构造参数，Hooks则类比为Java的成员变量和方法。通过这种"Java思维→前端映射&qu

2025-11-08 23:17:42 861

原创【知行技术人的管理之路读书笔记】九管理之路

管理者的价值兑换分为两种，一种是能力价值也就是管理能力价值，也就是带着团队持续产生业绩的能力，另一种是组织价值，表现为组织对你的依赖（信任，默契，影响力）。所以要提升自己的核心价值兑换能力，也就是提升管理能力价值（角色认知，看方向，带人，做事，管理沟通，管理方法论）和组织价值（信任建立，默契培养，影响力输出）。价值提升了短期看和上级和公司的利益目标保持一致，长期看也是自我实现的一种方式吧！

2025-06-20 22:00:46 5449

原创【知行技术人的管理之路读书笔记】八管理方法论

管理方法论是管理方法的方法，更具本质性和系统性。整体盘点管理方法论，从全景图来看就是明确角色认知，具备带人，做事，看方向的能力，以及基于管理沟通框架进行有效的管理沟通。管理方法论的积累：诚意正心（以身作则，有明确的角色认知），事儿上练（不要脱离事情去学习，也就是要实践，要应用），处理管理问题的一般步骤（定义问题，明确目标，选择方式，评估结果）管理全景图的应用：盘点问题，定义问题，定位问题，转换问题，收纳问题那么接下来就是实践了，从管理规划做起，明确自己的职能，目标，团队，路径。先看方向，在事儿上

2025-06-20 21:54:33 251

原创【知行技术人的管理之路读书笔记】七管理的基本框架：管理沟通

管理沟通分为管理视角和沟通视角，沟通的前提条件是管理，明确管理的问题才能的放矢的沟通。管理沟通的基本框架分为：沟通目的（建立通道，同步信息，表达情感，输出影响）；沟通通道（强化沟通意愿，评估通道类型，了解沟通对象风格，建立信任关系，目标是建立稳定高效的沟通通道）；沟通内容（内容选取，呈现逻辑，学会倾听）；输出影响力管理沟通的四项沉淀：强化管理逻辑；提升通道品质；积累沟通技巧（3F倾听法（事实-情感-意图），发问模式（封闭式和开放式））；提升非职权影响力（信任【品格；历史评估（及时响应，敢于承诺）】）

2025-06-15 22:53:25 485

原创【知行技术人的管理之路读书笔记】六管理的基本框架：任务管理

任务管理分为事前，事中，事后。事前要分清轻重缓急，决策优先级；事中要保证执行，做好过程管理；事后要复盘沉淀，建立流程机制事前：事项分类：重要的事（做了收益很大的事）和紧急的事（不做损失很大的事）。计划内的事收益高（重要）的要优先做，收益低（不重要）的当待办，计划外的事损失大的优先做（紧急），损失不大（不紧急）的当待办；决策原则：目标要清晰，目标不明确事的重要度就不明确；任务弹性评估（进度，质量，效果）多套方案，基于核心诉求决定事项分类和优先级；沟通不可或缺，上下级统一对齐，对事项优先级有共识事中：有

2025-06-13 00:29:33 437

原创【知行技术人的管理之路读书笔记】五管理的基本框架：团队建设

好团队的定义是**一支能持续高效打胜仗的团队**，团队建设分为六大要素，员工个体层面是能力培养和员工激励，团队成员之间是分工与协作，团队整体层面是梯队培养和文化建设能力培养：基于专业能力、通用能力（结构化思考，团队协作，自驱学习，项目管理）和人格能力（人格特质）去培养；对于不同级别要明确期待，专项跟进，专项提升；培养过程按照7-2-1法则（70%实践，20%交流讨论，10%听课自学）；培养过程先推后拉最后放手授权员工激励：知识经济时代内驱激励，提升自主性（结果导向，过程有一定自由度），专精度（明确工

2025-06-11 23:16:46 397

原创【知行技术人的管理之路读书笔记】四管理的基本框架：管理规划

管理规划分为四部分。1 首先是职能，职能就是团队设定的目的和意义，职能分为基本的职责和升华的使命，设定职能时需要收集信息（上级、平级、下级和自己），提炼和升华（提炼职责，提炼使命，明确价值衡量标准），确认和主张（激励团队）。2 其次是目标，目标就是未来一段时间团队要达成什么目的，目标设定的意义是提升团队执行力，激励团队，关联资源调配，目标设定的原则是SMART和最少原则，在一定时间内设置明确可衡量的稍微有挑战的目标，目标的数量在3-5个之间便于聚焦，目标设定的维度分为业务目标（业绩），团建目标（规模

2025-05-18 15:33:07 557

原创【知行技术人的管理之路读书笔记】三管理的基本框架：角色认知

角色认知是迈向成功的关键一步，只有准确地建立新的角色认知，后续的目标行动路径才能得以坚定不移地贯彻执行。这是一项需要长期投入并辅以专业训练的重要任务，即不断提醒自己：你已是一名管理者。为了实现这一角色转变，需要在多个方面进行调整：工作思路的转变：工作内容不再局限于具体事务，而是聚焦于全盘规划，上级与我们仅针对目标进行对齐；负责对象从自己拓展到包括上级、自己以及团队成员；关注焦点由关注工作过程转变为聚焦目标结果。工作能力的转变：从单纯的技术能力，转变为具备技术判断力、目标管理能力、团队规划能力、项目管

2025-05-17 22:18:53 315

原创【知行技术人的管理之路读书笔记】二管理的基本框架：整体认知

管理的基本框架如下图所示，作为一个管理者首先要有清晰的角色认知，基于这个角色认知来行动和表达，在此基础之上，管理者主要的目标是：看方向（把事情作对），带人（做事情的主体），做事（把事情做出来），也就是管理规划、团队建设和任务管理，管理规划分为职能（明确团队的职责，以及如何设定任务、人才盘点、资源管理、路径管理），目标（任务的目标是什么），团队（如何盘点团队，提升成员能力），路径（做事的路径以及需要的资源）。团队建设有三个层次，成员个体要进行能力培养和员工激励，成员之间要明确分工和协作机制，建立信任，团队整体

2025-05-17 16:45:37 367

原创【知行技术人的管理之路读书笔记】一管理的路线、视角、风格和自信

最近在深入学习一本关于技术管理的书籍，通过XMind工具梳理了关键内容，并在博客中分享了学习收获。书中强调了三个核心要点：首先，明确职业路线并投入热情，抓住合适的机会，如一个有管理热情的工程师在适当条件下转型为技术管理者。其次，建立管理视角同时提升技术视角，从代码开发转向关注项目成果、技术应用广度及技术评估。最后，明确并建立适合自己的管理风格，建议以教练型为主、指令型为辅，根据团队和任务特点灵活调整，并通过学习经验、避免与成员比较、寻求外部正反馈来建立管理自信。这些策略帮助管理者更有效地领导和激励团队。

2025-05-14 23:40:58 273

原创【人工智能学习笔记二】 MCP 和 Function Calling的区别与联系

MCP（Model Context Protocol）与Function Calling（函数调用）是两种不同层面的技术方案，服务于大模型（LLM）与外部资源的交互，但设计理念和应用场景有显著区别。以下是两者的核心差异分析：MCP：开放协议层的基础设施Function Calling：特定模型的增值功能MCP适用场景Function Calling适用场景两者可结合使用：例如，在电商场景中，MCP整合用户订单数据，Function Calling调用库存API生成补货建议。通过这种分层协作，既能实现通用性，

2025-05-04 15:09:12 2106

原创【人工智能学习笔记一】 AI分层架构、基本概念分类与产品技术架构

总的来说AI主要由算法、算力、数据组成，算法是核心。LLM是基于Transformer架构的算法成果，属于NLP领域关键技术，赋予AI理解和生成语言的能力。如果把AI AGENT看作人工助手，LLM就是其大脑，提供智能核心。AIGC则基于LLM等技术，生成语言、图像、音频等内容，就像人基于大脑的一些语言和视觉的表达。举个例子：云雀模型是LLM，豆包的问答查询基于此，是AIGC在语言领域的应用；图片生成借助专门模型，也是AIGC。豆包APP里的智能体是AI AGENT，集成云雀能力为用户服务。

2025-02-02 12:37:17 6399

原创【领域驱动设计打通DDD最小闭环】三模型的建立-领域建模

同事件风暴一样领域建模也是在模型建立阶段，但更进一步的，领域建模不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识，使模型中的知识不再停留在业务的表面，而是深入到业务的本质，进而加入技术视角选择最合适的建模方案。可以理解为是对事件风暴的技术性加工，使用UML图的一些标记例如：注释、约束、多重性、自关联、多关联、角色以及一些技巧如：多对多关联拆分、抽象化实体、模块化来进行领域建模。一个比较深的体会是对于多对多关联拆分的考虑，例如业务事件阶段的【门店、合作】以领域名词的形式候选为实体，在领域建模阶段明确其多

2024-08-25 22:42:02 1523

原创【领域驱动设计打通DDD最小闭环】二模型的建立-业务事件风暴

事件风暴不仅能帮助我们尽量把需求补充完全，而且还能以协作的方式保证业务人员和技术人员对需求理解一致。实践过程中有点儿像模型推演，先识别流程，例如入驻流程，然后识别领域事件，例如【门店已联网】，同时明确业务规则，门店一旦有了联网时间不能重置；再识别命令，例如A+开启导致门店联网，同时明确命令执行者是系统，执行时需要查询门店信息。当然可能还有可选领域事件，例如【门店维护人变更】不影响主流程。诸如此类串联完一系列领域事件、命令、查询、执行者之后总结出了【门店】这个领域名词。一个深的体会是过程中的UL语言建立以及结

2024-08-24 22:25:02 1368

原创【领域驱动设计打通DDD最小闭环】一 DDD的开发流程

其实我们日常开发都比较伪DDD，整体实现还是使用 MVC，代码结构类似 Controller、Service、DAO，个人认为这也无可厚非，只是代码的组织形式而已，关键是我们在整体设计时往往缺乏（领域建模-架构设计）这关键两步，很多时候都是就着一个功能点进行（需求分析-数据库 -> 代码实现）。这样没有全局的视角很容易盲人摸象，导致后续摸到一点打个补丁，项目难以维护。DDD的关键不全然是代码架构设计的指导，更是一种应对复杂业务的开发及协作模式，关键人员先通过UL建立有全局共识认知，不确认的地方预留扩展点，再

2024-08-23 22:36:08 1327

原创【从零开始学架构架构基础】五架构设计的复杂度来源：低成本、安全、规模

低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束；安全一般接触不到，功能安全一般框架保证、架构安全一般运营商以及云服务保证；规模其实代表的是业务复杂度的上升对架构的挑战，其实扩展性不好的架构其规模复杂度往往也会随着业务不断升级，所以需要设计扩展性好的架构并且在预测到业务计算及数据规模可能影响正常业务的时候及时进行架构优化。

2024-06-30 17:44:22 868

原创【从零开始学架构架构基础】四架构设计的复杂度来源：可扩展性复杂度来源

结合这篇Blog，其实我感觉主要是如何在过度设计与不可扩展间去权衡。长期预测的代价和变数太多，可能在落地前业务就凉了，不做预测又可能刚开始迭代就发现难以支持。所以2年预测是一个经验值，如果到了2年业务发展的好了，会倒逼决策层给资源给钱进行架构升级，如果都用不了2年就凉了那5-10年预测就没意义了；在预测的前提下，我们在方案设计的时候是否可以考虑短、中、长三种方案，短期策略一般考虑的变化少，短视，但迅速，修改小，立竿见影。长期策略一般看重远期，但成本高很高，也很可能预测不中。综合成本情况下如果决定采用短期策略

2024-06-30 15:07:23 1408

原创【从零开始学架构架构基础】三架构设计的复杂度来源：高可用复杂度来源

网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失

2024-06-29 23:57:01 1399

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

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

2026-03-21 23:04:36 194

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

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

2026-03-21 21:53:16 438

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

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

2026-03-21 16:07:10 334

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

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

2026-03-21 15:26:37 285

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

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

2026-03-21 13:05:19 284

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

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

2026-03-08 20:04:14 312

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

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

2026-03-08 19:11:47 503

原创【中间件设计 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 553

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

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

2026-03-04 23:22:01 485

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

原则的详细读书笔记罗列

Java面试大全

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