分布式mysql一致性问题_分布式事务和数据库与缓存的一致性问题

一.什么是分布式事务：如果一个事务调用了不同服务器上的操作，那么它就成为了一个分布式事务。

二.分布式理论

CAP定理：一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)

可用性(Availability)： 每个操作都必须以可预期的响应结束

分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成

具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。

在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？ 前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。

BASE理论：Basically Available(基本可用)

Soft state(软状态)

Eventually consistent(最终一致性)

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)。

三.分布式事务的解决方案

3.1.两阶段提交协议(two-phase commit protocol)

两阶段提交协议(two-phase commit protocol)的设计出发点是允许任何一个参与者自行放弃它自己的那部分事务。由于事务原子性的要求，如果部分事务被放弃，那么整个分布式事务也必须被放弃。在该协议的第一个阶段，每个参与者投票表决该事务是放弃还是提交，一旦参与者要求提交事务，那么就不允许放弃该事务。因此，在一个参与者要求提交事务之前，它必须保证最终能够执行分布式事务中自己的那部分，即使该参与者出现故障而被中途替换掉。

3.2.使用消息队列

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

但是使用消息队列就需要解决两个问题：1.保证消息的百分百投递，就可以出现多次投递。

2.消费方消费的时候需要多次消费，这是就需要对调用的消息做幂等。保证只执行一个相同的操作。使系统达到最终一致性。

四、分布式之数据库和缓存双写一致性方案解析1.没有读写分离就直接删除就行了

2.采用了读写分离，建议使用延迟删除来保证一致性

(1)先淘汰缓存

(2)再写数据库(这两步和原来一样)

(3)休眠1秒，再次淘汰缓存

3.采用这种同步淘汰策略，吞吐量降低怎么办？

首先，给缓存设有效时间是一种方案。其次将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。

五、分布式之数据库和缓存删除失败的解决方案

有两种解决方案：

方案一：

(0)删除缓存。

(1)更新数据库数据；

(2)缓存因为种种问题删除失败

(3)将需要删除的key发送至消息队列

(4)自己消费消息，获得需要删除的key

(5)继续重试删除操作，直到成功

然而，该方案有一个缺点，对业务线代码造成大量的侵入。

方案二：

(0)删除缓存。

(1)更新数据库数据

(2)数据库会将操作信息写入binlog日志当中

(3)订阅程序提取出所需要的数据以及key

(4)另起一段非业务代码，获得该信息

(5)尝试删除缓存操作，发现删除失败

(6)将这些信息发送至消息队列

(7)重新从消息队列中获得该数据，重试操作。

× 请我吃糖~