微服务——一致性问题

微服务架构是一把双刃剑，我们在享受微服务对单体系统拆分后的红利的同时，也会遇到数据模型和服务之间不一致的问题。在微服务架构下多个服务通过非可靠的网络进行通信，如何让服务之间高效的通信和协作，如果保证系统之间状态的一致，都是我们需要解决的问题。
PS:本文只介绍原理，不提供具体实现，如需具体实现请询问度娘！哈哈哈哈哈！
1.ACID原则
2.CAP原则
3.BASE原则
4.分布式一致性协议
4.1.两段式提交协议
4.2.三段式提交协议
4.3.TCC
5.保证最终一致性的模式
5.1.查询模式
5.2.补偿模式
5.3.异步确保模式
5.4.定时校对模式
6.消息的幂等性处理
7.如何保证缓存一致性

ACID原则

A：Atomicity，原子性。
C：Consistency，一致性。
I：Isolation，隔离性。
D：Durability，持久性。
这个没啥讲的了，数据库基础了。
PS：NoSql完全不适合交易场景，主要用来做数据分析、报表、数据挖掘、推荐、日志处理、调用链跟踪等非核心交易场景。

CAP原则

C：Consistency，一致性。
A：Availability，可用性，较高的响应性能。
P：Partition tolerance，分区容忍性。即使网络上有部分消息丢失，但系统仍然可继续工作。

BASE原则

BA：Basically Available，基本可用。
S：Soft State，软状态，状态可以在一段时间内不同步。
E：Eventually Consistent，最终一致，在一定的时间窗口内，最终数据达成一致即可。
多数业务系统还是使用数据库记录的字段来记录任务的执行状态。

分布式一致性协议

两段式提交协议

准备阶段：锁定资源，执行操作，但是并不提交。
提交阶段：如果每个参与者明确返回准备成功，则协调者向参与者发起提交指令。

三段式提交协议

三段式提交协议是两阶段提交协议的改进版本。
询问阶段：协调者询问参与者是否可以完成指令。
准备阶段：如果在询问阶段所有参与者都返回可以执行操作，则协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作但是不提交操作。
提交阶段：如果参与者在尊卑阶段返回准备成功，也就是说预留资源和执行操作成功，则协调者向参与者发起提交指令。

TCC

TCC协议将一个任务拆分成Try，Confirm，Cancel三个步骤。

保证最终一致性的模式

现实系统的底线是仅仅需要达到最终一致性。

查询模式

任何服务操作都需要提供一个查询接口，用来向外部输出操作执行的状态。
为了能够实现查询，每个服务操作都需要有唯一的流水号标识。

补偿模式

如果每个操作都处于不正常的状态，则我们需要修正操作中有问题的子操作，这可能需要重新执行未完成的子操作，后者取消已经完成的子操作，通过修复使整个分布式系统达成一致。为了让系统最终达成一致状态而做的努力都叫补偿。

异步确保模式

异步确保模式是补偿模式的一个典型案例，经常应用到使用方对响应时间要求不太高的场景中，通常把这里操作从主流程中摘除，通过异步的方式进行处理，处理后把结果通过通知系统通知给使用方。
在实践中，通常通过定时捞取未完成的任务进行补偿操作来实现异步确保模式，只要定时系统足够鲁棒，则任何任务最终都会被成功执行。

定时校对模式

在操作主流程中的系统间执行校对操作，可以在时候异步的批量校对操作的状态。如果发现不一致的操作，则进行补偿。

消息的幂等性处理

因为网络环境的不可控，幂等性问题是不可避免的。例如：发送一次请求，因为网络异常报了超时，但是后台却已经执行成功。调用方收到超时提醒，重新发送了请求。这个时候就会有两条一模一样的记录，如果是金融行业，就可能会造成损失。
保证操作的幂等性的常用方法如下：
1.使用数据库表的唯一主键进行滤重，拒绝重复的请求。
2.使用分布式表对请求进行过滤。
3.使用状态流转的方向性来滤重，通常使用数据库的行级锁来实现。
4.根据业务的特点，操作本身就是幂等的，例如：删除一个资源，增加一个资源，获得一个资源等。

如何保证缓存一致性

在大规模、高并发系统中的一个常见的核心需求就是亿级的读需求，互联网的经典做法就是使用缓存来抗住读流量。
1.如果性能要求不是非常高，则尽量使用分布式缓存，而不是使用本地缓存。
2.写缓存时一定要完整，不能一部分有效，一部分无效。
3.使用缓存牺牲了一致性，为了提高性能，数据库与缓存只需要保持弱一致性。
4.读的顺序是先读缓存，后读数据库。写的顺序要先写数据库，后写缓存。