- 博客(64)
- 收藏
- 关注
RSS订阅原创 Canal同步MySQL数据的优缺点以及加字段情况
实时、低侵入、增量、灵活、生态好。配置管理复杂、仅增量、需转换、DDL同步难、一致性和性能需保障。MySQL 5.7 及以下导致表重建和全表更新，产生海量 binlog UPDATE 事件。MySQL 8.0也会触发全表 UPDATE。解决加字段突增：用 MySQL 8.0+；避免；用NULL列+分批更新；低峰期操作。强队列缓冲；增加生产者/消费者/分区并行度；批量消费；消费者逻辑优化（幂等、过滤伪更新）；监控告警；弹性伸缩。(谨慎) Canal 过滤；暂停同步 + 全量重建；
2025-07-03 08:39:22
553
原创 Feign请求参数传递问题解决方案
在 Spring Cloud Feign 中，需要被注册为 Spring 的 Bean 才能生效，但不需要特定的注解标记拦截器本身。
2025-06-19 16:00:07
228
原创 Redission实现的分布式锁的可重入性
一个锁 Key (String) 对应一个 Hash 数据结构。Hash 的Field是 <ClientUUID>:<ThreadID>，唯一标识持有锁的客户端和线程。Hash 的Value是一个整数，记录该线程对这把锁的重入次数。加锁 (HSET ... 1)、解锁 ()、检查持有者 (HEXISTS)、删除锁 (DEL) 等关键操作都封装在 Lua 脚本中执行，保证原子性。同一个线程多次获取锁时，操作的是同一个 Hash Field，对其 Value 进行递增；
2025-06-18 20:04:50
817
原创 Redisson实现的分布式锁核心原理
Redisson 分布式锁的核心在于通过 Lua 脚本在 Redis 上原子性地操作一个 Hash 结构来实现锁状态的管理（创建、重入计数、释放），同时利用TTL 防止死锁，利用看门狗机制续期防止业务未完成锁超时失效，并利用发布订阅机制实现高效的锁等待通知。这种设计提供了高性能、高可靠且功能丰富（可重入、公平锁等）的分布式锁实现。
2025-06-18 20:00:12
1063
原创 算法日常记录
考虑枚举数组中的每个数 x，考虑以其为起点，不断尝试匹配 x+1,x+2,⋯ 是否存在，假设最长匹配到了 x+y，那么以 x 为起点的最长连续序列即为 x,x+1,x+2,⋯,x+y，其长度为 y+1，我们不断枚举并更新答案即可。同一组字母异位词中的字符串具备相同点，可以使用相同点作为一组字母异位词的标志，使用哈希表存储每一组字母异位词，哈希表的键为一组字母异位词的标志，哈希表的值为一组字母异位词列表。使用双指针，左指针指向当前已经处理好的序列的尾部，右指针指向待处理序列的头部。
2025-04-02 20:22:59
291
原创 Kafka的零拷贝
Kafka通过零拷贝技术，结合操作系统的sendfile和mmap机制，最大化减少了数据传输过程中的冗余步骤。这种设计使其在消费者拉取消息时能够高效利用系统资源，显著提升吞吐量并降低延迟，成为高并发场景下消息系统的理想选择。kafka使用sendfile：返回的是成功发送了几个字节数，具体发了什么应用层不知道。rocketMQ使用mmap：因为mmap返回的是数据的内容，应用层能获取到消息内容进行一些逻辑处理。rocketmq的一些消息需要获取到消息内容，比较将失败的消息重新投递到死信队列中。
2025-03-15 14:50:06
1204
原创 MQ保证消息的顺序性
生产者：按业务标识将消息路由到同一队列。MQ服务端：确保队列内消息存储有序。消费者：单线程消费队列，失败时阻塞重试。通过合理设计业务标识和MQ配置，可以在分布式系统中高效实现局部顺序性，平衡一致性与性能。2. 不同MQ如何选择三种MQ相比较而言，RocketMQ更适合顺序消费的业务场景. RabbitMQ需要设定交换机Exchange与队列Queue的绑定关系，并且一个队列只对应一个消费者Consumer才可以保证顺序消费，但是队列中的消息被消费者拉去后会从队列删除，如果。
2025-03-05 17:14:22
1820
原创 RocketMQ事务消息机制
RocketMQ事务消息通过两阶段提交和定时回查机制，结合半消息、Op消息的存储设计，实现了分布式事务的最终一致性。其源码核心在于和对消息状态的管理，以及的补偿逻辑。具体实现细节可参考官方文档及源码中的关键类（如和。
2025-03-04 13:09:06
704
原创 RocketMQ定时/延时消息实现机制
RocketMQ 的延迟消息是其核心特性之一，允许消息在指定延迟时间后才被消费者消费。定时消息生命周期。
2025-03-03 18:41:46
1488
原创 RocketMQ顺序消费机制
RocketMQ的顺序消费通过生产端路由策略消费端锁机制及Broker协同管理实现。其设计在保证局部顺序的同时兼顾性能，适用于多数业务场景。源码层面，和是核心模块，通过定时加锁单线程消费及队列快照管理确保顺序性。实际使用时需结合业务特点设计Sharding Key，并处理可能的异常情况。
2025-03-03 16:04:42
1895
原创 RocketMQ消息过滤机制
Tag 过滤：通过哈希匹配，性能最优，适合简单场景。SQL92 过滤：通过表达式解析，灵活性高，适合复杂业务逻辑。源码核心：过滤逻辑在 Broker 端处理，通过和实现高效匹配。
2025-03-03 11:58:13
1158
原创 RocketMQ 集群消费与广播消费
每个消费者分组只初始化唯一一个消费者，每个消费者可消费到消费者分组内所有的消息，各消费者分组都订阅相同的消息，以此实现单客户端级别的广播一对多推送效果。：，每个消费者分组下初始化了多个消费者，这些消费者共同分担消费者分组内的所有消息，实现消费者分组内流量的水平拆分和均衡负载。该方式一般可用于网关推送、配置推送等场景。该方式一般可用于微服务解耦场景。消费者启动时指定消费模式，通过。处理，根据分配的队列拉取消息。处理消息，区分并发/顺序消费。：消费完成后提交进度。
2025-03-02 11:58:51
1613
原创 RocketMQ客户端消息确认机制
生产者确认：通过同步/异步回调确保消息发送到 Broker。消费者确认：通过返回状态或手动 ACK 控制消息重试逻辑。可靠性保障：结合重试队列、消费进度持久化和死信队列实现端到端可靠性。源码中的关键逻辑集中在（发送）和（消费），通过状态机管理消息生命周期。
2025-03-02 11:34:43
1658
原创 RocketMQ的运行架构
RocketMQ 的架构通过 NameServer 实现解耦，Broker 主从设计保障高可用，生产者与消费者的分布式部署支持水平扩展。其高性能、可靠性和丰富的功能（如事务、顺序消息）使其适用于电商、金融等对消息一致性要求高的场景。
2025-03-01 16:06:51
1179
原创 RocketMQ消费者重平衡机制
触发条件消费者启动或关闭。定时触发（默认20秒一次）。Topic的队列数量变化。消费者组内成员变化（通过心跳检测）。目标：在集群模式下，每个队列仅被一个消费者消费，确保负载均衡。流程获取Topic的队列列表和当前消费者组成员。根据分配策略重新分配队列。释放不再属于当前消费者的队列，并申请新分配的队列。RocketMQ通过定期触发重平衡，利用分配策略调整队列分配，确保负载均衡。源码核心在于的队列计算与管理，结合心跳机制维护消费者组状态。
2025-02-28 12:48:44
1268
原创 模板方法模式
模板方法模式（Template Method Pattern）是一种行为型设计模式，它定义了一个算法的骨架，允许子类在不改变算法结构的情况下重写某些步骤的具体实现。
2025-02-24 18:08:00
449
原创 高并发系统设计
设计高并发系统是一个复杂的系统工程，需要从架构设计、技术选型、资源优化、容错机制等多方面综合考虑。，需结合业务特点选择合适的技术组合。，通过迭代优化应对不断增长的流量挑战。高并发系统的核心目标是。
2025-02-23 17:17:39
796
原创 线程池的状态流转
线程池的状态流转由关闭方法的调用（shutdown()）和任务执行完成情况共同驱动，确保资源有序释放。理解状态流转有助于合理管理线程池生命周期，避免任务丢失或资源泄露。
2025-02-22 11:52:45
473
原创 线程池提交任务的具体流程
这一流程平衡了资源利用与任务处理效率，确保在高负载下仍能合理分配系统资源。：内部通过锁或CAS操作确保线程安全，避免多线程提交导致状态不一致。
2025-02-22 09:55:13
541
原创 MySQL多列索引查询优化
单列索引场景：通常只用一个索引，其他条件回表过滤。索引合并场景：可能用多个索引，但需满足优化器策略。最佳实践：优先使用联合索引(a, b, c)，效率最高。建议根据实际查询模式设计联合索引，并通过EXPLAIN验证优化器的选择。
2025-02-20 16:11:27
520
原创 SpringBoot和Spring主要区别
Spring是基础框架，强调灵活性，适合复杂定制场景。是 Spring 的“脚手架”，通过自动化配置和约定简化开发，适合快速构建现代应用。关系：Spring Boot 基于 Spring 实现，核心功能（如 IoC、AOP）完全依赖 Spring Framework。
2025-02-10 15:49:17
669
原创 Dubbo高级特性
具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 weighted random 基于权重的随机负载均衡策略。目前 Dubbo 内置了如下负载均衡算法，可通过调整配置项启用。建议：超时时间建议定义在服务提供方，而不是调用方。注册中心挂了，服务是否可以正常访问？服务消费者指定集群容错的模式。服务消费者指定负载均衡算法。服务提供者可以设置权重。
2025-02-09 15:56:58
1092
原创 Dubbo快速入门
如果调用的接口很多，为方便管理以及提高开发效率，可以创建一个公共模块，用于定义、管理远程调用的接口，如dubbo-interfance。服务提供者和消费者只需要引入该模块即可。
2025-02-09 14:16:30
206
原创 服务发现（Dubbo-zookeeper）
Dubbo 提供的是一种 Client-Based 的服务发现机制，依赖第三方注册中心组件来协调服务发现过程，支持常用的注册中心如 Nacos、Consul、zookeeper。
2025-02-09 11:49:17
487
原创 调用第三方接口-OkHttpClient
服务端接口http://12.131.23.1/user/list。使用OkHttpClient发送GET请求，如查询列表。参数(UserReqDto userReqDto)使用OkHttpClient发送post请求。例如后端接口接收参数为 User user。
2024-07-19 17:40:52
519
原创 调用第三方接口-RestTemplate
服务端接口http://12.131.23.1/user/get/{userId}参数(PathVariable(“userId”) String userId)服务端接口http://12.131.23.1/user/list。使用RestTemplate发送post请求，暂未进行异常处理。使用RestTemplate发送GET请求，如查询列表。使用RestTemplate发送post请求。例如后端接口接收参数为 User user。例如后端接口接收参数为List users。
2024-07-19 17:18:57
657
原创 异步线程池（SpringBoot）
对于异步方法调用，从Spring3开始提供了@Async注解，我们只需要在方法上标注此注解，此方法即可实现异步调用。当然，我们还需要一个配置类，通过Enable模块驱动注解来开启异步功能。
2024-02-29 22:14:54
1377
1
原创 redis命令
同时设置一个或多个key-value对，当且仅当所有给定的key都不存在时成功。用value覆写key中所储存的字符串值，从起始位置开始（索引从0开始）ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期。将key中储存的数字值减1，只能对数字操作，如果为空，新增值为-1。exist key 判断某个key是否存在，1存在，0不存在。获取值的范围，类似java中的subString，前包，后包。设置键值的同时，设置过期时间，单位为秒。只有在key不存在时，设置key的值。
2024-02-17 17:05:13
444
原创 You can‘t specify target table ‘dps_result‘ for update in FROM clause
在MySQL中，可能会遇到You can't specify target table '表名' for update in FROM clause这样的错误。意思是说，不能在同一语句中，先select出同一个表中的某些值，再update这个表，即不能依据某字段值做判断再来更新某字段的值。，就可以避免这个错误。
2023-12-28 17:06:32
750
原创 Java线程
FutureTask 能够接收 Callable 类型的参数，用来处理有返回结果的情况。分析 Thread 的源码，理清它与 Runnable 的关系。原理之 Thread 与 Runnable 的关系。把【线程】和【任务】（要执行的代码）分开。
2023-12-25 16:41:25
107
原创 进程与线程
单核 cpu 下，多线程不能实际提高程序运行效率，只是为了能够在不同的任务之间切换，不同线程轮流使用cpu ，不至于一个线程总占用 cpu，别的线程没法干活多核 cpu 可以并行跑多个线程，但能否提高程序运行效率还是要分情况的有些任务，经过精心设计，将任务拆分，并行执行，当然可以提高程序的运行效率。但不是所有计算任务都能拆分（参考后文的【阿姆达尔定律】）也不是所有任务都需要拆分，任务的目的如果不同，谈拆分和效率没啥意义。
2023-12-25 15:33:01
180
为什么两个线程读取es的数据不一样
2024-09-28
dependency-check
2023-04-21
maven编译报错compilerException
2023-04-13
sonarQube代码扫描
2023-04-11
达梦8进行数据备份为sql文件
2023-01-30
TA创建的收藏夹 TA关注的收藏夹
TA关注的人