hjr-微服务（七）：如何保障数据一致性和高可用的平衡

CAP

告诉我们
在一个分布式系统中
一致性（Consistency）：多个数据副本的数据保持一致，如果花费很多时间在数据同步上，会导致查询无法立刻返回最新数据，因为没同步完成呢

可用性（Availability）：利用分布式事务，每次写操作或者全部成功或者全部失败，用户访问服务器上面的数据，响应时间在可以接受的范围内，如果想要快速返回数据就不能在数据同步上花费太多时间

分区容错性（Partition tolerance）：分区指，分布式系统节点通信故障了，两个故障的节点就是两个分区，把数据同步复制到多个分区。可以解决分区容错性但是会带来一致性问题

为什么最多只能实现两个

因为C和A是互相冲突的，因此只能保障一个，因此一般分布式系统或者是CP或者是AP（Eureka）

那有人会问 为啥不是CA？，因为CA相当于不是分布式系统了，只有一个节点，当然又快有准又不需要多节点同步数据

数据一致性如何保障

强一致性

数据一致性是多个节点之间做数据同步会产生的问题

数据可能出现的问题有两个

一个是准确性：

解决方案：定时统计多节点数据数目，比如消费和上报数目，比较核对

一个是数据重复：

解决方案：通过缓存空间记录消费的数据编码，重复数据检测

弱一致性

通过如Kafka消息队列异步处置

可用性

分布式锁：Redis和Mysql加锁

分布式事务：事务消息表

保障数据不被篡改

数据传输之前使用不可逆加密算法对摘要加密（签名），同时把数据与 摘要加密部分发送过去，接收方用同样的算法对摘要验签，证明数据没被篡改

分布式锁：

是服务做集群时（集群：单个服务多实例部署），可以解决把从不同服务进来的同一请求线程串行话;

分布式事务：

多个微服务之间相互调用时，一个请求涉及多个服务之间的数据新增或变化，要么都成功、要么失败都回滚；

分布式锁推荐使用redission

分布式事务推荐使用阿里的seata