数据库一致性

特点 原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability) 一、事务的目的 1、可靠性和并发处理 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 二、实现事务功能的三个技术 1、日志文件(redo log 和 undo log) 2、锁技术 3、MVCC 1.1 redo log 与 undo log介绍 1.1.1redo log 什么是redo log ? redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。 当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi） start transaction; select

原文: 分布式事务,EventBus 解决方案:CAP【中文文档】 最新文档地址： https://github.com/dotnetcore/CAP/wiki 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解，所以花了将近两周时间写了这份中文的CAP文档，对 CAP 还不知道的同学可以先看一下 这篇文章 。 本文档为 CAP 文献（Wiki），本文献同时提供中文和英文版本，英文版本目前还在翻译中，会放到Github Wiki 中。 目录 前言 1、Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick Start 2、API接口 2.1 发布/发送 2.1.1 事务 2.2 订阅/消费 2.2.1 例外情况 3、配置 3.1 Cap Options 3.2 RabbitMQ Options 3.3 Kafka Options 3.4 SqlServer Options 3.5 MySql Options 4、设计原理 4.1 动机 4.2 持久化 4.3 通讯数据流 4.4 一致性 5、实现 5.1 消息表 5.2 消息格式 5.3 EventBus 5.4 重试 6、分布式事务 6.1 异步确保 7、FAQ 1、Getting Started 1.1 介绍 CAP 是一个遵循 .NET Standard 标准库的C#库

问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如

分布式系统当中有一个著名的 CAP 理论，它也是分布式系统理论的基础。 CAP理论最早发表于2000年，由加州伯克利的教授首先在ACM PODC会议上提出猜想，两年之后，被麻省理工学院的教授Seth Gilbert和Nancy Lynch从理论上证明。从此之后，它成了分布式系统领域的公认定理。 今天这篇文章就和大家聊聊这个大名鼎鼎的CAP理论。 CAP理论描述起来其实很简单，它说的是 一个分布式系统最多只能满足C（一致性）、A（可用性）和P（分区性）这三者当中的两个 。我们先来看一下这三项分别代表了什么。 Consistency 一致性 分布式系统当中的一致性指的是 所有节点的数据一致 ，或者说是 所有副本的数据一致 。用英文描述是： All the nodes see the same data at the same time 。它和数据库事务中的一致性是两码事，在我们之前的文章里，曾经详细描述过分布式系统中的各种一致性模型，感兴趣的同学可以点击这里。 我们可以将一致性一分为二，分别从 客户端和服务端 进行探究。对于客户端而言，并不关心后端的实现，也不关心后端的节点运行情况。唯一只关心 多次并发访问下都能获得准确的符合预期的结果 。比如用户多次点击付款，也只会付款一次，余额无论什么时候查询都是当下最新的值。 而服务端关心的是会引发数据变更的请求过来，

分布式场景下，缓存与数据库的一致性是必须要绕过去的一道坎。而强一致性同步成本太高，如果追求强一致，那么没必要用缓存了，直接用mysql即可。通常考虑的，都是最终一致性。我们要做的，就是把这个最终一致性的时间降到最低。 从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。 方案一：先同步数据库，再删除缓存。 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。 命中：应用程序从cache中取数据，取到后返回。 更新：先把数据存到数据库中，成功后，再让缓存失效。 看看更新操作有没有问题。 如果数据库同步成功，缓存操作失败，则让事务回滚，最终还是一致的。 如果数据库同步失败， 缓存也不会再被操作，数据是一致的。 方案二：监听binlog日志 监听binlog日志，当监听到的数据变化时，让缓存失效或更新。 实现方法：业务服务，同步数据完成后，删除缓存。定义好缓存类与数据库表的映射关系，并定义为缓存同步类型，当监听到某一表变化时，调用该同步类型对应的实现类，把数据同步到redis中。 监听biglog的工具： （1）mysql

