事务管理

原文引用 大专栏 https://www.dazhuanlan.com/2019/08/26/5d6350a8eda02/ 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。 Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58同城等很多互联网公司都进行了微服务化实践。 当前微服务的开发框架也非常多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。 2 微服务落地存在的问题 虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面： 1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。 2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。 3）微服务数量众多，其测试、部署、监控等都变的更加困难。 随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议

在并发环境，一个数据库系统会同时为各种各样的客户程序提供服务，也就是说，在同一时刻，会有多个客户程序同时访问数据库系统，这多个客户程序中的失误访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种各样的并发问题的发生，这些并发问题可归纳为以下几类 多个事务并发引起的问题： 1)第一类丢失更新：撤消一个事务时，把其它事务已提交的更新的数据覆盖了。 2)脏读：一个事务读到另一个事务未提交的更新数据。 3) 幻读：一个事务执行两次查询，但第二次查询比第一次查询多出了一些数据行。 4)不可重复读：一个事务两次读同一行数据，可是这两次读到的数据不一样。 5)第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据。 事务隔离级别 为了解决多个事务并发会引发的问题。数据库系统提供了四种事务隔离级别供用户选择。 1) Serializable：串行化。隔离级别最高 2) Repeatable Read：可重复读。--MySQL默认是这个 3) Read Committed：读已提交数据。--Oracle默认是这个 4) Read Uncommitted：读未提交数据。隔离级别最差。--sql server默认是这个 数据库系统采用不同的锁类型来实现以上四种隔离级别，具体的实现过程对用户是透明的。用户应该关心的是如何选择合适的隔离级别。 对于多数应用程序

Hibernate事务和并发控制 ++YONG原创，转载请注明 1. 事务介绍： 1.1. 事务的定义： 事务就是指作为单个逻辑工作单元执行的一组数据操作，这些操作要么必须全部成功，要么必须全部失败，以保证数据的一致性和完整性。 1.2. 事务具有 ACID 属性： o 原子性 (Atomic)：事务由一个或多个行为绑在一起组成，好像是一个单独的工作单元。原子性确保在事务中的所有操作要么都发生，要么都不发生。 o 一致性 (Consistent)：一旦一个事务结束了(不管成功与否)，系统所处的状态和它的业务规则是一致的。即数据应当不会被破坏。 o 隔离性 (Isolated)：事务应该允许多个用户操作同一个数据，一个用户的操作不会和其他用户的操作相混淆。 o 持久性 (Durable)：一旦事务完成，事务的结果应该持久化。 事务的ACID特性是由关系数据库管理系统(RDBMS)来实现的。 o 数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。 o 数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库相同的数据时，只允许持有锁的事务能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。

1、Spring声明式事务配置的五种方式 　　前段时间对Spring的事务配置做了比较深入的研究，在此之前对Spring的事务配置虽说也配置过，但是一直没有一个清楚的认识。通过这次的学习发觉Spring的事务配置只要把思路理清，还是比较好掌握的。 　　总结如下： 　　Spring配置文件中关于事务配置总是由三个组成部分，分别是DataSource、TransactionManager和代理机制这三部分，无论哪种配置方式，一般变化的只是代理机制这部分。 　　DataSource、TransactionManager这两部分只是会根据数据访问方式有所变化，比如使用Hibernate进行数据访问时，DataSource实际为SessionFactory，TransactionManager的实现为HibernateTransactionManager。 　　具体如下图： 　　根据代理机制的不同，总结了五种Spring事务的配置方式，配置文件如下： 第一种方式：每个Bean都有一个代理 <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

本文转自： https://www.cnblogs.com/ybyebo/p/10086473.html 1. UI操作容易受到各种意外的干扰，因此应该缩短 UI操作阶段的总体时间。而为了缩短 UI操作阶段的总体时间，应该将 UI操作尽量放在一起，将后台的各种操作尽量放在 UI操作的前后。例如，现在有一个 Assign和两个 Click需要执行，那么比较推荐的设计是 Assign->Click->Click或者 Click->Click->Assign，而不是 Click->Assign->Click。集中的 UI操作也会给人一种“机器人非常高效”的观感，留下较良好的印象。 2. 为了确保“增加一倍的投入就必须相应提高一倍的效率”，流程的总体设计要尽量将问题转化为事务式（ Transactional）处理的模式。这是什么意思呢？假设现在有一份 Excel表格记录了宾客列表，机器人要读取这份列表，为每位宾客生成一份 Word请柬，然后以邮件形式发送出去。有一种流程设计思路是这样的，机器人读取宾客列表 ABC后，为 A生成请柬 ->为 B生成请柬 ->为 C生成请柬 ->向 A发送邮件 ->向 B发送邮件 ->向 C发送邮件。这种流程设计模式虽然逻辑上没有错，但是多机器人共同协作时分割工作负载相对比较困难，很难确保“增加 N倍数量的机器人可以以相应提高 N倍的处理能力”。因此

