我的api中有一个支持写入的端点。有问题的资源是协作的，因此可以合理地预期并行写入请求会同时到达。
如果写入次数很少，那么使用简单的lambda相对简单 - 读取当前状态，计算新状态，比较和交换，旋转直到交换成功或直到我们放弃。在任何一种情况下，我们都会计算适当的http响应并将其返回给调用者。
如果API成功，那么最终浪费的冲突写入变得非常昂贵，无法解决。
看起来自然响应就是将请求复制到队列中，并使用一个消耗批次的函数;在每个批处理中，我们按顺序处理请求，存储新的写入，并计算对请求的适当响应。
有哪些选项可以将这些计算出的响应复制到http响应中，有哪些权衡要考虑？
我的感觉是，在处理http请求时，在（同步）将消息排入队列后，我需要阻止/轮询某些，最终将填充对请求的响应。
答案 0 :(得分：0)
我不确定这是否会算一个答案，但我不同意自然的反应是复制/队列/阻止;感觉就像你只是为一种悲观的交易乐观的并发控制（而且你可能更容易使用例如Redis实现锁定 - 更不用说Lambda本身还有其他问题可以使这种方法你描述的更难了。）
用户可能不需要像这样的API，因为它具有高延迟。
在我看来，专为协作修改某些共享状态而设计的API具有更高阶的构造，使API成功：以对话为例，您可以将聊天分解为单个消息，其中每条消息是对其他一些消息的回复;对会话的并发修改大部分是附加的（您可能允许用户编辑单个消息，但这不是资源争用点），您可能会做异步计算会话中的消息数等事情。它最终是一致的。
您可以查看API的域，看看是否有办法通过修改目标子实体来减少争用，从而减少对争用的影响（即使API将此表示为单个资源，存储引擎不必）。
另一个选择是查看像事件源这样的模型，其中更改本身是字面上附加的，您可以从某些快照和最近的更改中获取状态。