时间太长的调查和解决的方法

发送层消费topic后，会把消息放在各自的内存队列上，多个线程消费内存队列的消息来实现消息的下发。

可以看到的是：从接入层发到消息队列上我们就已经做了分topic来实现业务上的隔离，在消费时我们也是放到各自的内存队列中来进行消费。这就实现了：不同渠道和同渠道的不同类型的消息都互不干扰。

看到上面这张图，如果思考过的同学肯定会问：这要内存队列干啥啊?反正你在上层已经分了topic了，不用内存队列也可以实现你所讲的“业务隔离”啊。

也的确，这里使用内存队列的主要原因是为了提高并发度。提高了并发度，这意味着下发速度可以更快(在下发消息的过程中，最耗时的还是网络交互，像短信这种可以多开点线程进行消费)。

在前面所提到的业务规则就是在下发层这儿做的，包括夜间屏蔽、1小时去重和Id转换等

• 夜间屏蔽就是判断是否在晚上，如果勾选了夜间屏蔽并且在晚上，过滤掉就好了
• 1小时去重就是拿userId+消息渠道作为Key，看是否存在Redis上，假设存在，则过滤掉
• id转换这功能我们做成了个系统，这块我放在下面简单说一下吧，这就不在赘述了。

画外音：这种场景最好使用Pipeline来读写Redis

随后就是适配各个渠道的接口，调用API下发消息了，这块就跟你们单个的实现没什么大的区别了，调用个接口还能给你玩出花来?(代码风格会稍好一些，模板方法模式、责任链、生产者与消费者模式等在项目中都有对应的应用)
 

画外音：上面我们所说的接口定义在统一调用层(接入层)中

调用者调用我们的send/batchSend方法，会直接调用下游的API下发消息吗?不会

直接调用下游的API下发消息风险太大了，接口1W+QPS都是很正常的事，所以我们接收到消息后只是做简单的参数校验处理和信息补全就把消息发到消息队列上。这样做的好处就是接口接入层十分轻量级，只要Kafka抗得住，请求就没问题。
 

接着，只需要层层下推，我们就可以分析出哪个是系统最复杂的一部分。如下图中的复杂点，依次是：platforms、java、plugins、android。

变更频次

紧接着，我们就可以通过获取 Git 提交历史来知道，对应文件的修改变化。这里，我依旧使用的是 coca git -t。它源自于对于 git log --all --date=short --pretty="format:[%h] %aN %ad %s" --numstat --reverse --summary 命令的分析结果，有兴趣的读者可以参考 Coca 的源码，自行编写不同版本地对应实现。

可怕的是，我在 intellij-community 执行了 coca git -t 之后，生成了一个 241M 的文件，回去 GitHub 看了一眼：累计 290，459 次提交。

在我第一次没意识到应该记录下 log 之后，我又重新执行了一遍。最终，拿到了结果：

（编辑：盐城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!