事务管理

以下内容的一些总结 create，alter，drop，show， 用于 表/数据库 DDL CRUD后都要加database/databases/table/tables select database(); -DOS窗口中查询当前正在使用的数据库，使用用use。 表中数据的增加用insert into，修改update，删除delete这两个一般加上限定条件WHERE DQL中NULL不能用“==” 等运算符判读，需要使用IS/IS NOT where与hanving限定的区别，在分组查询中，where限定是在分组之前，不满足条件不参与分组，having限定是在分组之后，不满足条件不会被查询出来。 where 后不能进行聚合函数的判断，having可以 修改表，进行数据项约束： alter table 表名 modify 列名 数据类型 NOT NULL; mysql中，唯一约束限定的列的值可以有多个null 删除特例 删除主键约束：ALTER TABLE stu DROP PRIMARY KEY; 删除唯一约束：ALTER TABLE stu DROP INDEX 列名; MySQL数据库软件安装与卸载 卸载 去mysql的安装目录找到my.ini文件 复制 datadir="C:/ProgramData/MySQL/MySQL Server 5.5/Data/"

1 案例中的问题 1.1 示例代码 示例： package com.sunxiaping.spring5.service.impl; import com.sunxiaping.spring5.dao.IAccountDao; import com.sunxiaping.spring5.domain.Account; import com.sunxiaping.spring5.service.IAccountService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import java.util.List; @Service public class AccountServiceImpl implements IAccountService { @Autowired private IAccountDao accountDao; @Override public void save(Account account) { accountDao.save(account); } @Override public void update(Account account) { accountDao.update

一．Spanner功能概要 Spanner具有 高扩展性 ， 多版本 （multi-version）、 世界级分布 （globally-distributed）及 同步复制 （synchronously-replicated）等特性。 Spanner立足于高抽象层次，使用Paxos协议横跨多个数据集把数据分散到世界上不同数据中心的状态机中。世界范围内响应，出故障时客户副本之间的自动切换。当数据总量或服务器的数量发生改变时，为了平衡负载和处理故障，Spanner自动完成数据的重切片和跨机器（甚至跨数据中心）的数据迁移。 Spanner可以轻松的横跨数百个数据中心将万亿级数据库行扩展到数百万台机器中。高可靠性更是让应用程序如虎添翼，即使面对大范围的自然灾害，可靠性仍然能得到良好的保障（因为Spanner有着世界级的数据转移）。最初的用户来自F1 — 使用了美国境内的5个拷贝。多数其他应用程序都是在同一个地理区域将数据复制3到5份，使用相对独立的故障模式。也就是说多数的应用程序会选择低延迟超过高有效性，只用一两个数据中心来保障数据的可靠性。 Spanner的 主旨是数据中心的管理 ，但是在分布系统基础设施的特色上同样是下足了功夫。尽管Bigtable很讨一些项目欢心，我们还是收到了一些Bigtable在某些应用程序（复杂的、不断变化的架构或者需要在大区域响应中保持强一致性

一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销

摘自： https://www.cnblogs.com/xiaoXuZhi/p/xyh_trans_distributed.html 关于分布式事务的实现梳理 关于分布式事务的实现梳理 场景描述 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的数据库，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。 解决方案 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式： 　　其一、分布式事务 　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。 　　其二、消息队列 　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。 　　其三、异步作业 　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。 　　　　在实际使用过程中

NoSQL 入门与概述 为什么用 NoSQL? 什么是单机 MySQL? 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 Memcached（缓存）+MySQL+垂直拆分 MySQL 主从读写分离 由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。MySQL 的 Master-Slave 模式成为这个时候的网站标配了。 分表分库+水平拆分+MySQL集群 在 Memcached 的高速缓存，MySQL 的主从复制，读写分离的基础之上，这时 MySQL 主库的写压力开始出现瓶颈，而数据量的持续猛增，由于 MyISAM 使用表锁，在高并发下会出现严重的锁问题，大量的高并发 MySQL 应用开始使用 InnoDB 引擎代替MyISAM。 同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL 推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然 MySQL 推出了 MySQL Cluster 集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。 MySQL 的扩展问题 MySQL

关于分布式事务的实现梳理 场景描述 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的 数据库 ，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。 解决方案 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式： 　　其一、分布式事务 　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。 　　其二、消息队列 　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。 　　其三、异步作业 　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。 　　　　在实际使用过程中，一般都是消息队列和异步作业配套实现，当消息队列出现问题，异步作业能正常的把流程走完。 　　分布式事务 　　在介绍分布式事务时，分两部分来介绍：sql分布式事务、ADO

MySQL各大存储引擎： 最好先看下你下的MySQL支持什么数据库引擎 存储引擎主要有： 1. MyIsam , 2. InnoDB, 3. Memory, 4. Blackhole, 5. CSV, 6. Performance_Schema, 7. Archive, 8. Federated , 9 Mrg_Myisam 但是我们主要分析使用MyIsam 和InnoDB。其余略微带过，详情请分别百度。 （1）InnoDB： 定义： （默认的存储引擎） InnoDB是一个事务型的存储引擎，有行级锁定和外键约束。 Innodb引擎提供了对数据库ACID事务的支持，并且实现了SQL标准的四种隔离级别，关于数据库事务与其隔离级别的内容请见数据库事务与其隔离级别这类型的文章。该引擎还提供了行级锁和外键约束，它的设计目标是处理大容量数据库系统，它本身其实就是基于MySQL后台的完整数据库系统，MySQL运行时Innodb会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引，而且它没有保存表的行数，当SELECT COUNT(*) FROM TABLE时需要扫描全表。当需要使用数据库事务时，该引擎当然是首选。由于锁的粒度更小，写操作不会锁定全表，所以在并发较高时，使用Innodb引擎会提升效率。但是使用行级锁也不是绝对的

第一个mybatis程序 IDE:myeclipse2017 jar包：mybatis3.5.2，mybatis依赖包，mysql8.0.17驱动包 注：mybatis包和所需的依赖包，可到 http://www.mybatis.cn/ 下载， mybatis官方文档 (可选中文) 1.项目结构图 注：本示例参考于 C语言中文网 ，如对本示例有疑问可查看此网站，看是否能解决问题 2.建库建表 CREATE DATABASE test; USE test; DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `uid` INT UNSIGNED AUTO_INCREMENT, `uname` varchar(20) DEFAULT NULL, `usex` varchar(10) DEFAULT NULL, PRIMARY KEY (`uid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 3.导jar包 4.创建日志文件 MyBatis 默认使用 log4j 输出日志信息，如果开发者需要查看控制台输出的 SQL 语句，那么需要在 classpath 路径下配置其日志文件。在 myBatis应用的 src 目录下创建 log4j.properties 文件，其内容如下： # Global logging

1.XA XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）。下图说明了事务管理器、资源管理器，与应用程序之间的关系： 图1.XA规范下的分布式事务各类参与者之间的关系 2.JTA 作为java平台上事务规范JTA（Java Transaction API）也定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的，在JTA 中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。像很多其他的java规范一样，JTA仅仅定义了接口，具体的实现则是由供应商(如J2EE厂商)负责提供，目前JTA的实现主要由以下几种： 1