当网站运营的时长达到一定程度后，就难以避免地会碰到一部分不请自来的访客。收藏功能原本是为了助力用户能够迅速进行回访而设计的，然而却总会有一些人借助脚本或者工具，以批量点击收藏按钮的方式，刷出不真实的数据，对统计工作造成干扰，甚至还会使服务器的运行速度变慢。对于这种恶意的收藏刷量行为，仅仅依靠前端进行限制，几乎不会产生任何效果，必须要从后端的逻辑以及策略层面上设立屏障来加以防范。

收藏刷量是哪里来的问题

不少站长起初觉得收藏刷量不过是几个闲着没事干的用户手动点击的，可实际上大多是自动化脚本在作祟。这些脚本模仿正常用户的操作，于短时间之内向收藏接口发送大量请求，绕过前端验证径直操作数据库。

若你不采取任何防护措施，一日之内收藏表当中或许会多出几千条没有效用的数据。更为棘手的是，这些虚假的数据会致使你的推荐算法和用户画像均偏离正轨，甚至造成服务器负载急剧攀升，进而影响真实用户的访问。

所以，防刷收藏的核心思路在于，要使得机器操作的成本比收益更高，与此同时，还不能对真实用户的正常使用造成影响。前端添加验证码、限制点击频率这些仅仅是最为基础的，而真正具备效果的防刷，必然要与服务端限流、行为分析以及数据校验相结合。

怎么搭建一套实用的防刷收藏系统

具体搭建时，我建议分三步走，每一步都能挡住大部分恶意请求。

针对接口层面的限流，首先要做一件事，这件事呢，是借助Nginx或者应用层的有关中间件，像Redis这类的，去开展对应操作，操作的内容是达成IP级别的频率控制。比如说有这样一种情况，就是一个IP在10秒的时间范围内，仅仅能够触发一次收藏的相关操作，一旦超过了这个限定，那么就要返回429状态码，并且给出提示，提示内容是“操作太频繁”。要是涉及到登录用户，那么在此基础之上，还能够增添用户ID维度的限流措施，其目的在于防止通过更换IP的方式继续进行刷操作。

# Nginx限流配置示例
limit_req_zone $binary_remote_addr zone=collect_limit:10m rate=6r/m;
location /api/collect {
    limit_req zone=collect_limit burst=1 nodelay;
}

紧接着的步骤是增添行为校验，一般情况下，正常的用户在收藏一篇文章之时，往往是先对页面进行一段时长的浏览，并非在页面刚被打开之际就立刻实施点击收藏 的动作，那么此处你的后端完全能够记录下用户从进入页面开始一直到发起收藏行为之间的时间间隔，要是该时间间隔小于 3 秒，便直接判定这属于机器操作行为，随后写进日志然而却并不进行落地存储，与此同时，要核查 Referer 是否源自本站，虽说这是可以被人造假伪造的，不过它能够阻挡住最为浅显的攻击行为。

第三步是在数据层面进行去重以及异常检测，于收藏表之中建立用户ID与内容ID的唯一索引，以此来防止同一用户反复收藏同一内容，另外，编写一个定时脚本，统计每个用户每日的收藏频率，倘若某用户一天的收藏量超出正常阈值（譬如100次），便自动将该用户添加入黑名单，下次请求时直接返回错误。

MySQL唯一索引示例
ALTER TABLE user_collect ADD UNIQUE INDEX idx_user_content (user_id, content_id);

日誌監控絕不可缺，將每次遭攔截的請求，記錄於獨立的日誌文件之中，定期剖析IP來源以及UA特徵，若察覺大量請求源自相同IP段或者重複的User - Agent，便直接封禁整個段，此步驟雖屬手動操作，然而卻能有效清除頑固的刷量源。

并非一次性简单终结的事情是收藏防刷，攻击手段会持续朝着进阶方向发展，你所运用的防护举措也得定期予以更新。在构建好基础的三层防护之后，平日里只需聚焦于异常日志，适时对限流参数作出调整，便能致使恶意刷量的成本攀升至无人甘愿去触碰你的站点。http://www.fouwan.com