我有一个网站，客户可以登录并购买特定系列的产品(根据他们的客户编号)。导航栏有一个产品类别下拉菜单，但不会显示任何没有产品的地方。
目前，在每个页面上查询数据库以填充产品类别菜单，但这感觉效率低下。我现在想知道“允许”产品的列表是否应该在 session 开始时存储在 cookie 或 session 变量中。
根据我从其他问题中收集到的信息，通常会使用 session 变量，但他们警告不要在 session 变量中存储大量数据。在这种情况下，我将为每个用户存储一个可能很大的产品列表，那么 cookies 会更好吗？我不会将产品列表归类为特别敏感，并且我会在下订单之前进行服务器端检查。或者我应该坚持当前每次查询数据库的解决方案？
需要明确的是，我仍然会将信息存储在数据库中，这个问题只是询问临时存储以便在整个 session 中快速访问。
我已经看过以下问题，但我仍然觉得我还没有完全得到我的特定场景的答案，并且接近的问题没有提到 cookie。
最佳答案
我会采取的方法可能是这样的:
- 将产品数据存储在所有客户之间共享的缓存中，并使用每个产品的主键作为每个产品的缓存键(一部分)。使用的缓存策略可能会根据可扩展性要求而有所不同(System.Runtime.Caching vs redis vs 文件缓存)。一般来说，我可能会使用滑动到期或 LRU cache (请参阅 this .NET example )了解产品数据，因此最受欢迎的产品比不太受欢迎的产品保留缓存的时间更长。当请求针对特定主键时，首先检查缓存中是否有该键，如果返回 null，则从数据库中查找产品并填充缓存，然后返回产品(请参阅 this example )。
- 对于每个客户，仅存储主键和其他相关数据(他们可能获得什么级别的折扣等)。如果主键列表足够小，您可能可以使用 cookie ( encrypted ) 来完成此操作。如果您需要对其进行扩展，以便为每个客户提供超出 Cookie 容量的内容，请在数据库中查询主键。
- 当客户请求数据时，首先获取主键列表，然后使用这些键访问预缓存的产品数据来构建 View 。您可以根据需要存储任意数量的不同主键列表，以满足您的要求，而无需从数据库中获取每个客户或单个客户的每个用例的产品数据。
Think twice about using session state - 建议不要将 session 状态用于用户配置文件数据。
当然，上述内容并未考虑可能需要的任何其他营销要求。因此，您可能需要根据您的需求调整此策略。例如，如果您需要比缓存正常过期的速度更快地更新产品信息，您可能会考虑先更新数据库中的产品数据，如果成功，则获取缓存上的写锁并更新缓存，也。这将允许近乎实时的缓存更新，而无需使缓存失效并从数据库重新加载。
关于asp.net-mvc - Cookie、 session 、数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42560264/