roykingw的专栏

本文探讨了在领域驱动设计(DDD)中如何管理领域对象与数据存储之间的关系。作者通过电商系统中订单与地址的设计案例，分析了理想领域模型与现实数据库存储之间的鸿沟。DDD通过引入仓库(Repository)和工厂(Factory)两个核心组件来解决这一问题：仓库负责管理对象生命周期，工厂专注于从零散数据创建复杂领域对象。这种架构隔离了业务逻辑与数据存储细节，使得可以灵活更换存储方案而无需修改核心业务代码。文章强调DDD的核心价值不在于一开始就找到完美存储方案，而在于构建可随业务认知变化而灵活演进的系统架构。

今天这个视频我将来点不一样的。我会用DDD——领域驱动设计，这个在大厂和复杂项目中被广泛验证的方法论，带你看看真正的架构师是怎么思考这个问题的。更重要的是，掌握一套可以应对各种业务场景设计的思维框架。

聊到Kafka，你应该经常遇到这样的面试题：“小伙子，基础不错。那聊聊Kafka 凭什么这么快？”你可能觉得我看过，但是要注意，这既是送分题，又是送命题。说它是送分题，是因为大部分人都能答出“顺序写、零拷贝”这几个关键词。但如果不注意，这也是个送命题，因为这种题目是没有标准答案的。你所认为的那些标准答案，可能只是面试官眼中让人昏昏欲睡的陈词滥调。所以你提的每一个点，都是要体现出你对技术的思考和总结。

本文通过一张架构图深入解析RocketMQ的核心设计。从基础消息队列模型出发，逐步解决性能瓶颈（多队列+消费者组）、高可用问题（主从架构）和集群协调（自主设计的NameServer）。重点剖析了RocketMQ区别于Kafka的设计哲学——为金融电商等严肃业务场景服务，特别解释了事务消息的实现原理和生产者组的设计必要性。文章还提供了高阶面试题集锦，帮助读者掌握RocketMQ的核心技术要点和设计理念，真正理解其"为可靠业务而生"的完整闭环。最终达到从架构层面应对各类面试问题的能力。

文章摘要： 响应式编程是Java高性能开发的秘密武器，广泛应用于Spring Cloud Gateway等开源框架中。它通过异步非阻塞和事件驱动机制优化线程调度，解决传统同步编程的性能瓶颈。核心思想是将数据作为可观测流处理，并引入背压机制防止内存溢出。虽然响应式编程能显著提升高并发场景下的性能，但学习门槛高且应用场景有限，导致日常开发中较少使用。随着JDK21虚拟线程的推出，其用户态线程调度机制进一步简化了并发编程，降低了响应式编程的必要性。

现在IT大环境下滑，开始催生出了一个程序员极地求生新技能：防御性编程。​ 原本防御性编程的意思是在写业务代码时应该要更多的考过各种可能出现的边界情况，做更多防御性的考量。但是，防御性编程有了新的含义。那就是让我的代码只有我能看懂，别人都看不懂。这样，别人就无法抢我的饭碗了。老板裁员时自然也要掂量掂量了。

文章摘要： Redis之所以快，关键在于其精细化的内存管理和数据结构设计。源码分析揭示，Redis根据value类型采用不同存储策略：1) 数字类型使用int直接存储，并复用缓存对象；2) 短字符串(≤44字节)采用embstr紧凑存储，将字符串与redisObject连续存放；3) 大字符串使用raw类型分散存储。此外，Redis通过预定义SDS(Simple Dynamic String)结构，采用固定长度的内存分配策略，避免了C语言字符串的缺陷，提升了内存访问效率。这种底层优化使Redis在内存操作上

面试题就是一没有体系化的基础知识作为支撑，二没有明确的项目环境作为背景，零零散散的到处聊聊天而已，却偏偏要为了一点流量装个逼。一整个机构的人，天天专业的忙乎着这点事情，赚点生活费，到头来还不如你这时不时的出来蹦跶两下？一帮帮人，从小白学java，最少也要学个年把，好不容易到了要出山的时候了，你们一个劲的鼓吹他们白学了，趁早转行。在这个连公务员，老师的饭碗都端不稳的时代，各行各业都应该要抱团取暖的时候，你们一个个来拆柱子，属实可恶。最后，java的行情确实不好，但是，这是个大环境，不是java的祸。

​ 关于DDD，大部分朋友应该都听说过。 全称是Dmoain Driven Design，翻译过来就是领域驱动设计。这个神秘的架构思想，虽然远没有SpringBoot这类框架这么名声在外，但是却经常时不时冒出来，牵动一下大家的神经。美团、阿里每年的技术年会都会有关于DDD的经验分享，而另一方面，又有移动、电信等公司爆出DDD从入门到放弃的失败案例。​ 那么到底什么是领域驱动设计呢？是不是用上了DDD的所谓四层架构，就是在用DDD了？其实DDD这东西看起来挺抽象，但是核心就是需要搞明白三个问题。

