数据库一致性

“ 不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。 又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。 有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)， 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。 C：一致性(Consistency)， 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。 如果事务成功地完成

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

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。 相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤： 从 A 账户取 100 元。

from:https://blog.csdn.net/alex_xfboy/article/details/77335982 领域驱动设计（DDD）是一种奇妙的技术，试图使我们的设计更接近于业务领域 。我们采用了领域驱动的开发方式，使用了充血模型，享受了他的好处，但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务一致性的问题在Monolithic下面不是大问题，在微服务下面却是很致命，我们回顾一下所谓的ACID原则 Atomicity - 原子性，改变数据状态要么是一起完成，要么一起失败 Consistency - 一致性，数据的状态是完整一致的 Isolation - 隔离线，即使有并发事务，互相之间也不影响 Durability - 持久性， 一旦事务提交，不可撤销 在单体服务和关系型数据库的时候，我们很容易通过数据库的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服务架构，他们的数据库就已经分离开了，你就要独立面对分布式事务，要在自己的代码里面满足ACID。 对于分布式事务，大家一般会想到以前的JTA标准，2PC两段式提交。我记得当年在Dubbo群里面，基本每周都会有人询问Dubbo啥时候支撑分布式事务。实际上根据分布式系统中CAP原则，当P(分区容忍)发生的时候，强行追求C（一致性），会导致（A）可用性、吞吐量下降

目前主流的MQ产品 1.ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。 扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。 2.RabbitMQ 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。 性能较好，但是不利于做二次开发和维护。 3.ActiveMQ 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好。 4.Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。 测试数据分为 128Bytes、512Bytes、1K和10K四个不同大小的数据。 实验表明：入队时

1.Cache引起的数据一致性问题 　　主要原因是位于数据IO路径上的各种Cache和Buffer（包括数据块Cache，文件系统的Cache，存储控制器的Cache，磁盘Cache等），由于不同系统模块操作处理数据IO的速度有差异，所以就需要添加Cache来缓存IO操作，适配不同模块的处理速度。这些Cache在提高系统处理性能的同时，也可能会‘滞留’IO操作，带来一些负面影响。如果在系统发生故障时，仍有部分IO‘滞留’在IO操作中，真正写到磁盘中的数据就会少于应用程序实际写出的数据，造成的数据不一致。当系统恢复时，直接从硬盘中读出的数据可能存在逻辑错误，导致应用无法启动。尽管一些数据库（Oracle，DB2）可以根据redo日志重新生成数据，修复逻辑错误，单着过程是非常耗时的，而且也不一定每次都能成功。对于一些相对功能较弱的数据库（SQL Server），这个问题就更加严重了。 　　解决办法 　　关闭Cache或者创建快照。尽管关闭Cache会导致系统系统性能下降，但在有些应用中，这却是必要的选择 。比如一些高等级的容灾方案中（ RPO 为 0 ），都是利用同步镜像技术在生产中心和灾备中心之间实时同步复制数据。由于数据是实时复制的，所以就必须要关闭 Cache 。 　　快照的目的是为数据卷创建一个在特定时间点的状态视图，通过这个视图只可以看到数据卷在创建时刻的数据

目前主流的MQ产品 1.ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。 扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。 2.RabbitMQ 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。 性能较好，但是不利于做二次开发和维护。 3.ActiveMQ 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好。 4.Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。 测试数据分为 128Bytes、512Bytes、1K和10K四个不同大小的数据。 实验表明：入队时

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 知识脑图： 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性，ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用

一致性是指数据处于一种语义上的有意义且正确的状态。一致性是对数据可见性的约束，保证在一个事务中的多次操作的数据中间状态对其他事务不可见的。因为这些中间状态，是一个过渡状态，与事务的开始状态和事务的结束状态是不一致的。 　　举个粒子，张三给李四转账100元。事务要做的是从张三账户上减掉100元，李四账户上加上100元。一致性的含义是其他事务要么看到张三还没有给李四转账的状态，要么张三已经成功转账给李四的状态，而对于张三少了100元，李四还没加上100元这个中间状态是不可见的。 　　那么反驳的声音来了： 　　要么转账操作全部成功，要么全部失败，这是原子性。从例子上看全部成功，那么一致性就是原子性的一部分咯，为什么还要单独说一致性和原子性？ 　　你说的不对。在未提交读的隔离级别下是事务内部操作是可见的，明显违背了一致性，怎么解释？ 　　好吧，需要注意的是： 原子性和一致性的的侧重点不同： 原子性关注状态，要么全部成功，要么全部失败，不存在部分成功的状态。 而 一致性关注数据的可见性，中间状态的数据对外部不可见，只有最初状态和最终状态的数据对外可见 　　隔离性是多个事物的时候, 相互不能干扰，一致性是要保证操作前和操作后数据或者数据结构的一致性，而我提到的事务的一致性是 关注 数据的中间状态，也就是一致性需要监视中间状态的数据，如果有变化，即刻回滚 (一系列操作后

分布式基础知识 https://www.cnblogs.com/zhang-qc/p/8687663.html 参考 https://github.com/CyC2018/Interview-Notebook/blob/master/notes/ 基本概念 （1）异常： 1. 服务器宕机 　　内存错误、服务器停电等都会导致服务器宕机，此时节点无法正常工作，称为不可用。 　　服务器宕机会导致节点失去所有内存信息，因此需要将内存信息保存到持久化介质上。 2. 网络异常 　　有一种特殊的网络异常称为 网络分区 ，即集群的所有节点被划分为多个区域，每个区域内部可以通信，但是区域之间无法通信。 3. 磁盘故障 　　磁盘故障是一种发生概率很高的异常。 　　使用冗余机制，将数据存储到多台服务器。 （2）超时： 　　可以将服务器的操作设计为具有 幂等性 ，即执行多次的结果与执行一次的结果相同。如果使用这种方式，当出现超时的时候，可以不断地重新请求直到成功。 （3）衡量指标 1. 性能 　　常见的性能指标有：吞吐量、响应时间。这两个指标往往是矛盾的，追求高吞吐的系统，往往很难做到低响应时间。 　　高吞吐意味并发系统，高并发提高 CPU 资源的利用率，但是请求不能马上被处理，需要和其它请求一起进行并发处理，响应时间增高。 2. 可用性：指系统在面对各种异常时可以提供正常服务的能力 3. 一致性