分布式系统常见问题

这篇具有很好参考价值的文章主要介绍了分布式系统常见问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一.概述

分布式系统存在网络,时钟,以及许多不可预测的故障。分布式事务,一致性与共识问题,迄今为止仍没有得到很好的解决方案。要想完美地解决分布式系统中的问题不太可能,但是实践中应对特定问题仍有许多可靠的解决方案。本文不会谈及诸如BASE, CAP, ACID 等空泛的理论,只基于实践中遇到的问题提出可行的解决方案。

二.常见问题

1.读自己的写

现象: 用户在发布页发布了帖子,然后访问自己的主页查看帖子列表,并没有马上看到自己刚刚发布的帖子,等待1~2s后才看到

分析:后端db采取主从结构,复制任务在负载较高的情况下会有延迟。用户读取帖子列表查询的是从节点,所以无法及时看到刚刚发布的帖子。一般情况下延迟1~2s是可以接受的,但是为了更好的体验,可以做一些改进。

分布式系统常见问题

解决方案:

  • 如果用户读取的是自己的主页,就访问主节点。如果访问是他人的主页,就访问从节点。只需要在db层路由即可。
  • 客户端还可以记住最近更新时的时间戳,并附带在读请求中,据此信息,系统可以确保对该用户提供读服务时都应该至少包含了该时间戳的更新。如果不够新,要么交由另一个副本来处理,要么等待直到副本接收到了最近的更新

2.单调读

现象:用户查看某个帖子下面的评论,一会儿看到5条评论,一会儿看到6条评论。

分析:后端db采取主从结构,复制任务在负载较高的情况下会有延迟。用户读取评论列表查询的是从节点,但是两次读的是不同的从节点,当某个从节点具有明显延迟就会出现数据反复的现象。

分布式系统常见问题

解决方案:

  • 确保同一个用户每次都是读取同一个副本,可以在db层进行路由。这是一种典型的sticky 请求路由。

    replica = hash(user_id) % number_of_replica

3.负载倾斜与热点问题

现象:某个分区的数据明显比其他分区多,并且访问频率高,负载压力大。

分析:在某些特殊的业务场景下,比如官方或者名人账号有百万粉丝,当这些账号发布消息事件时,人们会对该消息进行评论,如果评论数据存储使用事件id进行hash,就会造成某个分区的负载产生倾斜。

解决:

  •   在关键词,比如消息事件id,的开头或者结尾添加一个随机数。只需一个两位数的十进制随机数就可以将关键字的写做操作分布到100个不同的关键字上,从而分片到不同的分区上。这些特殊逻辑只应用在一些特殊账号上。

4.fencing令牌

现象:在采用分布式锁的情况下,数据库中的事务重复执行。

分析:在分布式锁环境中,客户端A执行事务超时,分布式锁被释放。客户端B执行事务插入数据。客户端A恢复后继续执行事务,重复插入数据。

分布式系统常见问题

解决方案:

  • 这不是分布式事务的范畴。可以采用fencing令牌来解决。我们假设每次锁服务授予锁或租约时,同时还会返回一个fencing令牌,该令牌每授予一次就会递增。然后,要求客户端每次向存储系统发生写请求时,都必须包含所持有的fencing令牌。当使用zookeeper 作为锁服务时,可以用事务标识zxid,或节点版本cversion来充当fencing令牌,这两个都可以满足单调递增的要求。

分布式系统常见问题

5.Lamport时间戳

现象:客户端从两个分区获取两条不同的数据,比如事件a, b;a的序号小于b,但事实上b比a先发生。

分析:常见的有以下几种非因果序列发生器,产生的序列号与因果关系并不严格一致。

  • 每个节点单独产生自己的一组序列号。
  • 把墙上时间戳信息(物理时钟)附加在每个操作上。
  • 预先分配好序列号的区间范围,比如节点A负责区间1~1000的序列号,节点B负责1001~2000。

解决方案:

  • 使用Lamport时间戳。Lamport时间戳是一个kv对(计数器,节点ID)。核心流程:每个节点以及每个客户端都跟踪迄今为止所见到的最大计数器,并在每个请求中附带该最大计数器值。当节点收到请求(或者回复)时,如果发现请求内嵌的最大计数器大于节点自身的计数器,则它立即把自己的计数器修改为该最大值。

  分布式系统常见问题  

