做的好的h游戏下载网站有哪些,观澜做网站公司,wordpress 前台 很慢,2013年建设工程发布网站一、本地事务
1、事务的基本特性 数据库事务的几个基本特性#xff1a;原子性、一致性、隔离性、持久性。 原子性#xff1a;一系列的操作整体不可拆分#xff0c;要么同时成功#xff0c;要么同时失败。 一致性#xff1a;数据在事务的前后#xff0c;业务整体一…一、本地事务
1、事务的基本特性 数据库事务的几个基本特性原子性、一致性、隔离性、持久性。 原子性一系列的操作整体不可拆分要么同时成功要么同时失败。 一致性数据在事务的前后业务整体一致。 转账。A:1000B:1000 转 200 事务成功A800 B1200 隔离性事务之间互相隔离。 隔离级别的一个核心问题是一个事务的执行过程和结果是否会影响到其他正在执行的事务。可串行化是最高级别的隔离即事务之间互不影响。多个并行的事务的结果与一个一个串行执行的结果一样 持久性一旦事务成功数据一定会落盘在数据库。 2、事务的隔离级别
读未提交 该隔离级别的事务会读到其它未提交事务的数据此现象也称之为脏读。 事务1对A进行修改还未提交事务2读取的是所谓的脏数据 丢失更新 读已提交 一个事务可以读取另一个已提交的事务多次读取会造成不一样的结果此现象称为不可重 复读问题Oracle 和 SQL Server 的默认隔离级别。 不可重复读是指一个事务在整个事务过程中对同一笔数据进行读取的到的结果不同。出现的原因就是事务的并发修改记录。 可重复读 该隔离级别是 MySQL 默认的隔离级别在同一个事务里select 的结果是事务开始时时间 点的状态因此同样的 select 操作读到的结果会是一致的但是会有幻读现象。MySQL 的 InnoDB 引擎可以通过 next-key locks 机制来避免幻读。 幻读是同一个事务的同一个查询的多次返回结果记录数量不一致。 序列化 在该隔离级别下事务都是串行顺序执行的MySQL 数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁从而避免了脏读、不可重复读和幻读问题。 3、Java事务控制
编程式事务
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;public class JdbcTransactionExample {public static void main(String[] args) {String url jdbc:mysql://localhost:3306/mydatabase;String user username;String password password;try (Connection conn DriverManager.getConnection(url, user, password)) {// 关闭自动提交开启事务conn.setAutoCommit(false);try (Statement stmt conn.createStatement()) {// 执行一些SQL操作stmt.executeUpdate(INSERT INTO table1 (column1) VALUES (value1));stmt.executeUpdate(UPDATE table2 SET column2 value2 WHERE id 1);// 提交事务conn.commit();} catch (SQLException e) {// 回滚事务conn.rollback();e.printStackTrace();}} catch (SQLException e) {e.printStackTrace();}}
}声明式事务 基于Spring AOP通过注解或XML配置实现有助于用户将操作与事务规则进行解耦。
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;Service
public class MyService {Autowiredprivate JdbcTemplate jdbcTemplate;Transactionalpublic void performTransaction() {jdbcTemplate.update(INSERT INTO table1 (column1) VALUES (value1));jdbcTemplate.update(UPDATE table2 SET column2 value2 WHERE id 1);}
}tx:advice idtxAdvice transaction-managertransactionManagertx:attributestx:method name* propagationREQUIRED //tx:attributes
/tx:adviceaop:configaop:pointcut idserviceMethods expressionexecution(* com.example.service.*.*(..))/aop:advisor advice-reftxAdvice pointcut-refserviceMethods/
/aop:config二、分布式事务 分布式系统经常出现的异常机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失。分布式事务是企业集成中的一个技术难点也是每一个分布式系统架构中都会涉及到的一个 东西特别是在微服务架构中几乎可以说是无法避免。
1、CAP 定理与 BASE理论
1.1、CAP定理 CAP 原则又称 CAP 定理指的是在一个分布式系统中 一致性Consistency 在分布式系统中的所有数据备份在同一时刻是否是同样的值。等同于所有节点访问同一份最新的数据副本。 可用性Availability 在集群中一部分节点故障后集群整体是否还能响应客户端的读写请求。对数据更新具备高可用性 分区容错性Partition tolerance 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区partition。 分区容错的意思是区间通信可能失败。比如一台服务器放在中国另一台服务 器放在美国这就是两个区它们之间可能无法通信。
CAP 原则指的是这三个要素最多只能同时实现两点不可能三者兼顾。
分布式事务raft算法 1.2、BASE 理论 是对 CAP 理论的延伸思想是即使无法做到强一致性CAP 的一致性就是强一致性但可以采用适当的采取弱一致性即最终一致性。 BASE 是指 基本可用Basically Available 基本可用是指分布式系统在出现故障的时候允许损失部分可用性例如响应时间、 功能上的可用性允许损失部分可用性。需要注意的是基本可用不等价于系统不可用。 响应时间上的损失正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果但由于出现故障比如系统部分机房发生断电或断网故障查询结果的响应时间增加到了 1~2 秒。 功能上的损失购物网站在购物高峰如双十一时为了保护系统的稳定性 部分消费者可能会被引导到一个降级页面。 软状态 Soft State 软状态是指允许系统存在中间状态而该中间状态不会影响系统整体可用性。分布 式存储中一般一份数据会有多个副本允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。 最终一致性 Eventual Consistency 最终一致性是指系统中的所有数据副本经过一定时间后最终能够达到一致的状 态。弱一致性和强一致性相反最终一致性是弱一致性的一种特殊情况。
1.3、强一致性、弱一致性、最终一致性 从客户端角度多进程并发访问时更新过的数据在不同进程如何获取的不同策略决定了 不同的一致性。对于关系型数据库要求更新过的数据能被后续的访问都能看到这是强一致性。如果能容忍后续的部分或者全部访问不到则是弱一致性。如果经过一段时间后要求能访问到更新后的数据则是最终一致性。
三、分布式事务的几种方案
1、2PC模式 第一阶段事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作并反映是 否可以提交。 第二阶段事务协调器要求每个数据库提交数据。 其中如果有任何一个数据库否决此次提交那么所有数据库都会被要求回滚它们在此事务中的那部分信息。
2、柔性事务-TCC 事务补偿型方案
刚性事务遵循 ACID 原则强一致性。
柔性事务遵循 BASE 理论最终一致性 与刚性事务不同柔性事务允许一定时间内不同节点的数据不一致但要求最终一致。
一阶段 prepare 行为调用 自定义 的 prepare 逻辑。
二阶段 commit 行为调用 自定义 的 commit 逻辑。
二阶段 rollback 行为调用 自定义 的 rollback 逻辑。
所谓 TCC 模式是指支持把 自定义 的分支事务纳入到全局事务的管理中。
3、柔性事务-最大努力通知型方案 按规律进行通知不保证数据一定能通知成功但会提供可查询操作接口进行核对。这种 方案主要用在与第三方系统通讯时比如调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现例如通过 MQ 发送 http 请求设置最大通知次数。达到通知次数后即不再通知。
