MsBlog

使用systemctl创建tomcat服务

本文介绍了如何使用systemd和systemctl工具在Linux系统中配置Tomcat服务的自启动。首先，创建一个位于`/usr/lib/systemd/system/`目录下的名为`tomcat.service`的服务文件，并在其中定义Tomcat服务的基本信息、启动停止命令等。接着，通过执行`systemctl daemon-reload`加载新创建的服务脚本，然后可以使用一系列`systemctl`命令来管理Tomcat服务（如启动、停止、重启及查看状态）。此外，还提供了遇到错误时（特别是控制进程退出码203）可能的原因及其解决办法。最后，详细解释了`.service`文件各部分([Unit], [Service], [Install])的作用与常用选项配置，帮助用户更好地理解和定制自己的服务。

2022-06-27

2748

sql中不要用关键字作为表名或字段

在编写SQL查询语句时遇到执行错误，如`select * from table1 where key='xxx'`，原因是`key`是SQL中的关键字。为避免此类问题，当字段名或表名与SQL关键字冲突时，应使用反引号（`` ` ``）将其包裹起来，正确的写法应为`select * from table1 where `key`='xxx'`。此外，建议尽量避免使用SQL保留字作为数据库中的表名或字段名，以减少潜在的错误。可以参考[这里](http://postgres.cn/docs/9.6/sql-keywords-appendix.html)获取更多关于SQL关键字的信息。

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

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

@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）来解决注入歧义问题。

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

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

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

本文介绍了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作为统一存储介质（目前较为流行的解决方案）。每种方法都有其优缺点，在实际应用时需根据具体需求选择合适的策略。