我想实现一个面向用户的视图计数器(类似于SO对于问题视图的视图),它跟踪页面的唯一视图的数量.这里有几个问题,但似乎没有一个问题完全回答我的问题.
什么是最好的设置(在数据库表等方面)？将’views’列添加到’questions’表并在每个页面视图上增加它会不会很好？如果我希望视图是唯一的,我想我可以有另一个带有问题ID和IP地址的表,如果还没有当前IP的条目,则只增加“视图”列.然而,这个’ip-view’表会很快变得很有用……主要是我担心必须在表中存储每个页面视图和每个IP的开销.
如何对其进行优化以使其不会成为性能瓶颈？有没有比我描述的更好的方法？请注意,对我来说非常重要的是只计算独特的观点.
更新：除了建议实现方法之外,我还想进一步了解性能问题在哪里发挥作用,假设只是简单地检查IP是否存在以及更新每个页面视图上的“视图”列的简单方法.主要问题是发生大量插入(假设流量很大),还是更大的对象到ip映射表的大小(这可能很大,因为每个新的唯一访问者每个问题都会插入一个新行).是否应考虑竞争条件(我只是假设更新/增量sql语句是原子的)？对不起所有的问题,但我只是迷失了我应该如何处理这个问题.
如果您需要专门跟踪独特的视图,可能有两种方法可以执行此操作…除非您使用可以识别的内部用户进行操作.现在,为了做到这一点,您需要跟踪访问该页面的每个用户.
原文链接：https://www.f2er.com/php/136818.html跟踪可以在服务器端或客户端完成.
服务器端需要是IP地址,除非您正在处理可以识别的内部用户.每当您处理IP地址时,所有关于使用它们来识别人员的常见警告(每个IP可能有多个用户,或每个用户可能有多个IP),您无法做任何事情.
您还应该考虑“巨大的IP死亡表”并不是一个解决方案.如果你有成千上万的用户,性能只会成为一个问题……当然,假设它被正确编入索引.
客户端可能会让您离开“我已经访问过！”曲奇饼.如果cookie不存在,则增加用户数.如果无法创建cookie,则必须使用膨胀的用户视图.关于处理cookie的所有警告都适用……也就是说,它们最终会变坏并消失.
