Cookies vs 会话 vs 数据库 [关闭]答案

【问题标题】：Cookies vs Session vs Database [closed]Cookies vs 会话 vs 数据库 [关闭]
【发布时间】：2017-07-22 11:09:14
【问题描述】：

我有一个网站，客户可以登录并购买特定范围内的产品（根据他们的客户编号）。导航栏有一个产品类别的下拉菜单，但没有显示任何没有产品的地方。

此时，在每个页面上查询数据库以填充产品类别菜单，但这感觉效率低下。我现在想知道“允许”产品列表是否应该在会话开始时存储在 cookie 或会话变量中。

根据我从其他问题中收集到的信息，通常会使用会话变量，但他们已警告不要在会话变量中存储大量数据。在这种情况下，我将为每个用户存储一个可能很大的产品列表，那么 cookie 会更好吗？我不会将产品列表归类为特别敏感，并且我会在下订单之前进行服务器端检查。还是我应该坚持每次都查询数据库的当前解决方案？

需要说明的是，我仍然会将信息存储在数据库中，这个问题只是询问临时存储以便在整个会话期间快速访问。

我已经查看了以下问题，但我仍然不觉得我已经完全得到了我的特定场景的答案，并且接近的问题没有提到 cookie。

【问题讨论】：

缓存。始终缓存。如果您只是想避免往返于数据库，那么会话和 cookie 绝不是合适的选择。
请有人告诉我为什么投反对票？
不确定，但一般来说，您的问题与 Stack Overflow 无关。
@ChrisPratt 我不确定这里和软件工程之间的关系，但选择这里是因为我遇到了其他问题。
哈哈。是的，所有这些也都是题外话。 Stack Overflow 是针对与编程过程中遇到的特定问题相关的问题：如何完成特定任务、解决错误等。这在软件工程中会更合适，因为它是一个更抽象的设计/实现问题。

【解决方案1】：

我会采取的方法可能是这样的：

将产品数据存储在所有客户共享的缓存中，并使用每个产品的主键作为每个产品的缓存键（一部分）。使用的缓存策略可能因可扩展性要求而异（System.Runtime.Caching vs redis vs 文件缓存）。一般来说，我可能会对产品数据使用滑动过期时间或LRU cache（请参阅this .NET example），以便最受欢迎的产品比不太受欢迎的产品保留更长的缓存时间。当请求针对特定主键时，首先检查缓存中的键，如果返回 null，则在返回产品之前从数据库中查找产品并填充缓存（请参阅this example）。
对于每个客户，仅存储主键和其他相关数据（他们可能获得的折扣类别等）。如果主键列表足够小，您可以使用 cookie (encrypted) 来解决这个问题。如果您需要对其进行扩展以向每个客户提供超出 cookie 的容量，请在数据库中查询主键。
当客户请求数据时，首先获取主键列表，然后使用这些键访问预缓存的产品数据以构建视图。您可以根据需要存储任意数量的不同主键列表以满足您的要求，而无需从数据库中获取每个客户的产品数据或单个客户的每个用例。

Think twice about using session state - 建议不要将会话状态用于用户配置文件数据。

当然，上述内容并未考虑可能需要的任何其他营销要求。因此，您可能需要根据需要调整此策略。例如，如果您需要比缓存正常过期更快地更新产品信息，您可能会考虑一种方法，首先更新数据库中的产品数据，如果成功，则在缓存上获取写锁定并更新缓存，也。这将允许近乎实时的缓存更新，而无需使缓存失效并从数据库重新加载。

【讨论】：