想象一下，我们有大量的产品清单，这些清单取自数据库，转换为数组并以JSON形式返回。
大多数产品字段都是静态的-很少更改，这就是为什么我们要缓存此JSON的原因。
问题在于我们无法缓存某些字段值。
例如：
那么在这种情况下，我们应该如何划分动态和静态内容？
答案 0 :(得分：1)
is_favorite和views_count本质上是关于产品的元数据，与实际产品无关。
例如，如果您有Book产品，则该产品将包含title，author，isbn，no_of_pages，genre预订本身。无论在何种情况下使用本书，这些属性都不会改变。这本书可以与这些属性分开存在。如果它们都为零，则对产品没有任何意义。零可能对其他人（例如，图书销售商）来说意味着什么，但是图书的存在并不取决于这两个属性。可以缓存那些存在于书本中的属性，就像它们是新书一样。
is_favorite是用户上下文，而views_count是全局上下文。 price例如是市场环境。所有这些属性各不相同，也许不应该缓存（也许price可以缓存一段时间）。
因此，这确实指向属性的寿命。内部属性永远不会改变，因此可以进行缓存。价格等中期属性可能会被缓存，但是需要一些机制来更新它们。诸如is_favorite和views_count之类的易失属性不应被缓存。
可能的实现方式可能是缓存书籍的本地副本并从缓存的版本驱动用户界面，而不是根据用户的每个请求调用端点。内在属性不会改变，因此您只需要获取它们一次，然后再从缓存中读取。 is_favorite是应用程序的一部分，因此您无需在第一本书GET之后从端点读取它。如果用户使该书成为收藏夹，则更新缓存的书，并PUT更新该信息所在的位置。单独的作业可以查询views_count端点并间歇地更新缓存的书。因此，应用程序依赖于缓存的书来完成其工作。用户的任何更新（例如使其成为收藏夹）都会导致对API的出站PUT请求，并写入到缓存的书中。您无需为GET is_favorite设置端点，因为您的应用程序首先会创建该信息。