确保我的 Go 页面浏览计数器没有被滥用答案

【问题标题】：Making sure my Go page view counter isn't abused确保我的 Go 页面浏览计数器没有被滥用
【发布时间】：2017-10-09 07:18:13
【问题描述】：

我相信我找到了一个非常好的快速解决方案来有效地计算页面浏览量：

此处为 go playground 中的工作示例：https://play.golang.org/p/q_mYEYLa1h

我的想法是每 X 分钟将其推送到数据库，并在按下键后将其从页面映射中删除。

我现在的问题是，确保不被滥用的最佳方法是什么？理想情况下，如果自上次访问页面后有 2 小时的时间间隔，我只想增加同一个人的页面计数。据我所知，存储和比较 IP 和用户代理是理想的（我不想依赖 cookie/localstorage），但我不太确定如何有效地存储和比较这些信息。

我可能会从 http.Request 获得 IP (req.Header.Get("x-forwarded-for")) 和 UserAgent (req.UserAgent())。

我正在考虑创建一个类似于我的页面结构的访问者结构，如下所示：

type visitor struct {
    mutex          sync.Mutex
    urlIPUAAndTime map[string]time
}

这种方式应该可以做与以前类似的事情。但是，想象一下，如果网站有如此多的请求，将存储数亿个唯一访问者地图，而每个访问者地图只能在 2（或更多）小时后被删除。因此，我认为这不是一个好的解决方案。

我猜想写入和读取某个文件是理想的/必要的，但不确定如何有效地完成此操作。非常感谢您的帮助

【问题讨论】：

大部分优化可能不需要，但是在我们的办公室，因为我们正在处理大量数据；我们使用 nosql 存储来自不同客户端的各种更新，然后我们对我们的数据进行某种分析，继续对我们的数据进行某种汇总；因此我们稍微关注客户端如何更新，更多关注更新本身的内容
定义“同一个人”。
@zerkms 也许“同一设备”是一个更好的术语。应该防止人们通过简单地刷新页面来增加查看次数
@fisker HTTP 没有“设备”概念。只需设置一个包含上次计算访问时间的 cookie。
其中任何一个都很容易被滥用，我看不出有什么区别。但是 cookie 解决方案更便宜且更易于实施/维护。现在考虑您是否要对能够有效提供同样低水平保护的解决方案进行更多投资。我不坚持，你自己决定。

标签： go

【解决方案1】：

其中一种优化方法是在此地图之前添加一个布隆过滤器。布隆过滤器是一种概率结构，可以说是其中之一：

这个用户绝对是新用户
这个用户可能在这里

这是一种在早期阶段切断计算的方法。如果您的许多用户是新用户，那么您将请求保存到数据库以检查所有用户。如果结构说“用户可能不是唯一的”怎么办？然后你去数据库并检查它。这里还有一个优化：如果您不需要非常准确的信息并且可以同意大约百分之几的错误，您可以使用唯一的布隆过滤器。我想许多大型网站都使用这种技术进行估算。

【讨论】：

嗯，已经阅读了一些关于 Bloom 过滤器的信息 - 听起来很复杂。如果我理解正确，那么布隆过滤器将成为页面结构的一部分？但是布隆过滤器需要用 N 个项目初始化，其中每个项目是一个组合的 IP+UA 字符串。但是假设我想非常乐观（委婉地说）并假设一个页面可能有一天会获得 10 亿独立访问者。这意味着每个页面都必须使用 10 亿个项目进行初始化，因为一旦第一次设置就不可能增加它？
我一直在考虑更多，也许一种解决方案是有一个布隆过滤器切片，其中初始项目大小为 1000，如果它被填满，则可以附加一个新过滤器大小为 50.000，然后是 100.000，等等。不确定这是否有意义，或者它是否有效/低效（甚至可能）..
另一种选择可能是在bloomfilter达到1000时简单地删除并替换它。这样，同一个访问者仍然可以考虑多个视图（这不是一件坏事），但他不能滥用它，因为这需要 999 次其他浏览量才能计算他的新浏览量。
布隆过滤器可以是主过滤器之前的单独结构。 github上有几个实现，我没有看过它们。 BF 的一个很好的特性是它可以根据所需的内存 - 误报概率 - 唯一键的数量进行调整。这是一个计算器 - hur.st/bloomfilter?n=1000000000&p=0.01 您需要大约 1.12GB 的空间来存储 1B 键，误报概率为 1%。
简单一点的想法：hash (ip+ua) 然后 map 只取最后 30 位并将数据放入 125M 内存 - 只需设置相应的位。我没有测试过这个。我认为这会产生更多的误报，但会运行得更快并且使用更少的空间。