<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[xiaolyuh的专栏]]></title><description><![CDATA[凡是过去，皆为序幕]]></description><link>https://blog.csdn.net/xiaolyuh123</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; xiaolyuh123]]></copyright><item><title><![CDATA[TOGAF EA®企业架构师认证备考]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/167393721</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/167393721</guid><author>xiaolyuh123</author><pubDate>Sun, 11 Oct 2026 13:46:04 +0800</pubDate><description><![CDATA[企业：具有共同目标的、跨系统跨职能的复杂组织体（可含政府机构、公益组织、供应链伙伴），不限于商业公司。企业架构目的：开发 EA 的唯一目的是为有效变革提供指导（规划变革 + 治理变革）。手段：as-is（现状）→ to-be（目标）→差距分析 gap→路线图 roadmap→ 变革项目。Gartner 定义：创建/传达优化企业未来状态的关键原则和模型的过程。EA 关键益处。]]></description><category></category></item><item><title><![CDATA[READEME记录标准]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/164399202</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/164399202</guid><author>xiaolyuh123</author><pubDate>Sat, 05 Sep 2026 13:25:17 +0800</pubDate><description><![CDATA[xxx是基础公共组件库：提供通用工具类与开箱即用的接口请求日志 / 日志链路（SkyWalking）能力。]]></description><category></category></item><item><title><![CDATA[MySQL MVCC（多版本并发控制）实现机制深度解析]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157431645</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157431645</guid><author>xiaolyuh123</author><pubDate>Tue, 27 Jan 2026 14:54:58 +0800</pubDate><description><![CDATA[MVCC是InnoDB专为读已提交（RC）和可重复读（RR）核心思想：为每一行数据维护多个版本（快照），不同事务读取时，根据规则选择对应版本的数据，而非直接读取最新数据；适用场景：仅针对快照读（普通SELECT生效，当前读（INSERTUPDATEDELETE）仍需加锁；解决“读写冲突”，避免传统锁机制中“读阻塞写、写阻塞读”的问题，提升并发性能。核心依赖：MVCC基于行记录隐藏字段（DB_TRX_ID）、Undo Log版本链、Read View可见性规则实现；核心逻辑。]]></description><category></category></item><item><title><![CDATA[Kafka、RocketMQ、RabbitMQ 事务消息核心差异对比]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157288949</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157288949</guid><author>xiaolyuh123</author><pubDate>Fri, 23 Jan 2026 11:41:24 +0800</pubDate><description><![CDATA[设计目标差异：Kafka聚焦生产端原子性与Exactly Once，RocketMQ聚焦分布式事务，RabbitMQ仅支持本地Channel事务；实现机制差异：Kafka依赖事务协调器+2PC，RocketMQ依赖半消息+回查，RabbitMQ依赖AMQP协议的Channel事务；场景适配差异：Kafka适配大数据流，RocketMQ适配微服务分布式事务，RabbitMQ适配简单业务的本地事务。]]></description><category></category></item><item><title><![CDATA[Spring Boot 深度解析]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157263062</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157263062</guid><author>xiaolyuh123</author><pubDate>Fri, 23 Jan 2026 10:51:16 +0800</pubDate><description><![CDATA[/ 1. 自定义拦截器@Bean// 注册拦截器@Override// 2. 自定义消息转换器（如FastJson替换Jackson）@Override// 移除默认Jackson转换器// 添加FastJson转换器// 3. 自定义视图解析器（Thymeleaf）@Bean// 4. 跨域配置@Override若需要完全替换Spring Boot的默认MVC配置，可添加。]]></description><category></category></item><item><title><![CDATA[Spring MVC 深度解析]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157261724</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157261724</guid><author>xiaolyuh123</author><pubDate>Thu, 22 Jan 2026 22:13:30 +0800</pubDate><description><![CDATA[实现接口（或继承注册拦截器到Spring容器，指定拦截路径；// 1. 自定义拦截器@Component// 请求到达处理器前执行@Overrideresponse.getWriter().write("未登录");// 中断请求// 放行// 处理器执行后、视图渲染前执行@OverrideSystem.out.println("处理器执行完成：" + request.getRequestURI());// 视图渲染完成后执行@Override。]]></description><category></category></item><item><title><![CDATA[HikariCP 深度解析]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157256145</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157256145</guid><author>xiaolyuh123</author><pubDate>Thu, 22 Jan 2026 16:16:32 +0800</pubDate><description><![CDATA[核心优势：HikariCP 是高性能连接池，核心优势是快、轻量、可靠，Spring Boot 2.0+ 默认推荐使用；性能核心并发容器、零锁设计、精简代码、精细化连接管理；配置核心按 CPU 核心数配置，等于最大连接数，小于数据库连接超时时间；运维核心：监控活跃/空闲连接数、开启泄漏检测、配置合理的超时时间；适用场景：高并发、低延迟的互联网场景优先使用，需精细化监控可结合 Druid。配置：优先使用 Spring Boot 自动配置，核心参数按性能公式设置，避免过度配置；编码。]]></description><category></category></item><item><title><![CDATA[团队管理中最棘手的6个问题]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157177625</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157177625</guid><author>xiaolyuh123</author><pubDate>Tue, 20 Jan 2026 15:10:39 +0800</pubDate><description><![CDATA[研发团队的管理棘手问题，大多集中在。]]></description><category></category></item><item><title><![CDATA[Docker 深度全解析（容器化核心技术）]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157023688</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157023688</guid><author>xiaolyuh123</author><pubDate>Fri, 16 Jan 2026 12:23:02 +0800</pubDate><description><![CDATA[镜像是一个只读的、静态的文件包，是创建Docker容器的「模板/蓝本」，包含了运行应用所需的所有内容：应用程序、运行环境、系统库、配置文件、依赖包等。容器是Docker镜像的运行时实例，是一个可读可写的动态环境，是应用程序实际运行的载体。镜像=类，容器=类的实例对象。数据卷是Docker提供的独立于容器的持久化存储目录，是宿主机文件系统上的一个真实目录，可被挂载到容器内的指定路径，实现容器的数据持久化与共享。Docker的网络是为容器提供通信能力。]]></description><category></category></item><item><title><![CDATA[Kubernetes（K8s）深度全解析]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/157020858</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/157020858</guid><author>xiaolyuh123</author><pubDate>Fri, 16 Jan 2026 11:57:42 +0800</pubDate><description><![CDATA[A：调和机制是控制器的核心工作模式，无限循环执行「观察-对比-行动」，将实际状态调整为期望状态；是K8s的核心灵魂，所有自动化能力都基于该机制实现。Kubernetes是云原生技术体系的核心，其本质是容器编排与集群管理系统，核心价值是自动化、高可用、弹性伸缩、解耦。本文从核心架构→核心概念→核心工作机制→核心特性→运维配置→使用场景→常见问题，全维度深度解析了K8s，覆盖了从基础到进阶的所有核心知识点。声明式API为灵魂，调和机制为核心，控制器为管控核心，Pod为执行单元。]]></description><category></category></item><item><title><![CDATA[架构设计之千万级设备接入云平台方案]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156987602</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156987602</guid><author>xiaolyuh123</author><pubDate>Thu, 15 Jan 2026 15:56:13 +0800</pubDate><description><![CDATA[支撑千万级设备并发连接、海量消息高吞吐处理、设备状态实时监控、数据可靠存储与高效检索，满足高可用、高弹性、可扩展的物联网平台需求：设备接入层 → 协议适配层 → 消息处理层 → 业务服务层 → 数据存储层 → 监控运维层。]]></description><category></category></item><item><title><![CDATA[RocketMQ 深度详解]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156982277</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156982277</guid><author>xiaolyuh123</author><pubDate>Thu, 15 Jan 2026 14:31:29 +0800</pubDate><description><![CDATA[⑤Message：消息载体，封装业务数据。生产环境必用多Master多Slave主从模式，原因：Master负责读写，Slave同步数据，Master宕机后Slave无缝接管，无消息丢失，保障高可用和数据可靠性。Queue的核心作用是实现并行处理，多个Queue分布在不同Broker上，生产者负载均衡发送，消费者并行消费，提升吞吐量和并发能力。如果是「一个Topic一个文件」，Broker需要维护海量的文件映射关系，元数据存储压力大，而且Topic的创建/删除会带来大量的文件创建/删除操作，运维复杂。]]></description><category></category></item><item><title><![CDATA[Kafka 深度详解]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156980079</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156980079</guid><author>xiaolyuh123</author><pubDate>Thu, 15 Jan 2026 11:12:08 +0800</pubDate><description><![CDATA[核心组件包括 Producer（生产者，发送消息）、Consumer（消费者，消费消息）、Broker（服务节点，存储和处理消息）、Topic（主题，消息逻辑分类）、Partition（分区，物理存储单元）、Replica（副本，保障高可用）、Controller（控制器，管理集群元数据）。：Topic 是消息的逻辑分类，Partition 是 Topic 的物理存储单元，一个 Topic 可分为多个 Partition；：Offset 是消息在 Partition 内的唯一标识，是一个自增整数；]]></description><category></category></item><item><title><![CDATA[RabbitMQ 深度详解]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156955189</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156955189</guid><author>xiaolyuh123</author><pubDate>Wed, 14 Jan 2026 23:18:40 +0800</pubDate><description><![CDATA[保障：消费者只有成功处理完消息后，才会告知Broker删除消息，杜绝消费过程中消息丢失的问题，分为两种模式，，所有业务场景均围绕这三个核心价值展开，以下是生产中最常用的核心场景，覆盖99%的业务需求，所有RabbitMQ的消息流转，均基于这四个核心组件完成，是RabbitMQ的核心骨架，，从生产到消费全链路保障消息的可靠性，杜绝消息丢失，这是RabbitMQ的核心优势，各自的路由规则是什么？RabbitMQ的集群架构是保障高可用的核心，所有架构均基于。：RabbitMQ 消息从生产到消费的完整流程是什么？]]></description><category></category></item><item><title><![CDATA[MQTT 协议深度详解]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156941083</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156941083</guid><author>xiaolyuh123</author><pubDate>Wed, 14 Jan 2026 11:37:16 +0800</pubDate><description><![CDATA[Topic是 MQTT 的消息路由标识，本质是一个「层级化的字符串」，用于标识消息的类别和流向，相当于消息的「地址」。发布者发送消息时，必须指定一条「主题」，表示「这条消息属于哪个分类」；订阅者想要接收消息时，必须「订阅对应的主题」，表示「我要接收这个分类的消息」；Broker 会根据「消息的主题」，将消息精准推送给所有订阅了该主题的订阅者。QoS是 MQTT 协议的核心可靠性保障机制，表示「消息的投递质量/可靠性等级」，定义了发布者与Broker之间、Broker与订阅者之间的消息投递规则。]]></description><category></category></item><item><title><![CDATA[Redis 核心业务流程]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156910756</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156910756</guid><author>xiaolyuh123</author><pubDate>Tue, 13 Jan 2026 18:41:03 +0800</pubDate><description><![CDATA[Redis 启动加载完整核心流程（所有流程的统一入口）Redis 单线程命令执行核心流程（高性能底层根源，所有请求通用）Redis 过期Key清理核心流程（定期删除+惰性删除）Redis 内存淘汰机制执行流程（内存超限兜底）Redis RDB持久化完整核心流程Redis AOF持久化+AOF重写完整核心流程Redis 主从复制完整核心流程（含断点续传）Redis 哨兵模式故障转移完整核心流程Redis Cluster 哈希槽分配+数据迁移核心流程。]]></description><category></category></item><item><title><![CDATA[Redis 核心详解]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156895839</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156895839</guid><author>xiaolyuh123</author><pubDate>Tue, 13 Jan 2026 18:08:46 +0800</pubDate><description><![CDATA[高性能内存KV数据库 + 持久化 + 高可用 + 分布式，是互联网后端的核心中间件，无出其右。单线程模型 + 内存操作 + 高效底层数据结构 + 渐进式rehash，四大核心缺一不可。Redis的核心价值：不仅是缓存，更是一套完整的「数据结构解决方案」，覆盖绝大多数业务场景，无需重复造轮子。单机 → 主从（读写分离） → 哨兵（自动故障转移） → Cluster（分布式分片），按需选择，循序渐进。三分部署，七分运维。]]></description><category></category></item><item><title><![CDATA[架构设计之异地多活架构]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156891608</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156891608</guid><author>xiaolyuh123</author><pubDate>Tue, 13 Jan 2026 10:44:25 +0800</pubDate><description><![CDATA[异地多活架构的本质是“分层冗余+智能调度+数据一致”接入层通过DNS+网关跨地域冗余，实现流量就近接入与故障漂移；数据层按分类选择同步策略，通过多副本存储与一致性协议，保障核心数据零丢失；业务层无状态化设计，支持跨地域弹性扩容与无缝接管；调度层统一管控，实现故障自动检测、切换、恢复，缩短业务中断时间。异地多活不是“越复杂越好”，而是“适配业务需求的最优解”——核心业务追求极致可用性，非核心业务平衡成本与可用性，最终实现“业务永续、数据安全、体验无感知”的目标。]]></description><category></category></item><item><title><![CDATA[架构设计之千万级设备接入场景容灾方案]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156869806</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156869806</guid><author>xiaolyuh123</author><pubDate>Mon, 12 Jan 2026 18:33:32 +0800</pubDate><description><![CDATA[接入层通过多地域/多可用区网关集群，应对设备高并发连接与重连冲击；数据层通过多副本存储、异步传输、跨地域同步，保障核心数据零丢失；业务层通过熔断降级、多副本部署，实现故障隔离与弹性恢复；基础设施层通过网络、电力、存储冗余，筑牢底层保障；依托自动化监控与切换机制，缩短故障影响时间，最终实现“设备接入不中断、核心业务不停止、数据资产不丢失”的目标。要不要我帮你整理一份千万级设备接入容灾 Checklist，涵盖接入层、数据层、业务层等维度的校验项，可直接用于项目容灾落地与审计？]]></description><category></category></item><item><title><![CDATA[架构设计之微服务治理]]></title><link>https://blog.csdn.net/xiaolyuh123/article/details/156869468</link><guid>https://blog.csdn.net/xiaolyuh123/article/details/156869468</guid><author>xiaolyuh123</author><pubDate>Mon, 12 Jan 2026 18:17:20 +0800</pubDate><description><![CDATA[用标准化的规则约束分布式架构的复杂性，用体系化的机制保障架构的稳定性，用自动化的工具提升研发和运维效率。治理的核心逻辑：源头做设计管控，运行做容错保障，数据做自治隔离，可观测做问题兜底，安全做全链路防护，交付做高效迭代。治理的核心认知：微服务治理不是「管控」，而是「赋能」，通过治理减少无效内耗、规避架构风险、降低故障成本，最终让技术团队聚焦业务价值的交付。治理的核心节奏：治理是循序渐进的过程，不是一蹴而就的，先解决核心痛点（如稳定性、数据耦合），再逐步完善细节，最终实现全维度的合规治理。]]></description><category></category></item></channel></rss>