6.端到端的重复消除问题

现象:消息重复是非常普遍的,比如

  • 生产者发送消息到消费者,消费者消费成功后宕机,但是却没有更新消费位置,消费者重启后就会重新消费。
  • 常见的rpc调用,调用方因为网络问题没有收到被调用方的响应,选择重试。
  • 2PC 分布式事务中,因为网络问题,也可能出现重复事务的问题。
  • 用户在页面重复提交POST请求。

分析:端到端的重复问题是非常普遍的,在TCP 网络中也需要处理重复数据包的问题。有以下两种解决办法:

  • 最有效的办法之一是使操作满足幂等性,即无论执行一次还是多次,确保具有相同的结果。比如以下语句无论执行多少次效果都是一致的。

   update table set v = v2 where v = v1

  • 可以为操作生成一个唯一的标识符如(UUID),服务端对此UUID 进行去重校验。

  分布式系统常见问题

  • 在典型的电商下单接口中采用了以上两种方法的结合:使用唯一标识符来进行去重,如果写入异常返回之前的订单。
create table order(
  # ...
  dedup_key varchar(60) not null comment 'key to pretend order duplication',
  client_id,
  # ...
  unique uniq_dedup_key(dedup_key, client_id)
);


@Transactional
Order createOrder(Integer userId, String prodCode, Decimal amount, String dedupKey) {
  try {
    String orderId = createOrder(userId, prodCode, amount, deupKey); // insert a new order
    Order order = getOrderById(orderId); // read order from db
    order.setDuplicated(false); // 标记是否有重复下单
    return order;
  } catch(UniqueKeyViolationException e) {
    // if duplicated order has existed, return previous order
    Order order = getOrderByDedupKey(dedupKey, clientId);
    order.setDuplicated(true);
    return order;
  } catch (Exception e) {
    // hanlde other errors and rollback transaction ...
  }
}

7.唯一性约束

现象:在集群高并发的环境下,用户A创建用户marquezzzz,用户B同时创建了用户marquezzzz,两者的用户名相同,这违背了唯一性约束。

分析:创建用户名的逻辑是,先去db中查询是否有对应的用户名(步骤1),如果没有就创建,如果存在就更新用户的其他信息(步骤2)。用户A执行了步骤1, 用户B执行了步骤1和2,然后用户A执行了步骤2,这样生成了两个同名的用户。

解决方案:

  • 串行化请求,将创建用户的请求串行化,比如发送到队列中,这样可以确保全局唯一性。
  • 在db层进行唯一性约束,比如使用唯一索引,考虑到庞大的数据量,性能会下降。如果做了分表,唯一索引的方法也不太可行。
  • 使用分布式锁,比如redis, zookeeper,redis伪代码如下:
boolean r = redisClient.setnx("userName", currentThread, 10s); // 使用 setnx 原子命令
if (!r) {
    return false;
}

// 步骤1 查找db确保没有重名

// 步骤2 插入用户

redisClient.delete("userName");

8.时钟问题

现象:在许多app中,客户端会上报事件,但是事件的发生时间不准确

分析:app客户端时钟可能不准确,或者用户手动调整过系统时钟。

解决方案:

为了调整不正确的设备时钟,一种方法是记录三个时间戳:

  1. 根据设备的时钟,记录事件发生的时间, device_event_time
  2. 根据设备的时钟,记录将事件发生到服务器的时间, device_send_time
  3. 根据服务器时钟,记录服务器收到事件的时间, server_receive_time

事件真实发生时间 = device_event_time + (server_receive_time - device_send_time)

三.参考

《数据密集型应用系统设计》

https://cloud.tencent.com/developer/article/1121727文章来源地址https://www.toymoban.com/news/detail-442037.html

