<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[mf97532的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/mf97532</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; mf97532]]></copyright><item><title><![CDATA[用通俗的语言介绍 RPC 框架的架构原理！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/155038816</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/155038816</guid><author>mf97532</author><pubDate>Wed, 19 Nov 2025 21:49:52 +0800</pubDate><description><![CDATA[（1）服务提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的 Thrift 框架的IDL文件，Web service的 WSDL 文件；服务的消费者需要通过一定的场景获取远程服务调用相关的信息。（2）远程代理对象：服务消费者用的服务实际是远程服务的本地代理，说白了就是通过动态代理来实现的。（3）序列化：毕竟是远程通信，需要将对象转化成二进制流进行传输。不同的RPC框架应用的场景不同，在序列化上也会采取不同的技术。（4）通信。]]></description><category></category></item><item><title><![CDATA[记一次现网内存泄漏问题排查和分析]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/155038789</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/155038789</guid><author>mf97532</author><pubDate>Wed, 19 Nov 2025 21:48:21 +0800</pubDate><description><![CDATA[但是为什么会内存溢出呢？按说访问量也不是很高，于是进行了下面的排查和分析。]]></description><category></category></item><item><title><![CDATA[手绘6张图彻底搞懂动态代理！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/155038773</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/155038773</guid><author>mf97532</author><pubDate>Wed, 19 Nov 2025 21:47:35 +0800</pubDate><description><![CDATA[在讲解动态代理前我们先聊聊什么是静态代理。]]></description><category></category></item><item><title><![CDATA[面试官：详细说说你对序列化的理解？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/155038761</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/155038761</guid><author>mf97532</author><pubDate>Wed, 19 Nov 2025 21:46:53 +0800</pubDate><description><![CDATA[前面引入游戏的例子是为了让大家生动地理解什么是序列化和反序列化。序列化是指将对象实例的状态存到存储媒体的过程反序列化是指将存储在存储媒体中的对象状态装换成对象的过程把对象转化为可传输的字节序列过程反序列化：把字节序列还原为对象的过程。]]></description><category></category></item><item><title><![CDATA[10 张图搞懂服务注册发现机制！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/155038745</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/155038745</guid><author>mf97532</author><pubDate>Wed, 19 Nov 2025 21:46:06 +0800</pubDate><description><![CDATA[在单体架构中一个应用程序就是一个服务包，包内的模块通过函数方法相互调用，模型足够简单，根本没有服务注册和发现一说。在微服务架构中会将一个应用程序拆分为多个微服务，微服务会部署在不同的服务器、不同的容器、甚至多数据中心，微服务间要相互调用，服务注册和发现成为了一个不可或缺的组件。]]></description><category></category></item><item><title><![CDATA[Redis 突然变慢了如何排查并解决？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/155038714</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/155038714</guid><author>mf97532</author><pubDate>Wed, 19 Nov 2025 21:45:15 +0800</pubDate><description><![CDATA[如下检查清单，帮助你在遇到 Redis 性能变慢的时候能高效解决问题。获取当前 Redis 的基线性能；开启慢指令监控，定位慢指令导致的问题；找到慢指令，使用 scan 的方式；将实例的数据大小控制在 2-4GB，避免主从复制加载过大 RDB 文件而阻塞；禁用内存大页，采用了内存大页，生成 RDB 期间，即使客户端修改的数据只有 50B 的数据，Redis 需要复制 2MB 的大页。当写的指令比较多的时候就会导致大量的拷贝，导致性能变慢。Redis 使用的内存是否过大导致 swap；]]></description><category></category></item><item><title><![CDATA[图盘点七种基本的GC垃圾回收算法！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706691</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706691</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 22:11:32 +0800</pubDate><description><![CDATA[内存其实就是一块连续的空间，可以看做一个大数组，这块空间在业务运行时，经常会或零散或整齐的分布一些大大小小的对象，怎么样高效的分配和回收这块空间，同时尽量不影响业务系统的运行，就是 GC 垃圾回收要做的事，学习了七种基本的 GC 算法之后，我们更加知道，工程技术中没有“银弹”，没有完美无缺的算法，只有最适合自己业务系统的解法。]]></description><category></category></item><item><title><![CDATA[三万字盘点Spring最最核心的9大核心功能！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706647</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706647</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 22:09:39 +0800</pubDate><description><![CDATA[本节主要讲了实现IOC的几个核心的组件BeanFactory及其接口体系：BeanDefinition及其相关组件：BeanDefinitionReader和ClassPathBeanDefinitionScanner：读取资源，生成BeanDefinitionBeanDefinitionRegistry：存储BeanDefinitionBeanFactory核心实现：DefaultListableBeanFactory：IOC容器，同时实现了BeanDefinitionRegistry接口。]]></description><category></category></item><item><title><![CDATA[如何画好一张架构图？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706462</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706462</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 22:02:51 +0800</pubDate><description><![CDATA[系统采用什么样的应用架构，则受到业务复杂度的影响，包括企业的发展阶段和业务特点；业务的复杂度（包括业务量大）必然带来技术的复杂度，应用架构的目标是在解决业务复杂度的同时避免技术太复杂，确保业务架构落地。技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm 等），这些运行组件之间的关系，以及部署到硬件的策略。对需求全盘理解之后，进行高度的抽象分类，然后对各个分类进行对应的产品设计，完成抽象的逻辑梳理和数据梳理，逻辑和数据最终组成一个有机体，成为产品架构。]]></description><category></category></item><item><title><![CDATA[七种分布式全局 ID 生成策略，你更爱哪种？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706429</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706429</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:58:57 +0800</pubDate><description><![CDATA[上了微服务之后，很多原本很简单的问题现在都变复杂了，例如全局 ID 这事！最近工作中刚好用到这块内容，于是调研了市面上几种常见的全局 ID 生成策略，稍微做了一下对比，供小伙伴们参考。当数据库分库分表之后，原本的主键自增就不方便继续使用了，需要找到一个新的合适的方案。接下来我们一起来捋一捋。]]></description><category></category></item><item><title><![CDATA[探秘Redis架构演化之路！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706374</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706374</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:56:20 +0800</pubDate><description><![CDATA[总结一下，我们是如何从 0 到 1，再从 1 到 N 构建一个稳定、高性能的 Redis 集群的，从这之中你可以清晰地看到 Redis 架构演进的整个过程。数据怕丢失：持久化（RDB/AOF）主从副本（副本随时可切）故障手动切换慢：哨兵集群（自动切换）读存在压力：扩容副本（读写分离）写存在压力/容量瓶颈：分片集群分片集群社区方案：Twemproxy、Codis（Redis 节点之间无通信，需要部署哨兵，可横向扩容）分片集群官方方案。]]></description><category></category></item><item><title><![CDATA[聊一聊幂等设计？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706346</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706346</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:54:17 +0800</pubDate><description><![CDATA[幂等是一个数学与计算机科学概念。。比如求绝对值的函数，就是幂等的，。计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。]]></description><category></category></item><item><title><![CDATA[把Redis当作队列来用，真的合适吗？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706201</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706201</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:53:28 +0800</pubDate><description><![CDATA[好了，总结一下。这篇文章我们从「Redis 能否用作队列」这个角度出发，介绍了 List、Pub/Sub、Stream 在做队列的使用方式，以及它们各自的优劣。之后又把 Redis 和专业的消息队列中间件做对比，发现 Redis 的不足之处。最后，我们得出 Redis 做队列的合适场景。这里我也列了一个表格，总结了它们各自的优缺点。]]></description><category></category></item><item><title><![CDATA[DDD领域驱动设计理论]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706135</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706135</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:46:57 +0800</pubDate><description><![CDATA[领域建模的优秀与否，可以说直接决定着本次设计的成败，因为一旦发生建模边界不清晰，实体划分错乱，核心属性没有遵守开闭原则等问题，虽然当下可以正常交付业务，但是对于整个项目的后续发展可以说是灾难性的（之前接触过一个系统，因为一个实体的关键属性在最初设计时，没有制定标准规范，语义不统一，造成使用混乱。文章的前面部分，我讲了许多的概念：聚合根、值对象、领域事件、限界上下文等，但是实际设计开发过程中，并不需要照搬全套的体现出来，只要能够表达清楚核心的实体和关系、清晰的边界和合理的扩展性即是好的领域设计。]]></description><category></category></item><item><title><![CDATA[探秘Redis高效的网络模型！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154706061</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154706061</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:45:37 +0800</pubDate><description><![CDATA[这部分在一定程度上是我的强迫症作祟，我关于文章对知识点讲解的完备性上对自己近乎苛刻。我觉得把Socket讲明白对接下来的讲解是一件很重要的事情，看过我之前的文章的读者或许能意识到，我尽量避免把前置知识直接以链接的形式展示出来，我认为会割裂整篇文章的阅读体验。不割裂的结果就是文章可能显得很啰嗦，好像一件事情非得从盘古开天辟地开始讲起。因此，如果各位觉得对这个知识点有足够的把握，就直接略过好了～我们所做的任何需要和远程设备进行交互的操作，并非是操作软件本身进行的数据通信。]]></description><category></category></item><item><title><![CDATA[MySQL面试整理：MySQL日志15连问（带解析）]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154705914</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154705914</guid><author>mf97532</author><pubDate>Tue, 11 Nov 2025 21:43:30 +0800</pubDate><description><![CDATA[WAL，中文全称是Write-Ahead Logging，它的关键点就是日志先写内存，再写磁盘。MySQL执行更新操作后，在真正把数据写入到磁盘前，先记录日志。好处是不用每一次操作都实时把数据写盘，就算crash后也可以通过redo log恢复，所以能够实现快速响应SQL语句。其实所谓的两阶段就是把一个事务分成两个阶段来提交。两阶段提交两阶段提交主要有三步曲：redo log在写入后，进入prepare状态执行器写入bin log进入commit状态，事务可以提交。为什么需要两阶段提交呢?]]></description><category></category></item><item><title><![CDATA[你管这破玩意儿叫 MQ？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154618256</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154618256</guid><author>mf97532</author><pubDate>Sun, 09 Nov 2025 21:30:33 +0800</pubDate><description><![CDATA[最近是又喜又忧，喜的是业务量发展猛增，忧的是由于业务量猛增，一些原来不是问题的问题变成了大问题，比如说新会员注册吧，原来注册成功只要发个短信就行了，但随着业务的发展，现在注册成功也需要发 push，发优惠券,…等这样光注册用户这一步就需要调用很多服务，导致用户注册都需要花不少时间，假设每个服务调用需要 50 ms，那么光以上服务就需要调用 200 ms，而且后续产品还有可能再加一些等活动，每加一个功能，除了引入额外的服务增加耗时外，还需要额外集成服务，重发代码，实在让人烦不胜烦，张大胖想一劳永逸地解决这个问]]></description><category></category></item><item><title><![CDATA[26张图盘点架构师必备10大接口性能优化秘技，条条经典！]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154618146</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154618146</guid><author>mf97532</author><pubDate>Sun, 09 Nov 2025 21:29:40 +0800</pubDate><description><![CDATA[在测试案例对比中，时间耗时的顺序为 Pzstd < ISA-L < Pigz < LZ 4 < Zstd < Brotli < Gzip （排名越靠前越好），其中压缩和解压缩的时间在整体的耗时上占比较大，因此备选策略为 Pzstd、ISA-L、Pigz。详细的测试过程和方案对比可以参考原文：《速度与压缩比如何兼得？压缩算法在构建部署中的优化》9.3 小结。]]></description><category></category></item><item><title><![CDATA[Redis会遇到的15个「坑」，你踩过几个？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154618093</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154618093</guid><author>mf97532</author><pubDate>Sun, 09 Nov 2025 21:25:51 +0800</pubDate><description><![CDATA[好了，总结一下，这篇文章我们主要讲了 Redis 在「命令使用」、「数据持久化」、「主从同步」3 个方面可能存在的「坑」。怎么样？有没有颠覆你的认知呢？这篇文章信息量还是比较大的，如果你现在的思维已经有些「凌乱」了，别急，我也给你准备好了思维导图，方便你更好地理解和记忆。希望你在使用 Redis 时，可以提前规避这些坑，让 Redis 更好地提供服务。]]></description><category></category></item><item><title><![CDATA[如何实现可视化全链路日志追踪？]]></title><link>https://blog.youkuaiyun.com/mf97532/article/details/154618042</link><guid>https://blog.youkuaiyun.com/mf97532/article/details/154618042</guid><author>mf97532</author><pubDate>Sun, 09 Nov 2025 21:24:05 +0800</pubDate><description><![CDATA[传统的ELK方案是一种滞后的业务追踪，需要事后从大量离散的日志中搜集和筛选出需要的日志，并人工进行日志的串联分析，其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时，实时地完成了链路的动态串联，但由于是会话级别且仅关注于调用关系等问题，导致其无法很好地应用于业务追踪。因此，无论是传统的ELK方案还是分布式会话跟踪方案，都难以满足日益复杂的业务追踪需求。]]></description><category></category></item></channel></rss>