【问题标题】：REST application, Transactions, Cache dropREST 应用程序、事务、缓存删除
【发布时间】：2026-02-21 10:55:01
【问题描述】：
我在 php 中构建 REST API，顶部有 memcache 层，用于缓存所有资源。经过一些阅读/体验后发现，文档尽可能简单是最好的选择……主要是因为删除了缓存序列。
因此，如果“房间”文档有“建筑物”、“房间”实体，我只会放置“建筑物”的 ID，而不是它的全部数据。然后在 api 客户端我会根据需要合并数据。
当我需要更新/插入时出现问题（大多数情况下不止一张表）。我更新了一个资源，但在第二次更新系统失败或其他任何情况下，数据库出现不一致。
我看到了几种解决方案：
实施我认为错误且复杂的剩余事务，因为想法是无状态且简单。
在更新/插入操作时，我传递更复杂的数据（不是单个实体），因此我可以在 API 级别强制事务。但这会使您的 GET 文档结构与 PUT 文档结构相同变得很奇怪。再次以某种方式使放置序列变得复杂。
任何指针都非常受欢迎。
干杯，
【问题讨论】：
标签：
architecture
rest
caching
transactions
【解决方案1】：
你想做的是这样的：
客户端 代理缓存（如 Squid） REST 接口 memcached 域模型
如果您充分利用 HTTP 缓存，您可能根本不需要 memcached 层。缓存失效是一个需要解决的棘手问题，HTTP 已经有很多规则和机制可以让你保持清醒。我对 memcached 不是很熟悉，但是关于这个主题的快速谷歌似乎表明您需要推出自己的缓存失效策略。 HTTP 还具有能够在客户端缓存内容的额外好处。
如果您有客户端需要一次更新多个域对象的场景，那么您需要在 REST 接口中创建代表虚拟“复合”对象的资源。客户端应该只感知他们正在更新单个资源。如果您愿意，您可以在后台更新数据库事务中的多个资源。
如果您将资源映射到PresentationModels，则更容易创建 REST 系统。大多数人犯的错误是试图将 REST 资源严格映射到域对象。可能存在密切相关，但除非您有一个非常无聊的应用程序，否则它不会是直接映射！