如果面试问你，你会做一个权限系统吗？那你肯定会说做过。不就是各种登录、验证吗。我做的第一个CRUD应用就是注册、登录。简单！但是，如果问你在工作中真的做过权限系统吗？其实很多人都只能默默摇摇头。因为在很多真实项目中，权限系统可能不是最复杂的，但一定是牵连最广的。因此往往大型项目中真正去做权限系统的，都只是非常核心的一小部分人。而如果你的应用越来越复杂，作为安全门户的权限系统也会随着变得更加复杂。各种方案层出不穷。

​ 我们写的Java应用，都是以Jar包的形式发布的，所以对于Jar包，你一定习以为常。但是，如果你有一天打开一下JDK9以后的版本在你本地的安装目录，你会发现，JDK中那些熟悉的jar包，完全不见了。取而代之的是一些jmod文件。​ 甚至在熟悉的IDEA里，JDK的包下也不再是一个个Jar包，而变成了一个个与这些jmod文件对应的模块。​ 这些jmod文件是什么呢？​ 其实这些jmod文件可以认为是一种特殊的jar包。JMOD设计为在编译时间和链接时间使用，但不在运行时使用。

人生三大境界，见山是山，见山不是山，见山还是山！​ 学了好多年Java，你知道你写的java代码到底是什么样子的吗？k=k++，这样一个简单的代码，就足够考验考验Java程序员的斤两。​ 类似这样的非人类代码的面试题，其实不在少数。这一类面试题，想要考验的，从来不仅仅是程序员的代码理解能力，而是对语言底层逻辑的熟悉程度。​ 如果你是一个刚入门的Java新手，那么，对于这一类问题，只要能够推断出执行的结果就行了。

MySQL，是现在业界最受欢迎的关系型数据库之一，他的好处毋庸置疑。但是这也让MySQL成了面试中的重灾区。到底要怎么理解MySQL那些复杂又神秘的底层架构呢？这次楼兰就带你从日志系统出发，快速解析MySQL的整体架构设计。​ MySQL的日志文件分为redolog，undolog和binlog三种。这些复杂的日志文件分别是干什么的？有什么关系？接下来我们就一层层的来拆解MySQL。

各位伟大的Java程序员，现在有一条财富自由的路摆在你的面前，你有没有信心为此去挑战一下自己？​ 这次我们来聊一个比较有意思的话题，如何防止Class文件被反编译。

现在面试动不动就是问三高架构。应用大了，数据量多了，查询性能自然就下降了。怎么办呢？很多人自然就想到分库分表。但是一旦把底层数据库给拆分开了，在业务层面就会暴露出很多问题。那么在一个具体的业务场景下，要如何设计分库分表方案，并对方案进行优化呢？这次就以用户信息这个具体的场景来分享下如何设计分库分表方案。

@Autowired和@Resource这两个注解的功能都差不多，都是在Spring框架中做自动注入的。但是他们有什么区别呢？楼兰带你来分析分析

同步刷盘，异步刷盘？同步同步，异步同步？零拷贝，顺序写？你是不是曾经在各种各样的流量短视频和博客中听说过跟RocketMQ相关的这些亮瞎眼的高大上的技术名词？你有没有想过自己去RocketMQ中看看这些概念背后的Java代码是什么样的？如果你有过这样的想法，那么，楼兰到你到RocketMQ的源码当中逛逛，看看RocketMQ的大神们，是如何用简单常见的MVC思想开发出RocketMQ这样的神作的。

比如在分布式场景下做用户登录功能，我们就可以将用户信息以JSON字符串的形式保存到Redis中，来代替单体应用中的Session，从而实现统一的登录状态管理。哈希函数的选择对过滤器的性能有很大影响，理想的哈希函数应该具有良好的散列性，使得不同的输入尽可能均匀地映射到位数组的不同位置。通常使用的 keys * 这样的指令，在生产环境一般都是直接禁用的，因为这样会产生严重的线程阻塞，影响其他的读写操作。所以，在布隆过滤器的初始化过程中，通常只需要指定过滤器的容量和误判率，就足够了。相对的，算法实现也就更复杂。

​ 使用CompletableFuture，程序员可以很方便的控制线程的执行顺序。包括串行、并行或者多个线程的组合与转化功能。​ CompletableFuture主要实现了两个关键接口：Future：Future是一个代表异步计算结果的对象。它允许你从一个异步操作中获取结果（一旦结果可用），取消正在执行的计算，或者检查计算是否已经完成。Future 通常与 ExecutorService 结合使用来提交任务，并且是 java.util.concurrent 包的一部分.

程序员短视频上瘾综合症

JVM 调优快速上手指南。最快速度带你上手虚无神秘的 JVM 调优。

​ 关于中年危机，网上已经有了各种各样的解读。但是，这两天一个学员跟我简单几句聊天，却触发了对于中年危机的另一种思考。如果你曾经也有点迷茫，或许你可以稍微花几分钟看下这个故事。

RocketMQ 5.x版本快速上手

所有Follower Partition上报后，Leader Partition才能更新HW的值，然后Follower Partition在下次拉取消息时，才能更新HW值。当Leader Partition出现切换，所有的Follower Partition都按照自己的HW进行数据恢复，就会出现数据不一致的情况。所以在很多对性能要求比较高的线上环境，会选择关闭Kafka的这个Leader Partiton自平衡操作，而用其他运维的方式手动进行Leader Partiton自平衡，尽量减少自平衡过程。

