3

目前，我们的 DNS 将用户路由到正确的数据中心，然后我们对服务器进行轮询。我们目前将会话信息存储在 cookie 中，但它变得太大，因此我们希望将其从浏览器中移出并放入数据库中。我担心如果我们创建一个他们都命中的中间盒子，那么响应时间会受到影响。存储所有机器的会话信息是不可行的，因为我们谈论的是每月 200M+ 独特的会话。有什么建议，想法吗？

4

2 回答 2

4

让我们了解基于浏览器的cookies的作用

  • Cookie 是按浏览器配置文件存储的。
  • 从不同计算机或浏览器登录的同一用户被视为不同用户。
  • 状态 cookie 与用户 cookie 混合

隔离 cookie。

  • 长期状态 cookie，例如当前记住的 userId。
  • 会话状态 cookie
  • 用户 cookie

读到您的站点才刚刚开始考虑服务器端 cookie，这意味着尚未完成 cookie 的隔离。用户 cookie 应尽可能存储在服务器上，以便当用户在另一台计算机或浏览器上登录时，偏好和购物车被保留。您的开发团队必须决定将某些 cookie（例如购物车）置于会话状态或用户信息 cookie 之间。

用户 cookie 需要在整个网站上可访问，无论用户在哪里登录。您的开发人员必须决定，当用户更新偏好或购物车时，如果相同的 userId 在另一个用户登录地点。

这意味着您必须实现分布式数据库系统。您有一个主数据库服务器。假设您有 20 台 Web 服务器，每台服务器都有自己的数据库。

仅将经常更改的 cookie 存储在本地数据库上，并将不经常更改的 cookie 留在主数据库上。

每次在本地数据库更新 cookie 时，都会将更新的标志排队等待更新到主数据库。master 中的 cookie 记录没有更新，只是用新数据所在的位置号标记为过时。因此，如果该用户 ID 以某种方式同时在 3000 英里外被激活，该会话将找出陈旧的记录并触发将这些记录从新位置复制到其自己的本地数据库和主数据库的请求，并且记录不再标记为主数据库上陈旧。

然后，您安排定期同步最常用的 cookie。同步频率可以是每晚，也可以取决于 cookie 修改的表征结果。

首先，您的程序员需要编写一个例程来记录所有 cookie 读/写。您应该收集一周的 cookie 读/写活动来执行初始组件分析。

您对每个 cookie、用户 ID 和更改频率执行简单的统计表征。然后根据您的偏好滑动，决定将哪些 cookie 推送到所有本地数据库，哪些保留在主数据库上。决策在本地 dbs 上的 cookie 块大小和您愿意允许的数据库同步频率之间取得平衡。这意味着并非每个用户都传播了相同的 cookie 集。当然，您的程序员需要编写例程来自动执行定期重新表征。您可能希望通过使用集群分析对用户进行分组来减轻 cookie 传播的处理负载，而不是按用户。可能是您网站的用户分组非常明显，您无需执行聚类分析。

您可能会惊讶地发现，大多数 cookie 可能会落入比每周更新时间更长的存储桶中。或者更糟糕的情况，每日更新。您应该接受的最坏情况是每小时更新未推送到本地数据库的 cookie 字段。您希望增加在本地数据库上发生 cookie 访问而不是从主数据库中提取的机会。因此，当用户决定点击很少更改的“首选项”时，您会抢先从主人那里拉取首选项记录，同时用一些花哨的东西分散用户的注意力，例如“你考虑过预览我们的新服务吗？”，“你想回答我们的可用性调查？”、“新的 Gibson 咆哮，你会发表评论吗？”等，直到“偏好”cookie 被复制。

cookie 的表征可以按用户 ID 或按用户集群来决定将哪个 cookie 字段推送到本地数据库。

对每个用户 ID 进行表征更加简单，因为它几乎不涉及程序员的任何统计分析技能。缺点是 Web 服务器必须为 2 亿用户中的每一个执行决策。数据库 cookie 表将是

Cookie[id, param, value, expectedMutationInterval].

您的网络服务器将决定每个用户在阈值时间之前定期推送哪些 cookie。

SELECT param, value
WHERE expectedMutationInterval < $thresholdTime
  AND id = UserId

您必须定期对 cookie 进行重新表征，以更新每个 cookie 的每个用户的 expectedMutationInterval。一个简单的 SQL 查询将能够执行 expectedMutationInterval 的更新。可以执行更复杂的分析以产生值 expectedMutationInterval。

如果每个 cookie 字段更改都按时间、用户 ID 和 ipaddr 记录，那么您的 Cookie 日志表将是

CookieLog[id, time, ipaddr, param, value].

这将有助于您的自动重新表征例程根据星期几/月/季节和位置/区域/ipaddr 决定要推送哪些字段。

然后在从浏览器中删除用户信息 cookie 后，如果您仍然发现会话 cookie 溢出，您现在决定将哪些会话 cookie 推送到浏览器，哪些保留在本地服务器上。您使用相同的主本地数据库分析技术，但现在用于在本地数据库和推送到浏览器之间做出决定。您将最不常访问的会话 cookie 保留在本地服务器上，作为会话属性或内存数据库。因此，当客户端发现缺少 cookie 时，它​​会向服务器请求 cookie，同时牺牲浏览器上一些最近/经常使用的 cookie 空间来容纳新 cookie 的放置。

由于这些是会话 cookie，因此需要将它们传播到其他位置，因为如果在 3000 英里外登录相同的用户 ID，它应该有自己的一组会话 cookie。

浏览器 cookie 的特征具有讽刺意味，因为对于 AJAX 应用程序，客户端在不让服务器知道的情况下访问 cookie。让服务器知道可能会破坏首先将 cookie 放置在浏览器中的目的。因此，您必须选择空闲时间以将 cookie 访问发送到服务器以进行记录 - 出于表征目的。

这种粒度级别适用于长度较短的 cookie（参数值 + 参数名称），无论是基于会话的 cookie 还是基于用户的 cookie。

因此，如果您的参数名称和 cookie 字段的值很长，您可能会寻求量化它们。但是，量化要复杂一些。浏览器 cookie 有很多共性。就像任何量化/压缩方法一样，您寻找共性集群并为每个共性块分配一个签名。然后根据量化签名存储 cookie。

您如何促进基于浏览器的 cookie 的量化？以 GWT 为例，使用 Dictionary 或 Map 类。

例如，cookie "%1"="^$Kdm3i" 可能会转换为 LastConnectedFriend=MohammadAli@jinnah。

您应该不需要执行表征，例如，当您可以将其映射到“%1”时，为什么将您的 cookie 存储为“LastConnectedFriend”？当用户登录时，为什么不映射最常访问的朋友等，并将该映射放在 GWT/AJAX 启动页面上？这样，您可以缩短会话 cookie 的长度。

那么，贵公司是否在寻找统计程序员？免责声明是，这是即兴的，可能需要一些事实性的重新调整。

于 2010-07-21T20:17:54.437 回答
4

memcached的作业，或者，如果您想将会话数据保存到磁盘，memcacheddb

Memaced 是一个免费和开源的高性能分布式内存对象缓存系统，本质上是通用的，但旨在通过减轻数据库负载来加速动态 Web 应用程序。

Memcached 是一种内存键值存储，用于存储来自数据库调用、API 调用或页面渲染结果的任意数据（字符串、对象）的小块。

Memcached 简单但功能强大。其简单的设计促进了快速部署、易于开发，并解决了大数据缓存面临的许多问题。它的 API 适用于大多数流行的语言。

于 2010-07-21T20:06:34.663 回答