系统设计：多个客户端更新相同 table
System Design: multiple client updating same table
我遇到了这个面试问题，想了想这里的社区有什么看法：
There are 100000 vending machines all around the world which need to
update a database about maintenance activities like restocking or any
technical failure. The update happens at midnight for all the
machines. A batch system runs after the update and creates work orders
for the maintenance task. Do you see a problem in this design?
这是一个非常抽象的问题，但想知道这里社区的建议。
我的想法/或交叉问题是（
通用）：
- 在数据库出现故障时从失败中恢复。写
争用，取决于 table 页面的记录大小
已锁定。
- 如果发生超时，客户端发送什么
再次请求？
- 服务器可能会非常忙于处理这些请求，而其他客户端 HTTP 请求可能会开始排队。
- 更新过程的依赖性。是否更新过程
继续轮询数据库？
注意：我知道从堆栈溢出的角度来看这不是一个经过深思熟虑的问题，但我想了解如何解决此类问题。
I want to understand how to tackle such questions.
这一切都取决于您的心智模型，以及您如何学会在不同的场景中应用它。我像这样处理技术 scenarios/questions 的方法是使用以下内容的一些模糊组合：
- 确保我理解问题。通常我会给自己做一个图表来帮助直观地理解它。
- 确保我理解实际问题。不要忽视实际要求您做的事情——不要分心。在此示例中，很容易查看 'vending machines all around the world' 和 'update a database'，但没有提及它们的实际连接方式。 “天哪，使用 REST API 新手！”... 可能 是更好的解决方案，但这是对另一个问题的回答。
- 分解事物并通过不同的“镜头”考虑它们...
- 扩展和心理演练 - 扩展就是把基础知识充实起来。心理演练是您尝试使它在您的脑海中更加真实并开始逐步完成它们可以帮助识别缺陷的地方。
对于面试问题，我想您通常会按任何顺序做#1 和 2，然后做 3 或 4 - 这取决于具体情况。同样，对于面试问题，我发现 #4 的两个部分通常同时发生。
镜片
我在这里对“镜头”一词的使用是通用的——只是一种以不同方式看待事物的方式。一些特定的领域对这些有特定的术语 - 例如 Views and perspectives 在建筑学中找到。
并非所有这些都适用于您的示例问题；它们适用于各种情况。使用哪些通常是显而易见的 - 至少随着您获得更多经验，应该会变得更加直观。
- 假设 - 做出了哪些假设以及它们的安全性如何？有时，面试问题的重点是找到有缺陷的假设并对其进行解释。在 real-world 中，人们总是做出假设 - 有时他们是有缺陷的，有时他们 是 正确的，但情况会随着时间的推移而变化，这会使他们有缺陷。
- Dependencies - 存在哪些依赖关系以及这些依赖关系如何相关？这些可能是明确和明显的，或暗示的（更微妙的）。它们可能存在于 运行 时间，或者是事物结构中固有的。依赖关系也将通过以下大多数镜头出现。
- 关系 - 事物在逻辑上是如何联系的？例如。东西tightly-coupled在它们应该loosely-coupled的地方吗？
- Ins and Outs - 各种输入和输出是什么？
- 运行时 - 执行时发生了什么？它在哪里执行？
- 设计与构建 - 是否有任何影响解决方案构建方式的含义？或者，换句话说：设计/构建方法是否对解决方案的部署方式和运行有影响？
- 部署 - 解决方案在物理上是如何安排的？到达那里的过程是什么？
- 连通性 - 事物如何通信？他们如何发现彼此？
- 安全 - Public / 面向互联网或私人或两者兼而有之？认证和授权是如何处理的？
- SDLC - 设计、构建、测试、部署、操作、modifying/maintaining、升级和停用解决方案的生命周期。
- 架构 - 总体架构是什么 - 它是否适合任何可识别的架构，它告诉您什么？逻辑层和物理层等基本概念可以作为评估的良好心理起点。
- 情景 - 您可以通过想象“如果……会怎样？”来进行心理测试。例如。 system/component失败。
- 回到基础 - 很容易陷入细节，有时你需要回到基础和基础，从第一原则开始工作等
其中有很多重叠，例如部署一只脚在设计和构建区域（如何为部署打包东西），另一只脚在 运行时间（部署后会发生什么).
进一步阅读：“欺骗Sheet”方法
对我来说，回答这些类型的面试问题和 real-world 问题以及你如何处理它们之间有很多协同作用。
上面的列表是一堆你可以用来解决问题的东西，但我也开发了一个类似的方法来学习架构 - 以及我如何处理各种 day-to-day 场景作为解决方案架构师，您需要快速切换上下文（从一个会议转到另一个会议），或者寻找完整性（例如审查设计）。
简而言之，你可以开发一个“秘籍”sheet" 供参考，它有两种工作方式：
- 作弊 sheet 的开发本身就是一种 (self-directed) 学习行为。
- 作弊 sheet 提供了一个快速参考点。
我主要是在初级架构师的时候使用这种方法。
我的原创文章在我的博客上：Architectural Cheat Sheet (v3.0 – 2009), and more recently I've been doing workshops and meet-ups 就可以了。
我遇到了这个面试问题，想了想这里的社区有什么看法：
There are 100000 vending machines all around the world which need to update a database about maintenance activities like restocking or any technical failure. The update happens at midnight for all the machines. A batch system runs after the update and creates work orders for the maintenance task. Do you see a problem in this design?
这是一个非常抽象的问题，但想知道这里社区的建议。
我的想法/或交叉问题是（ 通用）：
- 在数据库出现故障时从失败中恢复。写 争用，取决于 table 页面的记录大小 已锁定。
- 如果发生超时，客户端发送什么 再次请求？
- 服务器可能会非常忙于处理这些请求，而其他客户端 HTTP 请求可能会开始排队。
- 更新过程的依赖性。是否更新过程 继续轮询数据库？
注意：我知道从堆栈溢出的角度来看这不是一个经过深思熟虑的问题，但我想了解如何解决此类问题。
I want to understand how to tackle such questions.
这一切都取决于您的心智模型，以及您如何学会在不同的场景中应用它。我像这样处理技术 scenarios/questions 的方法是使用以下内容的一些模糊组合：
- 确保我理解问题。通常我会给自己做一个图表来帮助直观地理解它。
- 确保我理解实际问题。不要忽视实际要求您做的事情——不要分心。在此示例中，很容易查看 'vending machines all around the world' 和 'update a database'，但没有提及它们的实际连接方式。 “天哪，使用 REST API 新手！”... 可能 是更好的解决方案，但这是对另一个问题的回答。
- 分解事物并通过不同的“镜头”考虑它们...
- 扩展和心理演练 - 扩展就是把基础知识充实起来。心理演练是您尝试使它在您的脑海中更加真实并开始逐步完成它们可以帮助识别缺陷的地方。
对于面试问题，我想您通常会按任何顺序做#1 和 2，然后做 3 或 4 - 这取决于具体情况。同样，对于面试问题，我发现 #4 的两个部分通常同时发生。
镜片
我在这里对“镜头”一词的使用是通用的——只是一种以不同方式看待事物的方式。一些特定的领域对这些有特定的术语 - 例如 Views and perspectives 在建筑学中找到。
并非所有这些都适用于您的示例问题；它们适用于各种情况。使用哪些通常是显而易见的 - 至少随着您获得更多经验，应该会变得更加直观。
- 假设 - 做出了哪些假设以及它们的安全性如何？有时，面试问题的重点是找到有缺陷的假设并对其进行解释。在 real-world 中，人们总是做出假设 - 有时他们是有缺陷的，有时他们 是 正确的，但情况会随着时间的推移而变化，这会使他们有缺陷。
- Dependencies - 存在哪些依赖关系以及这些依赖关系如何相关？这些可能是明确和明显的，或暗示的（更微妙的）。它们可能存在于 运行 时间，或者是事物结构中固有的。依赖关系也将通过以下大多数镜头出现。
- 关系 - 事物在逻辑上是如何联系的？例如。东西tightly-coupled在它们应该loosely-coupled的地方吗？
- Ins and Outs - 各种输入和输出是什么？
- 运行时 - 执行时发生了什么？它在哪里执行？
- 设计与构建 - 是否有任何影响解决方案构建方式的含义？或者，换句话说：设计/构建方法是否对解决方案的部署方式和运行有影响？
- 部署 - 解决方案在物理上是如何安排的？到达那里的过程是什么？
- 连通性 - 事物如何通信？他们如何发现彼此？
- 安全 - Public / 面向互联网或私人或两者兼而有之？认证和授权是如何处理的？
- SDLC - 设计、构建、测试、部署、操作、modifying/maintaining、升级和停用解决方案的生命周期。
- 架构 - 总体架构是什么 - 它是否适合任何可识别的架构，它告诉您什么？逻辑层和物理层等基本概念可以作为评估的良好心理起点。
- 情景 - 您可以通过想象“如果……会怎样？”来进行心理测试。例如。 system/component失败。
- 回到基础 - 很容易陷入细节，有时你需要回到基础和基础，从第一原则开始工作等
其中有很多重叠，例如部署一只脚在设计和构建区域（如何为部署打包东西），另一只脚在 运行时间（部署后会发生什么).
进一步阅读：“欺骗Sheet”方法
对我来说，回答这些类型的面试问题和 real-world 问题以及你如何处理它们之间有很多协同作用。
上面的列表是一堆你可以用来解决问题的东西，但我也开发了一个类似的方法来学习架构 - 以及我如何处理各种 day-to-day 场景作为解决方案架构师，您需要快速切换上下文（从一个会议转到另一个会议），或者寻找完整性（例如审查设计）。
简而言之，你可以开发一个“秘籍”sheet" 供参考，它有两种工作方式：
- 作弊 sheet 的开发本身就是一种 (self-directed) 学习行为。
- 作弊 sheet 提供了一个快速参考点。
我主要是在初级架构师的时候使用这种方法。
我的原创文章在我的博客上：Architectural Cheat Sheet (v3.0 – 2009), and more recently I've been doing workshops and meet-ups 就可以了。