前言说道“心跳”这个词大家都不陌生，当然不是指男女之间的心跳，而是和长连接相关的。 顾名思义就是证明是否还活着的依据。 什么场景下需要心跳呢？ 目前我们接触到的大多是一些基于长连接的应用需要心跳来“保活”。 由于在长连接的场景下，客户端和服务端并不是一直处于通信状态，如果双方长期没有沟通则双方都不清楚对方目前的状态；所以需要发送一段很小的报文告诉对方“我还活着”。

前言 最近这段时间确实有点忙，这篇的目录还是在飞机上敲出来了的。 言归正传，上周更新了 cim 第一版：为自己搭建一个分布式 IM(即时通讯) 系统；没想到反响热烈，最高时上了 GitHub Trending Java 版块的首位，一天收到了 300+ 的 star。

前言大家新年快乐！ 新的一年第一篇技术文章希望开个好头，所以元旦三天我也没怎么闲着，希望给大家带来一篇比较感兴趣的干货内容。 老读者应该还记得我在去年国庆节前分享过一篇《设计一个百万级的消息推送系统》；虽然我在文中有贴一些伪代码，依然有些朋友希望能直接分享一些可以运行的源码；这么久了是时候把坑填上了。 本文较长，高能预警；带好瓜子板凳。

前言看着今年的进度表已经所剩无几，是时候来复盘一把了。

前言到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。 还真是想什么来什么，前些天还故意把某些服务器的负载提高（没错，老板让我写个 BUG！），不过还好是不同的环境互相没有影响。

前言标题没有看错，真的是让我写个 bug！ 刚接到这个需求时我内心没有丝毫波澜，甚至还有点激动。这可是我特长啊；终于可以光明正大的写 bug 了🙄。 先来看看具体是要干啥吧，其实主要就是要让一些负载很低的服务器额外消耗一些内存、CPU 等资源（至于背景就不多说了），让它的负载可以提高一些。

前言最近有朋友问我这么一个面试题目： 现在有一个非常庞大的数据，假设全是 int 类型。现在我给你一个数，你需要告诉我它是否存在其中(尽量高效)。 需求其实很清晰，只是要判断一个数据是否存在即可。 但这里有一个比较重要的前提：非常庞大的数据。

前言之前写过一篇《从源码分析如何优雅的使用 Kafka 生产者》 ，有生产者自然也就有消费者。 建议对 Kakfa 还比较陌生的朋友可以先看看。 就我的使用经验来说，大部分情况都是处于数据下游的消费者角色。也用 Kafka 消费过日均过亿的消息（不得不佩服 Kakfa 的设计），本文将借助我使用 Kakfa 消费数据的经验来聊聊如何高效的消费数据。

前言磨了许久，借助最近的一次通宵上线 cicada 终于更新了 v2.0.0 版本。 之所以大的版本号变为 2，确实是向下不兼容了；主要表现为： 修复了几个反馈的 bug。 灵活的路由方式。 可拔插的 IOC 容器选择。 其中重点是后面两个。

背景最近时运不佳，几乎天天被线上问题骚扰。前几天刚解决了一个 HashSet 的并发问题，周六又来了一个性能问题。 大致的现象是： 我们提供出去的一个 OpenAPI 反应时快时慢，快的时候几十毫秒，慢的时候几秒钟才响应。 尝试解决由于这种也不是业务问题，不能直接定位。所以尝试在测试环境复现，但遗憾的测试环境贼快。 没办法只能硬着头皮上了。 中途有抱着侥幸心里让运维查看了 Nginx 里 O