当代码中在多个线程中访问一个数据时，该数据就需要进行保护，保证在查询和修改时不会因为其它线程的操作而产生不可预料的异常。

下面简单总结了 Java 多线程开发中几个不同场景下的线程安全类和锁的使用样例。

爱快软路由有非常完善的监控功能，但因为是爱快自己的体系，很不灵活，只能满足基本的使用，没法在 Prometheus 里使用，想要做些告警的功能就更不行了。

再加上最近跑网心云的虚机挂了几天才发现，搞一套内网的监控告警体系迫在眉睫了。对于家庭内网的监控告警，有几个需求需要满足：

1. 能统计每天设备的流量
2. 能对公网在线状态进行监控告警
3. 能对设备的在线状态进行监控告警

基于 JWT 来实现 Token 认证很简单，相对复杂的签名认证算法都已经封装到工具包里，使用起来很容易。

而真正造成 JWT 的应用困难其实是在适应业务上，并不是所有业务都适合原生的 JWT 特性。我们很多时候选型使用 JWT 看重的是其无状态和校验方便的优点，但在实际的业务场景中经常是要 Revoke 功能的。

如果要实现 Token 的 Revoke 那 Token 会变成有状态，这让人使用起来非常纠结。 我都有状态了为啥还要用 JWT？直接生成一个 ID 存 Redis 不更简单？直接用 Redis 缓存有效性来控制 Token 的有效性，失效删除就好了。

最终选择使用 JWT 作为 Token 主要是基于以下考虑：

1. JWT 实现完善，有丰富的开发工具包；
2. 不需要自己再设计一套 Token 结构和校验算法；
3. 可以利用 JWT 进行前置验证（JWT 正确性、是否超时失效），避免每次都查询缓存；
4. JWT 可以基于 Payload 存储数据，使用很灵活，可以提供保存一些数据在 Token 中避免查询；
5. JWT 签名方法很丰富，能满足以后演进的需要，能实现一处签发，多处验证。

和漏桶算法算法类似，令牌桶算法的核心是固定“进口”速率，可以应对突发流量，是非常非常常用的算法。

• 桶里装的是令牌
• 在被处理之前需要拿到一个令牌，请求处理完毕之后将这个令牌丢弃（删除）
• 拿不到令牌就被「流量干预」
• 根据限流大小，按照一定的速率往桶里添加令牌

通常在实现中，令牌的增加都是基于时间的延迟计算和预消费的思想。

漏桶算法把发请求的动作比作成注水到桶中，处理请求的过程可以比喻为漏桶漏水。

往桶中以任意速率流入水，以一定速率流出水，当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

滑动窗口其实就是对固定窗口做了进一步的细分，将原先的粒度切的更细，相当于固定窗口计数器算法的升级版。

如果固定窗口的「固定周期」已经很小了，那么使用滑动窗口的意义也就没有了。

本文整理了滑动窗口计数器的伪代码、Redis、Go 的实现方法。

固定窗口计数器规定单位时间处理的请求数量。该算法无法保证限流速率，因而无法保证突然激增的流量。优点是容易理解，实现简单。

本文整理了固定窗口计数器的伪代码、Redis、Go 和 Java 的实现方法和思路。

在并发编程领域有一些名词我经常搞混淆，被问及也无法答出个所以然。所以在这里我把这些容易搞迷糊的概念整理一下，方便查阅。