泽韦德-优快云博客

原创【RocketMQ】第4节｜RocketMQ核心源码解读

Producer负载均衡：轮询MessageQueue，支持故障规避和自定义选择器。Consumer负载均衡：集群模式下通过多种算法分配MessageQueue，广播模式下所有消费者获取所有队列。

2025-07-10 00:11:49 611

原创【RocketMQ】第3节｜RocketMQ客户端编程模型

RocketMQ客户端通过灵活的消息模型和丰富的特性，满足了不同业务场景的需求。在实际开发中，需根据可靠性、吞吐量和顺序性要求选择合适的发送与消费模式，并结合Spring Boot等框架简化开发流程，同时注重幂等性和监控机制，确保系统稳定运行。

2025-07-08 17:38:10 818

原创【RockeMQ】第2节｜RocketMQ快速实战以及核⼼概念详解（二）

NameServer定位：集群的“大脑”，提供轻量级路由管理，不存储状态，节点间相互独立。功能接收Broker注册信息，维护Topic与Broker的路由关系。为Producer和Consumer提供实时路由查询服务。Broker定位：核心数据节点，负责消息存储、转发与查询，类似“硬盘”角色。分类Master：处理读写请求，支持数据同步到Slave。Slave：备份Master数据，故障时可切换为只读节点（主从架构）或自动升级为Leader（Dledger集群）。

2025-06-08 17:56:18 1027

原创【RockeMQ】第1节｜RocketMQ快速实战以及核⼼概念详解（一）

MQ（Message Queue，消息队列）是互联网中广泛使用的服务中间件，由“Message（消息）”和“Queue（队列）”组成。消息是不同进程间传递的数据，进程可在同一或不同机器上；队列是具有FIFO（先进先出）特性的数据结构，用于缓存数据。广义上，能实现消息跨进程传输和队列数据缓存的系统即可称为消息队列，如QQ、微信等面向人的系统，而本文讨论的MQ产品面向应用程序。

2025-06-08 17:55:38 1102

原创【Redis】笔记｜第10节｜京东HotKey实现多级缓存架构

功能点：（如代码有错误，欢迎讨论纠正）

2025-06-05 16:33:47 744

原创【Redis】笔记｜第9节｜Redis Stack扩展功能

【代码】【Redis】笔记｜第9节｜Redis Stack扩展功能。

2025-06-05 16:32:49 594

原创【Redis】笔记｜第8节｜大厂高并发缓存架构实战与优化

【代码】【Redis】笔记｜第8节｜大厂高并发缓存架构实战与优化。

2025-06-04 11:08:35 805

原创【Redis】笔记｜第7节｜大厂生产级Redis高并发分布式锁实战（二）

优势高性能读并发：读锁共享，支持多客户端同时读取热点缓存。强一致性：基于 Redis 的分布式特性，保证跨进程的锁互斥。自动续期：内置看门狗机制（默认 30 秒续期），防止业务执行期间锁过期。注意事项锁粒度控制：避免锁粒度过大（如全局锁）导致竞争激烈，建议按业务维度（如商品 ID）拆分锁。写锁优先级：Redisson 读写锁默认非公平（可能导致写锁饥饿），需业务评估是否需要公平锁（超时设置：需根据业务执行时间设置合理的锁超时时间（tryLock的leaseTime），避免锁无法及时释放。

2025-06-03 17:15:02 898

原创【Redis】笔记｜第5节｜Redisson实现高并发分布式锁核心源码

2. Lua脚本实现（关键）3. 关键点原子性：通过Lua脚本保证检查锁和创建锁的原子性。数据结构：使用Redis的存储锁信息，为线程标识，为重入次数。过期时间：默认30秒（看门狗机制自动续期），防止死锁。二、解锁流程1. 核心方法调用链2. Lua脚本实现（关键）3. 关键点安全释放：仅锁持有者（匹配）可释放锁。发布订阅：锁释放时通过Redis的通知等待线程。重入处理：通过递减重入次数，确保正确释放。三、锁续时（看门狗机制）

2025-06-02 10:12:15 643

原创【Redis】笔记｜第4节｜Redis数据安全性分析

Redis数据存储于内存，读写性能高效，但存在断电数据丢失风险，因此实际项目中需结合应用场景估算性能，在数据安全性与读写性能间寻找平衡。Redis提供压测脚本，可快速进行基准测试。策略特点适用场景无持久化完全关闭持久化，数据仅存内存，断电丢失。仅作缓存，无需持久化存储。RDB按时间间隔生成内存快照（全量备份），文件紧凑，恢复快但可能丢失部分数据。需定期备份、对性能敏感场景。AOF记录每一次写操作（增量备份），数据更完整但文件较大，恢复稍慢。高数据安全性要求场景。RDB+AOF。

