🪴 Obsidian Publish

@3 分布式 2

8分钟阅读

面试问题

  • 请说说你对分布式系统 CAP 理论的理解，CAP 分别代表什么含义？

  • 为什么分布式系统的一致性和可用性不能同时满足？

  • 你了解数据库的 binlog 和 redolog 吗？是如何实现一致性的呢？

  • 怎么实现系统之间的分布式一致性？

回答流程

  • 考察 CAP 理论

    • 结合自己的思考描述。
    • 将理论结合实践，讨论实际中处理问题时的思考逻辑。
      • 不同场景下对于数据一致性和可用性的重要程度是不一样的，需要在 CP 和 AP 中权衡。
      • 如下单场景下，互联网场景有高并发的需求，因此可用性是更高要求，即只能使用最终一致性。也就是 CAP 理论在 AP 下的延伸 —— BASE 理论。BASE 是 Basically Available、Soft State 和 Eventually Consistent 三个单词的简写，作用是保证系统的可用性，然后通过最终一致性来代替强一致性。其保障核心功能的基本可用，其实是做了“可用性”方面的妥协，比如：
        • 电商网站在双十一大促等访问压力较大的时候，关闭商品排行榜等次要功能的展示，从而保证商品交易主流程的可用性，这也是我们常说的服务降级；
        • 为了错开双十一高峰期，电商网站会将预售商品的支付时间延后十到二十分钟，这就是流量削峰；
        • 在你抢购商品的时候，往往会在队列中等待处理，这也是常用的延迟队列。
      • 而如果是一致性要求比较高的场景，如元数据的存储，一致性要求会更高一些。比如，不能创建一个数据库表之后，再插入数据时提示数据库表不存在。

  • 考察 Redis 是否可以作为分布式锁

    • 从 CAP 理论分析，分布式锁需要满足 CP 模型，Redis 设计模式为 AP 模式，不合适。满足 CP 模型的应该是 Zookeeper 或者 Etcd。
    • 从分布式存储分析，考虑数据分布、数据复制、数据分片等信息。
    • 多维度、多角度去对比分析。然后综合权衡各种方法的优缺点，最终形成自己的技术认知和技术判断力。

  • InfluxDB 节点一致性模型

    • InfluxDB 是由 META 节点和 DATA 节点 2 个逻辑单元组成，这 2 个节点的功能和数据特点不同，需要我们分别为它们设计分区容错一致性模型。
      • 作为分布式系统，分区容错性是必须要实现的，不能因为节点间出现了分区故障，而出现整个系统不工作的情况。
      • META 节点存储关键信息，比如 xxx 数据。这些数据必须读取的是最新数据，否则比如创建一个表后，插入数据失败等情况。选择 CP 架构。
      • DATA 节点保存的是具体的时序数据记录，比如一条记录 CPU 负载的时序数据。虽然这些数据不是系统运行相关的元信息，但服务会被访问频繁，水平扩展、性能、可用性等是关键，采用 AP 架构。
    • 如果 DATA 节点采用 CP 如 raft 会怎么样？
      • 受限于 Raft 的强领导者模型。所有写请求都在领导者节点上处理，整个集群的写性能等于单机性能。这样会造成集群接入性能低下，无法支撑海量或大数据量的时序数据。
      • 受限于强领导者模型，以及 Raft 的节点和副本一一对应的限制，无法实现水平扩展，分布式集群扩展了读性能，但写性能并没有提升。这样会出现写性能低下，和因为架构上的限制，无法提升写性能的问题。
    • 02 | CAP理论：分布式系统的PH试纸，用它来测酸碱度-分布式协议与算法实战-极客时间

  • 怎么实现系统之间的分布式一致性？

    • (这里指的系统之间的分布式一致性，也就是不同系统之间如何实现分布式一致性，即涉及到分布式事务)
    • 提出不同系统之间的分布式一致性需要通过分布式事务来实现。当前已有的分布式事务实现方式有，2PC、3PC、TCC、基于 MQ 的最终一致性。其中，主流实现分布式系统事务的一致性方案为基于 MQ 的可靠消息投递的机制，回答 MQ 实现方案和关键知识点。
    • 简单介绍下 2PC、3PC、TCC 等。因为 2PC 或 TCC 在工业界落地代价很大，不适合互联网场景，所以只有少部分的强一致性业务场景（如金融支付领域）会基于这两种方案实现。

  • 高并发场景下消息积压导致消息丢失问题。

    • 这个的生产者生产速度高于消费者消费速度，那么可以通过降低生产者的速度和增加消费者的速度来解决。降低生产者可以通过限流等方式来解决，对于增加消费者速度可以通过扩容机制来解决。
    • 另外，可以先将订单系统要发送的消息持久化到本地数据库，状态为待发送，同时读取 binlog 或者定时任务来获取需要处理的消息放到消息队列中异步处理。

基于“高并发场景下的消息积压导致消息丢失” 这个问题，想到。如果回答问题的时候，可以从通用和特定场景两个角度来回答问题。通用就是正常一般怎么处理，特定场景的话，就是基于业务、产品等使用非技术或其他手段来间接解决。例如秒杀时候，前端随机进行过滤。