kafka是一种高可用,高吞吐量,基于zookeeper协调的分布式发布订阅消息系统。
消息中间件:生产者和消费者
举个例子:
生产者:做馒头,消费者:吃馒头,数据流:馒头
如果消费者宕机了,吃不下去了,那么馒头就浪费了,所以生产者生产之后丢在篮子里,消费者要吃的时候到篮子立面去取。
这个篮子就好比我们的kafka,起到一个缓冲的作用,如果篮子满了装不下馒头了,那就多准备几个篮子,多准备篮子就是kafka的扩容
producer:生产者,生产馒头的
consumer:消费者,吃馒头的
broker:篮子
topic:主题,相当于给馒头打一个标签,并不是生产者生产的所有馒头消费者都会吃的。比方说topicA馒头是给你吃的,topicB馒头是给你妹妹吃的
消息系统有两种模式:peer to peer,和发布/订阅
peer to peer:
1.一般基于pull和polling接收消息
2.发送到队列的消息被一个且仅仅被一个接收者接收,即便有多个接收者在队列中监听同一消息
3.支持异步"即发即弃"的消息传送方式,也支持同步请求/应答传送方式。意思是我们即可以发送完就滚蛋,也可以发送完不走,确定被接收者接收之后再走
发布/订阅
1.发布到一个主题的消息,可被多个订阅者接收
2.发布/订阅即可基于push消费数据,也可以基于pull/polling消费数据
3.解耦能力比peer to peer模型更强
消息系统适用场景:
1.解耦:各位系统之间通过消息系统这个统一的接口交换数据,无需了解彼此的存在
2.冗余:部分消息系统具有消息持久化的能力,可规避消息处理前丢失的风险
3.扩展:消息系统是统一的数据接口,各系统可独立扩展
4.峰值处理能力:消息系统可顶住峰值流量,业务系统可根据处理能力从消息系统中获取对应处理量的请求
5.可恢复性:系统中部分组件失效并不会影响整个系统,回复之后仍然可以从消息系统中获取数据
6.异步通信:在不需要立即处理请求的场景下,可以将请求放入消息系统,合适的时候再处理
常用消息系统对比:
rabbitMQ:erlang编写,支持多协议,AMQP,XMPP,SMTP,STOMP.支持负载均衡,数据持久化。同时支持peer to peer和发布/订阅模式
Redis:基于key-value的nosql数据库,同时支持MQ功能,可做轻量队列使用。就入队操作而言,对短消息(小于10kb)的处理,redis的性能比rabbitmq要好
kafka/jafka:高性能跨语言的分布式发布/订阅消息系统,数据持久化,全分布式,同时支持在线和离线处理。jafka是kafka的java实现。
以及还有zeroMQ,activeMQ,MetaQ等等这里就不推荐了,个人建议使用rabbitMQ或者kafka
kafka的设计目标:
高吞吐率:在链家的商用机器上单机可支持每秒100万条消息的读写,尽管是把消息持久化到磁盘,但是不代表性能低,实际上吞吐率是相当高的
消息持久化:所有消息均被持久化到磁盘,无消息丢失,支持消息重放
完全分布式:producer,broker,consumer均支持水平扩展
同时满足适应在线流处理和离线流处理,现在的sparkStreaming也和kafka结合的比较好。也可以将kafka里的数据导入到HDFS里面,方式也比较多,一般是通过flume的kafka source将kafka的数据拿过来,在使用flume的hdfs sink或者hive sink将数据导入hdfs或者hive进行离线的流式批处理
05-14 16:55