“基于级别”和“基于边缘”的一般含义是什么？
我从 kubernetes 文档中读到“换句话说，系统的行为是基于级别而不是基于边缘的”： https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api-conventions.md
使用 Google，我只能找到： http://www.keil.com/forum/9423/edge-based-vs-level-based-interrupt/
谢谢。
【问题讨论】：
标签： kubernetes
它还有一个更一般的定义（至少我们倾向于在文档中使用它的方式）。如果一个逻辑只依赖于当前状态，那么它就是“基于级别的”。如果一个逻辑除了当前状态之外还依赖于历史/转换，那么它就是“基于边缘的”。
“基于关卡”的组件更具弹性，因为如果它们崩溃，它们可以重新启动并查看当前状态。 “基于边缘的”组件必须存储它们所依赖的历史（或依赖于存储它的其他组件），以便当它们恢复时可以查看当前状态和历史。此外，如果存在某种临时网络分区并且基于边缘的组件错过了一些更新，那么它将计算错误的输出。
但是，“基于级别”的组件通常效率较低，因为它们可能需要扫描大量状态才能计算输出，而不仅仅是读取增量。
许多组件是两者的混合物。
简单示例：您想要构建一个报告处于 READY 状态的 pod 数量的组件。基于级别的实现将从 etcd（或 API 服务器）获取所有 pod 并计数。基于边缘的实现会在启动时执行一次，然后只观察 pod 进入和退出 READY 状态。
【讨论】：
我想说他们在网站上解释得很好：
当发布或放置对象的新版本时，“规范”会更新并立即可用。随着时间的推移，系统将努力使“状态”与“规范”保持一致。无论该节的先前版本如何，系统都将朝着最新的“规范”前进。 换句话说，如果一个 PUT 中的值从 2 更改为 5，然后在另一个 PUT 中又回到 3，则系统不需要在将“状态”更改为 3 之前在 5 处“触底”强>。
因此，从该语句中，我们知道“level base”意味着如果主要目标不需要，则不需要满足 PUT 请求； 可以随意跳过 PUT 请求。
这让我假设“基于边缘的”系统需要满足每个 PUT 请求，即使可以跳过某些请求而不改变最终结果，因为这将是跳过请求的替代方案.
我不是 RESTful 开发人员（您可以通过我的帐户活动看到）。我在其他任何地方都找不到这些东西的任何信息来源，所以我将根据他们给出的解释进行，这似乎很简单。
【讨论】：