本文转载自《金融电子化》 作者： 吉林省农村信用社联合社信息科技中心 总经理 孙刚、总经理助理 程永义 随着移动互联网的迅猛发展，分布式架构在互联网IT技术领域广泛应用并积累了大量实践经验。在互联网金融快速发展和利率市场化的大环境下，建设能够支持海量客户、具有弹性扩展能力、高效灵活的分布式架构应用系统已成为国内金融行业迫切的需要。 分布式数据库应用大势所趋 我社普惠金融平台建设，旨在“充分运用金融科技手段，优化信贷流程和客户评价模型，降低企业融资成本，纾解民营企业、小微企业融资难融资贵问题，增强金融服务实体经济能力”。 普惠金融服务是典型的互联网应用，其与传统信贷系统不同，具有互联网场景接入能力，如果沿用集中式的技术架构，在应对海量客户的互联网应用场景和总拥有成本等方面存在以下的潜在问题： 集中式架构普遍缺乏弹性伸缩的能力。随着交易量和数据量的增长，系统整体吞吐量会遇到硬件或技术的瓶颈。尤其在支持面向互联网客户相关业务时，不能有效处理瞬时爆发的高并发交易，制约了客户获取以及大规模业务营销。 集中式架构采用单体应用设计。软件开发和运行管理的最小单元是应用，管理力度较粗，容易“牵一发而动全身”，应用的开发过程不易践行轻量化敏捷开发理念，系统在运行过程中容易出现单点故障，难以有效进行故障隔离。 集中式架构系统的基础设施通常使用高端服务器和存储设备，以及传统关系型数据库

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文转载自《金融电子化》 作者： 吉林省农村信用社联合社信息科技中心 总经理 孙刚、总经理助理 程永义 随着移动互联网的迅猛发展，分布式架构在互联网IT技术领域广泛应用并积累了大量实践经验。在互联网金融快速发展和利率市场化的大环境下，建设能够支持海量客户、具有弹性扩展能力、高效灵活的分布式架构应用系统已成为国内金融行业迫切的需要。 分布式数据库应用大势所趋 我社普惠金融平台建设，旨在“充分运用金融科技手段，优化信贷流程和客户评价模型，降低企业融资成本，纾解民营企业、小微企业融资难融资贵问题，增强金融服务实体经济能力”。 普惠金融服务是典型的互联网应用，其与传统信贷系统不同，具有互联网场景接入能力，如果沿用集中式的技术架构，在应对海量客户的互联网应用场景和总拥有成本等方面存在以下的潜在问题： 集中式架构普遍缺乏弹性伸缩的能力。随着交易量和数据量的增长，系统整体吞吐量会遇到硬件或技术的瓶颈。尤其在支持面向互联网客户相关业务时，不能有效处理瞬时爆发的高并发交易，制约了客户获取以及大规模业务营销。 集中式架构采用单体应用设计。软件开发和运行管理的最小单元是应用，管理力度较粗，容易“牵一发而动全身”，应用的开发过程不易践行轻量化敏捷开发理念，系统在运行过程中容易出现单点故障，难以有效进行故障隔离。

NoSQL简史及定义 NoSQL 这个术语最早是在 1998 年被 Carlo Strozzi 命名在他的轻量的，开源的关系型数据库上的，但是该数据库没有提供标准的 SQL 接口； 在 2009 年再次被 Eric Evans 提起，讨论分布式开源数据库的问题，这是的 NoSQL 主要指的非关系型，分布式的，不提供关系型的 atomicity(A) ， consistency(C) ， isolation(I) ， durability(D) 即 ACID 的特性； 紧接着 2009 年在亚特兰大举行的 no:sql 讨论会是一个里程碑，当时的口号是 select fun, profit from real_world where relational=false ，因此之后对于 NoSQL 最普遍的解释为 非关系型的 ，强调 Key-Value 和 Document(文档) 数据库的优点，并非单纯的反对关系型数据库； 下面给 NoSQL 下一个定义，如果你在网上查阅资料会得到很多种定义，大家的理解不尽相同，我这里引用 http://nosql-database.org/ 网站上的定义： 下一代，主要解决以下几点：非关系数据库、分布式数据库、开源数据库和水平扩展数据库 原文信息：Next Generation Databases mostly addressing some of

原文作者：VectorJin https://juejin.im/post/5e066c9ff265da33b0718f89 1. 本地事务 　　事务Transaction由一组SQL组成，具有四个ACID特性 1.1 ACID Atomicity 原子性 构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况 Consistency 一致性 数据库经过事务操作后从一种状态转变为另一个状态。可以说原子性是从行为上描述，而一致性是从结果上描述 isolation 隔离性 事务操作的数据对象 相对于 其他事务操作的数据对象相互隔离，互不影响 durability 持久性 事务提交后，其结果就是永久性的，即使发生宕机（非磁盘损坏） 1.2 事务实现 　　对于MySQL数据库（InnoDB存储引擎）而言，隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性通过redo log 重做日志和undo log回滚日志来保证的。 　　 redo log： 当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启

前置知识 事务: 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任意一个执行失败，将导致整个事务的回滚。简单来说就是提供一种”要么什么都不做，要不全都做“的机制。 本地事务: 当事务是由资源管理器本地管理时被称为本地事务。本地事务的有点是支持严格的 ACID 特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。MySql 的 InnoDB 通过日志（Redo 和 Undo）和锁来保证事务。 全局事务: 当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局事务状态和参与的资源，协同资源的一直提交回滚。 刚性事务和柔性事务 刚性事务：遵循 ACID 原则，强一致性，典型的例子就是数据库事务。 柔性事务：尊循 BASE 理论，最终一致性，允许在一定时间内，不同节点的数据不一致，但要求最终一致性。 分布式知识 CAP 分布式系统在设计时只能在一致性，可用性和分区容错性中满足两种，无法兼顾三种。 C： 在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的要求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。 A：