在开发中，为了降低单点压力，通常会根据业务情况进行分表分库，将表分布在不同的库中（库可能分布在不同的机器上）。在这种场景下，事务的提交会变得相对复杂，因为多个节点（库）的存在，可能存在部分节点提交失败的情况，即事务的ACID特性需要在各个不同的数据库实例中保证。比如更新db1库的A表时，必须同步更新db2库的B表，两个更新形成一个事务，要么都成功，要么都失败。 那么我们如何利用MySQL实现分布式数据库的事务呢？
事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元； 事务应该具有4个属性：原子性、一致性、隔离性、持续性； 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之
MySQL 为我们提供了分布式事务解决方案，在前面的内容中 聊一聊分布式事务的解决方案 提到过 binlog 的同步，其实是 MySQL XA 规范的一个应用，那么 XA 规范是如何定义的，具体又是如何应用的呢？
存储引擎的事务特性能够保证在存储引擎级别实现ACID。而分布式事务则让存储引擎级别的ACID可以扩展到数据库层面，甚至可以扩展到多个数据库之间–这需要两阶段提交实现。MySQL5.0和更新版本的数据库已经开始支持XA事务了。
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败，本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
PART 01 背景 InnoDB中undo段的状态 InnoDB如何安全地崩溃恢复主要通过undo log机制来保证。事务的undo日志存放在undo段中，一个事务可能拥有多个undo段，事务prepare时会将所有undo段头部的TRX_UNDO_STATE字段修改为TRX_UNDO_PREPARED，这个操作完成后（完成的标准是修改undo段状态的所有redo日志都已落盘），事务所有的修改都已经持久化，即使程序崩溃也不会丢失（不考虑硬件损坏等特殊情况）。 崩溃恢复的时候会将根据undo段的状态来决定事
作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：
XA，2PC，two-phase commit protocol。 两阶段事务提交采⽤的是 X/OPEN 组织定义的DTP 模型所抽象的
XA，2PC，two-phase commit protocol，两阶段事务提交采⽤的是 X/OPEN 组织定义的DTP 模型所抽象的：
陈某的《Spring Cloud Alibaba实战项目》 视频教程已经录完了，涉及到Alibaba的各种中间件、OAuth2微服务认证鉴权、全链路灰度发布、分布式事务实战，戳这里--->Spring Cloud Alibaba 实战 视频专栏 开放订阅~
文章主要介绍了腾讯云分布式数据库DCDB的一些特性、架构、以及业务价值。DCDB可支持大容量、高并发的业务需求，同时具备高可用性、高性能、以及更优的TCO。在架构上，DCDB采用了全冗余、全解耦的设计，保证了高可用性。此外，DCDB还具备弹性扩展的能力，能够根据业务的需求自动调整计算资源。通过这些特性，DCDB能够满足金融行业对数据库的各种需求，包括高并发、高可用、高稳定性、以及低成本。
参考：http://www.linuxidc.com/Linux/2015-11/124942.htm
分布式事务，我们已经给小伙伴介绍了整体内容： 一文搞明白分布式事务解决方案！真的 so easy！ AT 模式的实现： 手把手带领小伙伴们写一个分布式事务案例！ AT 模式在多数据源中的应用： Spring Boot 多数据源如何处理事务？教你一招！ TCC 模式的实现： 听说 TCC 不支持 OpenFeign？这个坑松哥必须给大家填了！ 今天我们就一起来看下另一种模式，XA 模式！ 其实我觉得 seata 中的四种不同的分布式事务模式，学完 AT、TCC 以及 XA 就够了，Saga 不好玩，而且长事务
Mycat 目前没有出来跨分片的事务强一致性支持，目前单库内部可以保证事务的完整性，如果跨库事务，在执行的时候任何分片出错，可以保证所有分片回滚，但是一旦应用发起 commit 指令，无法保证所有分片都成功考虑到某个分片挂的可能性不大所以称为弱 xa。
http://www.linuxidc.com/Linux/2015-11/124942.htm
在MySQL 5.7.7版本中，才将xa的bug修复，符合Open Group 的<<Distributed Transaction Processing:The XA Specification>> 标准。Mysql中存在两种XA事务，一种是内部XA事务主要用来协调存储引擎和二进制日志，一种是外部事务可以参与到外部分布式事务中（比如多个数据库实现的分布式事务）。xa的语法如下：
Xa主要规定了RM与TM之间的交互，下面来看下XA规范中定义的RM 和 TM交互的接口：
随着并发量、数据量越来越大及业务已经细化到不能再按照业务划分，我们不得不使用分布式数据库提高系统的性能。在分布式系统中，各个节点在物理上都是相对独立的，每个节点上的数据操作都可以满足 ACID。但是，各独立节点之间无法知道其他节点事务的执行情况，如果想让多台机器中的数据保存一致，就必须保证所有节点上的数据操作要么全部执行成功，要么全部不执行，比较常规的解决方法是引入“协调者”来统一调度所有节点的执行。
MySQL 从5.0.3开始支持XA分布式事务，且只有InnoDB存储引擎支持。MySQL Connector/J 从5.0.0版本之后开始直接提供对XA的支持。
小熊学Java个人网站：https://javaxiaobear.gitee.io/，每周持续更新干货，建议收藏！
前几天和一个搞JAVA的朋友聊天，无意中聊到了分布式事务，他们公司的是通过TCC来实现分布式事务的，具体什么是TCC，会在下面的文章中介绍；本文主要介绍MYSQL中基于XA实现的分布式事务；
松哥最近正在录制 TienChin 项目视频～采用 Spring Boot+Vue3 技术栈，里边会涉及到各种好玩的技术，小伙伴们来和松哥一起做一个完成率超 90% 的项目，戳戳戳这里-->TienChin 项目配套视频来啦。 ---- 分布式事务，咱们前边也聊过很多次了，网上其实也有不少文章在介绍分布式事务，不过里边都会涉及到不少专业名词，看的大家云里雾里，所以还是有一些小伙伴在微信上问我。 那么今天，我就再来一篇文章，和大家捋一捋这个话题。以下的内容主要围绕阿里的 seata 来和大家解释。 1. 什么
原文地址： https://www.percona.com/blog/2019/09/27/multiplexing-mux-in-proxysql/
本文介绍了TDSQL在分布式事务上的实践，重点讲解了事务的基本概念、分布式事务的难点、解决方案以及在实践中的运用。此外，还介绍了TDSQL在分布式事务上的优化，包括减少长事务、事务隔离级别、事务提交、事务消息等，为读者提供了全面且深入的分布式事务理解。
多数据源的事务处理是个老生常谈的话题，跨两个数据源的事务管理也算是分布式事务的范畴，在同一个JVM里处理多数据源的事务，比较经典的处理方案是JTA(基于XA协议建模的java标准事务抽象)+XA(XA事务协议)，常见的JTA实现框架有Atomikos、Bitronix、Narayana，Spring对这些框架都有组件封装，基本可以做到开箱即用程度。本文除了分享XA事务方案外，提供了一种新的多数据源事务解决思路和视角。
先说下哈，这次给大家带来的大厂面试题，都来源于我的知识星球，总共 20 道题，17 道题来自悟空分享，另外 3 道题来自 MySQL 大牛：东哥。
通过上文《MySQL是如何保证数据不丢失的？》可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。
下图说明了一个DTP系统的本地实例，其中AP调用TM来构造事务。这些框表示X/Open DTP模型中的软件组件。箭头指示控制流的方向。
初次接触二阶段提交，源于想以事务的方式实现对 MongoDB 中多个集合数据的修改，而 MongoDB 本身不支持事务，官方推荐的方案就是使用二阶段提交。
XA 是由 X/Open 组织提出的分布式事务规范，XA 规范主要定义了事务协调者（Transaction Manager）和资源管理器（Resource Manager）之间的接口。
为了使代码好看, 很多时候 函数返回 True 表示失败, False表示成功. 但还是得看个人习惯, 比如我更习惯在条件前面加个not或者!, 虽然会有额外的转换, 但是代码更易读.
导读：本文从MySQL架构、MySQL日志、MySQL的MVCC、MySQL索引、MySQL语法分析及优化、执行计划和慢查询日志、主从备份、分布式事务等方面进行了体系化的讲述。
本公众号提供的工具、教程、学习路线、精品文章均为原创或互联网收集，旨在提高网络安全技术水平为目的，只做技术研究，谨遵守国家相关法律法规，请勿用于违法用途，如果您对文章内容有疑问，可以尝试加入交流群讨论或留言私信，如有侵权请联系小编处理。
MySQL偶尔会出现OOM（内存溢出）现象,导致MySQl服务重启，以下哪种方式能有效缓解OOM的情况发生（）
1、MySQL偶尔会出现OOM（内存溢出）现象,导致MySQl服务重启，以下哪种方式能有效缓解OOM的情况发生（ ）
本文由读者 muggle 投稿，muggle 是一位具有极客精神的 90 后优秀单身老实猿。muggle 的个人博客地址是 http://muggle.javaboy.org。本文较长，认真读完后相信你一定会有所收获。
本文主要研究一下sharding-jdbc的XAConnectionWrapper
事务是访问并更新数据库中各种数据项的一个程序执行单元，事务会把数据库从一种一致状态转换为另一种一致状态，这就是事务的目的，也是事务模型区别与文件系统的重要特性之一。
Statements considered unsafe. Statements with the following characteristics are considered unsafe:
如果一个字符的大小是一个字节的，称为窄字节；如果一个字符的大小是两个字节的，成为宽字节
是在是抱歉，本来每周一都是 POSTGRESQL 的，但由于某些原因这周更换顺序，下周会恢复的。
今天巡检时突然发现有很多锁等待超时的情况，原以为是一个简单的小事，一查，结果令人深思。
在mysql5.5版本之后新增了performance_schema的数据库用于监视数据库性能，该数据库中表的引擎都是performance_schema。PS数据库默认是关闭的，其中的表都是内存表，不存储在磁盘中，在服务器重启后数据消失。在数据文件performance_schema目录下只有表结构文件不存在数据文件，对这些表的改变不会记录到binlog中。数据收集是通过修改服务器源代码来实现的，不存在与PS相关联的单独线程。PS数据库消耗很少的性能，官方文档介绍即使将PS中所有监控项开启也不会对mysql server性能造成太大影响。
MyCat就是一个数据库中间件，数据库的代理，它屏蔽了物理数据库，应用连接MyCat，然后MyCat再连接物理数据库。 Mycat的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
