- 博客(141)
- 收藏
- 关注
RSS订阅原创 18-21源码剖析——Mybatis整体架构设计、核心组件调用关系、源码环境搭建
到mybatis官网https://mybatis.p2hp.com/，找到仓库地址https://github.com/mybatis/mybatis-3/releases/tag/mybatis-3.5.7，下载源码。我这里用的版本和视频中的一样3.5.7。错误2. 如果报配置文件找不到，就检查build后自己的target目录下，是否包含配置文件。可以试试把pom文件中resource和testResource相关的注释掉，用默认的方式。错误1：如果下面的报错，就在测试类中添加代码。
2025-04-16 19:50:42
821
原创 22-23源码剖析——初始化——解析核心配置文件
学习视频资料来源：https://www.bilibili.com/video/BV1R14y1W7yS测试类还是还是和以前一样，不解释了上篇我们讲到下面这行仅将核心配置文件从磁盘加载进内存中，变成输入流inputStream，并没有对核心配置文件进行解析。核心配置文件是通过SqlSessionFactoryBuilder的build方法完成的。下边我们详细进行介绍。2. 核心配置文件解析的准备工作2.1SqlSessionFactoryBuilderSqlSessionFactoryBuild
2025-04-16 16:23:41
875
原创 21源码剖析——初始化——加载核心配置文件
Resources类委托给ClassLoaderWrapper加载核心配置文件，ClassLoaderWrapper是个包装器，里边有多个ClassLoader。在ClassLoaderWrapper中选择正确的ClassLoader加载核心配置文件，并处理一些细节问题，可以使得上层的代码的耦合度，使得代码更加清晰。可以看到Resources.getResourceAsStream，仅仅是将配置文件从磁盘加载到内存，转换成了InputStream。并没有解析配置文件，具体的解析逻辑下一篇文章介绍。
2025-04-16 14:01:40
784
原创 15-17手写持久层框架——优化和总结
不过这是在测试类中执行的，如果要在项目中实际使用，需要定义UserDao 接口并实现，将上述操作封装进实现类方法中。可以看到结果也可以正确返回了。
2025-04-08 20:40:25
872
原创 09-14手写持久层框架——session创建、sql解析、参数设置、结果集封装
并把{}内值解析出来。因为这时的sql是#{}形式，如：select * from user where id = #{id} and username = #{username}，而预编译需要的是：select * from user where id =？这一步比较简单，因为我们在上一章解析xml配置文件的时候，已经创建了数据源，并封装金configuration中，这里从透传下来的configuration中直接取即可。，存到一个List parameterMappings中，用于后续设置参数。
2025-04-03 18:43:02
855
原创 04-08手写持久层框架——核心配置和映射配置文件解析
项目分为2个模块，ipersistent 和ipersistent-test。ipersistent为框架，ipersistent-test为框架使用端，ipersistent-test依赖ipersistent。视频里是使用maven管理项目，我这里是使用gradle管理项目。
2025-04-02 20:05:22
711
原创 01-03手写持久层框架——JDBC问题与框架实现思路
SqlMapConfig.xml存放的是数据库的配置信息和mapper.xml文件的路径。存放mapper.xml的路径，是为了解析时只需提供SqlMapConfig.xml的路径，就能解析出mapper.xml文件的路径，不用传2个路径了。mapper.xml存放sql信息，参数类型、返回值类型。
2025-04-01 19:29:56
1008
原创 Acknowledgment.nack方法重试消费kafka消息异常
当BatchAcknowledgingMessageListener批量消费消息时， 使用的是ConsumerBatchAcknowledgment，重试时需要告诉ConsumerBatchAcknowledgment要从这批量消息中的哪条开始重试消费，即要指定index值。而使用AcknowledgingMessageListener消费单条消息时，使用的是ConsumerAcknowledgment，重试时它知道重试当前的消息，因为就这一条，所以只需要指定重试时间就可以了。这样的设计也很好理解。
2025-03-11 12:59:59
931
原创 21.子领域——被误解和无用的概念
它是一个唯一的、定义明确的领域模型，要对它进行战略投资，并在一个明确的限界上下文中投入大量资源去精心打磨通用语言。它是组织中最重要的项目，因为这将是你与其他竞争者的区别所在。正是因为你的组织无法在所有领域都出类拔萃，所以必须把核心域打造成组织的核心竞争力。做出这样的决定需要对核心域进行深入的学习与理解，而这需要承诺、协作与试验。这是组织最需要在软件中倾斜其投资的方向。
2024-12-11 20:11:00
499
原创 20.LMAX——DDD的极致性能架构
极致性能全内存化模型设计，更灵活自由，可以大量使用对象和对象之间的引用。不像之前传统设计聚合的时候，是尽量减少聚合和聚合之间的引用。
2024-12-09 20:41:38
1267
原创 19.事件溯源
没必要每个场景都使用事件溯源当我们把不需要一些事件溯源的优点的时候，就没必要用事件溯源，其实大部分场景都不需要用事件溯源。当事件溯源优点有必要性时采用高性能写审计穿越排障建模更自由。
2024-12-03 20:19:26
1204
原创 08.聚合的上下限
每个黄色点代表一个业务对象，箭头表示它们之间存在的关系，被绿线圈起来的表示这几个业务对象之间存在一致性。到底按哪种方式去将它们聚合是件困难的事情，如果按一致性去划分，很难衡量到底哪几个对象之间一致性更强。再回到DDD的核心方法论：领域驱动模型，模型驱动软件设计。从问题域的角度来看，聚合是紧密联系的一组功能；从软件设计的角度来看，聚合是一个内存单元，包含一组对象，要被。
2024-11-11 11:15:21
385
原创 05-07实现面向对象领域模型-停车案例
在领域模块仅仅是定义，实现在领域外。我觉得这个也可以定义到领域外模块主要是报警策略的定义用到了监听器，所以只能放领域内了。仓储在领域模块内仅仅是定义，实现在领域外模块。
2024-11-01 18:51:27
939
原创 04.DDD与CQRS
CQRS全称Command Query Responsibility Segregation，即命令和查询职责分离。它的设计理念来源于单一职责原则。软件系统功能拆解成命令和查询命令：有作用，会导致系统发生变更。查询：无副作用，不会导致系统发生变更。
2024-10-30 17:13:12
798
原创 03.DDD六边形架构
对于程序单元A和B编译依赖：如果要编译A，必须要用到B的编译结果，则在编译期A依赖B。运行依赖：在运行期，如果B不能运行，则A一定也不能运行，则A在运行期依赖B。语义依赖：如果要理解A的语义，必须先理解B的语义，那么A在语义上依赖B。一般A在编译上依赖B，那么A在语义上也会依赖B，因为A使用的B的代码。
2024-10-30 15:34:02
992
原创 02.DDD实践路径
学习视频来源：DDD独家秘籍视频合集 https://space.bilibili.com/24690212/channel/collectiondetail?
2024-10-30 14:51:44
478
原创 MySQL COUNT(*)、COUNT(1)、COUNT(id)、COUNT(字段)效果及性能
效果上，都是统计满足条件的总行数，不考虑是否为null。COUNT(字段)是要考虑是否为空。性能上COUNT(*)>COUNT(1)>COUNT(id)>COUNT(字段)能用COUNT(*)就用COUNT(*)个人感觉，COUNT(1)和COUNT(id)没有存在必要，可以放弃掉，这样简单一点，哈哈哈哈哈哈！
2024-10-23 11:18:32
762
1
原创 MySQL8.0以下版本重启后自增主键值丢失问题
上周运维同学重启了UAT环境的MySQL数据库服务，刚开始我是不知道数据库重启了，先是业务服务开始异常，初步定位到的原因是一个表的主键ID出现了回退，又查到MySQL低版本（8.0以下）重启可能会导致自增主键值回退或重置，最后和运维同学确认了下重启时间，确认了原因。正如前文中所说，这种方式复杂且风险很大，MySQL8.0并不完全兼容低版本，升级后这个问题解决了，但可能会导致其他方面的问题，所以生产环境一般是不会同意这样做的。在MySQL8.0中，执行同样的操作，自增值仍为6，没有丢失，这里就不演示啦！
2024-10-21 18:27:26
1263
原创 Gradel离线、在线编译Java项目
离线编译Java项目，需要jdk、gradle。下载所需版本的gradle和jdk，gradle不区分windows环境和linux环境，但是jdk区分。以下基于windows环境，Linux环境把gradlew.bat换成 gradlew即可。1.进入项目目录2.在当前目录下，打开终端，执行命令。命令中指定gradle路径和jdk路径。本例中使用的JDK版本为windows下的1.8.0_xxx版本，可根据不同环境自行选择。
2024-09-23 19:52:02
481
原创 记一次极限的OPTIMIZE TABLE 经历
可以通过OPTIMIZE TABLE 回收掉没有在使用的磁盘空间碎片，但需要提前预估好供其“倒腾“使用的空间。
2024-09-05 11:28:37
1008
原创 将python项目打包成一个可执行文件（包含需要的资源文件）
项目源码是采用Python编写，代码中需要读取部分资源文件。现在需要将项目打包成一个exe文件，没有其他任何多余文件，仅1个exe文件。
2024-09-03 11:06:45
779
原创 Clickhouse Code: 173. xxxxx DB::Exception: Couldn‘t allocate 21 bytes when parsing JSON: While xx
我这里是使用Clickhouse对接Kafka消息，建立源表，物化视图并把数据存至目标表。在物化视图中需要对消息进行解析提取关键字段，用到了Clickhouse中的JSONExtractString函数，问题就出在这里。
2024-08-02 17:45:41
348
1
原创 @SchedulerLock注解使用
name任务唯一标识。最重要的参数。同一个name的任务，同一个时刻，多个线程只会有一个线程获取到锁。其他没有获取到锁的线程会跳过，不会阻塞等待。持有锁的最短时间。这个主要是防止不同节点时间存在误差，比如有个任务是0点执行，节点1的时间是准的，在0点执行花了30秒执行完成。节点2的时间比节点1慢了1分钟，那么节点2到0点的时候，又执行了一次任务。这个参数可以设置10秒、30秒等。保证不同节点的时间戳不会出现。持有锁的最长时间。主要是为了防止死锁。
2024-08-02 16:59:34
959
原创 @Scheduled注解定时任务未按时执行问题记录
经排查原因是因为每分钟执行一次的任务，在1分钟内执行不完，且@Scheduled注解底层虽然是使用线程池，但是线程池中默认只有一个线程！在0点的时候前面还有很多1分钟执行一次的任务没执行完，导致在0点执行的任务阻塞，直到前面阻塞的任务都执行完，1点多才执行0点的任务。在一个项目中多处使用了@Scheduled注解，有些任务是1分钟执行一次，有些任务是每天凌晨0点执行一次。但是发现本该在凌晨0点执行的任务在0点并没有执行，而是在凌晨1点多才执行，而且每次执行的时间还不一样。也可以向下边一样注入配置类即可。
2024-08-02 16:13:13
480
原创 Mongo删除数据 释放空间
最近因为业务需要，需要对Mongo数据库一个collection的一个字段进行调整。该字段本来存储了A,B,C 3个内容，现在需要将A,B,C3个内容分别存到3个字段，并把原字段删掉。这样做了以后，直觉上感觉数据占用磁盘大小应该不会变，因为数据还是那么多数据，只不过分开存储了，原来字段删了。但这样做完以后发现数据占用的空间几乎变大了1倍，已删除的数据磁盘空间没有得到释放。最后，发现mongo占用的内存也很大，我直接重启了mongo服务，发现内存占用变小了很多。显示结果如下：磁盘空间成功释放了5个多G。
2024-05-08 17:13:05
585
原创 Cause: com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large
查阅后发现问题是由于max_allowed_packet参数引起的，该参数是指mysql服务器端和客户端在一次传送数据包的过程当中最大允许的数据包大小。一次插入的数据超过了max_allowed_packet，则会数据库保存失败，报出异常。我这里是批量插入多条数据，数据条数目测有个几千条，数据大小超过了阈值。网上解决方案是修改max_allowed_packet的值，调大这个值，临时修改或者永久修改都可以。比如之前一次插入5000条数据，我这里改成一次插入500条，分10次插入就ok了。
2024-04-17 16:28:12
733
1
原创 Spring.Shell.History内置命令覆盖
最近工作上遇到的一个小问题，在Spring Shell中，我们可以自己定义一些命令，已完成我们想要的功能，也可以使用内置命令如help、history、clear。但当一些内置命令达不到我们想要的功能时，就需要对其进行重新。如本次遇到的histroy命令，显示的格式是一个List列表，所有命令在一行。而我想要其以每一条命令一行的格式输出，就需要对其进行覆盖。
2024-01-19 18:42:08
564
1
原创 《微服务架构设计模式》之三：微服务架构中的进程通信
正如刚才所见，你无法使用服务的IP地址静态配置客户端。相反，应用程序必须使用动态发现机制。服务发现的关键组件是服务注册表，它是包含服务实例网络位置信息的一个数据库。服务实例启动和停止时，服务发现机制会更新服务注册表。当客户端调用服务时，服务发现机制会查询服务注册表以获取可用服务实例的列表，并将请求路由到其中一个服务实例。服务及其客户直接与服务注册表交互通过部署基础设施来处理服务发现消息是由消息头部和消息主体组成。消息有几种不同类型的消息。文档：仅包含数据的通用消息。接收者决定如何解释它。
2023-11-07 18:48:00
370
原创 prysm-beacon-chain节点报错：Caught SIGILL in blst_cgo_init, consult ＜blst＞/bindinds/go/README.md. #12567
重新拉取镜像ethereum/client-go、 prysmaticlabs/prysm-beacon-chain，启动容器后发现ethereum/client-go正常，但是 prysmaticlabs/prysm-beacon-chain启动失败打出日志：Caught SIGILL in blst_cgo_init, consult /bindinds/go/README.md. #12567。经过排查，没找到具体原因，两台机器用的配置也相似，可能和硬件有关系。知道的朋友麻烦评论区告诉我一下。
2023-09-28 18:10:36
359
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人