Day07

简介: 简介:本文涵盖分布式系统核心理论CAP与BASE,解析一致性、可用性与分区容错的权衡,介绍Seata AT模式的分布式事务执行流程,并探讨MQ消息防丢失、防重复消费及消息积压处理方案。

每日必会

CAP和Base理论了解吗

Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
Availability (可用性):用户访问集群中的任意健康节点必须能得到响应,而不是超时或拒绝。
Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务

系统间的网络不能100%保证健康,一定会有故障的时候,而服务又必须对外保证服务。因此Partition Tolerance不可避免。

如果此时要保证一致性,就必须等待网络恢复,完成数据同步后,整个集群才对外提供服务,服务处于阻塞状态,不可用。

如果此时要保证可用性,就不能等待网络恢复,那node01、node02与node03之间就会出现数据不一致。

也就是说,在P一定会出现的情况下,A和C之间只能实现一个

BASE理论是对CAP的一种解决思路,包含三个思想:

  • Basically Available(基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
  • Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
  • Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。

说下Seata的AT模式执行流程吧

  • 其余模式同理,这里不重复,要能说出XA、AT、TCC执行流程

Seata AT模式的执行流程:

  1. 分布式事务发起方发送全局事务开始请求(Begin)给Seata Server,Seata Server为该全局事务生成一个全局事务ID(XID)。
  2. 分布式事务发起方开始执行本地事务,并在本地事务执行前向Seata发起分支事务注册请求(Branch Register),包括全局事务ID(XID)、分支事务ID(Branch ID)、分支事务参与者(即本地事务的执行者)等信息。
  3. 分布式事务发起方执行本地事务,如果本地事务执行成功,则向Seata发起分支事务提交请求(Branch Report);如果本地事务执行失败,则向Seata发起分支事务回滚请求(Branch Report)。
  4. Seata Server接收到分支事务提交或回滚请求后,会根据请求的结果来决定是否进行全局事务的提交或回滚。
  5. 如果所有分支事务都提交成功,Seata会向所有参与者发送全局事务提交请求(Global Commit);如果有任何一个分支事务回滚,Seata会向所有参与者发送全局事务回滚请求(Global Rollback)。
  6. 参与者接收到全局事务提交或回滚请求后,根据请求的指令来执行本地事务的提交或回滚操作。

理论专项

  • MQ
  • 怎么防止消息丢失
  • 怎么防止消息重复消费
  • 100W个消息怎么防止积压
相关文章
|
3月前
|
监控 Java 测试技术
OOM排查之路:一次曲折的线上故障复盘
本文记录了一次Paimon数据湖与RocksDB集成服务线上频繁OOM的排查历程。通过分析线程暴增、堆外内存泄漏,最终定位到SDK中RocksDB的JNI内存未释放问题,并借助Flink重构写入链路彻底解决。分享了MAT、NMT、async-profiler等工具的实战经验与排查思路,为类似技术栈提供借鉴。
OOM排查之路:一次曲折的线上故障复盘
|
3月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用中两大关键技术。前者为跨模型标准化通信协议,实现工具与模型解耦;后者是模型调用外部功能的内置机制。二者互补协作,推动AI应用向更开放、灵活、可扩展的方向发展。
|
3月前
|
存储 缓存 运维
一场FullGC故障排查
本文记录了一次由Full GC引发的CPU使用率飙升至104%的问题排查过程。通过分析JVM堆内存,发现大对象(List<Map>)导致老年代频繁被占满,进而触发Full GC。使用JProfiler定位到问题根源:Excel数据以低效结构加载至内存且长期驻留,造成内存膨胀。最终提出“治本”与“治标”两类解决方案,并总结了线上高CPU问题的排查思路与经验。
一场FullGC故障排查
|
3月前
|
自然语言处理 fastjson Java
FastJson:大面积故障规避案例
本文记录了一次由Kotlin语法混淆引发的FastJson反序列化故障排查过程。因误将 `{}` 赋值给Java对象字段,导致FastJson解析时触发 `kotlin_error` 静态标记位异常,进而引发全局反序列化失败。问题隐蔽且影响广泛,最终通过深入源码定位并反思多语言混编下的开发规范与框架风险,强调了对底层机制理解的重要性。(239字)
 FastJson:大面积故障规避案例
|
3月前
|
存储 SQL 关系型数据库
第四章 数据库
本文详解MySQL核心知识点,涵盖char与varchar区别、事务ACID特性、索引结构(B+tree)、聚簇与二级索引、回表查询、索引创建原则及失效场景,并结合explain执行计划分析SQL性能优化策略,助力数据库高效设计与调优。
|
3月前
|
消息中间件 监控 Java
RocketMQ:底层Netty频繁OS OOM
本文记录了一例Java应用因Netty多ClassLoader加载导致堆外内存超限引发OS OOM的排查过程。通过NMT、Arthas等工具定位到多个PooledByteBufAllocator实例各自独立占用堆外内存,最终超出容器限制。建议业务调优JVM参数并推动中间件优化。
|
3月前
|
SQL 存储 JSON
慢SQL说起:淘天交易订单表如何做索引优化
本文以淘天电商订单表的慢SQL优化实践为切入点,系统剖析了非典型慢SQL的成因与排查方法,深入讲解了索引分类、B+Tree与B-Tree结构差异、执行计划解读及Query Profiler等诊断工具的使用,并结合大表索引变更案例,总结了索引优化理论与线上SOP,提炼出常见慢SQL问题的解决策略。
慢SQL说起:淘天交易订单表如何做索引优化
|
3月前
|
Java 关系型数据库 MySQL
低代码平台芋道:代码本地运行(☆)
简介:本任务面向新人,要求掌握SpringBoot、MySQL、Maven技术栈,预计2小时完成。需从Gitee拉取yudao-boot-mini项目,本地导入并运行,自行解决JDK、Maven、Idea版本等问题。完成后录制不低于8分钟视频,结构化阐述项目技术栈、核心功能、数据库表关系,并提出当前困惑,提升表达与理解能力。
|
3月前
|
存储 安全 前端开发
Java基础篇
本文详解Java核心知识点:final关键字作用、重载与重写区别、==与equals对比、反射机制及应用、String三兄弟差异、集合框架、HashMap原理与扩容、ConcurrentHashMap线程安全实现、多线程创建与加锁方式等,涵盖面试高频问题与项目实战经验。
|
3月前
|
SQL Java 数据库连接
SSM框架篇
本文介绍了Spring框架核心概念,包括IOC(控制反转)与DI(依赖注入)原理、三种依赖注入方式、Bean的五种作用域、单例Bean的线程安全性问题、自动装配模式及事务管理机制。同时涵盖事务失效场景、传播行为、JDK与CGLIB动态代理区别、AOP应用、SpringMVC执行流程与常用注解,以及MyBatis中#{}和${}的区别,全面解析Java开发中常见技术要点。

热门文章

最新文章