SpringBoot3单机Kafka服务 | 码农修炼笔记

type

status

date

slug

summary

SpringBoot 3.4 + JDK17 构建单机Kafka服务

如果您跟我一样，作为独立开发者，在自己写后台服务的时候，消息的技术选型是必由之路、良好的技术选型能让我们在后续开发维护以及功能扩展上节省不少的时间，为什么不建议自己去写消息中间件（我知道很多大佬喜欢什么都自己手搓），因为解决问题的成本极大，独立开发，需要你对开发工作投入正常工作时间的90%，如果由于中间件问题线上出现了bug，一时半会处理不掉，请人处理也得极费时间的情况下，会给自己带来不必要的麻烦。成熟可靠的技术选型才是生产的首要目标。

选择Kafka可以为后续用户数据收集，结合Hive+Flink+Spark做数据分析时，扩展作为流推送基座管道，是一个不错的选择，并且kafka技术社区成熟，遇到问题基本都有解决方案。废话不多讲，从物理机部署到生产实操一步一步来吧，不要怕遇到问题，遇到问题解决问题才能成长，并且，最珍贵的经验都是从干中学的，而不是学中干来的。

一、物理机选型

一般的独立开发，单机并发量不会太高，撑死你按照1w用户1000日活来算，单机2C2G全用来部署Kafka单机Broker节点是完全足够的，甚至你能部署两台Kafka，一点都不夸张，不要道听途说别人说怎么怎么样，实际怎么样，要自己去操作才有话语权，纸上谈兵不能称之为实干家。

假设每条消息1KB，百万消息就是1GB的数据量，再有足够的带宽支持（我目前采用的是这家云服务器相当给力，20M带宽，对我来说完全够用）。像我这种物理机，在Kafka默认配置下，能达到5000~10000的并发量每秒。对于一个小型应用来说，完全足够，能支撑用户量2w人左右，用户活跃量与总数一般是有10%的差距，2w的用户，一般日活在线2k左右，最好情况下不到3k，最坏情况下小于1k，如果你不做私人运营你是体会不到的这种落差感的，如果你的应用不追求日活，那2C2G完全够用，你甚至还能部署一个小鸡面板，毫不夸张，但是在资源紧张的时候你可能会频繁收到服务器告警，会遇到内存飙升等问题，所以一般建议还是正常保留20%空间，2G的话就是400MB保留左右。