2025-06-01 11:48:00 852

原创【MySQL】第13节｜MySQL 中模糊查询的全面总结

通过合理选择索引方案，可将模糊查询性能提升数十倍甚至数百倍，避免生产环境出现慢查询瓶颈。

2025-06-01 11:38:38 848

原创【Redis】第3节｜深入理解Redis线程模型

数据结构丰富：支持字符串、哈希、列表、集合、有序集合等复杂数据类型，远超传统Key-Value存储范畴。内存存储与持久化：数据基于内存存储确保读写高性能，同时通过RDB（快照）和AOF（日志追加）实现持久化，可作为数据库使用。功能定位扩展：从单纯缓存发展为具备Cache（缓存）、Database（数据库）、Vector Search（向量搜索）的综合服务。BigKey：占用内存大或元素数量多的键（如百万级元素的List），导致主线程阻塞、网络延迟增加。线程模型本质。

2025-05-29 21:33:10 971

原创【MySQL】第12节｜MySQL 8.0 主从复制原理分析与实战（二）

实际应用中，建议结合中间件（如 MySQL Router）和监控工具，构建健壮的分布式数据库集群。组复制（MGR）是 MySQL 官方提供的高可用解决方案，通过 GTID 和分布式协议解决了传统复制的痛点。custom.cnf（主节点配置）custom.cnf（从节点配置）custom.cnf（从节点配置）较高（需配置插件和分布式协议）mgr-node1（主）mgr-node2（从）mgr-node3（从）多主写入（需处理冲突）自动选主（单主模式）自动选举（单主模式）强一致（多节点确认）

2025-05-28 21:22:30 606

原创【MySQL】第11节｜MySQL 8.0 主从复制原理分析与实战（一）

MySQL主从复制是将主库（Source/Master）的数据变更同步到一个或多个从库（Replica/Slave）的机制，默认采用。从库接收Binlog并写入本地Relay Log，由SQL线程解析并回放，更新本地数据。主库的Dump线程根据从库请求的位点推送Binlog数据。主库执行写操作时，将变更记录到Binlog文件（如。）和起始位置（Position），请求同步数据。，支持全库、指定库或表的同步。中（需配置插件和参数）快（自动同步差集事务）中（至少1从库确认）中（需手动切换主库）

2025-05-27 21:26:47 1259

原创【Redis】第2节｜Redis基本数据类型

List实现简单队列，Stream支持消费者组。简单高效，支持过期时间。分值排序，范围查询高效。内存固定，适合亿级数据。字段结构化，节省内存。经纬度索引与距离计算。

2025-05-27 00:16:28 896

原创【Redis】第1节｜Redis服务搭建

集群创建、信息查询、节点列表。安全关闭 Redis 实例。连接 Redis 实例。每个节点独立配置文件。

2025-05-27 00:14:32 1473 2

原创【MySQL】第10节｜MySQL全局优化与Mysql 8.0新增特性详解

以下是 InnoDB 核心参数的含义、作用及推荐配置（结合 OLTP 与 OLAP 场景差异，实际需根据业务负载调整）：验证方法：通过查看缓冲池命中率（应 >99%）、锁等待次数（应接近 0），结合监控磁盘 IO 压力，动态调整参数。是 MySQL 中控制二进制日志（binlog）写入磁盘频率的核心参数，直接影响数据一致性、主从复制可靠性和系统性能。以下从作用、取值含义、影响及推荐配置详细说明：定义了 MySQL 在提交事务时，将 binlog 从内存缓冲区强制刷新到磁盘的频率（即调用系

2025-05-25 19:33:19 1307

原创【MySQL】第9节｜Innodb底层原理与Mysql日志机制深入剖析（二）

在 MySQL 中，redo logundo log和binlog是三种不同类型的日志，分别服务于不同的数据库特性（如事务原子性、持久性、一致性，以及数据备份、恢复、复制等）。以下从。

2025-05-25 19:32:08 733

原创【MySQL】第8节｜Innodb底层原理与Mysql日志机制深入剖析（一）

redo log 是 InnoDB 实现事务持久化的核心机制，通过。

2025-05-24 22:36:33 597

原创【MySQL】第7节｜Mysql锁机制与优化实践以及MVCC底层原理剖析

MVCC是InnoDB实现高并发的基石，通过版本链和读视图在。

2025-05-24 22:33:32 1360

