分布式事务提交慢的一次总结和思考

分布式,事务,提交,一次,总结,思考 · 浏览次数 : 8

小编点评

**分布式事务未提交的原因** 1. **内存泄露**:当事务提交后,如果应用程序内存分配不够,会导致内存泄露,数据库无法正常处理后续提交的事务。 2. **分布式事务未提交**:当应用程序在提交事务之前,由于连接池满或连接失败,无法建立新的连接,导致事务无法提交。 3. **线程池泄露**:当线程池中存在死锁或闲置线程时,会导致线程池泄露,影响事务提交效率。 4. **异常代码**:当应用程序中存在异常代码导致事务状态异常时,会导致事务无法提交。 5. **第三方库异常**:当第三方库的代码出现异常时,会导致事务无法提交。 6. **服务器系统配置不规范**:当应用程序配置不正确或数据库参数设置不合理时,会导致事务提交失败。 **思考背景** * **事务提交逻辑复杂**:分布式事务的提交逻辑比较复杂,需要考虑多个并发连接的处理和事务隔离等问题。 * **网络连接**:事务提交需要多个数据库连接,因此网络连接非常重要。 * **线程数和连接数**:在配置连接池时,需要根据应用程序的资源情况进行设置。 * **资源限制**:数据库资源有限,因此需要合理配置连接池的大小。

正文

分布式事务提交慢的一次总结和思考


背景

分布式事务未提交 是应用程序出现宕机异常的很重要的一原因. 

应用宕机主要可以分为:
1. 内存泄露导致的OOM宕机. 表现在系统越来越慢, 应用的内存和CPU占用量越来越高. 最终达到无响应的状态, 此时数据库一般是正常的. 
2. 分布式事务未提交导致的宕机, 表现在无法建立新的连接, 会出现连接池满,或者超时等的现象. 数据库的压力会比较大, 应用的压力一般不会很高. 
3. 线程池泄露导致的栈溢出问题, 一般表现在线程/线程池处理不规范, 创建后没有做清理处理, 导致线程堆积, 非堆区超过上下, 出现栈溢出或者是OOM溢出. 
   这种现象下堆区内存较为正常, 但是非堆区会比较异常. 
4. 异常代码导致的宕机,比如死循环, 笛卡尔积, 大数据量下的未分页,全部积压到JVM的堆区内存中. 
5. 第三方库的异常, 比如json解析过大, 影像图片解析异常, excel解析异常(错误的格式或者是16k*20k的渲染), 错误文件导致的解析死循环. 
6. 服务器系统配置不规范,应用配置不规范, 比如nofile, 内存限制, 过低,过于严格, IO突然的降低导致延迟增加或者是延迟热加载时文件加载失败(损坏,不完整等),或者是重复加载. 内存,文件连接不释放

问题与思考

本次问题出现的范围比较广, 原因也比较复杂, 这里仅分析与思考一下一个事务相关的问题. 
其他的比如 数据库参数配置, 大表的批量更新与删除, 索引的过多,不完整等问题暂时不深入. 

OLTP的环境下, 事务的处理必须是短促的. 要占用尽可能少的数据库时间与资源.
在提交事务后, 应该尽快的执行commit 或者是 rollback. 
避免占用过多,过久的数据库的资源. 

TCP连接/Session/Process 是数据库资源
Lock/latch/ 也是数据库资源.
数据文件写入/redo/undo的写入, 归档的写入, 更数据库资源.
SQL解析,SQL执行,排序,关联 等等 都是数据库的资源. 

事务未提交, 主要会占用 网络,session, 以及lock相关的资源. 
他会锁住要执行变更的部分行信息. 

并且因为不提交, 这个数据库连接不能被复用. 应用服务器的连接池值能够继续创建新的连接.
这就会导致:
1. 创建TCP连接.数据库创建process. 创建session 是很重的操作, 会耗时比较久, 高并发的情况下基本上是秒级操作. 
2. 提交事务的时间越久, 其他用户需要的连接越多, 建立的连接的效率就会越低. 会进入螺旋上升的性能屏障. 
3. 建立Process和Session, 数据库会分配内存和CPU资源, 会导致数据库的负载上升, 响应能力下降. 
4. 数据库的性能下降会导致本来可以很快提交的动作变的更慢. 导致真个流程变的更加漫长. 

优化思路

分布式事务未提交是不可接受的. 
事务提交逻辑复杂也是不可接受的. 

1. 开启事务后要尽快提交, 不要有太过复杂的逻辑处理, 不要一次性修改更多的数据, 尤其不要有大表的not in 批量处理等. 
2. 开启事务后, 必须有finally , 能够catch 住异常, 并且执行rollback等操作, 避免事务处理时异常数据导致不提交,出现异常卡顿. 
3. 不建议在开启事务后有非关键核心的表处理, 比如临时表, 排序,大表的数据检索与验证等. 避免提交事务变慢. 需要插入修改删除的数据需要再事务开启之间准备好. 
4. 开启连接池,并且适当设置连接池的大小. 尤其不要过高, 过高在遇到事务问题时会将数据库的资源耗尽, 过低会导致无法满足业务需求. 

关于线程数和连接数

应用服务器的线程数可以理解为干活的人数. 
对应数据库的连接数可以理解为工人交付工作成果的窗口. 

