【面试突击】分布式架构面试连环炮

🌈🌈🌈🌈🌈🌈🌈🌈
欢迎关注公众号（通过文章导读关注：【11来了】），及时收到 AI 前沿项目工具及新技术的推送！

在我后台回复 「资料」 可领取编程高频电子书！
在我后台回复「面试」可领取硬核面试笔记！

文章导读地址：点击查看文章导读！

感谢你的关注！

🍁🍁🍁🍁🍁🍁🍁🍁

分布式架构面试连环炮

接下来说一下分布式架构中的一些面试连环炮，主要从链路监控、事务提交、这几个方面来说一下

分布式系统链路监控

主要说一下分布式系统链路监控实现的原理是什么

分布式系统链路监控主要适用于进行性能监控和故障排查，国内常用的有 CAT（大众点评的） 和 zipkin（Twitter 的）

其实链路监控主要就是做一个框架，包含一个客户端服务端：

• 在需要监控的系统中集成客户端，对一些需要监控的数据，调用链路监控的客户端 API 发送到服务端去
• 服务端将监控数据进行落库以及生成报表

我之前面试的时候，也碰到过一个面试官给我说，让我设计一个分布式系统链路监控的方案，画了一个图如下（这里主要参考了美团点评的 CAT 监控框架，美团技术团队官方文章：[深度剖析开源分布式监控CAT](https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html)）：

这里我也简单说一下流程：

1. 应用 A 在调用接口时，生成一个唯一的监控 id，这个监控 id 由：请求入口 id + 服务调用 id + 上游服务 id + 调用时间组成，保证 id 的唯一性，并且可以判断这个链路调用方向是如何的
2. 之后通过数据监控的客户端将监控数据发送给服务端，可以通过 MQ 发送，也可以自己写一个 Netty 逻辑，通过 Netty 发送
3. 服务端收到监控数据后，将数据落库，在 MySQL 和时序数据库中都存放一份，在数据的查询使用时序数据库速度比较快，而时序数据库中不可以修改数据，所以还是要在 MySQL 存储一份（对这里我了解的也不太多，如果感兴趣可以详细了解一下具体数据的存储）
4. 之后就是前端生成报表展示了

分布式事务中的两阶段提交和三阶段提交

分布式事务的两阶段提交（Two-phase Commit，简称2PC）是分布式系统中用于确保事务原子性的协议。它由两个主要阶段组成：

1. 准备阶段（Prepare Phase）：
   • 事务协调者（Transaction Coordinator）向所有参与者（Participants）发送准备请求（Prepare Request），询问它们是否准备好提交事务。
   • 参与者执行事务操作，但不提交事务。它们将操作结果记录在本地日志中，以便在需要时可以回滚。
   • 参与者向协调者发送准备响应（Prepare Response），告知它们是否准备好提交事务。
2. 提交阶段（Commit Phase）：
   • 如果所有参与者都报告准备就绪（Prepared），协调者向所有参与者发送提交请求（Commit Request），指示它们提交事务。
   • 如果有任何一个参与者报告未准备好（Not Prepared），协调者向所有参与者发送回滚请求（Rollback Request），指示它们回滚事务。
   • 参与者根据协调者的指令执行提交或回滚操作，并将结果（Commit Acknowledgment 或 Rollback Acknowledgment）发送回协调者。
   • 协调者收到所有参与者的确认后，事务提交或回滚过程完成。

两阶段提交协议的目的是确保分布式事务的一致性。在分布式系统中，事务可能涉及多个节点，每个节点上的操作必须同时成功或同时失败，以保持数据的完整性和一致性。

然而，两阶段提交协议也存在一些问题，主要包括：

• 同步阻塞：在准备阶段，所有参与者必须等待协调者的提交或回滚指令，这可能导致资源锁定和系统响应延迟。
• 单点故障：如果协调者在提交阶段失败，而没有发送提交指令，那么所有参与者将无法提交事务，可能导致数据不一致。
• 协调者过载：协调者需要处理所有事务的提交和回滚请求，这可能导致协调者成为性能瓶颈。
• 超时和网络分区：在网络不稳定的环境中，协调者和参与者之间的通信可能会超时，导致事务无法完成。

为了解决这些问题，有些系统可能会采用改进的两阶段提交协议，或者使用其他分布式事务处理机制，如三阶段提交（3PC）、补偿事务（Compensating Transactions）或最终一致性（Eventual Consistency）等。