RDBMS 编辑 RDBMS即关系数据库管理系统(Relational Database Management System)，是将数据组织为相关的行和列的系统，而管理关系数据库的计算机软件就是关系数据库管理系统，常用的数据库软件有Oracle、SQL Server等。 事务管理（ACID） 谈到事务一般都是以下四点 原子性（Atomicity） 原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。 一致性（Consistency） 事务前后数据的完整性必须保持一致。 隔离性（Isolation） 事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。 持久性（Durability） 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响 CAP原则 编辑 讨论4 本词条由“科普中国”科学百科词条编写与应用工作项目 审核 。 CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 中文名 CAP原则 外文名 CAP Principle 学

原创 | 本体社区成员@币莱 原文 | https://m.lcyoufu.com/#/articleDetail?articleid=625261&inviter=dE4Y&VNK=d6a2eec7 ----------------------------------------------- 一、分片和区块链分片 1 、分片 分片是数据库分区的一种形式，也称为水平分区，即将一个大的数据库切分成很多小的、可处理的部分，从而提高性能，缩短响应时间。商业上，一个普遍的分片案例就是将用户信息的数据库按照地理位置划分，同一个区域的用户信息放在一起，存到单独的服务器中。 2、 区块链分片 区块链就相当于一个数据库，每一个节点都相当于一个独立的服务器。正常情况下，这些节点每次只有一个节点能获得记账出块的权利，剩下没获得出块权的节点相当于做了“无用功”，白白浪费了算力。 如果将分片技术运用到区块链中，就相当于将区块链网络里的所有待处理任务（比如确认交易、运行 DApp 等）进行分解，全网的节点也进行分组，每一组同时处理一个分解后的任务（比如200笔待确认交易），这样就从原先单一节点处理全网的所有任务变成了多组节点同时并行处理。 多年来，分片一直是传统数据库技术的重要组成部分，也是区块链扩容方面的焦点。数据库分片技术是将数据库分成更小、更快和更容易管理的数据分片

原文: http://blog.gqylpy.com/gqy/448 置顶：来自一名75后老程序员的武林秘籍——必读 （博主推荐） 来，先呈上武林秘籍链接： http://blog.gqylpy.com/gqy/401/ 你好，我是一名极客！一个 75 后的老工程师！ 我将花两分钟，表述清楚我让你读这段文字的目的！ 如果你看过武侠小说，你可以把这个经历理解为，你失足落入一个山洞遇到了一位垂暮的老者！而这位老者打算传你一套武功秘籍！ 没错，我就是这个老者！ 干研发 20 多年了！我也年轻过，奋斗过！我会画原理图，会画 PCB，会模拟，会数字！玩过 PLC，玩过单片机，会用汇编，会用 C！玩过 ARM，比如 PLC，STM32，和时下正在起飞的 NXP RT1052！搞过 DSP，比如 TMS320F28335！搞过 FPGA，不管 Xilinx 还是 Altera，也不管是 Verilog 还是 VHDL，或者直接画数字电路图！我懂嵌入式系统，比如 uCOS 和 Linux！我懂开源的硬件，比如 Arduino 和树莓派!我也搞软件，学了一堆上位机的语言C#，JAVA，Python，Kotlin，Swift！会写爬虫工具，又自学写APP，不管Android 还是 IOS！ 可是这一切有什么用呢？土鸡瓦狗！不值一提！干技术的永远就是最苦逼的那个人！ 我相信看到这里的你，应该是个 IT

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

本文主要记录InnoDB存储引擎中锁的关键点，下篇文章通过实例确认加锁的范围。 InnoDB中的锁 1. 锁提供数据完整性和一致性 2. InnoDB行级锁：共享锁（S）和排他锁（X）。 　　为了支持多粒度锁定，InnoDB支持意向锁，该锁允许事务在行锁和表锁同时存在。包括意向共享锁（IS）和意向排他锁（IX）。 　　意向锁将锁定的对象分为多个层次，意味着事务希望在更细粒度上进行加锁，如需要对页上的记录r加X锁，分别需要对数据库、表、页加意向锁IX，最后对记录r加X锁，其中任何一部分导致等待，该操作需要等待粗粒度锁的完成。 3. 锁的查看方式 　　 通过show engine innodb status来查看，其中的transactions片段可以看到事务，其中包括锁等待。 　　在information_schema架构下，有3个表记录了事务和锁相关的信息。分别是 INNODB_TRX,INNODB_LOCKS,INNODB_LOCK_WAITS 。（具体看书或博客） 4. 一致性非锁读 　　非锁定读机制，是InnoDB存储引擎的默认设置，默认 读取不会占用和等待表上的锁 　　InnoDB存储引擎利用 行多版本控制 实现一致性非锁读， 　　当读取的行正在加X锁DELETE或UPDATE时，读操作不会等待锁释放，会读取行的一个 快照数据 　　快照数据是指该行之前版本的数据，其通过