- 博客(204)
- 资源 (2)
- 收藏
- 关注
RSS订阅原创 孤舟笔记 分布式与微服务篇二十五 OAuth和JWT到底是什么关系？面试总被一起问，一篇理清
OAuth与JWT的本质区别及组合使用 摘要：OAuth 2.0是授权协议，解决"如何获取授权"的问题；JWT是令牌格式，解决"如何传递信息"的问题。两者属于不同层面，常组合使用：OAuth处理授权流程，JWT作为令牌格式。主流组合是OAuth+JWT，资源服务器可本地验证JWT令牌。纯JWT适用于简单认证场景，OAuth适用于需要授权的场景。JWT存在三大问题：无法吊销（通过短有效期+黑名单解决）、信息过时（关键操作实时查库）、体积大（精简Payload）。选择方案时，第三方登录用OAuth+JWT，自家
2026-06-11 12:16:17
631
原创 孤舟笔记 分布式与微服务篇二十四 IaaS、PaaS、SaaS有啥区别？三个字母搞懂云计算三层模型
这篇文章用通俗易懂的"做饭"类比解释了云计算的三层服务模型：IaaS（租厨房自己做饭）、PaaS（外卖平台备好料只需炒菜）、SaaS（直接去饭店吃饭）。通过对比表格和示意图清晰展示了各层的特点：IaaS提供基础设施但运维成本高，PaaS提供运行环境适合快速上线，SaaS即开即用但定制性低。文章还指出当前云服务边界模糊化的趋势，并给出面试回答技巧，强调要结合实际产品（如AWS EC2、Heroku、Gmail）和场景选择服务类型。最后提出Serverless是PaaS的极致发展，以及多云部署的注意事项，为读者
2026-06-11 12:16:04
766
原创 孤舟笔记 分布式与微服务篇二十三 什么是服务网格？Istio到底在干嘛，面试官想听的是这层“代理“
服务网格是一种将微服务治理逻辑（如服务发现、负载均衡、熔断降级等）从业务代码中剥离的基础设施层，采用Sidecar架构（每个Pod旁配Envoy代理）。相比传统SDK方式，服务网格具有零侵入、语言无关等优势，但会带来1-3ms延迟和约50MB/Pod的内存开销。主流实现Istio分为控制面（istiod）和数据面（Envoy），通过YAML配置即可实现流量管理、安全加密等功能。面试回答需重点对比SDK与Sidecar模式的本质区别，并说明服务网格的适用场景与代价。
2026-06-10 14:39:50
362
原创 孤舟笔记 分布式与微服务篇二十二 什么是云原生？面试官问的不是一个名词，是一种方法论
云原生是一种构建和运行应用程序的方法论，其核心在于充分利用云计算环境的弹性、分布式和自动化特性。它并非单一技术，而是包含容器化、微服务、服务网格和声明式API等核心技术栈的整体架构理念。与传统架构相比，云原生应用具有自动扩缩容、自愈能力和不可变基础设施等优势，实现了从"搬到云上"到"为云而生"的转变。Kubernetes作为核心编排平台，配合Docker、Istio等技术，构成了完整的云原生技术生态。企业采用云原生需要循序渐进，根据实际需求从容器化逐步演进到服务网格等高级形态。
2026-06-10 14:39:33
329
原创 孤舟笔记 分布式与微服务篇二十一 Swagger工作流程是怎样的？API文档自动生成的原理一次讲透
摘要： Swagger是一款自动生成API文档的工具，通过代码注解（如@Api、@ApiOperation）自动扫描生成JSON/YAML文档，并通过Swagger UI提供可视化界面和在线调试功能。其工作流程包括注解扫描、文档生成和UI渲染。Swagger 2已演进为OpenAPI 3标准，推荐使用SpringDoc（替代停更的Springfox）实现零配置集成。核心注解涵盖接口描述、参数说明和实体定义，支持API规范化开发和前后端协作。面试中需强调其自动化流程、注解作用及生态演进（Swagger→Ope
2026-06-09 13:47:09
353
原创 孤舟笔记 分布式与微服务篇二十 OAuth到底是啥？面试总问但总说不清，看完这篇再也不怕
OAuth 2.0是一种开放授权协议，允许用户授权第三方应用访问资源而无需暴露密码。它包含四种授权模式：授权码模式（最安全，用于第三方登录）、隐式模式（已废弃）、密码模式（适用于第一方应用）和客户端凭证模式（用于服务间调用）。OAuth采用双Token机制：短期有效的Access Token用于访问资源，长期有效的Refresh Token用于更新令牌。与JWT的关系在于：OAuth是授权协议，JWT是令牌格式，二者可以结合使用。面试回答时应重点区分OAuth流程与JWT格式，并清晰说明四种模式的适用场景。
2026-06-09 13:46:44
511
原创 孤舟笔记 分布式与微服务篇十九 Sentinel的滑动窗口算法怎么实现的？从原理到源码一次讲透
Sentinel的滑动窗口实现LeapArray采用环形数组结构，每个格子(WindowWrap)存储时间戳和统计数据。通过时间取模计算索引定位格子，利用CAS无锁更新机制保证并发安全。当格子过期时直接覆盖重置，统计时仅累加有效窗口内的数据。默认配置为1秒窗口分为2个500ms精度的格子，固定数组大小避免内存开销。这种设计实现了高性能、低内存的流量统计，相比传统滑动窗口更高效。核心特点是环形复用、时间推进淘汰旧数据、无锁并发控制，适用于高并发场景下的精准限流。
2026-06-08 04:39:36
334
原创 孤舟笔记 分布式与微服务篇十八 雪花算法是怎么实现的？64位里藏着时间、机器和序列号
雪花算法是一种分布式ID生成方案，采用64位结构：1位符号+41位时间戳（69年）+5位数据中心+5位机器ID+12位序列号（4096个/毫秒）。核心流程包括检测时钟回拨、同毫秒序列号递增、溢出等待下一毫秒，最后移位拼装ID。主要风险是时钟回拨，解决方案包括等待追平或报错。机器ID分配可通过ZK、数据库或哈希实现。优化方案如美团Leaf采用双Buffer预生成ID避免时钟问题。回答时应重点说明生成流程和时钟回拨处理，展现对实现细节的理解。
2026-06-08 04:38:50
387
原创 架构师工具箱：除了 DDD，你还需要掌握哪些硬核方法论？
很多开发者对架构师的理解，还停留在“画大图、定规范、选中间件”的层面。事实上，架构师手里握着一整套，用来应对不同维度的系统复杂性。领域驱动设计（DDD）只是其中最常讨论的一把利器，但要真正驾驭大型系统，你还得知道它旁边放着的其他“家伙”。这篇文章，我把架构师常用的方法论整理成一张全景地图，希望能帮你建立完整的认知。
2026-06-06 13:54:01
376
原创 孤舟笔记 分布式与微服务篇十七 限流算法有哪些？面试官最想听的是滑动窗口和令牌桶
本文对比了四种常见的限流算法：固定窗口、滑动窗口、漏桶和令牌桶。固定窗口简单但有临界突刺问题；滑动窗口通过分格统计实现平滑限流，被Sentinel采用；漏桶严格匀速输出，不允许突发；令牌桶允许消耗积攒令牌处理突发流量，Guava RateLimiter采用此方案。文章详细分析了各算法原理、实现代码及适用场景，并指出一般场景推荐令牌桶，严格限速用漏桶。最后提供了面试回答技巧，强调要掌握算法对比和实际框架选择。
2026-06-06 10:11:31
428
原创 孤舟笔记 分布式与微服务篇十六 TCC中的悬挂问题是什么？怎么解决？这个坑踩过才算真懂分布式事务
TCC分布式事务的悬挂问题及解决方案 摘要：TCC模式在实际应用中存在悬挂问题，即Cancel先于Try执行导致资源永久冻结。根本原因是网络超时导致Try请求延迟到达。解决方案是引入事务状态表记录执行状态：Try时检查是否已Cancel（防悬挂），Cancel时记录状态（防空回滚）。Seata框架已内置这些处理机制。面试考察重点在于理解网络异常下的边界情况，而非仅知道Try/Confirm/Cancel三个接口。完整解决方案需同时处理悬挂、空回滚和幂等性三大问题。
2026-06-06 10:11:12
316
原创 孤舟笔记 分布式与微服务篇十五 Seata到底是怎么实现分布式事务的？AT模式原理一次讲透
Seata AT模式原理摘要（148字）： Seata AT模式通过两阶段实现分布式事务：一阶段直接提交本地事务，同时记录SQL修改前后的数据快照到undo_log；二阶段根据结果决定删除日志（提交）或利用undo_log生成反向SQL回滚（before image恢复数据）。关键机制包括：SQL拦截自动生成undo_log、全局锁防止脏写、XID跨服务传播。相比TCC模式，AT模式只需添加@GlobalTransactional注解即可实现零代码侵入，其核心优势在于一阶段立即提交的高性能特性，通过事后补偿
2026-06-04 00:39:40
352
原创 孤舟笔记 分布式与微服务篇十四 分布式事务有哪些解决方案？2PC、TCC、Saga一次讲透
本文对比分析了微服务架构下保证数据一致性的五种主流方案：2PC、TCC、Saga、本地消息表和事务消息。2PC实现简单但性能差，适合数据库层面；TCC一致性高但代码量大，适合资金交易；Saga适合长流程业务；本地消息表和事务消息则更实用。文章通过流程图和代码示例详细说明各方案原理，并给出选型建议：最终一致优于强一致，推荐本地消息表或事务消息。最后还提供了面试加分技巧，强调方案对比和场景选型的重要性。
2026-06-04 00:39:20
390
原创 孤舟笔记 分布式与微服务篇十三 Spring事务和分布式事务啥区别？搞不清这个，面试官直接扣分
这篇文章对比了Spring事务和分布式事务的核心区别与应用场景。Spring事务基于数据库事务和AOP封装，仅适用于单数据源操作，保证强一致性；而分布式事务解决跨库、跨服务的业务场景，通常采用2PC、TCC、Saga或消息队列等方案实现最终一致性。关键判断标准在于操作是否跨数据源——跨数据源时必须使用分布式事务。文章还指出应优先通过业务设计避免分布式事务，并提醒注意Spring事务的常见使用陷阱。面试中需重点区分两种事务的边界，理解Spring事务的局限性及分布式事务的必要性。
2026-06-03 11:39:10
676
原创 孤舟笔记 分布式与微服务篇十二 分布式锁选Redis还是ZooKeeper？面试官要的不是站队，是对比分析
Redis 锁和 ZK 锁的核心差异在一致性模型：Redis 是 AP（异步复制，故障切换可能丢锁），ZK 是 CP（过半确认，不丢锁）。选型：已有 Redis 或高并发场景选 Redis + Redisson，金融或强一致场景选 ZK + Curator。能从一致性模型讲起，说出 Redis 的三大风险和 ZK 的优势，再给出场景化建议，就是高分回答。Redis 快是因为纯内存操作，ZK 慢是因为每次写都要过半确认 + 磁盘持久化。最忌讳的回答是"Redis 更好"或"ZK 更好"——面试官想听的是。
2026-06-03 11:38:48
496
原创 孤舟笔记 分布式与微服务篇十一 分布式ID设计方案有哪些？面试官最想听的是雪花算法
本文对比了五种分布式ID生成方案：1）UUID简单但无序，不适合主键；2）数据库自增简单但扩展困难；3）号段模式批量取号减少数据库压力；4）Redis INCR高性能但有依赖；5）雪花算法（64位=1符号+41时间+10机器+12序列）本地生成性能最高，趋势递增但需处理时钟回拨问题。重点分析了雪花算法的实现原理和时钟回拨解决方案，指出生产环境首选雪花算法，同时可根据规模选择号段模式或混合方案。文章通过对比表格和结构图示直观展示了各方案优劣，并提供了面试回答技巧。
2026-06-02 16:24:12
182
原创 孤舟笔记 分布式与微服务篇十 一致性Hash算法到底怎么实现的？面试官想听的可不只是“环“
一致性Hash摘要： 一致性Hash解决了普通Hash在节点增减时导致大量数据重新分配的问题。其核心是将节点和数据映射到Hash环上，数据顺时针查找最近节点，使得增减节点只影响相邻数据而非全局。虚拟节点用于解决节点少时的数据倾斜问题，通过将真实节点映射为多个虚拟节点实现均匀分布。相比普通Hash的全量迁移，一致性Hash仅需局部迁移，显著提升了缓存命中率。典型应用包括Redis Cluster和Dubbo负载均衡，关键技术点在于Hash环设计、虚拟节点优化和数据局部迁移特性。
2026-06-02 11:28:11
371
原创 孤舟笔记 分布式与微服务篇九 什么是幂等性？为什么面试总问它？解决思路一次讲透
摘要： 幂等性指同一操作执行多次与执行一次结果一致，在分布式系统中尤为重要。常见重复场景包括用户双击、网络重试、MQ重复消费等。解决方案包括：1）唯一ID+去重表，通过唯一索引拦截重复请求；2）乐观锁，利用版本号控制并发更新；3）Token机制，服务端生成一次性令牌防重；4）状态机，通过业务状态约束流转。天然幂等操作（如查询、删除）无需处理，非幂等操作需针对性设计。回答时应结合具体场景选择方案，并注意事务一致性与实现细节。 （字数：150）
2026-06-02 11:27:55
499
原创 孤舟笔记 分布式与微服务篇八 分布式锁到底怎么实现？三种方案对比，面试官想听的可不只是Redis
本文对比了三种分布式锁实现方案：数据库锁（唯一索引/FOR UPDATE）、Redis锁（SETNX+过期时间）和ZooKeeper锁（临时顺序节点）。数据库锁简单但性能差；Redis锁性能高但需处理锁过期和误删除问题；ZooKeeper锁最可靠，具备自动释放和公平性。选型建议：高并发短任务用Redis，强一致性场景用ZooKeeper，简单场景可用数据库锁。文章还提供了Redisson看门狗机制、Lua脚本校验等解决方案，并总结了各方案的优缺点和适用场景。
2026-06-01 08:09:02
395
原创 孤舟笔记 分布式与微服务篇七 ZooKeeper怎么做Leader选举？原理比你想的简单，但细节比你想的多
ZooKeeper Leader选举机制解析：采用FastLeaderElection算法，在集群启动、Leader崩溃或网络恢复时触发选举。选举过程分为三步：节点先投自己，然后交换投票，按照"先比较ZXID（事务ID，代表数据新旧），再比较myid（节点编号）"的规则更新选择，获得过半票数的节点当选Leader。ZXID优先的设计保证了数据最新的节点当选，避免数据丢失。选举期间节点状态从LOOKING转为LEADING或FOLLOWING，Observer节点不参与投票。该机制体现了分布式共识的核心原则，
2026-06-01 08:07:18
288
原创 孤舟笔记 分布式与微服务篇六 ZooKeeper的Watch机制怎么实现的？面试官问的不是API，是原理
本文深入解析了ZooKeeper的Watch机制核心原理。Watch是一种一次性事件监听器，客户端在ZNode上注册后，服务端会存储Watcher列表。当数据变更时，服务端主动推送通知并自动删除Watcher。这种一次性设计避免了通知风暴（如1000个监听者×10次变更只需通知1000次），减轻服务端压力。通知仅包含事件类型和路径，不传新数据，客户端需自行拉取。文章详细阐述了Watch的生命周期、服务端存储结构（WatchManager的双HashMap）以及设计考量，并提供了面试回答技巧和加分知识点（如C
2026-05-31 09:20:44
314
原创 孤舟笔记 分布式与微服务篇五 ZooKeeper到底是个啥？面试必问的分布式协调者，原理一次讲透
ZooKeeper是分布式协调服务，核心功能包括配置管理、服务注册和分布式锁等。其数据模型采用树形ZNode结构，支持持久节点和临时节点，后者在会话断开时自动删除。通过Watch机制实现数据变更主动通知，避免轮询开销。ZAB协议保证数据一致性，采用过半确认机制和基于ZXID的Leader选举。ZooKeeper适用于协调场景而非存储，存在写入性能受限等局限性。面试时应重点阐述其数据模型、核心机制和一致性协议，而非仅将其视为注册中心。
2026-05-31 09:20:27
397
原创 孤舟笔记 分布式与微服务篇四 负载均衡到底在均衡啥？面试官问的绝不仅仅是Nginx配置
本文从多个维度系统讲解了负载均衡技术。首先区分了服务端负载均衡（如Nginx/F5）和客户端负载均衡（如Ribbon/Dubbo）的实现方式，对比了四层（基于IP/端口）和七层（基于HTTP内容）的负载均衡特点。重点介绍了轮询、随机、加权、最小连接数和一致性Hash等核心算法及其适用场景，特别强调了一致性Hash对有状态服务的重要性。文章还探讨了健康检查、会话保持、灰度发布等进阶问题，并提供了面试回答技巧。通过类比排队叫号、快递分拣等生活场景，生动形象地解释了负载均衡的核心概念。
2026-05-30 07:15:53
521
原创 孤舟笔记 分布式与微服务篇三 分布式和微服务到底啥区别？面试官一问就混，三分钟帮你理清
摘要： 分布式与微服务的核心区别在于概念定位、拆分维度和解决问题不同。分布式是部署架构，关注多机协同（如Redis集群），解决CAP问题；微服务是架构风格，按业务拆分独立服务（如Spring Cloud），侧重服务治理。微服务必为分布式，但分布式不一定是微服务（如HDFS）。关键差异：分布式实现"多人协作"，微服务实现"专业分工"。演进路径应为单体→分布式→微服务，避免过度设计。面试需明确：分布式解决机器协同，微服务解决业务解耦。
2026-05-30 00:48:38
350
原创 孤舟笔记 分布式与微服务篇二 HTTP和RPC到底啥区别？面试官一问就懵，看完这篇再也不怕
HTTP与RPC远程调用对比分析：HTTP作为标准传输协议，具有通用性强但性能较低的特点，适合对外API和多语言环境；RPC作为调用方式，采用自定义二进制协议和长连接，性能更高（3-5倍），调用体验更便捷，适合内部服务间高频调用。关键差异体现在协议格式（HTTP冗长vs RPC紧凑）、序列化方式（JSON文本vs二进制）和连接管理（短连接vs长连接）。选型建议：对外开放接口用HTTP，内部核心服务用RPC，云原生场景可考虑基于HTTP/2的gRPC方案。理解二者本质区别需从协议、性能、使用体验三个维度综合分
2026-05-29 12:08:35
376
原创 孤舟笔记 分布式与微服务篇一 面试总问RPC框架，它到底是个啥？凭什么远程调用像调本地方法一样丝滑
RPC（远程过程调用）框架的核心原理是通过动态代理、序列化和网络传输技术，让远程方法调用像本地调用一样简单。其工作流程包括：代理拦截方法调用→序列化请求→网络传输→服务端执行→返回结果。相比HTTP调用，RPC采用更高效的TCP自定义协议和二进制序列化（如Protobuf），并提供服务发现、负载均衡等治理能力。典型框架如Dubbo、gRPC通过封装底层细节，实现了高性能的分布式服务通信。理解RPC的关键在于把握其"透明化远程调用"的设计理念和完整的调用链路实现机制。
2026-05-29 01:36:54
284
原创 孤舟笔记 互联网常用框架篇十 MyBatis是如何进行分页的？三种方式各自的优劣
本文全面解析MyBatis的三种分页实现方式：1）逻辑分页（RowBounds）通过内存截取全量数据，性能差且易OOM；2）物理分页需手动编写LIMIT SQL，性能好但繁琐；3）插件分页（PageHelper）通过拦截器自动改写SQL并执行COUNT查询，是生产环境推荐方案。文章还深入分析了PageHelper的工作原理、使用注意事项，并针对深分页问题提出游标分页优化方案。最后总结了面试回答技巧，强调理解RowBounds缺陷和深分页优化是加分项。
2026-05-28 00:11:47
387
原创 孤舟笔记 互联网常用框架篇九 MyBatis中#和$的区别是什么？SQL注入你怕不怕
本文深入解析MyBatis中#和$的区别：#是预编译占位符，使用PreparedStatement的?占位，能防止SQL注入，适用于值参数；$是字符串直接替换，存在SQL注入风险，但必须用于列名、表名等不能预编译的场景。关键点包括：#通过预编译提高性能，$必须配合白名单校验使用，以及两者的适用场景差异。文章还提供了面试回答技巧，强调要从安全性、使用场景和性能三个层面全面理解两者的区别。
2026-05-28 00:11:33
514
原创 孤舟笔记 互联网常用框架篇八 MyBatis缓存机制你真的懂吗？一级缓存和二级缓存的坑都在这
MyBatis缓存机制解析：一级缓存作用域为SqlSession，默认开启但Spring环境下几乎失效；二级缓存需手动开启，跨Session共享但存在序列化要求和多表关联脏数据风险。生产环境建议使用Redis等外部缓存替代MyBatis二级缓存。关键点包括：一级缓存在同一事务中才有效，二级缓存需关闭Session后数据才入库，多表关联查询易产生脏数据。
2026-05-28 00:11:14
514
原创 孤舟笔记 互联网常用框架篇七 Netty中Pipeline工作原理是怎样的？Handler链是怎么串起来的
Netty的Pipeline是一个基于双向链表结构的责任链处理机制，核心要点如下： 数据结构：采用双向链表连接HeadContext和TailContext，中间插入多个Handler节点 处理方向： Inbound（入站）处理顺序：Head → Tail（如请求解码、业务处理） Outbound（出站）处理顺序：Tail → Head（如响应编码、网络写入） 关键设计： 通过ChannelHandlerContext实现事件传递 使用ctx.write()可优化Outbound处理路径 最佳实践： 解码器
2026-05-27 03:18:03
508
原创 孤舟笔记 互联网常用框架篇六 为什么Netty线程池默认大小是CPU核数的两倍？这个2倍怎么来的
Netty Worker线程池默认设置为CPU核数×2，其理论依据是线程数计算公式：线程数=CPU核数×(1+I/O等待时间/CPU计算时间)。Netty假设I/O等待与CPU计算时间大致相等(W/C≈1)，因此采用2倍核数，使CPU在I/O等待时仍能保持高效计算。这一默认值适用于多数I/O密集型场景，但实际应用中需根据业务特点调整：纯I/O转发可增加线程数，计算密集型可减少，业务逻辑重的应使用独立线程池。最终最优线程数需通过压测确定，避免过多线程导致上下文切换开销。
2026-05-27 03:17:46
443
原创 孤舟笔记 互联网常用框架篇五 Netty是如何实现零拷贝的？这三种方式你都知道吗
Netty 的零拷贝技术分为三个层面：操作系统级、JVM 堆级和逻辑级。操作系统级通过 FileRegion（sendfile 系统调用）和 MappedByteBuffer（mmap 内存映射）实现内核态数据直接传输；JVM 堆级使用 DirectByteBuffer 避免堆内到堆外的数据拷贝；逻辑级则通过 CompositeByteBuf 逻辑合并、wrappedBuffer 包装和 slice 切片等技术实现应用层零拷贝。这三种层面的优化共同减少了数据在不同层级间的拷贝次数，显著提升了 I/O 性能。
2026-05-26 01:46:23
215
原创 孤舟笔记 互联网常用框架篇四 Netty中的Reactor模式你真懂了吗？主从Reactor到底怎么工作的
Netty高性能的核心在于其采用的Reactor模式实现。文章详细解析了Reactor模式的三种变体：单Reactor单线程、单Reactor多线程和主从Reactor多线程模型。Netty采用主从Reactor多线程模型，通过Boss Group（主Reactor）负责Accept连接，Worker Group（从Reactor）处理I/O读写，实现职责分离。其中Boss Group通常只需1个线程，因为Accept操作轻量；Worker Group默认使用CPU核数×2的线程数。这种设计既避免了线程爆炸
2026-05-26 01:46:09
400
原创 孤舟笔记 互联网常用框架篇三 Dubbo是如何动态感知服务下线的？注册中心和服务端双保险
本文介绍了Dubbo在微服务环境下感知服务下线的四种机制：1）注册中心通知机制，通过Watch/Callback实现秒级感知；2）心跳检测机制，通过定时心跳超时剔除实现分钟级感知；3）连接事件机制，通过TCP连接断开实现毫秒级感知；4）定时拉取机制，作为兜底方案保证最终一致性。文章详细分析了各机制的工作原理、实时性差异及协作关系，并比较了不同注册中心的实现特点（如ZooKeeper临时节点、Nacos推送机制）。最后提供了面试回答技巧，强调理解机制优先级和适用场景的重要性，并建议补充优雅停机和本地缓存等实战
2026-05-25 21:14:59
278
原创 孤舟笔记 互联网常用框架篇二 Dubbo服务请求失败怎么处理？集群容错策略你用过几种
Dubbo 提供 6 种集群容错策略：Failover（失败自动重试，默认，适合读操作）、Failfast（快速失败，适合非幂等写操作）、Failsafe（忽略异常，适合非关键操作）、Failback（失败定时重发，适合最终一致场景）、Forking（并行调用取最快，适合实时读）、Broadcast（广播调用所有节点，适合通知类操作）。就像你去餐厅点菜，第一家说"售完了"，你自动换第二家点——总有一家能做。的读操作——搜索引擎、推荐系统等。的场景——更新缓存、刷新配置等。——写日志、发通知、更新缓存等。
2026-05-25 21:11:36
164
原创 孤舟笔记 互联网常用框架篇一 Dubbo和Spring Cloud到底该选谁？优缺点对比一次讲透
本文对比了微服务架构中Dubbo和Spring Cloud的核心差异。从通信方式看，Dubbo采用RPC（二进制协议+长连接）性能更高，而Spring Cloud使用HTTP REST更通用；在组件完整性方面，Dubbo专注RPC调用需搭配其他组件，Spring Cloud提供全家桶解决方案；性能上Dubbo可达Spring Cloud的3-5倍，但实际业务中网络延迟影响更大。选型建议：高并发内部服务用Dubbo，多语言或外部对接用Spring Cloud，两者也可混合使用。文章还指出Dubbo 3.x的演
2026-05-25 21:10:12
293
原创 孤舟笔记 Spring全家桶篇二十六 简述Nacos配置更新的工作流程？配置变更是怎么通知到服务的
Nacos配置更新流程摘要 Nacos采用长轮询机制实现配置更新： 启动阶段：客户端全量拉取配置并注册Listener监听器 监听阶段：通过定时发送dataId+md5的长轮询请求（最长挂起29.5秒） 变更处理：服务端比对md5，不一致立即返回变化，触发客户端拉取新配置 生效阶段：更新Spring Environment并重建@RefreshScope的Bean 核心设计： 选用长轮询（而非推送）平衡实时性与实现复杂度 Raft协议保证服务端配置强一致性 2.x版本引入gRPC长连接优化实时性 （98字）
2026-05-25 21:08:46
307
原创 孤舟笔记 Spring全家桶篇二十五 谈谈EurekaServer数据同步原理？注册中心怎么保证数据一致性
Eureka数据同步机制解析 Eureka作为AP型注册中心的经典代表，其数据同步机制体现了分布式系统设计的精髓。核心采用Peer to Peer对等复制模型，所有节点地位平等，服务注册到任意节点后会异步复制到其他节点，确保最终一致性而非强一致性。同步流程包含四个关键阶段：注册阶段通过isReplication标记防止循环复制；Peer to Peer异步复制阶段保证高可用；心跳续约阶段30秒一次维持服务活性；注册表拉取阶段采用增量+定期全量策略优化性能。Eureka选择AP模型而非CP，在网络分区时仍能提
2026-05-25 21:08:39
809
原创 孤舟笔记 Spring全家桶篇二十四 谈谈你对Spring Cloud的理解？微服务架构它负责什么
Spring Cloud 是微服务架构的一站式治理框架，解决服务注册发现、配置管理、负载均衡、服务网关、熔断降级、链路追踪六大问题。Spring Cloud 与 Spring Boot 的关系是：Spring Boot 负责单个服务的开发，Spring Cloud 负责服务间的协调治理。：注册中心——所有服务启动时把地址注册上去，调用时从注册中心获取。：熔断器——调用失败达到阈值后"跳闸"，快速返回降级结果。就像公司前台——客户只找前台，前台帮你转接到对应部门。
2026-05-25 21:08:29
525
原创 孤舟笔记 Spring全家桶篇二十三 如何理解Spring Boot中的Starter？自定义Starter该怎么写
本文介绍了Spring Boot Starter的核心概念和工作原理。Starter是自动装配的交付单元，包含依赖包、自动配置类、条件注解和注册文件。其工作流程为：引入Starter→classpath变化→条件满足→自动配置生效。文章详细说明了Starter的四个核心组成部分（配置属性类、自动配置类、spring.factories注册和pom依赖管理），并对比了官方与第三方Starter的命名规范。最后给出了自定义Starter的注意事项，包括命名规范、配置提示、可选依赖和排除机制。全文通过类比&quo
2026-05-25 21:08:17
396
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人