数据库一致性

1.使用缓存的场景 缓存是提高系统读性能的常用技术，尤其对于读多写少的应用场景，使用缓存可以极大的提高系统的性能 例子：查询用户的存款： select money from user where uid = YYY; 为了优化该查询功能，我们可以在缓存中建立uid->money的键值对。 减少数据库的查询压力。 2. 读操作流程 目前数据库和缓存中都有存储数据，当读取数据的时候，流程如下。 1）先读取缓存是否存在数据(uid->money)。如果缓存中有数据返回结果。 2）如果缓存中没有数据，则从数据库中读取数据。 介绍一个概念： 缓存命中率：缓存命中数/总缓存访问数。 3. 写操作流程 在介绍写操作流程之前，先讨论两个问题 问题一：淘汰缓存还是更新缓存？ 淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉。 更新缓存：数据不但写入数据库，还会写入缓存。 问题二：先写缓存还是先写数据库？ 由于对缓存的更新和数据库的更新无法保证事务性操作。一定涉及到哪个先做，哪个后做的问题，我们的原则是采取对业务影响小的策略。下面是四种不同的组合策略 由此可见第四种策略的影响最小，只会造成一次查询缓存miss而已。那么当查询缓存miss的时候，我们该怎么办？很简单，查询数据库，然后将数据库的内容更新到缓存中。可能有人会问第四种策略，如果一上来淘汰缓存就失败了怎么办，当然是直接返回即可

一、缓存更新 场景介绍 缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。 例如对于用户的余额信息表account(uid, money)，业务上的需求是： （1）查询用户的余额，SELECT money FROM account WHERE uid=XXX，占99%的请求 （2）更改用户余额，UPDATE account SET money=XXX WHERE uid=XXX，占1%的请求 由于大部分的请求是查询，我们在缓存中建立uid到money的键值对，能够极大降低数据库的压力。 读操作流程 有了数据库和缓存两个地方存放数据之后（uid->money），每当需要读取相关数据时（money），操作流程一般是这样的： （1）读取缓存中是否有相关数据，uid->money （2）如果缓存中有相关数据money，则返回【这就是所谓的 数据命中 “hit”】 （3）如果缓存中没有相关数据money，则从数据库读取相关数据money【这就是所谓的 数据未命中 “miss”】，放入缓存中uid->money，再返回 缓存的命中率 = 命中缓存请求个数/总缓存访问请求个数 = hit/(hit+miss) 上面举例的余额场景，99%的读，1%的写，这个缓存的命中率是非常高的，会在95%以上。 问题 当数据money发生变化的时候： （1

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）。数据更新的消息是通过一台中心的MQ进行转发。 先把问题简单化处理，假设A增加一条记录Message_A，发送到M，B增加一条记录 MESSAGE_B发送到M，都是通过MQ服务器进行转发，那么M系统接收到条消息，增加两条数据，那么M在把增加的消息群发给A，B，A和B找到自己缺失的数据，更新数据库。这样就完成了一个数据的同步。 从正常情况下来看，都没有问题，逻辑完全合理，但是请考虑以下三个问题 1 如何保证A->M的消息，M一定接收到了，同样，如何保证M->A的消息，M一定接收到了 2 如果数据需要一致性更新，比如A发送了三条消息给M，M要么全部保存，要么全部不保存，不能够只保存其中的几条记录。我们假设更新的数据是一条条发送的。 3 假设同时A发送了多条更新请求，如何保证顺序性要求？ 这两个问题就是分布式环境下数据一致性的问题 对于第一个问题，比较好解决，我们先看看一个tcp/ip协议链接建立的过程 我们的思路可以从这个上面出发，在简化一下，就一个请求，一个应答。 简单的通信模型是这样的 A

摘要： 前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总... 前言 目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。 基础理论相关 说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。 ACID 特性 A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行； C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确； I（隔离性

分布式CAP理论 来自wiki: 在 理论计算机科学 中， CAP定理 （CAP theorem），又被称作 布鲁尔定理 （Brewer's theorem），它指出对于一个 分布式计算系统 来说，不可能同时满足以下三点：[ 1] [ 2] 一致性（ C onsistency） （等同于所有节点访问同一份最新的数据副本） 可用性 （ A vailability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据） 分区容错性 （ P artition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[ 3] 。） 根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[ 4] 。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。 来自 : 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后

Mysql隔离性之一致性非锁定读 一致性非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过多版本控制（MVCC）读取当前数据库中行数据的方式。如果读取的行是正在执行delete or update操作，这时读取操作不会因此去等待行上锁的释放。相反地，InnoDB会去读取行的一个快照版本。 如上图所示：当会话B提交事务之后，会话A会再次运行SELECT * FROM TEST WHERE ID = 1的SQL语句时，两个事务在隔离级别RR下得到的结果不一致。 MVCC在mysql中的实现是依赖于undo log和read view。 欲知后事（Undo Log保证MVCC原理详解），请点击这里喔！ 来源： https://blog.csdn.net/longgeqiaojie304/article/details/98872139

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在这几年越来越火的微服务架构中，几乎可以说是无法避免。 本篇文章将通过详解分布式事务的一致性，以及分布式事务实战解决方案，帮助大家搞懂分布式事务，推荐收藏。 01 为什么需要分布式事务 由于近十年互联网的发展非常迅速，很多网站的访问越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分(包含：垂直拆分与水平拆分)，以及按照业务为单位提供服务，从早期的集中式转变为面向服务架构的分布式应用环境。 举一个典型的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。 这个时候 为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要在同一个事务中完，这就涉及到到了分布式事务。 本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。 02 分布式的一致性理论 最早加州大学伯克利分校 Eric Brewer教授提出一个分布式系统特性的CAP理论。 1.CAP 理论的不可能三角 一致性（Consistency） 可用性（Availability） 分区容错性（Partition tolerance） 在分布式系统中