分布式协调框架 ZooKeeper 使用的就是 2PC，由于 2PC 是同步阻塞的，因此 zk 适合小集群部署

分布式事务的三阶段提交（Three-phase Commit，简称3PC）是一种用于确保分布式系统中事务的原子性和一致性的协议。它在两阶段提交（Two-phase Commit，简称2PC）的基础上增加了一个额外的阶段，以解决2PC中可能存在的同步问题。三阶段提交包括以下三个阶段：

1. 准备阶段（CanCommit Phase）：
   • 事务协调者（Coordinator）向所有参与者（Participants）发送CanCommit消息，询问是否可以执行事务提交操作。
   • 参与者收到CanCommit消息后，会执行事务操作，并将操作结果记录在本地日志中，但不提交事务。
   • 参与者会将操作结果（可以提交或不能提交）反馈给协调者。
2. 预提交阶段（PreCommit Phase）：
   • 如果协调者收到了所有参与者的CanCommit响应，并且所有参与者都表示可以提交，协调者会发送PreCommit消息给所有参与者。
   • 参与者收到PreCommit消息后，会执行事务的预提交操作，并将结果（成功或失败）记录在本地日志中，然后向协调者发送Ack消息。
   • 如果协调者收到了所有参与者的Ack消息，或者在超时时间内没有收到任何Ack消息，协调者会认为事务可以提交。
3. 提交阶段（DoCommit Phase）：
   • 协调者向所有参与者发送DoCommit消息，指示它们提交事务。
   • 参与者收到DoCommit消息后，会正式提交事务，并将提交结果记录在本地日志中。
   • 参与者提交事务后，会向协调者发送Ack消息。
   • 协调者收到所有参与者的Ack消息后，事务提交过程完成。

三阶段提交协议的目的是为了解决两阶段提交协议中的同步问题，特别是在网络分区（Network Partition）或协调者故障的情况下。在2PC中，如果协调者在发送Commit消息后崩溃，而参与者没有收到Commit消息，那么参与者将无法提交事务，这可能导致数据不一致。通过引入预提交阶段，3PC允许参与者在提交之前确认他们已经准备好，从而减少了这种不一致性的风险。

然而，三阶段提交协议并没有完全解决2PC的所有问题，它仍然可能面临一些同步问题，例如，如果协调者在发送PreCommit消息后崩溃，而参与者在没有收到DoCommit消息的情况下也崩溃，那么参与者可能会在重启后尝试提交事务，这可能导致数据不一致。因此，在实际应用中，需要根据系统的特定需求和可用资源来选择最合适的事务处理策略。

总结一下：2PC 由于只有两个阶段，性能是比 3PC 要好的，而 3PC 通过增加了一个阶段，提供了更好的故障恢复能力

唯一 ID 生成机制中的 Snowflake 算法的时钟回拨问题如何解决？

Snowflake 算法是由Twitter开发的一个分布式ID生成算法，用于在分布式系统中生成唯一且有序的ID。它的核心思想是将一个64位的长整型数字分割成不同的部分，每个部分代表不同的信息，从而确保ID的唯一性和有序性。Snowflake算法的ID结构通常如下：

• 第1位：符号位，始终为0，表示正数。
• 第2-41位：时间戳，使用41位来表示当前时间与预设的起始时间（如1970年1月1日）之间的毫秒差。这样可以支持大约69年的时间范围。
• 第42-52位：数据中心ID，用于区分不同的数据中心。通常使用5位或10位，可以支持最多32个数据中心。
• 第53-62位：机器ID，用于区分不同的机器。同样使用5位或10位，可以支持最多1024台机器。
• 第63-64位：序列号，用于在同一个毫秒内生成多个ID。通常使用12位，可以支持4096个序列号。

在使用 Snowflake 生成的唯一 ID 有 41 位是时间戳，那么假如系统时钟回拨，系统时间比上次生成唯一 ID 的时间小，那么可能会生成重复的 ID

为什么会发送时钟回拨呢？

当前的机器的会跟一台基准时间服务器进行时间校准，如果你的机器的时间跑的稍微快了一点，此时跟基准时间服务器进行了校准，你的时间被校准后就倒退回去了

怎么解决呢？

如果发生了时钟回拨，此时你看看时钟回到了之前的哪一毫秒里去，直接接着在那一毫秒里的最大的 ID 继续自增就可以了