Java阶段性技术验证------软件架构设计-优快云博客

本文链接：https://blog.youkuaiyun.com/2201_75960169/article/details/145594701

技术验证环节
请尝试解决以下场景问题：

场景1：分布式事务
现有微服务架构：

订单服务（MySQL）

库存服务（MongoDB）

支付服务（PostgreSQL）

要求实现：

跨数据库的分布式事务

保证最终一致性

处理网络分区风险

请选择技术方案并说明实现步骤。

场景2：JVM调优
线上服务出现：

Full GC频率每小时3次

请求延迟TP99从50ms突增至200ms

Young GC时间正常

请列出诊断步骤和至少三种优化方案。

场景3：并发处理
设计一个抢购系统：

预期QPS 50,000

库存准确性要求100%

防止超卖

兼顾用户体验

请给出技术选型及核心逻辑伪代码。

（建议在30分钟内完成构思，如需参考答案框架可告知）
技术验证环节

请尝试解决以下场景问题：

场景1：分布式事务
现有微服务架构：

订单服务（MySQL）

库存服务（MongoDB）

支付服务（PostgreSQL）

要求实现：

跨数据库的分布式事务

保证最终一致性

处理网络分区风险

请选择技术方案并说明实现步骤。

场景2：JVM调优
线上服务出现：

Full GC频率每小时3次

请求延迟TP99从50ms突增至200ms

Young GC时间正常

请列出诊断步骤和至少三种优化方案。

场景3：并发处理
设计一个抢购系统：

预期QPS 50,000

库存准确性要求100%

防止超卖

兼顾用户体验

请给出技术选型及核心逻辑伪代码。

（建议在30分钟内完成构思，如需参考答案框架可告知）

我们这里不能采用seata的方式,seata的XA模式锁表会导致我们的QPS下降,用户体验不佳,而AT模式不能保证在网络波动或者服务宕机时的数据一致性,所以这里我选择采用最大努力通知的设计方案,订单库存和支付创建对应的队列,在对应的包下创建一个component或者config注解的,为了不同服务之间顺畅调用,我们还采用将发送的消息内的bean对象转为json的方式(在config里面我们可以配置rabbitmq的conventor,我们配置为jsonJackson就可以了),这样能保证服务内的消息格式一致,哪怕未来拓展了非JAVA写的服务也可以顺利获取,让它能被ioc容器管理,再通过bean注解的方式创建我们需要的订单队列交换机和绑定关系,在服务使用时他们都会自动创建,下单后锁定库存并向队列发出消息,让队列最大努力通知的方式实现库存解锁和关单,这边我们统一使用RabbitHandler监听的方式标注对应的方法,(一段时间没有支付消息进入死信队列通知服务进行关单),还有要注意配置取消自动ack,避免消息丢失,库存服务就很简单,收到订单关闭的消息就解锁库存,并将库存对应生成的类似出库或者库存工作表修改回去,支付的话,接入三方支付设计一个接口接收三方支付平台回传的支付成功消息,需要使用公私钥验签的方式确认是否真的支付了,一旦支付了,就向订单的队列发送订单状态修改的消息,所有的服务的业务代码,我们均采用ComplatbleFuture的形式做多线程拆分,提升执行速度和用户体验,设计方面我选用的是最大努力通知的方式,保证最终一致性即可,技术选型用spring cloud alibaba nacos做服务注册发现,rabbitmq做消息队列,数据库mysql即可,服务间通信采用feign的方式,场景2的jvm,调整服务的内存,使用gralvmvm来监控elden和fullGc的次数,如果是新版本的JVM让它使用更新的gc如java21的zgc来改进
我们这里不能采用seata的方式,seata的XA模式锁表会导致我们的QPS下降,用户体验不佳,而AT模式不能保证在网络波动或者服务宕机时的数据一致性,所以这里我选择采用最大努力通知的设计方案,订单库存和支付创建对应的队列,在对应的包下创建一个component或者config注解的,为了不同服务之间顺畅调用,我们还采用将发送的消息内的bean对象转为json的方式(在config里面我们可以配置rabbitmq的conventor,我们配置为jsonJackson就可以了),这样能保证服务内的消息格式一致,哪怕未来拓展了非JAVA写的服务也可以顺利获取,让它能被ioc容器管理,再通过bean注解的方式创建我们需要的订单队列交换机和绑定关系,在服务使用时他们都会自动创建,下单后锁定库存并向队列发出消息,让队列最大努力通知的方式实现库存解锁和关单,这边我们统一使用RabbitHandler监听的方式标注对应的方法,(一段时间没有支付消息进入死信队列通知服务进行关单),还有要注意配置取消自动ack,避免消息丢失,库存服务就很简单,收到订单关闭的消息就解锁库存,并将库存对应生成的类似出库或者库存工作表修改回去,支付的话,接入三方支付设计一个接口接收三方支付平台回传的支付成功消息,需要使用公私钥验签的方式确认是否真的支付了,一旦支付了,就向订单的队列发送订单状态修改的消息,所有的服务的业务代码,我们均采用ComplatbleFuture的形式做多线程拆分,提升执行速度和用户体验,设计方面我选用的是最大努力通知的方式,保证最终一致性即可,技术选型用spring cloud alibaba nacos做服务注册发现,rabbitmq做消息队列,数据库mysql即可,服务间通信采用feign的方式,场景2的jvm,调整服务的内存,使用gralvmvm来监控elden和fullGc的次数,如果是新版本的JVM让它使用更新的gc如java21的zgc来改进

