前言

最近分享的一些源码、框架设计的东西。我发现大家热情不是特别高，想想大多数应该还是正儿八经写代码的居多；这次就分享一点接地气的： SpringBoot 使用中的一些小技巧。

算不上多高大上的东西，但都还挺有用。

前言

在上文 设计一个百万级的消息推送系统 中提到消息流转采用的是 Kafka 作为中间件。

其中有朋友咨询在大量消息的情况下 Kakfa 是如何保证消息的高效及一致性呢？

正好以这个问题结合 Kakfa 的源码讨论下如何正确、高效的发送消息。

内容较多，对源码感兴趣的朋友请系好安全带😏(源码基于 v0.10.0.0 版本分析)。同时最好是有一定的 Kafka 使用经验，知晓基本的用法。

前言

本次 Cicada 已经更新到了 v1.0.3。

主要是解决了两个 issue，#9 #8。

所以本次的主要更新为：

• Cicada 采用合理的线程分配来处理接入请求线程以及 IO 线程。
• 支持多种响应方式（以前只有 json，现在支持 text）。
• 为了满足上者引入了 context。
• 优雅停机。

其中我觉得最核心也最有用的就是这个 Context，并为此重构了大部分代码。

前言

首先迟到的祝大家中秋快乐。

最近一周多没有更新了。其实我一直想憋一个大招，分享一些大家感兴趣的干货。

鉴于最近我个人的工作内容，于是利用这三天小长假憋了一个出来（其实是玩了两天🤣）。

先简单说下本次的主题，由于我最近做的是物联网相关的开发工作，其中就不免会遇到和设备的交互。

最主要的工作就是要有一个系统来支持设备的接入、向设备推送消息；同时还得满足大量设备接入的需求。

所以本次分享的内容不但可以满足物联网领域同时还支持以下场景：

• 基于 WEB 的聊天系统（点对点、群聊）。
• WEB 应用中需求服务端推送的场景。
• 基于 SDK 的消息推送平台。

技术选型

要满足大量的连接数、同时支持双全工通信，并且性能也得有保障。

在 Java 技术栈中进行选型首先自然是排除掉了传统 IO。

那就只有选 NIO 了，在这个层面其实选择也不多，考虑到社区、资料维护等方面最终选择了 Netty。

最终的架构图如下：

前言

在前两次的 cicada 版本中其实还不支持读取配置文件，比如对端口、路由的配置。

因此我按照自己的想法创建了一个 issue ，也收集到了一些很不错的建议。

最终其实还是按照我之前的想法来做了这个配置管理。

同时将 cicada 升级到了 v1.0.2。

原文链接

代码昨天还是运行好好的今天就不行了。

代码被删了。

突然出现了一个奇怪的 bug，但是没人知道怎么回事。

如果你出现过上面的任何一种情况，那本篇文章就是为你准备的。

除了知道 git add, git commit , git push 之外，Git 中还需要其他重要的技术需要掌握。长远来看对我们是有帮助的。这里我将向你展示 Git 的最佳实践。

前言

两天前写了文章《「造个轮子」——cicada(轻量级 WEB 框架)》 向大家介绍了 cicada 之后收到很多反馈，也有许多不错的建议。

同时在 GitHub 也收获了 100 多颗 小♥♥（绝对不是刷的。。）

也有朋友希望能出一个源码介绍，本文就目前的 v1.0.1 版本来一起分析分析。

没有看错，刚发布就修复了一个 bug，想要试用的请升级到 1.0.1 吧。

前言

俗话说 「不要重复造轮子」，关于是否有必要不再本次讨论范围。

创建这个项目的主要目的还是提升自己，看看和知名类开源项目的差距以及学习优秀的开源方式。

好了，现在着重来谈谈 cicada 这个项目的核心功能。

我把他定义为一个快速、轻量级 WEB 框架；没有过多的依赖，核心 jar 包仅 30KB。

也仅需要一行代码即可启动一个 HTTP 服务。

前言

OutOfMemoryError 问题相信很多朋友都遇到过，相对于常见的业务异常（数组越界、空指针等）来说这类问题是很难定位和解决的。

本文以最近碰到的一次线上内存溢出的定位、解决问题的方式展开；希望能对碰到类似问题的同学带来思路和帮助。

主要从表现-->排查-->定位-->解决 四个步骤来分析和解决问题。

背景

最近在做分布式相关的工作，由于人手不够只能我一个人来怼；看着这段时间的加班表想想就是够惨的。

不过其中也有遇到的不少有意思的事情今后再拿来分享，今天重点来讨论服务的注册与发现。

分布式带来的问题

我的业务比较简单，只是需要知道现在有哪些服务实例可供使用就可以了（并不是做远程调用，只需要拿到信息即可）。

要实现这一功能最简单的方式可以在应用中配置所有的服务节点，这样每次在使用时只需要通过某种算法从配置列表中选择一个就可以了。

但这样会有一个非常严重的问题：

由于应用需要根据应用负载情况来灵活的调整服务节点的数量，这样我的配置就不能写死。

不然就会出现要么新增的节点没有访问或者是已经 down 掉的节点却有请求，这样肯定是不行的。

往往要解决这类分布式问题都需要一个公共的区域来保存这些信息，比如是否可以利用 Redis？

每个节点启动之后都向 Redis 注册信息，关闭时也删除数据。

其实就是存放节点的 ip + port，然后在需要知道服务节点信息时候只需要去 Redis 中获取即可。