架构师如何高效管理100w+定时事件？？？（第30讲）

主要观点总结

文章主要介绍了《架构师之路：架构设计中的100个知识点》中关于海量定时事件管理的知识点。文章描述了三种处理海量定时事件的方法：轮询扫描法、多timer触发法、环形队列法，并解释了每种方法的特点和适用场景。

关键观点总结

关键观点1: 文章背景介绍

文章首先介绍了关于海量定时事件管理的场景，例如有100W个用户uid在线接单时的存活上报处理。

关键观点2: 轮询扫描法

该方法使用一个Map记录每个uid的最近一次上报时间，并启动一个timer进行轮询扫描。特点是只启动一个timer，但CPU消耗较大。

关键观点3: 多timer触发法

该方法同样使用Map记录上报时间，但为每个uid启动一个timer。特点是无需轮询，但timer的维护量较大，内存消耗较多。

关键观点4: 环形队列法

该方法使用环形队列和Set、Map结构，只需一个timer，既不耗内存也不耗CPU，业务处理效率高。环形队列法是一个通用方法，适用于其他场景。

关键观点5: 文章总结和补充材料

文章最后对三种方法进行了总结，并提供了补充阅读材料《HashedWheelTimer》的链接。系列文章《架构师定会遇到的80个经典架构问题》等也值得关注。

文章预览

《架构师之路：架构设计中的100个知识点》 30.海量定时事件管理 什么场景会用到海量定时事件？ 例如：有100W个用户uid在线接单，客户端每30s会有一个存活上报，如果30s没有上报，服务端要将用户的状态置为不可接单。 一般如何怎么实现这类需求？ 大体来说，有三类方法： 方案一：轮询扫描法。 1. 用一个Map 来记录每一个uid最近一次上报时间； 2. 当某个用户uid 存活上报时 ，实时更新这个Map； 3. 启动一个timer，轮询扫描这个Map，看每个uid的last_time是否超过30s，如果超过则进行超时处理； 这个方案的特点是： 只启动一个timer，但要轮询，CPU会跑满，比较消耗计算资源。 方案二：多timer触发法。 1. 还是用一个Map 来记录每一个uid最近一次上报时间； 2. 当某个用户uid 存活上报时 ，实时更新这个Map，并同时对这个uid启动一个timer，30s之后触发； 3. 每个u ………………………………