原创【MySQL】第6节｜深入理解Mysql事务隔离级别与锁机制

间隙锁主要在。

2025-05-23 23:51:53 891

原创【MySQL】第5节｜Mysql索引优化实战二

字段有索引：count(*)≈count(1)>count(字段)>count(主键 id) //字段有索引，count(字段)统计走二级索引，二。字段无索引：count(*)≈count(1)>count(主键 id)>count(字段) //字段没有索引count(字段)统计走不了索引，1. 因为t2记录少，t2为驱动表，从表 t2 中读取一行数据（如果t2表有查询过滤条件的，会从过滤结果里取出一行数据）；count(主键 id)还可以走主键索引，所以count(主键 id)>count(字段)

2025-05-22 23:46:53 714

原创【MySQL】第4节｜Mysql索引优化实战一

结论：联合索引第一个字段就用范围查找不会走索引，mysql内部可能觉得第一个字段就用范围，结果集应该很大，回表效率不高，还不如就全表扫描结论：虽然使用了强制走索引让联合索引第一个字段范围查找也走索引，扫描的行rows看上去也少了点，但是最终查找效率不一定比全表扫描高，因为回表效率不高做了一个小实验：‐‐ 关闭查询缓存（Mysql8不需要，已经移除查询缓存功能）‐‐ 执行时间0.554s‐‐ 执行时间0.592s，强制走索引性能反而低注：5.7不走，Mysql8下实测，记录少也是走索引。

2025-05-21 15:36:35 900

原创【MySQL】第3节｜Explain详解与索引最佳实践

覆盖索引定义：mysql执行计划explain结果里的key有使用索引，如果select后面查询的字段都可以从这个索引的树中获取，这种情况一般可以说是用到了覆盖索引，extra里一般都有using index；：扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这种通常比ALL快一些。例如：在索引列中选取最小值，可以单独查找索引来完成，不需要在执行时访问表。

2025-05-20 21:57:26 859

原创【MySQL】第2节｜深入理解Mysql索引底层数据结构与算法

索引是帮助MySQL高效获取数据的排好序的数据结构。

2025-05-20 14:36:49 746

原创【MySQL】第1节｜全面理解MySQL架构

-name mysql8：给容器命名--privileged=true：给予容器额外的权限。这意味着容器将拥有主机系统的所有权限--restart=always：服务器启动时，自启动-p 13306:3306：端口映射，第一个 13306 是映射出去的端口，第二个 3306 是这个容器的端口-v /home/mysql8/data:/var/lib/mysql：文件挂载，前为宿主机的目录位置，后为容器内文件对应位置。

2025-05-19 15:56:17 1263

原创 Kafka集群K8S部署与开发实践

Kafka集群K8S部署与开发实践摘要本文记录了Kafka在K8S上部署过程及Spring访问Kafka代码示例，包括了如下内容：使用helm 3部署bitnami/kafka到Kubernetes 1.22环境使用spring-kafka进行消息收发的简单示例Kafka集群部署概述首先使用helm 3部署3节点ZooKeeper和3节点Kafka集群。如果要开户集群的数据持久化，需要提前在K8S上建立可用的PVC，但由于我的环境中还未搭建好NFS，就暂时配置两者的存储为临时存储作为演示，

2021-12-19 19:59:20 2106

原创 Redis6三种集群模式在Docker下的部署实践

概述本文记录了Redis常用的三种集群模式在Dokcer下的部署实践，由于只用来本地环境下的学习研究（作业）使用，只考虑了必需的参数配置。各种参数调优将在后续继续完善。Redis主从模式在该模式下，目标是配置一主两从，主从复制的Redis集群。为了部署方便，此处使用Docker-Compose作为容器编排的工具，它通过编写docker-compose.yml脚本声明Redis集群的部署配置，此处为了容器网络配置方便，我将所有节点的内部端口都保持为默认的6379，然后都其分别映射为宿主机上的不

2021-12-12 22:26:36 1593

原创 Mac OS下可视化Docker管理平台Portainer的安装方法

Portainer是一款轻量级的可视化Docker管理平台，它本身也是以容器化的方式运行，有了它我们可以用更直观的方式来与Docker引擎进行交互，尤其是对于刚入门Docker的新手。

2021-06-11 15:03:15 4025 1

原创 2021系统分析师论文题目记忆

2021系统分析师论文题目**论面向对象的系统分析方法及OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和OOD的区别之所在。OOA的任务是“做什么”，OOD的任务是“怎么做”。论静态测试方法及应用静态测试是指被测

2021-05-30 00:23:59 6124 1

泽韦德的专栏