彻底解决分布式系统一致性问题整理(下)

举报
赵KK日常技术记录 发表于 2023/06/24 13:58:05 2023/06/24
【摘要】 首先本章内容参考《分布式服务架构》整理,思考和总结纯个人理解。其实个人理解的时候,更希望能够得到代码层面的实现,单纯的理论知识还是不够落地,总结容易,真正实现起来还是需要项目的积累。保证最终一致性的模式1.查询模式任何服务操作都需要提供一个查询接口,用来向外输出操作执行的状态。即:单笔查询,为了使查询操作有一个唯一标识,需要一个分布式环境下的ID,可用分布式锁,redis 递增,机器的唯一码...

首先本章内容参考《分布式服务架构》整理,思考和总结纯个人理解。

其实个人理解的时候,更希望能够得到代码层面的实现,单纯的理论知识还是不够落地,总结容易,真正实现起来还是需要项目的积累。

保证最终一致性的模式

1.查询模式

任何服务操作都需要提供一个查询接口,用来向外输出操作执行的状态。即:单笔查询,为了使查询操作有一个唯一标识,需要一个分布式环境下的ID,可用分布式锁,redis 递增,机器的唯一码 拿出几位存为机器id,这样一来每次查询操作相对更快。可解决同步调用超时问题异步回调超时问题。

2.补偿模式

再操作失败,我们需要修正有问题的操作,是分布式系统达到一致,为了让系统达到一致而做出的努力都叫做补偿操作。这个场景就和出水问题一样啊!!!补偿操作分为:自动回复,通知运营,和技巧运营。

3.异步确保模式

再对响应时间要求不高的场景,通过异步的方式处理,再把结果告知使用方,这个方案最大的好处就是能对高并发流量进行消峰,例如电商中的物流,配送,支付系统的计费,入账。

4.定期校对模

再操作主流系统间执行校对操作,再时候异步批量校对操作的状态,如果不一直进行补偿,这句话有点不太理解,定期校对系统如图

请在此添加图片描述

定期校对系统多用于金融系统,针对于数据的准确性。

5.可靠消息模式

利用消息队列实现异步化

①消息的可靠发送

发送消息之前先将消息持久化到数据库,将状态标记为未发送,然后发送消息,如果发送成功,则标记,定时从数据库捞取一定时间内未发送的消息并发送。

②消息处理器的幂等性

幂等性,幂等性,面试和刷题你总会遇到,要想解决,就得先知道啥叫幂等性。

在网络延迟传输中,会造成消息队列重试,在充实过程中,消息会存在重复

解决方案:

1.如果是数据库的插入操作,给消息做一个主键,避免出现脏数据。

2.使用第三方做消费记录,例如Redis,全局id为K,消息为V,写入到Redis,消费之前先去查Redis是否存在

3.使用数据库的行级锁

6.缓存一致性模式

如果面对亿级读需求,需要非关系型数据库抗住流量,这里有个问题?啥叫关系型数据库?(能够互相连接的列表式数据库)

读的顺序是先读缓存,读不到再读数据库,写的顺序是先写数据库,后写缓存。

超时处理模式

1微服务的交互模式

①同步调用模式

服务1调用服务2,服务1等待服务2返回结果

②异步调用模式

服务1调用服务2,服务2处理后,反向通知服务2

③消息队列异步处理模式

服务1传递给服务2,不需要关心返回结果

①同步调用模式解决方案

两状态

请在此添加图片描述

请在此添加图片描述

三状态

请在此添加图片描述

②异步调用模式解决方案

请在此添加图片描述

③消息队列异步处理模式解决方案

请在此添加图片描述

文章对服务化系统中同步调用,异步调用,消息队列等应用场景进行了分析,个人理解还是不到位,还有一些疑问,例如什么时候会导致消息重发?消息重发仍然失败怎么办?失败次数超过预期怎么办?还有就是怎么样从代码层面实现,这些在面试中都太笼统了,根本解决不了实际问题,还是要从实际场景解决问题,文章也是给出一个解决思路。另外,有个有意思的事就是,总有公司问你亿级系统如何处理,举了一大堆例子,辩论半天,后来你发现这公司用户还没你朋友圈集赞点赞人数多,这种事常见,为未来做打算不是不对,还是先保证能用,再保证高可用吧。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。