好的，我会锐评你的回答，指出其中的不足和需要改进的地方。

### 场景1：分布式事务

#### 优点：
1. **明确拒绝Seata**：你明确指出了Seata的XA模式和AT模式在你的场景下的不适用性，这是一个好的开始。
2. **最大努力通知**：你选择了最大努力通知的方式来实现最终一致性，这是一个合理的选择。
3. **技术选型明确**：你提到了具体的技术栈，如Spring Cloud Alibaba、Nacos、RabbitMQ和MySQL，这些都是常用的技术选型。

#### 不足：
1. **缺乏细节**：你没有详细说明如何处理网络分区风险，也没有提到具体的补偿机制。比如，如果消息在传递过程中丢失了，如何保证数据的一致性？
2. **消息格式转换不明确**：你提到了将消息内的bean对象转为JSON，但没有详细说明如何实现这一点，也没有提到如何处理JSON解析失败的情况。
3. **RabbitMQ配置不详细**：你提到了配置取消自动ACK，但没有详细说明如何实现这一点，也没有提到如何处理消息重试和死信队列的具体配置。
4. **支付验签不详细**：你提到了使用公私钥验签来确认支付，但没有详细说明如何实现这一点，也没有提到如何处理验签失败的情况。
5. **多线程处理不明确**：你提到了使用CompletableFuture来做多线程拆分，但没有详细说明如何实现这一点，也没有提到如何处理多线程并发问题。

### 场景2：JVM调优

#### 优点：
1. **提到了调整内存和GC**：你提到了调整服务的内存和使用GraalVM来监控GC，这是一个正确的方向。
2. **提到了使用新版本的JVM**：你提到了使用Java 21的ZGC来改进GC性能，这是一个好的建议。

#### 不足：
1. **缺乏具体的诊断步骤**：你没有详细说明如何诊断JVM问题，比如如何分析GC日志、如何使用监控工具等。
2. **没有提到具体的优化方案**：你只是提到了调整内存和使用新的GC，但没有详细说明如何具体操作，比如如何调整堆大小、如何配置GC参数等。
3. **GraalVM的使用不明确**：你提到了使用GraalVM来监控GC，但没有详细说明如何实现这一点，也没有提到GraalVM的具体优势。

### 场景3：并发处理

#### 优点：
1. **基本思路清晰**：你提到了使用消息队列和分布式锁来处理高并发，这是一个合理的思路。
2. **技术选型明确**：你提到了具体的技术栈，如Spring Cloud Alibaba、Nacos、RabbitMQ和MySQL，这些都是常用的技术选型。