而在一个Partition的众多备份中，需要选举出一个Leader Partition，负责对接所有的客户端请求，并将消息优先保存，然后再通知其他Follower Partition来同步消息。​ 当一个集群内的Kafka服务启动时，就会尝试往Zookeeper上创建一个/controller临时节点，并将自己的brokerid写入这个节点。​ 选举产生的Controller节点，就会负责监听Zookeeper中的其他一些关键节点，触发集群的相关管理工作。

​ 这一部分主要是理解Kafka的服务端重要原理。但是Kafak为了保证高吞吐，高性能，很多具体实现都是相当复杂的。如果直接跳进去学习研究，很快就会晕头转向。所以，找一个简单清晰的主线就显得尤为重要。这一部分主要是从存储的角度来理解Kafka的Broker运行机制。这对于上一章节建立的简单模型，是一个很好的细节补充。​ Kafka依赖很多的存储数据，但是，总体上是有划分的。Kafka会将每个服务的不同之处，也就是状态信息，保存到Zookeeper中。

快速、系统掌握Kafka生产者消息事务

Kafka消息发送幂等性

快速理解Kafka的发送应答机制

快速理解Kafka的消息路由机制

快速理解Kafka的消息序列化机制

​ 关于Kafka保证消息不丢失的问题，就简单总结到这里，但这其实并不是结束。相反，随着你对Kafka理解得越深，你会发现这个问题会有更多的发散空间。像MQ如何保证消息不丢失？如何不重复消费？如何处理消息积压？等等，这都是一系列非常开放的面试题。对于你是否真正理解了每个MQ产品，是非常好的检验标准。所以，这么好的题目，如果只是简简单单背个八股文，那太可惜了。...

Kafka的HighLevel API的重要目的就是想要简化客户端的使用方式，所以对于API的使用，尽量熟练就可以了。对于其他重要的属性，都可以通过源码中的描述去学习，并且可以设计一些场景去进行验证。其重点，是要逐步在脑海之中建立一个Message在Kafka集群中进行流转的基础模型。​ 其实Kafka的设计精髓，是在网络不稳定，服务也随时会崩溃的这些作死的复杂场景下，如何保证消息的高并发、高吞吐，那才是Kafka最为精妙的地方。但是要理解那些复杂的问题，都是需要建立在这个基础模型基础上的。...

​ 这一部分主要是从客户端使用的角度来理解Kakfa的重要机制。重点依然是要建立自己脑海中的Kafka消费模型。Kafka的HighLevel API使用是非常简单的，所以梳理模型时也要尽量简单化，主线清晰，细节慢慢扩展。...

言简意赅，快速从零开始构建Kafka整体知识体系，有问题回头再来查。

消费者端存储广播消费的本地offsets文件的默认缓存目录是 System.getProperty(“user.home”) + File.separator + “.rocketmq_offsets” ，可以通过定制 rocketmq.client.localOffsetStoreDir 系统属性进行修改。本地offsets文件在缓存目录中的具体位置与消费者的clientIp 和 instanceName有关。...

​ 关于MyCat，不用做过多介绍，曾经大名鼎鼎的分库分表中间件。诞生于2013年，从MyCat1.6版本之后，陷入了一段时间的沉寂。从2021年11月低开始，重新推出新版本的MyCat2，官网地址：http://www.mycat.org.cn/ 。​ 重要特性一目了然，独立，是他最大的标签。然后在他的Git仓库中，对产品有一个简单的介绍：​ 立足于Sharding分库分表。简单、快速是MyCat2对自己最直白的声明。他的定位其实是代表了一整套基于MySQL的分布式数据处理系统，可以让MySQL拥有堪比

一套框架，带你对接所有的MQ产品。

文章目录一、整体理解新版本二、5.X部分新特性1、DistSQL2、可插拔内核3、数据迁移三、全部内容总结一、整体理解新版本​ ShardingSphere在2021年十月份推出了5.0的第一个发布版本，并在2022年一月份推出了5.1版本。从整体来看，ShardingSphere5.x将自己的功能定位从数据库中间件升级到了DataBase Plus，数据库功能增强。核心产品定位的变化，必然会带来非常多的改变。不过从功能方面来看，目前5.X版本还只是做了一些功能增强，但是核心功能并没有太大的变动。很多规

DDD真的来了。后微服务时代，软件系统越来越庞大，也越来越老化。需求越来越模糊，代码越来越混乱，测试越来越困难，技术演进也基本不可能。大型软件项目很快从充满朝气的，充满竞争力的青年，变成了不求变，不敢变的老年。如何解决系统老化的问题？DDD领域驱动设计成了业界最大的希望。各大厂都在落地DDD，还不知道DDD？那就真的OUT了。大龄程序员如何提高竞争力？靠你的技术实力吗？信息爆炸的时代，你会的技术别人分分钟就能学会，凭什么来拉开你与别人的差距？其实方法都知道，提升架构思维，设计高质量的架构，写高质量的代码