消息通知业务笔记

在负责Ad Exchange竞价成功的消息通知服务时，由于该服务需要消费一定量级的 Kafka 数据，并且保证服务不宕机，友好处理异常，并且异步并发请求的性能需要足够强劲。途中遇到许多之前没有学习的新思路新知识，在此记录

消费 Kafka 中 竞价成功消息通知回调 Topic 中的回调URL，并异步HTTP请求回调。

Kafka 分区数量 : 30

由需求得知，需要消费30个分区的消息数据。首先在生产上，考虑使用3台双核处理器。那么每个核心至少开启5个线程去消费 Kafka 消息，这样才能满足30个分区的信息能够被完整消费。

在HTTP请求上，需要异步去请求HTTP回调接口，考虑Netty和Apache HTTPAsyncClient两种HTTP Client，由于Netty可能需要自己编写HTTP Client，故使用了Apache HTTPAsyncClient作为HTTP客户端，Netty方案以PR形式压测之后考虑是否合并。

项目使用Spring Boot构建，加快开发速度，Kafka基本配置如同Get Started，做了一些自定义，由于需求给定的30个分区以及生产环境上使用多少个主机去开启服务暂不固定，并且Kafka Consumer的程序虽然基本上是while(true)任务，但不希望在生产环境上由于Alaways Running导致服务不可停止。综合以上两点，将线程任务的循环状态以及Kafka消费数量以配置文件加载，并且支持HotReload（使用Owner）。

搭建好了Kafka消费者之后则需要对消费的消息对处理，对URL编码之后，使用HTTPAsyncClient异步请求回调接口。

在项目开发阶段接触了Netty框架，感慨Netty的设计优美，但自己始终未能参透。SEDA，事件驱动，始终是一知半解。想在项目中使用Netty，又反而是为了用而用，性能差距并非巨大，也不太适合此业务。

又想，是否能将 SEDA 或者事件驱动带入项目，在深入了解后，感慨解耦的思想十分宝贵，但是在实际产出中，或许意义不大，Talking is cheap.

实际上手了一个 SEDA 项目，和消息队列做中间件的生产消费者模型十分相似，又如 Redis 发布/订阅模式。或许能在某天兴起，编写相关一个庞大项目。而并非Demo，去深入理解其思想和设计。以及实际在产出时的性能基准。但现在说这些始终是太早，还需夯实基础。