系统设计：多个客户端更新同一张表

Question

我遇到了这个面试问题，想到这里社区的观点是什么：

全世界有 100000 台自动售货机需要 更新有关维护活动的数据库，例如补货或任何 技术故障。更新发生在午夜所有 机器。批处理系统在更新后运行并创建工作订单 用于维护任务。你觉得这个设计有问题吗？

这是一个非常抽象的问题，但想在这里了解社区的建议。

我的想法/或交叉问题是（ 通用）：

1. 在 db 出现故障时从故障中恢复。写 争用，取决于表页可能有多大的记录 锁定。
2. 如果发生超时，客户端会发送什么 再次请求？
3. 服务器可能会忙于处理这些请求，而其他客户端 HTTP 请求可能开始排队。
4. 更新过程的依赖性。是否更新过程 继续轮询数据库？

注意：我知道从堆栈溢出的角度来看，这不是一个经过深思熟虑的问题，但我想了解如何解决这些问题。

Answer 1

我想了解如何解决这些问题。

这一切都取决于您的心智模型，以及您如何学会在不同的场景中应用它。我处理此类技术场景/问题的方法是使用以下模糊组合：

1. 确保我理解问题。我通常会自己制作一个图表以帮助直观地理解它。
2. 确保我理解实际问题。不要忽视实际要求你做的事情——不要分心。在此示例中，很容易查看“世界各地的自动售货机”和“更新数据库”，但没有提及这些实际连接方式。 “天啊，新手们，请使用 REST API！”...可能是一个更好的解决方案，但这是另一个问题的答案。
3. 分解事物并通过不同的“镜头”考虑它们...
4. 扩展和心理演练 - 扩展就是把基础知识充实起来。心理演练是您尝试在脑海中使其更加真实并开始逐步完成它们的地方，这有助于识别缺陷。

对于面试问题，我猜你通常会做 #1 和 2，然后按任意顺序做 3 或 4 - 这取决于具体情况。同样，对于面试问题，我发现 #4 的两个部分通常同时发生。

镜头

我在这里使用的“镜头”一词是通用的——只是一种以不同方式看待事物的方式。一些特定的域对这些有特定的术语 - 例如架构中的Views and perspectives。

并非所有这些都适用于您的示例问题；它们适用于各种情况。使用哪些通常是显而易见的 - 至少会随着您获得更多经验而变得更加直观。

• 假设 - 做出了哪些假设以及它们的安全性如何？有时面试问题的重点是找到一个有缺陷的假设并解释它。在现实世界中，人们总是做出假设 - 有时他们是有缺陷的，有时他们是正确的，但情况会随着时间的推移而改变，这可能会使他们有缺陷。
• 依赖关系 - 存在哪些依赖关系以及这些依赖关系如何？这些可能是明确的和明显的，或暗示的（更微妙的）。它们可能存在于运行时，或者是事物结构中固有的。依赖关系也将通过以下大部分镜头出现。
• 关系 - 事物在逻辑上是如何联系起来的？例如。事物在应该松耦合的地方紧耦合吗？
• 来龙去脉 - 各种输入和输出是什么？
• 运行时 - 执行时发生了什么？它在哪里执行？
• 设计与构建 - 是否存在影响解决方案构建方式的任何含义？或者，反过来说：设计/构建方法对解决方案的部署和运行方式有影响吗？
• 部署 - 解决方案在物理上是如何安排的？到达那里的过程是什么？
• 连通性 - 事物如何通信？他们是如何发现彼此的？
• 安全性 - 面向公共/互联网或私人或两者兼而有之？认证和授权是如何处理的？
• SDLC - 设计、构建、测试、部署、操作、修改/维护、升级和停用解决方案的生命周期。
• 架构 - 整体架构是什么 - 它是否适合任何可识别的架构，这告诉您什么？逻辑层和物理层等基本概念可以作为评估的良好心理起点。
• 场景 - 你在哪里通过想象“如果？”来对事物进行心理测试。例如。系统/组件故障。
• 回到基础 - 很容易陷入细节，有时您需要回到基础和基础，从第一原理开始工作等。

其中很多重叠，例如部署一只脚在设计和构建领域（如何打包以进行部署），另一只脚在运行时（部署后会发生什么）。

延伸阅读：“备忘单”方法

对我来说，回答这些类型的面试问题和现实世界的问题之间有很多协同作用 - 以及你如何解决这些问题。

上面的列表是你可能用来解决问题的一堆东西，但我也开发了一种类似的方法来了解我如何学习架构 - 以及我如何处理你遇到的各种日常场景作为解决方案架构师，您要么需要非常快速地切换上下文（从一次会议转到另一次会议），要么寻求完整性（例如审查设计）。

简而言之，您可以开发一个“备忘单”以供参考，它有两种工作方式：

1. 编写备忘单本身就是一种（自我指导的）学习行为。
2. 备忘单提供了一个快速参考点。

当我还是一名初级架构师时，我主要使用这种方法。

我最初的文章在我的博客上：Architectural Cheat Sheet (v3.0 – 2009)，最近我一直在做研讨会和meet-ups。