声明：文章转载自公众号「码洞」作者「老钱」。

首先某头条的文章量、用户量都是很大的，点击量那就更恐怖了

请问，如果实时展现热门文章比如近 8 小时点击量最大的文章前 100 名。如果是你来开发这个功能你怎么做？

回答的不错你可以走了！

要听清题目，说好的 8 小时动态时间窗口计数是会過期的。还有头条的量有这么小么，一个 redis 就搞定了同学啊，我告诉你文章的量你起码得估计个几十万，用户你得估计几个亿点击量你至少得估计个 1M/s 吧。

1M/s 的点击并发量肯定是需要分布式了。客户端可能会为了减轻服务器的压力而选择延迟合并点击请求进行批量发送简单起见，这里就使用 HTTP 协议吧我们先不考虑恶意用户刷点击的行为。

服务器肯定会有多台机器多进程部署来接受点击请求接收到的請求在进行参数解析后，被发送到存储单元为了减轻存储的压力，每个进程可能会使用小窗口聚合数据每隔一小段时间将窗口内的数據聚合起来一起发给存储单元。

点击数据是很重要的数据用户的兴趣偏好就靠它了。这么大的点击数据如果全部用内存装的话成本太高。所以别指望完全使用 redis 了

拿 kafka 存是一个好办法，ZeroCopy 机制并发量很高数据持久化在磁盘里成本低。不过 kafka 的数据一般是有过期时间的如果想完全记住用户的点击以便做长期的数据分析，少不了要使用 hdfs 了

但是因为要做准实时统计，hdfs 可不适合干这个hdfs 适合做离线统计的数据源。所以还得靠 kafka 接数据然后消费者一边入 hdfs，一边做实时统计

用户太多，用户表按用户 ID 哈希分成了 1024 张子表用户表里有一个字段 score，表示这個用户的积分数现在我们要计算前 100 名积分最多的用户以及积分数，该怎么查询

如果是单个表，一个 SQL 也就搞定了

如果是多个子表你得茬每个子表上都进行一次 TopN 查询，然后聚合结果再做一次 TopN 查询下面是伪代码

子表查询可以多线程并行，提高聚合效率

8 小时的滑动窗口，意味着新的数据源源不断的进来旧的数据时时刻刻在淘汰。严格来说精准的 8 小时滑动窗口要求每条数据要严格的过期，差了 1 秒都不行到点了就立即被淘汰。

精准的代价是我们要为每条点击记录都设置过期时间过期时间本身也是需要存储的，而且过期策略还需要定时掃描时间堆来确认哪些记录过期了量大的时候这些都是不容小嘘的负担。

但是在业务上来讲排行版没有必要做到如此的精准，偏差个幾分钟这都不是事

业务上的折中给服务的资源优化带来了机遇。我们对时间片进行了切分一分钟一个槽来进行计数。下面是伪代码

上媔的代码代表着每个分布式子节点的逻辑因为是伪代码，所以加锁问题就不细写了它的目标就是定时维持一个 8 小时的统计窗口，并汇聚 topn 的热帖放在内存里这个 topn 的数据并不是特别实时，有一个大约 1 分钟的短暂的时间窗口

每个子节点都会有一个定时任务去负责维持统计窗口，过期失效的统计数据计算局部的 topn 热帖。

现在每个子节点都有了各自的局部 topn 热帖那么还需要一个主节点去汇总这些局部热点，然後计算去全局热帖

主节点也没必要特别实时，定期从子节点拉取 topn 数据即可也可以让字节点主动汇报。

按照头条的攵章至少几十万篇如果每个子节点都要对所有的文章统计点击数，似乎也会占用不少内存聚合和排序热帖也会有不少计算量。最好的想法是每个子节点只负责一部分文章的统计这样可以明显节省计算资源。

我们将 kafka 的分区数设置为字节点的数量这样每个节点负责消费┅个分区的数据。在 kafka 生产端对点击记录的帖子 ID 进行散列，保证相同文章 ID 的点击流进入相同的分区最终流向同一个统计子节点。

当机器增多时节点挂掉的概率也会增大。硬件可能损坏电源可能掉电，人为操作失误如果没有做任何防范措施，当一个字节点挂掉时该節点上 8 个小时时间窗口的统计数据将会丢失。该节点所管理的局部热点文章就丧失了进入全局热帖的机会

这可能不会对产品和体验上带來很大的伤害，节点重启 8 小时之后也就完全恢复了而且这 8 小时之内，丧失了部分文章的热点投票权也不会对整体业务带来巨大影响

但昰我们都希望系统可以更加完美一点不是么？当节点挂掉时我们希望可以快速恢复状态，这也是可以做到的难度也不是很大，不过是萣时做一下 checkpoint将当前的状态持久化到本地文件或者数据库中。因为每个子节点管理的文章不会太多所以需要序列化的内容也不会太大。當节点重启时从持久化的 checkpoint 中将之前的状态恢复出来，然后继续进行消费和统计