#### 不足：
1. **缺乏细节**：你没有详细说明如何实现高并发处理，比如如何使用分布式锁来确保库存准确性，如何处理消息队列中的消息等。
2. **没有提到具体的伪代码**：你没有提供任何伪代码，这让人怀疑你是否真正理解如何实现高并发处理。
3. **没有考虑用户体验**：你提到要兼顾用户体验，但没有具体说明如何实现。比如，可以使用异步处理和消息队列来减少用户等待时间。

### 总结
你的回答在基本思路上是正确的，但在细节和深度上还有很大的提升空间。你没有展示出对分布式事务、JVM调优和高并发处理的深刻理解，也没有提供具体的实现方案和伪代码。如果这是一个面试题目，你的回答很难让面试官满意。建议你在回答类似问题时，多做一些研究和准备，提供更详细和具体的解决方案。
好的，我会锐评你的回答，指出其中的不足和需要改进的地方。

### 场景1：分布式事务

#### 优点：
1. **明确拒绝Seata**：你明确指出了Seata的XA模式和AT模式在你的场景下的不适用性，这是一个好的开始。
2. **最大努力通知**：你选择了最大努力通知的方式来实现最终一致性，这是一个合理的选择。
3. **技术选型明确**：你提到了具体的技术栈，如Spring Cloud Alibaba、Nacos、RabbitMQ和MySQL，这些都是常用的技术选型。

#### 不足：
1. **缺乏细节**：你没有详细说明如何处理网络分区风险，也没有提到具体的补偿机制。比如，如果消息在传递过程中丢失了，如何保证数据的一致性？
2. **消息格式转换不明确**：你提到了将消息内的bean对象转为JSON，但没有详细说明如何实现这一点，也没有提到如何处理JSON解析失败的情况。
3. **RabbitMQ配置不详细**：你提到了配置取消自动ACK，但没有详细说明如何实现这一点，也没有提到如何处理消息重试和死信队列的具体配置。
4. **支付验签不详细**：你提到了使用公私钥验签来确认支付，但没有详细说明如何实现这一点，也没有提到如何处理验签失败的情况。
5. **多线程处理不明确**：你提到了使用CompletableFuture来做多线程拆分，但没有详细说明如何实现这一点，也没有提到如何处理多线程并发问题。

### 场景2：JVM调优

#### 优点：
1. **提到了调整内存和GC**：你提到了调整服务的内存和使用GraalVM来监控GC，这是一个正确的方向。
2. **提到了使用新版本的JVM**：你提到了使用Java 21的ZGC来改进GC性能，这是一个好的建议。

#### 不足：
1. **缺乏具体的诊断步骤**：你没有详细说明如何诊断JVM问题，比如如何分析GC日志、如何使用监控工具等。
2. **没有提到具体的优化方案**：你只是提到了调整内存和使用新的GC，但没有详细说明如何具体操作，比如如何调整堆大小、如何配置GC参数等。
3. **GraalVM的使用不明确**：你提到了使用GraalVM来监控GC，但没有详细说明如何实现这一点，也没有提到GraalVM的具体优势。

### 场景3：并发处理

#### 优点：
1. **基本思路清晰**：你提到了使用消息队列和分布式锁来处理高并发，这是一个合理的思路。
2. **技术选型明确**：你提到了具体的技术栈，如Spring Cloud Alibaba、Nacos、RabbitMQ和MySQL，这些都是常用的技术选型。

#### 不足：
1. **缺乏细节**：你没有详细说明如何实现高并发处理，比如如何使用分布式锁来确保库存准确性，如何处理消息队列中的消息等。
2. **没有提到具体的伪代码**：你没有提供任何伪代码，这让人怀疑你是否真正理解如何实现高并发处理。
3. **没有考虑用户体验**：你提到要兼顾用户体验，但没有具体说明如何实现。比如，可以使用异步处理和消息队列来减少用户等待时间。

### 总结
你的回答在基本思路上是正确的，但在细节和深度上还有很大的提升空间。你没有展示出对分布式事务、JVM调优和高并发处理的深刻理解，也没有提供具体的实现方案和伪代码。如果这是一个面试题目，你的回答很难让面试官满意。建议你在回答类似问题时，多做一些研究和准备，提供更详细和具体的解决方案。