Cookie vs会话vs数据库

Question

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

当时，每个页面上都会查询数据库以填充产品类别菜单，但这样做效率不高。我现在想知道'允许'产品列表是否应该在会话开始时存储在cookie或会话变量中。

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

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

我已经看过以下问题，但我仍然觉得自己对于特定场景的回答并不满意，而且接近的问题没有提及Cookie。

• Cache VS Session VS cookies?
• Cookie VS Session
• Session Cookie vs Persistent Cookie
• Trade off between user data in session vs database?
• session variables vs database

Answer 1

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

• 将产品数据存储在所有客户共享的缓存中，并将每个产品的主键用作每个产品的缓存键（的一部分）。所使用的缓存策略可能因可伸缩性要求而异（System.Runtime.Caching vs redis vs file caching）。一般来说，我可能会使用滑动过期或LRU cache（请参阅this .NET example）获取产品数据，因此最受欢迎的产品保留的缓存时间比不受欢迎的产品长。当某个特定主键发出请求时，会首先检查该键的缓存，如果该键返回null，则在返回产品之前从数据库和缓存中查找产品（请参阅this example）。
• 对于每个客户，仅存储主键和其他相关数据（他们可能得到什么类别的折扣等）。如果主键列表足够小，那么可以通过cookie（encrypted）来获得。如果您需要按比例调整以使每个客户都能够放入Cookie中，则可以在数据库中查询主键。
• 当客户请求数据时，首先获取主键列表，然后使用这些键访问预缓存的产品数据以构建视图。您可以根据需要存储许多不同的主键列表，而无需从每个客户的数据库获取产品数据，也无需为每个客户获取每个用例。

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

当然，以上没有考虑到可能需要的任何其他营销要求。所以你可能需要根据你的需求调整这个策略。例如，如果您需要更快地更新产品信息而不是缓存通常过期，那么您可能会考虑一种方法，即首先更新数据库中的产品数据，如果成功，则会获取对缓存的写入锁定并更新缓存，太。这将允许近乎实时的缓存更新，而不必从数据库中无效并重新加载缓存。