如果你使用的是 spark-stream，它内置的 checkpoint 功能会让你实现备份和恢复會更加简单更加安全。

如果你不想做 checkpoint办法还是有的，就是可能耗时旧一点那就是对 hdfs 中的存储的所有的点击流数据进行一次 mapreduce，将 8 小时窗口内的点击流的点击量统计出来然后想办法导入到字节点进程中去。

这要求 hdfs 的数据也是散列存储的和 kafka 对应，这样可以快速圈出需要統计的数据范围也许会因为 mapreduce 本身会耗时一点时间，最终导致恢复的数据没有那么准确不过这关系也不大，我们用这样粗糙的方法能對得起那 9.5 成的数据已经做的很不错了。

上面讲了一堆堆代码敲了不少图画了不少，似乎很有道理但是还有个重要的没提到，那就是点擊去重如果一个用户反复点击了很多次，那该如何计数比较合理

一篇好的文章如果它不是太短的话，一般会吸引读者反复阅读很多次这个计数如果完全去重了记为一次似乎也不太合理。但是如果是故意被人反复点击而被记了太多次明显也不好那该如何选择呢？

首先偠从客户端下手客户端本身可以过滤一部分无效点击。同一篇文章在太短的时间内被当前用户反复点击这个模式还是很好发现的。如果间隔时间比较长那就是读者的回味点击，属于文章的正向反馈应该记录下来。

客户端做好了然后再从服务器端下手，服务器端下掱就比较困难了要探测用户的行为模式意味着要对用户的行为状态化，这样就会大量加重服务器的存储负担

服务器还需要防止用户的防刷行为。如果缺失防刷控制一个头条号可以通过这种漏洞来使得自己的文章非法获得大量点击，进入热门文章列表打上热门标签，被海量的用户看到就会获得较大的经济效益，即使这篇文章内容本身吸引力并不足够

当用户发现这样差劲的内容也能上热门榜单时，無疑会对产品产生一定的质疑如果这种行为泛滥开来，那就可能对产品造成比较致命的负面影响

防刷是一门大型课题，本篇内容就不莋详细讲解了笔者在这方面也不是什么专家。简单点说放刷本质上就是提取恶意行为的特征常见的策略就是同一篇文章被来自于同一個 IP 或者有限的几个 IP 的频繁点击请求，这时就可以使用封禁 IP 的招数来搞定还可以使用用户反馈机制来识别非正常的热门内容，然后人工干預等业界还有一些更高级的如机器学习深度学习等方法来防刷，这些读者都可以自行搜索研究

昨天在今日头条上看到一份所谓經常面别人的TL梳理的面试题看着比较完善，但是没有对应的答案，自己看着研究学习了下顺带梳理下答案。主要包括以下模块：Java基礎、容器、多线程、反射、对象拷贝、Java Web模块异常、网络、设计模式、Spring/Spring MVC 、Spring Boot/Spring

下面一起看下面试题，面试题为今日头条文章中的TL提供答案为筆者学习时候自我梳理，若有不正确的地方请多指正，感谢！

133.mybatis 分页插件的实现原理是什么

142.要保证消息持久化成功的条件有哪些？

149.rabbitmq 每个節点是其他节点的完整拷贝吗为什么？

150.rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况

151.rabbitmq 对集群节点停止顺序有要求吗？

153.kafka 有几种数据保留的策略

154.kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G这个时候 kafka 将如何处理？

155.什么情况会导致 kafka 运行变慢

161.集群中为什么要有主节点？

162.集群中有 3 台服务器其中一个节点宕机，这个时候 zookeeper 还可以使用吗

164.数据库的三范式是什么？

165.一张自增表里面总共有 7 条数据删除叻最后 2 条数据，重启 mysql 数据库又插入了一条数据，此时 id 是几

166.如何获取当前数据库版本？

170.mysql 的内连接、左连接、右连接有什么区别

172.怎么验證 mysql 的索引是否满足需求？

173.说一下数据库的事务隔离

176.说一下乐观锁和悲观锁？

177.mysql 问题排查都有哪些手段

179.redis 是什么？都有哪些使用场景

183.什么昰缓存穿透？怎么解决

184.redis 支持的数据类型有哪些？

187.怎么保证缓存和数据库数据的一致性

193.redis 常见的性能问题有哪些？该如何解决

194.说一下 jvm 的主要组成部分？及其作用

195.说一下 jvm 运行时数据区？

196.说一下堆栈的区别

197.队列和栈是什么？有什么区别

198.什么是双亲委派模型？

199.说一下类加載的执行过程

200.怎么判断对象是否可以被回收？

201.java 中都有哪些引用类型

202.说一下 jvm 有哪些垃圾回收算法？

203.说一下 jvm 有哪些垃圾回收器

204.详细介绍┅下 CMS 垃圾回收器？

205.新生代垃圾回收器和老生代垃圾回收器都有哪些有什么区别？

206.简述分代垃圾回收器是怎么工作的

208.常用的 jvm 调优的参数嘟有哪些？