到了这里,关于分布式系统常见问题的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 分布式系统(Distributed Systems)概述

    随着互联网的持续发展(以Web应用为代表)、计算机应用的深入、分布式系统构建技术的日益成熟,分布式系统逐渐深入到人们的日常生活,并渗透到社会、经济、文化生活的各个方面。现如今,分布式系统已成为主流的软件系统。本文主要介绍下分布式系统的特征和在进行分

    2024年02月14日
    浏览(41)
  • HDFS Hadoop分布式文件存储系统整体概述

    整体概述举例: 包括机架 rack1、rack2 包括5个Datanode,一个Namenode( 主角色 )带领5个Datanode( 从角色 ),每一个rack中包含不同的block模块文件为 分块存储模式 。块与块之间通过replication进行 副本备份 ,进行冗余存储,Namenode对存储的 元数据进行记录 。该架构可以概括为一个 抽象

    2024年02月16日
    浏览(64)
  • rsync+inotify实时同步 和 GFS分布式文件系统概述

    目录 一、rsync+inotify实时同步 1.1.实时同步的优点 1.2.Linux内核的inotify机制 1.3.发起端配置rsync+Inotify 1.4.配置远程登陆 1.4.1.修改rsync源服务器配置192.168.190.101 ​编辑  1.4.2.配置server 192.168.190.102 二、GFS 2.1.GlusterFS简介 2.2.GlusterFS特点 2.3.GlusterFS术语 2.4.模块化堆模式架构 2.5.Gluste

    2024年04月16日
    浏览(38)
  • Zabbix分布式监控系统概述、部署、自定义监控项、邮件告警

    目录 前言 (一)业务架构 (二)运维架构 一、Zabbix分布式监控平台 (一)Zabbix概述 (二)Zabbix监控原理 (三)Zabbix 6.0 新特性 1. Zabbix server高可用 2. Zabbix 6.0 LTS新增Kubernetes监控功能 (四)Zabbix 6.0 功能组件 1.Zabbix Server (1)Zabbix datdbdse (2)Zabbix web 2. Zabbix Agent (1)主动

    2024年01月21日
    浏览(46)
  • 解释什么是分布式数据库,列举几种常见的分布式数据库系统

    敏感信息和隐私保护是指在收集、存储和使用个人数据时,需要采取一系列措施来保护这些数据的安全和机密性,防止数据被未经授权的第三方访问、使用或泄露。这些措施包括加密、访问控制、数据脱敏、数据加密、隐私政策等。 在隐私保护的技术手段方面,常用的技术包

    2024年02月08日
    浏览(53)
  • 在学习分布式系统时遇到的五个常见误解

    哈喽大家好,我是咸鱼 我们知道,随着企业规模或者说业务规模的不断扩大,为了应对不断增长的业务需求和提高系统的可伸缩性、可靠性和性能,计算机系统由一开始的单体系统逐渐发展成分布式系统 那么今天咸鱼给大家介绍一些关于小白在学习分布式系统遇到的一些常

    2024年02月07日
    浏览(40)
  • (快手一面)分布式系统是什么?为什么要分布式系统?分布式环境下会有哪些问题?分布式系统是如何实现事务的?

    《分布式系统原理与泛型》中这么定义分布式系统: “ 分布式系统是若干独立计算机的集合, 这些计算机对于用户来说就像单个相关系统 ”, 分布式系统(distributed system)是建立在网络之上的软件系统。 就比如:用户在使用京东这个分布式系统的时候,会感觉是在使用一

    2024年02月08日
    浏览(67)
  • PyTorch 分布式概述

    这是 torch.distributed 包的概述页面。 由于在不同位置添加了越来越多的文档,示例和教程,因此不清楚要针对特定​​问题咨询哪个文档或教程,或者阅读这些内容的最佳顺序是什么。 该页面的目的是通过将文档分类为不同的主题并简要描述每个主题来解决此问题。 如果这是

    2024年02月13日
    浏览(46)
  • 分布式链路追踪概述

    随着系统设计变得日趋复杂,越来越多的组件开始走向分布式化,如微服务、分布式数据库、分布式缓存等,使得后台服务构成了一种复杂的分布式网络。往往前端的一个请求需要经过多个微服务、跨越多个数据中心才能最终获取到结果,如下图 并且随着业务的不断扩张,服

    2024年02月13日
    浏览(38)
  • 分布式id的概述与实现

    随着业务的增长,数据表可能要占用很大的物理存储空间,为了解决该问题,后期使用数据库分片技术。将一个数据库进行拆分,通过数据库中间件连接。如果数据库中该表选用ID自增策略,则可能产生重复的ID,此时应该使用分布式ID生成策略来生成ID。 提示:以下是本篇文

    2024年02月07日
    浏览(30)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包