前言
在负责Ad Exchange竞价成功的消息通知服务时,由于该服务需要消费一定量级的 Kafka 数据,并且保证服务不宕机,友好处理异常,并且异步并发请求的性能需要足够强劲。途中遇到许多之前没有学习的新思路新知识,在此记录
需求
消费 Kafka 中 竞价成功消息通知回调 Topic 中的回调URL,并异步HTTP请求回调。
Kafka 分区数量 : 30
实现
1.分析阶段
由需求得知,需要消费30个分区的消息数据。首先在生产上,考虑使用3台双核处理器。那么每个核心至少开启5个线程去消费 Kafka 消息,这样才能满足30个分区的信息能够被完整消费。
在HTTP请求上,需要异步去请求HTTP回调接口,考虑Netty和Apache HTTPAsyncClient两种HTTP Client,由于Netty可能需要自己编写HTTP Client,故使用了Apache HTTPAsyncClient作为HTTP客户端,Netty方案以PR形式压测之后考虑是否合并。
2. 消费Kafka数据
项目使用Spring Boot构建,加快开发速度,Kafka基本配置如同Get Started,做了一些自定义,由于需求给定的30个分区以及生产环境上使用多少个主机去开启服务暂不固定,并且Kafka Consumer的程序虽然基本上是while(true)任务,但不希望在生产环境上由于Alaways Running导致服务不可停止。综合以上两点,将线程任务的循环状态以及Kafka消费数量以配置文件加载,并且支持HotReload(使用Owner)。
3. 调用回调接口
搭建好了Kafka消费者之后则需要对消费的消息对处理,对URL编码之后,使用HTTPAsyncClient异步请求回调接口。
思考
在项目开发阶段接触了Netty框架,感慨Netty的设计优美,但自己始终未能参透。SEDA,事件驱动,始终是一知半解。想在项目中使用Netty,又反而是为了用而用,性能差距并非巨大,也不太适合此业务。
又想,是否能将 SEDA 或者事件驱动带入项目,在深入了解后,感慨解耦的思想十分宝贵,但是在实际产出中,或许意义不大,Talking is cheap.
实际上手了一个 SEDA 项目,和消息队列做中间件的生产消费者模型十分相似,又如 Redis 发布/订阅模式。或许能在某天兴起,编写相关一个庞大项目。而并非Demo,去深入理解其思想和设计。以及实际在产出时的性能基准。但现在说这些始终是太早,还需夯实基础。
近期评论