后端常见问题

码匠君 ... 2022-1-2 大约 4 分钟

# 后端常见问题

# [1]Row was updated or deleted by another transaction

# 为什么会出现此问题

本系统自研了基于 CaffeineRedis 的多级缓存,并将其与 Hibernate 有机整合,作为 Hibernate 的二级缓存以更好的支持查询数据,特别是分页查询和条件查询的数据缓存。

服务在启动过程中,会扫描所有的 Controller,将其中的所有的接口,作为权限数据存储到数据库中。Hibernate 的二级缓存默认的机制,是在服务退出时,清空缓存以保证缓存数据的一致性(本系统支持通过配置修改该机制,服务退出时不删除Redis缓存数据以支持服务的多实例缓存)。

Hibernate 的二级缓存默认的机制下,如果出现一个服务在启动一个服务在关闭的极端情况,就会导致缓存事务锁住出现错误的情况。特别是,如果没有按照文档操作步骤进行正确的数据库自动创建和数据初始化,缓存中产生不匹配的编码信息后,更容易出现此问题。

# 解决方法

此问题,经常出现在搭建环境的过程中,关停所有服务,参照文档检查数据库自动创建和数据初始化是否按照文档正确配置,清空Redis中所有的缓存数据。再次启动服务即可解决问题。

# [2]能不能不用Kafka(或消息队列)

# 为什么要用消息队列

消息队列是多系统集成的多种方式中,比较好的一种方式。既规避了ETL集成方式时效性差的问题,又规避了纯页面或者纯接口集成方式出发机制不理想的问题,而且将多系统集成的耦合性降到了最低。

微服务平台看似是一个完整的系统,本质还是多个系统(服务)间的整合及配合。因此,消息队列是必不可少的一个组成部分。

目前,就作者已知的或已了解过的开源微服务框架,还没有发现那个系统不用消息队列的。(不一定都是用Kafka,但都是用了消息队列)

# 确实不想用怎么办

因为本系统没有使用最基础的 Kafka,而是集成了 spring-cloud-bus。而 spring-cloud-bus 又依赖于 spring-cloud-streamspring-integrationspring-kafka 等多种组件。这就导致无法简单的通过修改配置文件来彻底关闭 Kafka

友情提示

spring-integration 是个神器的存在,只要你代码的上下文中包含 spring-cloud-streamspring-kafka 等依赖,连 Swagger 都会主动去连接消息队列。

所以想要彻底不使用 Kafka (消息队列),只能通过去除依赖包的方法。

具体操作的步骤是:

  1. eurynome-cloud-message 包中,删除 spring-cloud-starter-bus-kafka 依赖。
  2. eurynome-cloud-message 包中涉及到 Kafka 相关引用的代码删除。
  3. eurynome-cloud-bpmn-ability 包中,@KafkaListener 注解以及代码引用删除
  4. 重新编译代码运行。

警告

消息队列是本系统的核心组件,因目前关联的内容还不算特别多。非要剔除消息队列,可能导致部分功能的无法使用或者出现后续版本不兼容的情况。

所以请三思而后行!切记!

# [3]为什么没有看到 Seata

文档中,有提到本系统集成了 Seata,问什么在代码中,连 Seata 的安装信息都没有看到。

这个问题的主要原因是:

  1. 当前开源版本基础的服务本身比较少,没有什么具体的、合适的场景必须用到 Seata。即使加上就是多装一个东西,最多些点 Demo 代码。
  2. 在这种情况下,强制加上 Seata 只会增加本系统搭建资源成本、时间成本以及复杂程度。特别是学习使用本系统的朋友,各种能力程度和技能水平的都有,有些朋友搭建基本内容都有困难,多一项内容就更多了一份难度。
  3. 微服务框架本身涉及的内容就非常多,个人观点非必要、非必需的内容没有必要增加太多。确实需要时,集成一个 Seata 也非常简单,真正能用起来的东西才是有价值的。就像做单体项目时,又有多少人真真正正的使用过“事务”?

提示

这里引用一篇个人认为比较好的介绍分布式事务文章的结论供参考:

上边简单介绍了 2PC、3PC、TCC、MQ、Seata 这五种分布式事务解决方案,还详细的实践了 Seata 中间件。但不管我们选哪一种方案,在项目中应用都要谨慎再谨慎,除特定的数据强一致性场景外,能不用尽量就不要用,因为无论它们性能如何优越,一旦项目套上分布式事务,整体效率会几倍的下降,在高并发情况下弊端尤为明显。

原文地址 (opens new window)

上次编辑于: 2022年1月3日 14:33
贡献者: 码匠君