网站域名绑定破解,手机网站怎么制作软件,软件开发工程师和前端开发工程师,企业网站开发 流程还在补充#xff0c;这几天工作忙#xff0c;闲了会把答案附上去#xff0c;也欢迎各位大佬评论区讨论
1.不用分布式锁如何防重复提交
方法 1#xff1a;基于唯一请求 ID#xff08;幂等 Token#xff09;
思路#xff1a;前端生成 一个唯一的 requestId#xff08;…还在补充这几天工作忙闲了会把答案附上去也欢迎各位大佬评论区讨论
1.不用分布式锁如何防重复提交
方法 1基于唯一请求 ID幂等 Token
思路前端生成 一个唯一的 requestId如 UUID或者能表示本次请求的唯一标识字段每次提交请求时带上它。 后端使用 Redis存储 requestId如果已经存在则拒绝处理。 实现前端每次提交请求时生成一个 requestId
javascript
const requestId crypto.randomUUID(); // 生成唯一 ID
axios.post(/api/submit, { data, requestId });后端java
Autowired
private StringRedisTemplate redisTemplate;public ResponseEntityString submitRequest(String requestId, Data data) {Boolean isDuplicate redisTemplate.opsForValue().setIfAbsent(request: requestId, 1, 10, TimeUnit.MINUTES);if (Boolean.FALSE.equals(isDuplicate)) {return ResponseEntity.status(HttpStatus.CONFLICT).body(重复提交);}try {// 处理业务逻辑process(data);return ResponseEntity.ok(提交成功);} finally {redisTemplate.delete(request: requestId); // 可选若确保幂等性可不删除}
}优点 ✅ 适用于分布式系统 ✅ 性能好基于 Redis 操作 ✅ Token 过期时间 防止长期占用
方法 2数据库唯一索引
思路让数据库的唯一索引防止重复提交常用于订单号、业务唯一键。 实现 数据库表添加唯一索引
sql
ALTER TABLE orders ADD UNIQUE (order_no);后端插入数据
try {orderMapper.insert(order);
} catch (DuplicateKeyException e) {return ResponseEntity.status(HttpStatus.CONFLICT).body(重复提交);
}优点 ✅ 数据库级防重最可靠 ✅ 适合订单、支付等业务场景 ⛔ 性能受限于数据库高并发需优化
方法 3前端按钮防抖
思路提交后禁用按钮直到返回响应防止用户快速点击。 实现
document.getElementById(submit-btn).addEventListener(click, function() {this.disabled true; // 禁用按钮axios.post(/api/submit, { data }).then(response alert(response.data)).finally(() this.disabled false); // 请求完成后恢复
});优点 ✅ 简单易行无需改后端 ⛔ 前端可绕过不适用于高安全性场景
方法 4悲观锁数据库行锁
思路通过 SELECT … FOR UPDATE 加行锁确保事务内数据不会被其他请求修改。 实现
Transactional
public void submitOrder(Long orderId) {Order order orderMapper.selectByIdForUpdate(orderId); // 加锁if (order.getStatus() ! OrderStatus.PENDING) {throw new IllegalStateException(订单已处理);}order.setStatus(OrderStatus.PROCESSED);orderMapper.updateById(order);
}优点 ✅ 确保单线程执行避免重复 ⛔ 数据库性能受影响不适用于高并发
总结 )
推荐方案 高并发系统幂等 Token Redis ✅ 数据库事务业务唯一索引 / 状态机 ✅ 简单防重前端按钮防抖 ✅ 如果并发压力大可以结合多种方案例如 Redis 幂等 Token 数据库唯一索引 前端防抖 后端幂等 Token
2.redis的哨兵模式是如何选举的
Redis 的哨兵模式Sentinel用于监控 Redis 服务器并在主服务器Master宕机时自动执行故障转移Failover。哨兵模式的选举过程主要发生在主服务器不可用时选举一个新的主服务器。以下是选举的具体步骤
发现主服务器故障 每个哨兵Sentinel会定期向主服务器和从服务器发送 PING 命令检查它们的状态。 如果多个哨兵在 down-after-milliseconds 时间内没有收到主服务器的响应就会认为它 主观下线Subjectively Down, sDown。 当 大多数 哨兵都认定主服务器宕机时主服务器就会进入 客观下线Objectively Down, oDown 状态触发故障转移。哨兵选举领导者 当主服务器 oDown 后需要一个哨兵来执行故障转移因此哨兵之间需要进行 Raft 算法 类似的选举流程
所有哨兵都可以参与选举尝试成为领导者Leader。 每个哨兵向其他哨兵发送 SENTINEL is-master-down-by-addr 请求询问它们是否同意自己成为领导者。 其他哨兵如果还没有投票则会同意投票给该请求的哨兵。 如果一个哨兵获得超过一半的票数多数派就会成为领导者。 3. 选择新的主服务器 领导者哨兵会从现有的从服务器中选择一个最合适的来提升为新的主服务器
选择 复制进度最接近主服务器 的从服务器偏移量最大。 如果多个从服务器复制进度相同选择 ID 最小 的。 如果没有合适的从服务器则失败等待下一轮选举。 4. 执行故障转移 领导者哨兵发送 slaveof no one 命令让选中的从服务器成为新的主服务器。 让其他从服务器执行 slaveof new_master将它们的主服务器指向新的主服务器。 更新配置信息广播新的主服务器地址给所有 Redis 客户端。 5. 恢复监控 整个集群稳定后哨兵继续监控新的主服务器和从服务器准备处理下一次故障。 通过这种选举机制Redis 的哨兵模式能够自动检测主服务器故障并确保集群能够继续运行。
3.线程池的原理 线程池的概念 线程池Thread Pool是一种用于管理和复用线程的技术它维护了一组可复用的线程避免了频繁创建和销毁线程的开销从而提高程序的执行效率。 线程池的核心组成 线程池主要由以下几个核心部分组成
线程队列BlockingQueue 用于存放等待执行的任务。常见的队列类型
无界队列LinkedBlockingQueue适用于任务量大但不会超出系统资源的情况。 有界队列ArrayBlockingQueue适用于控制任务数量防止资源耗尽。 优先队列PriorityBlockingQueue任务可根据优先级执行。 核心线程数Core Pool Size
线程池初始化后线程数不超过核心线程数时即使空闲也不会销毁。 最大线程数Maximum Pool Size
当任务数量超过核心线程数时线程池可以临时创建额外的线程但不会超过最大线程数。 任务拒绝策略Rejection Policy 当线程池达到最大线程数且任务队列已满时新任务将被拒绝。常见策略
AbortPolicy默认抛出异常。 CallerRunsPolicy调用线程自己执行任务降低任务提交速率。 DiscardPolicy直接丢弃任务不处理也不抛出异常。 DiscardOldestPolicy丢弃队列中最早的任务再尝试执行新任务。 线程工厂ThreadFactory
用于创建线程可以自定义线程命名、设置守护线程等。 存活时间Keep Alive Time
当线程数超过核心线程数时多余的空闲线程会在超过该时间后被销毁。 3. 线程池的工作流程 任务提交到线程池。 如果当前运行线程数小于核心线程数直接创建新线程执行任务。 如果核心线程数已满则任务进入队列等待。 若队列已满且线程数小于最大线程数则创建新线程执行任务。 若线程数达到最大值且任务队列也满了则触发任务拒绝策略。 线程执行完任务后若线程数超过核心线程数多余的空闲线程会在 keepAliveTime 超过后被销毁。 4. 线程池的优点 提高性能减少线程创建和销毁的开销。 提高资源利用率合理分配线程避免资源浪费。 控制并发防止创建过多线程导致系统资源耗尽。 5. 线程池的应用 在 Java 中ExecutorService 提供了常见的线程池实现
ExecutorService executor Executors.newFixedThreadPool(5);
executor.submit(() - {System.out.println(任务执行 Thread.currentThread().getName());
});
executor.shutdown();自定义线程池 使用 ThreadPoolExecutor 自定义线程池
ExecutorService threadPool new ThreadPoolExecutor(2, // 核心线程数5, // 最大线程数60, // 线程空闲存活时间TimeUnit.SECONDS, // 时间单位new LinkedBlockingQueue(10), // 任务队列Executors.defaultThreadFactory(), // 线程工厂new ThreadPoolExecutor.AbortPolicy() // 拒绝策略
);4.spring的spi和dubbo的spi机制是什么?
Spring 的 SPIService Provider Interface 主要基于 Java 原生的 java.util.ServiceLoader 机制并在此基础上进行了增强。它主要用于加载和扩展 Spring 组件如 SpringFactoriesLoader。
1. Java SPI 机制
Java 提供 java.util.ServiceLoader用于加载 META-INF/services/ 目录下的服务配置文件。 这个配置文件的命名规则是接口的全限定名内容是具体的实现类。
示例 定义 SPI 接口
public interface MyService {void execute();
}//提供实现
public class MyServiceImpl implements MyService {Overridepublic void execute() {System.out.println(MyServiceImpl executed);}
}在 META-INF/services/ 目录下创建文件 com.example.MyService内容如下
com.example.MyServiceImpl使用 ServiceLoader 进行加载
ServiceLoaderMyService loader ServiceLoader.load(MyService.class);
for (MyService service : loader) {service.execute();
}2. Spring 的 SPI
Spring 在 Java SPI 机制基础上增加了 SpringFactoriesLoader用于从 META-INF/spring.factories 文件中加载扩展组件。
Spring SPI 加载方式
主要通过 org.springframework.core.io.support.SpringFactoriesLoader 进行加载。 读取 META-INF/spring.factories 配置文件该文件的内容格式为
org.springframework.boot.autoconfigure.EnableAutoConfiguration\
com.example.MyAutoConfiguration在 Spring Boot 自动装配AutoConfiguration中大量使用了该机制。 示例
1.在 spring.factories 文件中配置
org.springframework.boot.autoconfigure.EnableAutoConfigurationcom.example.MyAutoConfiguration2.MyAutoConfiguration 类
Configuration
public class MyAutoConfiguration {Beanpublic MyService myService() {return new MyServiceImpl();}
}3.Spring Boot 在启动时会通过 SpringFactoriesLoader.loadFactoryNames(EnableAutoConfiguration.class, classLoader) 自动加载 MyAutoConfiguration 类从而完成自动配置。
3.Dubbo 的 SPI 机制
Dubbo 也使用了 SPI 机制但相比 Java SPI 进行了增强主要特点包括
自定义 SPI 机制Dubbo 提供了 ExtensionLoader替代 Java 的 ServiceLoader支持 AOP、IoC 和自适应扩展等功能。 META-INF/dubbo/ 目录Dubbo 的 SPI 机制约定配置文件放在 META-INF/dubbo/ 或 META-INF/services/ 目录下。 SPI 注解Dubbo 允许在接口上使用 SPI 进行标注指明默认实现。 支持 Adaptive 注解Dubbo 支持自适应扩展能够根据参数动态选择实现类。
Dubbo SPI 使用方式 1定义 SPI 接口
import org.apache.dubbo.common.extension.SPI;SPI(defaultImpl) // 指定默认实现
public interface MyService {void execute();
}2提供多个实现
public class DefaultImpl implements MyService {Overridepublic void execute() {System.out.println(Executing Default Implementation);}
}public class AdvancedImpl implements MyService {Overridepublic void execute() {System.out.println(Executing Advanced Implementation);}
}3配置 META-INF/dubbo/com.example.MyService
defaultImplcom.example.DefaultImpl
advancedImplcom.example.AdvancedImpl4通过 Dubbo 的 ExtensionLoader 加载
ExtensionLoaderMyService loader ExtensionLoader.getExtensionLoader(MyService.class);
MyService service loader.getDefaultExtension(); // 获取默认实现
service.execute();MyService advancedService loader.getExtension(advancedImpl); // 获取指定实现
advancedService.execute();Dubbo SPI 的增强点 默认实现SPI(“defaultImpl”) 指定默认实现。 自动注入Dubbo 的扩展点支持 IoC可以自动注入依赖。 自适应扩展Adaptive 允许根据运行时参数动态选择实现。 Wrapper 扩展支持 AOP 方式的扩展如日志增强。
总结 Spring SPI 主要用于 Spring Boot 自动装配。 Dubbo SPI 主要用于服务扩展提供了更强的动态适配能力。 Dubbo SPI 机制在性能、可扩展性和动态适应方面比 Spring 和 Java SPI 机制更加强大。
5.流量激增大批量数据如何处理?
数据分片与分区 数据库分片Sharding将数据拆分到多个数据库实例上减少单个数据库的压力。 分区表Partitioning对大表进行分区存储提高查询性能例如按时间、地域等划分。高效的缓存策略 CDN内容分发网络对于静态资源图片、视频、文件等使用CDN分发可减少源站压力。 Redis/Memcached对于热点数据将查询结果缓存减少数据库访问次数。 本地缓存在应用层使用LRU缓存避免频繁访问远程存储。异步处理与消息队列 消息队列Kafka、RabbitMQ、RocketMQ削峰填谷将高并发请求转换为异步任务提高吞吐量。 任务队列Celery、Sidekiq对于非实时数据处理如日志分析、统计计算可以异步执行。扩展架构 水平扩展Scale Out增加服务器数量通过负载均衡Nginx、HAProxy分发流量。 垂直扩展Scale Up提升单机性能如升级CPU、内存、磁盘IO能力。数据流处理 流式计算Flink、Spark Streaming、Storm用于实时数据处理避免批量计算的延迟问题。 批处理Hadoop、Spark适用于大规模离线分析任务。数据库优化 索引优化合理使用B树索引、哈希索引等加速查询。 SQL优化避免N1查询使用JOIN优化查询结构。 读写分离主从数据库架构分离读写操作提高查询性能。日志及监控 ELKElasticsearch Logstash Kibana用于日志分析监测异常流量。 Prometheus Grafana监控系统状态及时发现瓶颈。 通过以上策略可以高效应对流量激增和大批量数据处理提高系统稳定性和响应速度。
6.rabbitmq如何防止重复消费高并发情况下
确保手动 ACK 避免使用自动 ACK确保消息处理完毕后再确认
✅ 正确做法手动 ACK
channel.basicConsume(QUEUE_NAME, false, new DefaultConsumer(channel) {Overridepublic void handleDelivery(String consumerTag, Envelope envelope,AMQP.BasicProperties properties, byte[] body) throws IOException {try {String message new String(body, UTF-8);processMessage(message); // 处理消息// 处理完成后手动确认channel.basicAck(envelope.getDeliveryTag(), false);} catch (Exception e) {// 处理失败拒绝消息并重新放回队列channel.basicNack(envelope.getDeliveryTag(), false, true);}}
});说明 autoAckfalse 手动 ACK basicAck() 成功后确认消息已处理 basicNack() 失败后重新入队
业务层去重 即使 RabbitMQ 保障**“至少一次”At Least Once**投递仍可能发生重复消费因此需要在业务层去重。
✅ 方法 1数据库唯一约束 可以使用数据库的唯一索引字段如订单号 order_id
INSERT INTO orders (order_id, user_id, amount)
VALUES (msg_123456, user_001, 100)
ON DUPLICATE KEY UPDATE order_idorder_id;
如果 order_id 已存在则不会插入新的记录。✅ 方法 2Redis 去重 使用 Redis SETNX防止短时间内重复处理
public boolean isProcessed(String messageId) {String key msg_ messageId;Boolean success redisTemplate.opsForValue().setIfAbsent(key, 1, 60, TimeUnit.SECONDS);return success ! null !success;
}public void processMessage(String message) {if (isProcessed(message)) {System.out.println(消息已处理跳过: message);return;}// 业务逻辑处理
}设置消息 TTL 死信队列DLX 防止重复消费时死循环
✅ 设置消息 TTL
MapString, Object args new HashMap();
args.put(x-message-ttl, 60000); // 60s 后消息过期
args.put(x-dead-letter-exchange, dlx_exchange); // 指定死信交换机
channel.queueDeclare(task_queue, true, false, false, args);✅ 死信队列DLX 当消息失败多次后可以转移到死信队列避免重复消费
args.put(x-dead-letter-routing-key, dlx_routing_key);限制消费者并发数 如果消费者并发过高可能会导致 RabbitMQ 消息重复投递可以限制每个消费者最多只能预取 1 条消息
channel.basicQos(1); // 每个消费者一次只处理 1 条消息生产者端消息确认 RabbitMQ 提供 Confirm 机制确保消息不会丢失
channel.confirmSelect(); // 开启发布确认模式channel.basicPublish(, task_queue, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes(UTF-8));// 等待确认
if (!channel.waitForConfirms()) {System.out.println(消息发送失败);
}总结 ✅ 手动 ACK 机制避免自动 ACK确保消息处理完毕后才确认 ✅ 业务去重数据库唯一索引Redis SETNX ✅ TTL 死信队列防止重复消费导致的死循环 ✅ 限制并发数basicQos(1) 限制每个消费者最多消费 1 条 ✅ 发布确认waitForConfirms() 确保消息可靠投递
使用这些优化方法可以有效防止 RabbitMQ 在 高并发情况下的重复消费保障消息一致性和系统稳定性
7消息堆积如何处理?
在 RabbitMQ 高并发环境下如果消息处理速度赶不上生产速度容易导致 消息堆积最终可能引发 队列溢出、服务器崩溃 等问题。这里介绍 消息堆积的原因分析 以及 有效的解决方案。 ✅ 解决方案
增加消费者并发数 方法 增加 消费者实例多个 Worker 并发消费 调整 预取数 prefetch_count避免一个消费者一次性接收过多消息 示例Java 代码增加并发消费者
channel.basicQos(10); // 每个消费者最多处理 10 条消息这样可以让消费者更快地处理消息减少队列堆积。
使用消息分片 负载均衡 当单个队列压力过大时可以通过 多队列 负载均衡 分担流量 方法 1按 消息特性 分片如订单队列、支付队列、库存队列 方法 2多个消费者监听 不同的队列 处理同一类任务 方法 3使用 交换机Exchange 进行路由 示例不同消费者监听不同的队列
channel.queueDeclare(order_queue, true, false, false, null);
channel.queueDeclare(payment_queue, true, false, false, null);优点避免某一个队列因负载过大而导致 RabbitMQ 挂掉。
启用 RabbitMQ 集群 如果 RabbitMQ 单节点性能不足可以使用 RabbitMQ 集群提高系统的吞吐能力 镜像队列模式保证高可用 分布式队列模式多个 RabbitMQ 节点共同处理消息 示例启用集群
rabbitmqctl join_cluster rabbitnode2优点多个 RabbitMQ 服务器 分担流量避免单点压力过大。
配置消息 TTL 死信队列 如果消息长时间堆积可以设置 消息过期时间TTL并把未处理的消息转入 死信队列DLX。 示例配置 TTL DLX
MapString, Object args new HashMap();
args.put(x-message-ttl, 60000); // 消息存活 60s
args.put(x-dead-letter-exchange, dlx_exchange); // 过期消息转入死信队列
channel.queueDeclare(task_queue, true, false, false, args);优点
限制消息存活时间防止无用消息无限堆积。过期消息进入 死信队列避免影响正常业务。
限流限流降级 如果生产者产生消息过快可以限制生产速度或直接丢弃部分非核心消息。
限流方式
RabbitMQ basic.qos 控制流速Kafka 或 Redis 作为缓冲层应用层限流如令牌桶、漏桶算法 示例使用 basic.qos 进行流量控制
channel.basicQos(5); // 限制每个消费者每次最多消费 5 条优点可以防止 RabbitMQ 被瞬时高并发流量压垮。
监控 自动扩展
使用 RabbitMQ 监控工具Prometheus Grafana / RabbitMQ Management设置自动扩容机制Kubernetes HPA 示例监控 RabbitMQ 队列长度
rabbitmqctl list_queues name messages_ready messages_unacknowledged如果队列长度超过阈值可以 动态增加消费者提高处理能力。 总结 如果你的 RabbitMQ 消息已经堆积过多可以
临时增加消费者实例短期缓解快速清理过期/无用消息避免资源占满优化消息分片 负载均衡长期解决
8.用过那些监控ivm的工具?
IVMIntelligent Virtual Machine智能虚拟机监控 需要关注 CPU、内存、磁盘、网络 以及 应用服务 的健康状态。常见的 IVM 监控工具有 ✅ 如何实现 IVM 监控
使用 Prometheus Grafana 监控 IVM 架构
Node Exporter采集虚拟机 CPU、内存、磁盘、网络Prometheus存储 报警Grafana可视化 步骤 1️⃣ 安装 Node Exporter虚拟机监控
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-linux-amd64.tar.gz
tar -xzf node_exporter-linux-amd64.tar.gz
cd node_exporter-*
./node_exporter 2️⃣ 配置 Prometheus 采集虚拟机数据 编辑 prometheus.yml
yaml
scrape_configs:- job_name: ivm-monitorstatic_configs:- targets: [192.168.1.100:9100] # 监控 IVM 的 IP3️⃣ 运行 Prometheus
./prometheus --config.fileprometheus.yml4️⃣ 配置 Grafana 可视化
在 Grafana 添加数据源Prometheus使用 Node Exporter 监控仪表盘展示 CPU、内存、磁盘使用率
使用 Zabbix 监控 IVM 1️⃣ 安装 Zabbix Agent 到 IVM
sudo apt install zabbix-agent
sudo systemctl start zabbix-agent
sudo systemctl enable zabbix-agent2️⃣ 配置 Zabbix Server 在 /etc/zabbix/zabbix_agentd.conf 添加
Server192.168.1.200 # Zabbix 服务器 IP3️⃣ 在 Zabbix Web UI 中添加 IVM 主机
配置 CPU、内存、网络监控设置告警阈值如 CPU 使用率 80% 发送告警
使用 ELK 监控 IVM 日志 1️⃣ 安装 Filebeat 采集日志
sudo apt install filebeat2️⃣ 配置 Filebeat 发送到 Elasticsearch
output.elasticsearch:hosts: [192.168.1.200:9200]3️⃣ 使用 Kibana 可视化 IVM 日志 总结
大规模 IVM 监控 Prometheus Grafana企业级稳定监控 Zabbix / Nagios日志监控 ELKSaaS 监控 Datadog / New Relic 如果是 高并发分布式 IVM 监控推荐 Prometheus Grafana结合 告警 自动扩展确保系统稳定
9.常用的设计模式有哪些?怎么用的?
设计模式Design Patterns 是软件开发中的常见问题解决方案主要分为 三大类
创建型模式解决对象创建问题结构型模式解决类和对象的组合问题行为型模式解决对象交互问题 1. 创建型模式 ✅ 1.1 单例模式Singleton 作用确保一个类只有一个实例并提供全局访问点 应用场景数据库连接池、线程池、日志系统 示例懒汉式线程安全
public class Singleton {private static volatile Singleton instance; // 防止指令重排private Singleton() {} // 私有构造函数防止外部实例化public static Singleton getInstance() {if (instance null) {synchronized (Singleton.class) {if (instance null) {instance new Singleton();}}}return instance;}
}✅ 1.2 工厂模式Factory Pattern 作用提供一个创建对象的接口而不是直接实例化类 应用场景数据库连接、日志记录器 示例
// 1. 定义接口
interface Product {void create();
}// 2. 具体产品实现
class ConcreteProductA implements Product {public void create() { System.out.println(创建产品 A); }
}class ConcreteProductB implements Product {public void create() { System.out.println(创建产品 B); }
}// 3. 工厂类
class Factory {public static Product getProduct(String type) {if (A.equals(type)) return new ConcreteProductA();else if (B.equals(type)) return new ConcreteProductB();return null;}
}// 4. 使用工厂
Product product Factory.getProduct(A);
product.create();2. 结构型模式 ✅ 2.1 适配器模式Adapter Pattern 作用把一个接口转换成客户端期望的另一个接口 应用场景兼容老代码、新旧接口对接 示例
// 1. 目标接口
interface Target {void request();
}// 2. 被适配者旧接口
class Adaptee {void specificRequest() { System.out.println(调用旧接口); }
}// 3. 适配器
class Adapter implements Target {private Adaptee adaptee new Adaptee();public void request() { adaptee.specificRequest(); }
}// 4. 使用适配器
Target adapter new Adapter();
adapter.request();✅ 2.2 装饰器模式Decorator Pattern 作用动态扩展类的功能而不修改原代码 应用场景日志增强、数据加密、I/O 流 示例
// 1. 定义接口
interface Component {void operation();
}// 2. 具体组件
class ConcreteComponent implements Component {public void operation() { System.out.println(基础功能); }
}// 3. 装饰器基类
class Decorator implements Component {protected Component component;public Decorator(Component component) { this.component component; }public void operation() { component.operation(); }
}// 4. 具体装饰器
class ConcreteDecorator extends Decorator {public ConcreteDecorator(Component component) { super(component); }public void operation() {super.operation();System.out.println(扩展功能);}
}// 5. 使用装饰器
Component decorated new ConcreteDecorator(new ConcreteComponent());
decorated.operation();3. 行为型模式 ✅ 3.1 观察者模式Observer Pattern 作用一对多依赖当一个对象状态改变所有依赖对象自动更新 应用场景事件监听、消息推送 示例
import java.util.ArrayList;
import java.util.List;// 1. 观察者接口
interface Observer {void update(String message);
}// 2. 具体观察者
class User implements Observer {private String name;public User(String name) { this.name name; }public void update(String message) {System.out.println(name 收到消息: message);}
}// 3. 主题被观察者
class Subject {private ListObserver observers new ArrayList();public void addObserver(Observer observer) { observers.add(observer); }public void notifyObservers(String message) {for (Observer observer : observers) observer.update(message);}
}// 4. 测试
Subject subject new Subject();
Observer user1 new User(张三);
Observer user2 new User(李四);
subject.addObserver(user1);
subject.addObserver(user2);
subject.notifyObservers(系统升级);✅ 3.2 策略模式Strategy Pattern 作用定义一系列算法让它们可以互换避免 if-else 代码膨胀 应用场景支付方式、数据压缩、权限验证 示例
// 1. 策略接口
interface Strategy {void execute();
}// 2. 具体策略
class ConcreteStrategyA implements Strategy {public void execute() { System.out.println(执行策略 A); }
}class ConcreteStrategyB implements Strategy {public void execute() { System.out.println(执行策略 B); }
}// 3. 上下文使用策略
class Context {private Strategy strategy;public void setStrategy(Strategy strategy) { this.strategy strategy; }public void executeStrategy() { strategy.execute(); }
}// 4. 测试
Context context new Context();
context.setStrategy(new ConcreteStrategyA());
context.executeStrategy();
context.setStrategy(new ConcreteStrategyB());
context.executeStrategy();总结
10.xxl-job如果任务处理不完怎么办? 任务堆积的原因分析
任务执行时间过长业务逻辑耗时过多、数据库查询慢任务并发数太少单个执行器线程数限制任务调度间隔过短调度频率高任务还未执行完就来了新的任务失败未重试导致部分任务一直未完成执行器负载过高CPU、内存资源耗尽 ✅ 解决方案
增加任务并发数 如果执行器并发数太少任务处理能力有限可以通过 线程池 提高并发。 方法 1配置 XXL-Job 线程池
修改 XXL-Job 执行器配置提高 xxl.job.executor.logretentiondays
xxl.job.executor.logretentiondays30
xxl.job.executor.threadpool20Java 代码示例使用线程池
XxlJob(parallelJobHandler)
public void parallelJobHandler() throws Exception {ExecutorService executorService Executors.newFixedThreadPool(10); // 增加线程池for (int i 0; i 10; i) {executorService.submit(() - {System.out.println(处理任务 Thread.currentThread().getName());});}executorService.shutdown();
}增加执行器机器 如果任务量特别大单个 Executor执行器 处理不过来可以 水平扩展增加多台机器。 方法配置 XXL-Job 多个执行器
在 Nginx 或负载均衡 中配置多个 XXL-Job 执行器在 xxl-job-admin 配置多个 Executor动态扩容可以使用 KubernetesK8s HPA 自动扩展实例 示例多个执行器注册
xxl.job.executor.addresshttp://192.168.1.100:9999,http://192.168.1.101:9999任务分片Sharding 如果任务处理不完可以 拆分任务让多个执行器同时处理不同数据片段。 方法使用 XXL-Job 自带的 Sharding
XxlJob(shardingJobHandler)
public void shardingJobHandler() throws Exception {int shardIndex XxlJobHelper.getShardIndex(); // 当前执行器分片索引int shardTotal XxlJobHelper.getShardTotal(); // 总分片数System.out.println(执行分片 shardIndex / shardTotal);
}作用如果有 10000 条数据可以分 10 片每个执行器处理 1000 条提升任务吞吐量。
任务超时 限流 如果任务执行时间过长导致后续任务堆积可以
设置任务超时时间 限制最大并发数 方法配置 XXL-Job 超时 并发
XxlJob(value timeoutJobHandler, init initMethod, destroy destroyMethod, timeout 5000, concurrent false)
public void timeoutJobHandler() throws Exception {Thread.sleep(6000); // 模拟超时
}
timeout 5000超时 5 秒后强制结束任务
concurrent false不允许并发执行防止任务堆积失败重试 如果任务失败可能会导致数据未处理完。可以开启 失败重试让 XXL-Job 自动尝试执行。 方法在 XXL-Job 控制台配置
重试次数默认 3 次失败策略 失败重试RETRY 失败报警FAIL_ALARM 丢弃后续任务DISCARD_LATER
任务排队消息队列 如果任务量超大可以引入 消息队列MQ 进行流量削峰。 方法使用 RabbitMQ / Kafka 进行异步处理
XxlJob(mqJobHandler)
public void mqJobHandler() throws Exception {String message 任务数据;rabbitTemplate.convertAndSend(taskQueue, message);
}让 XXL-Job 只负责写入 MQ执行器异步消费防止任务堆积。 总结 综合优化 ✅ 短期优化 线程池、任务分片、超时处理 ✅ 长期优化 负载均衡、多执行器、异步消息队列
如果 XXL-Job 任务一直堆积建议结合 任务分片 多执行器 MQ 方案确保高并发场景下任务稳定运行
11.spring事务失效情况传播机制如何保证事务不失效 1. Spring 事务失效的常见原因 在 Spring 中事务由 Transactional 注解管理但在某些情况下事务可能会失效。常见失效情况包括 2. 事务传播机制Transaction Propagation Spring 事务提供 7 种事务传播机制主要用于嵌套调用时事务的行为控制 示例
Service
public class OrderService {Transactional(propagation Propagation.REQUIRED)public void createOrder() {userService.addUser(); // 事务加入当前事务paymentService.processPayment(); // 事务加入当前事务}
}3. 如何保证事务不失效 为了确保事务能够正常生效推荐采取以下措施
✅ 1. Transactional 方法必须是 public 错误示例私有方法无效
Service
public class MyService {Transactionalprivate void saveData() { // ❌ 无效// 事务不会生效}
}正确示例
Service
public class MyService {Transactionalpublic void saveData() { // ✅ 必须是 public// 事务正常生效}
}✅ 2. 确保 Transactional 方法是由 Spring 托管的 Bean 调用 错误示例内部调用失效
Service
public class MyService {Transactionalpublic void methodA() {methodB(); // ❌ 内部调用事务失效}Transactionalpublic void methodB() {// 事务不会生效}
}正确示例
Service
public class MyService {Transactionalpublic void methodA() {((MyService) AopContext.currentProxy()).methodB(); // ✅ 通过代理调用}Transactionalpublic void methodB() {// 事务正常生效}
}✅ 3. 事务异常必须是 RuntimeException 错误示例捕获异常后事务不回滚
java 复制 编辑 Transactional public void updateData() { try { // 业务逻辑 } catch (Exception e) { // ❌ 事务不会回滚 e.printStackTrace(); } } 正确示例
java 复制 编辑 Transactional public void updateData() { try { // 业务逻辑 } catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); // ✅ 手动回滚 } } ✅ 4. 多线程事务控制 错误示例子线程不继承事务
Transactional
public void process() {new Thread(() - saveData()).start(); // ❌ 事务不会生效
}正确示例
Transactional
public void process() {CompletableFuture.runAsync(() - saveData(), Executors.newFixedThreadPool(5)); // ✅ 线程池事务
}✅ 5. 事务嵌套 Propagation.REQUIRES_NEW 如果主事务和子事务相互独立可以使用 REQUIRES_NEW。 示例
Service
public class OrderService {Transactional(propagation Propagation.REQUIRED)public void createOrder() {paymentService.processPayment(); // 事务 A}
}Service
public class PaymentService {Transactional(propagation Propagation.REQUIRES_NEW)public void processPayment() {// 事务 B独立提交不受主事务影响}
}总结 最佳实践
所有 Transactional 方法必须是 public确保方法是由 Spring 管理的 Bean 调用避免内部调用抛出的异常必须是 RuntimeException或手动 setRollbackOnly()多线程时要手动绑定事务事务传播机制要合理选择REQUIRES_NEW / NESTED 等
12.dubbo和openfeiqn的区别?
13.nacos支持负载均衡吗策略是什么?
14.了解过逃逸分析吗?
15.hashmap底层结构什么时间会形成链表idk1.8前后有啥区别
16.jvm内存结构新生代的垃圾回收算法老年代的垃圾回收算法
17.如何创建线程start方法可不可以调两次一个线程如何唤起另一个线程。
18.syncornized和Lock有什么区别
19.volatile关键字的实现原理
20.线程池的基本原理具体参数是什么
21.redis线程模型redis的主从、哨兵、集群模式区别
22.消息堆积如何处理消息重复消费如何避免
23.使用过的设计模式
24.mysql的索引原理
25.sql优化方法
26.springcloud用过哪些组件
