Kafka监控架构设计
目前的Kafka监控产品有很多，比如Kafka Manager、 Kafka Monitor、KafkaOffsetMonitor、Kafka Web Console、Burrow等，都有各自的优缺点，就个人而言用的最多的还是Kafka Manager，不过这些并不是十分的完美。
rocketMq和kafka的架构区别
概述
其实一直想写一篇rocketMq和kafka在架构设计上的差别，但是一直有个问题没搞明白所以迟迟没动手，今天无意中听人点播了一下似乎明白了这个问题，所以就有了这篇对比。
IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？
1、前言
在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此，它的价值不仅仅存在于技术上，更重要的是改变了以往同步处理消息的思路（比如进行IM消息历史存储时，传统的信息系统作法可能是收到一条消息就马上同步存入数据库，这种作法在小并发量的情况下可以很好的工作，但互联网大并发环境下就是灾难）。
Kafka压缩
在某些情况下，整个应用的瓶颈不在于CPU或者磁盘，而是受网络带宽的影响。当然你可以选择在业务代码中对每一条消息做压缩处理，之后再发送到kafka中，之后业务消费端再进行解压处理，这种方式对应消息的压缩效率是非常低。
Kafka的offset管理
消费者需要自己保留一个offset，从kafka 获取消息时，只拉去当前offset 以后的消息。Kafka 的scala/java 版的client 已经实现了这部分的逻辑，将offset 保存到zookeeper 上
1.
SpringCloud实战8-Bus消息总线
好了现在我们接着上一篇的随笔，继续来讲。上一篇我们讲到，我们如果要去更新所有微服务的配置，在不重启的情况下去更新配置，只能依靠spring cloud config了，但是，是我们要一个服务一个服务的发送post请求，
我们能受的了吗？这比之前的没配置中心好多了，那么我们如何继续避免挨个挨个的向服务发送Post请求来告知服务，你的配置信息改变了，需要及时修改内存中的配置信息。