干活的人数跟车间的大小相关(CPU和内存) 设置的太小了, 吞吐量会比较小.
但是设置的太大了, 会出现线程上下文切换, 出现等待事件,并且占用比较多的CPU和内存资源. 
所以线程池的设置 要根据应用服务器的配置, 以及业务场景的逻辑来进行设置. 

如果资源比较少, 并且业务逻辑处理比较快, 并发要求不是特别高, 可以适当减少线程池的大小. 
如果对并发和吞吐量要求特别高, 那么必须要加大配置. 增加线程池. 

连接池就像是线程池干完活后用于提交工作成果的. 
如果成果比较简单, 可以快速的提交和释放, 那么数据库连接池可以比较小一些. 
如果提交的工作比较复杂, 时间很久, 需要较高的连接池数量. 

需要注意, 如果连接池多了, 应用服务器需要关联较多的对象, 内存,CPU和切换起来都可能会慢. 
数据库对应更多的应用, 他会产生更大的压力. 虽然有epoll等网络模型
但是100个并发和1000个并发对数据库产生的压力是非常不一样的. 

所有放之四海皆准的配置, 需要根据业务场景,数据量, 应用和数据库的配置进行关联思考设置出最合适的配置来. 

与分布式事务提交慢的一次总结和思考相似的内容:

分布式事务提交慢的一次总结和思考

分布式事务提交慢的一次总结和思考 背景 分布式事务未提交 是应用程序出现宕机异常的很重要的一原因. 应用宕机主要可以分为: 1. 内存泄露导致的OOM宕机. 表现在系统越来越慢, 应用的内存和CPU占用量越来越高. 最终达到无响应的状态, 此时数据库一般是正常的. 2. 分布式事务未提交导致的宕机,

分布式事务:XA和Seata的XA模式

上一篇内容《从2PC和容错共识算法讨论zookeeper中的Create请求》介绍了保证分布式事务提交的两阶段提交协议,而XA是针对两阶段提交提出的接口实现标准,本文则对XA进行介绍

分布式事务解决方案汇总

2阶段(2PC)提交方案: 实现原理:基于XA规范搞的一套分布式事务的理论,也可以叫做一套规范,或者是协议。 (1)准备阶段(Prepare phase):事务管理器给每个参与者发送prepare消息,每个数据库参与者在本地执行事务,并写本地的Undo/Redo,此时事务没有提交。 (2)提交阶段(

RabbitMQ+redis+Redisson分布式锁+seata实现订单服务

引言 订单服务涉及许多方面,分布式事务,分布式锁,例如订单超时未支付要取消订单,订单如何防止重复提交,如何防止超卖、这里都会使用到。 开启分布式事务可以保证跨多个服务的数据操作的一致性和完整性, 使用分布式锁可以确保在同一时间只有一个操作能够成功执行,避免并发引起的问题。 订单流程(只展示重要的内容

MySQL高级5-SQL优化

一、插入数据优化 1.1 批量插入 如果有多条数据需要同时插入,不要每次插入一条,然后分多次插入,因为每执行一次插入的操作,都要进行数据库的连接,多个操作就会连接多次,而一次批量操作只需要连接1次 1.2 手动提交事务 因为Mysql默认每执行一次操作,就会提交一次事务,这样就会涉及到频繁的事务的开

从kafka与Flink的事务原理来看二阶段提交与事务日志的结合使用

两阶段提交的成立要基于以下假设: - 该分布式系统中,存在一个节点作为协调者,其他节点作为参与者,且节点之间可以进行网络通信。 - 所有节点都采用预写式日志,且日志被写入后即被保存在可靠的存储设备上,即使节点损坏也不会导致日志数据的丢失。 - 所有节点不会永久性损坏,即使损坏后也可以恢复。 ###

面试官:你了解git cherry-pick吗?

事情要从一次不规范的代码开发开始说起 背景故事 时间 2024年某个风平浪静的周五晚上 地点 中国,北京,西二旗,某互联网大厂会议室 人物 小杰,小A,小B,老K 对话 老K:昨天提交的代码被测试打回来了!为什么小B没开发完的内容也一起提交上去了? 小B:啊?我不清楚啊,我在开发分支B开发完一部分就

《痞子衡嵌入式半月刊》 第 104 期

痞子衡嵌入式半月刊: 第 104 期 这里分享嵌入式领域有用有趣的项目/工具以及一些热点新闻,农历年分二十四节气,希望在每个交节之日准时发布一期。 本期刊是开源项目(GitHub: JayHeng/pzh-mcu-bi-weekly),欢迎提交 issue,投稿或推荐你知道的嵌入式那些事儿。 上期回

《痞子衡嵌入式半月刊》 第 103 期

痞子衡嵌入式半月刊: 第 103 期 这里分享嵌入式领域有用有趣的项目/工具以及一些热点新闻,农历年分二十四节气,希望在每个交节之日准时发布一期。 本期刊是开源项目(GitHub: JayHeng/pzh-mcu-bi-weekly),欢迎提交 issue,投稿或推荐你知道的嵌入式那些事儿。 上期回

《痞子衡嵌入式半月刊》 第 102 期

痞子衡嵌入式半月刊: 第 102 期 这里分享嵌入式领域有用有趣的项目/工具以及一些热点新闻,农历年分二十四节气,希望在每个交节之日准时发布一期。 本期刊是开源项目(GitHub: JayHeng/pzh-mcu-bi-weekly),欢迎提交 issue,投稿或推荐你知道的嵌入式那些事儿。 上期回