MsBlog

打包jar运行出现invalid END header (bad central directory offset)

该文介绍了在文件传输过程中遇到问题时的解决方法。当使用SSH上传文件出现问题时，可以通过CMD命令行中的FTP功能进行上传。特别指出，在使用XFTP等工具进行文件传输时，如果遇到问题，可能是由于迁移类型设置为ASCII导致的，此时将迁移类型改为二进制（Binary）即可解决问题。这种方法适用于多种文件传输场景，尤其是对于需要保持文件原始格式不变的情况。

2021-10-05

2361

@Autowired与@Resource的区别

本文介绍了Spring框架中@Autowired和@Resource注解的区别及其使用方法。@Autowired是Spring特有的，而@Resource来源于J2EE标准。@Autowired默认通过类型(byType)注入对象，若存在多个相同类型的bean，则尝试按名称(byName)注入或结合@Qualifier指定具体实现；若未找到匹配的bean且required属性为true，则抛出异常。相比之下，@Resource默认先尝试按名称(byName)注入，失败后转而尝试按类型(byType)注入。它还支持显式设置name和type属性来指定具体的注入方式。当遇到多个同类型bean时，可以通过调整变量名、使用@Qualifier注解（对于@Autowired）或明确指定name/type属性（对于@Resource）来解决注入歧义问题。

spring cloud中OpenFeign整合Sentinel启动报错

文章描述了一个在使用Sentinel框架与OpenFeign集成时遇到的错误，具体表现为`AbstractMethodError`，指出`SentinelContractHolder`类中不存在`parseAndValidatateMetadata`方法。根本原因是该方法名拼写错误，在新版本的Sentinel和OpenFeign中已更正为`parseAndValidateMetadata`。问题出现在Spring Cloud Alibaba 2.2.1.RELEASE引入旧版OpenFeign (2.2.1.RELEASE) 方法，而Sentinel 2.2.1.RELEASE则尝试调用新版OpenFeign (2.2.2.RELEASE) 的方法。提供了两种解决方案：一是更新Spring Cloud Alibaba或Sentinel至兼容版本；二是通过自定义覆盖`SentinelContractHolder`类来继续支持旧版的方法调用，包括创建同名包及实现相应方法。

防止重复提交，接口幂等性

文章介绍了接口幂等性的概念及其重要性，即用户对同一操作发起的一次或多次请求结果一致，不会因多次点击产生副作用。文章列举了需要防止非幂等性的情况，如用户多次点击按钮、页面回退再次提交等，并以SQL为例说明了哪些操作是天然幂等的。对于如何保证幂等性，提出了多种解决方案：使用token机制（需注意先删除还是后删除token的问题及原子性）、数据库悲观锁与乐观锁、业务层分布式锁、数据库唯一约束、Redis set防重以及防重表和全局请求唯一ID等方法。这些方案各有优缺点，适用于不同的场景。

feign远程调用及异步调用丢失请求头问题

文章主要讨论了Feign在远程调用时丢失请求头的问题及其解决方案。对于同步调用，Feign会创建一个新的请求对象，但默认情况下不会携带原始请求的请求头信息。为解决这一问题，可以通过实现`RequestInterceptor`接口，并将其注册到Spring容器中，从而在新的请求中同步旧请求的请求头数据。此外，文章还介绍了异步调用场景下如何通过`CompletableFuture`结合`RequestContextHolder`将主线程中的请求属性复制到子线程，确保异步任务能够访问到正确的上下文信息。这些方法有效解决了Feign调用过程中请求头信息丢失的问题。

过滤器与拦截器的使用及区别

本文介绍了Java Web开发中过滤器（Filter）和拦截器（Interceptor）的概念、使用方法及其主要区别。过滤器主要用于在请求到达Servlet或Struts2的Action前，对请求或响应进行预处理，如设置字符集、过滤非法URL等；而拦截器则基于面向切面编程，在Service或特定方法调用前后执行额外逻辑，如日志记录。对于过滤器，可以通过Spring Boot的`FilterRegistrationBean`或原生Servlet注解来定义与注册；拦截器则需实现`HandlerInterceptor`接口，并通过配置类添加到应用中。两者的主要区别在于：过滤器依赖于Servlet容器且适用于所有请求，而拦截器基于反射技术，更灵活地应用于特定业务逻辑，并能访问更多上下文信息。此外，它们在执行顺序上也有所不同，遵循“过滤前-拦截前-action执行-拦截后-过滤后”的流程。

RabbitMQ消息确认机制-可靠抵达

为了确保消息的可靠传递，可以采用事务消息，但其性能会大幅下降。为此，引入了确认机制以提高效率。确认机制包括生产者端的ConfirmCallback和ReturnCallback以及消费者端的ack机制。 - **ConfirmCallback**：通过设置`spring.rabbitmq.publisher-confirms=true`或`spring.rabbitmq.publisher-confirm-type=correlated`开启，并在RabbitTemplate中设置确认回调，当消息被成功接收时触发。 - **ReturnCallback**：通过配置`spring.rabbitmq.publisher-returns=true`及`spring.rabbitmq.template.mandatory=true`启用，在消息未能正确路由到队列时触发回调。 - **消费者确认**：默认情况下，消费者自动确认消息；若需手动控制，则应将`spring.jms.listener.acknowledge-mode`设为`manual`，并在监听器中实现具体的消息签收（`basicAck`）或拒收逻辑（`basicNack`/`basicReject`）。这样即使处理过程中出现问题，也能保证消息不会丢失。

RabbitMQ的安装及使用

RabbitMQ是一款使用Erlang开发的开源消息中间件，支持AMQP协议。它具有高可靠性、灵活的消息分发策略（如简单模式、工作队列模式等）、集群支持、多种协议兼容性以及丰富的客户端语言支持。RabbitMQ还提供了可视化管理界面和插件扩展机制。通过Docker可以方便地安装和配置RabbitMQ，并设置为开机自启。文章详细介绍了四种类型的Exchange（Direct, Fanout, Topic, Headers）及其应用场景，同时展示了如何在Spring Boot项目中整合RabbitMQ，包括依赖引入、配置设置、组件启用及消息发送与接收的具体实现。这为开发者提供了一个全面了解和使用RabbitMQ作为消息中间件的基础指南。

SpringSession整合redis，解决分布式session问题

Spring Session是一个专注于解决session管理问题的项目，能够简单快速地集成到应用中，替代传统的HttpSession。其核心原理基于装饰者模式，通过`@EnableRedisHttpSession`注解导入配置类，实现对请求的拦截与处理。在每个请求经过`SessionRepositoryFilter`时，原生的HttpServletRequest和HttpServletResponse会被包装，并重写相关方法以调用自定义的session存储逻辑。使用Spring Session需要引入相应的依赖并配置Redis作为后端存储，同时可以通过自定义序列化器和CookieSerializer来扩展session的作用域及序列化方式。此外，通过简单的HTTP请求处理示例展示了如何在实际应用中保存和获取session信息。

分布式session

本文介绍了session的工作原理及其在分布式环境下的解决方案。session数据存储于服务端，通过客户端的jsessionId进行访问，但默认情况下session不可跨域。为了实现session在不同服务或集群间的共享，提出了几种方案：直接将信息存入cookie中（存在安全风险和大小限制）、session复制（效率低且不推荐）、基于哈希一致性算法分配特定机器处理请求（远程调用问题难以解决）以及使用Redis作为统一存储介质（目前较为流行的解决方案）。每种方法都有其优缺点，在实际应用时需根据具体需求选择合适的策略。