引入
BEA 开发了weblogic,weblogic是第一个商业化的java(J2EE)应用服务器软件(application sever)。后来BEA被并入了oracle公司.。
websphere 是由IBM公司开发的
1. 消息队列
消息中间件:可以接单理解为两个交互系统的媒介,有了消息中间件有如下好处:
- 解耦:对于相互交互的两个系统,发送消息的和接受消息可以不进行直接的连接,而是通过中间件
- 异步:发送消息和接收消息不需要一个等待另一个而是发送完之后在某个时候去取就行了
- 割峰:不会造成所有的消息在同一时刻都要求另外一个系统做响应。
2. 消息队列通信的模式(该怎么做)
- 点对点通信:基于拉取或者轮询的消息传送模型,是生产者和消费者的关系,当生产者把消息放入message queue之后,只会有一个消费者把这个信息拉取过去.因此,消费者拉取消息的频率可以由自己控制.但是需要额外的线程去监控是否有消息过来让消费者消费.
- 发布订阅模式 :和点对点的不同的是,生产者将消息放入消息队列之后,这些消息会都推送给消费者.因此他们不需要感知消息队列是否有待消费的消息.但是这个时候消息队列不知道各个消费者的能力,所以会出现有些消费者无法消费(处理)消息(跟不上他的进度),或者对于另一些消费这而言他们处理信息的能力比推送信息的速度还快(等着被接受)那么就会出现资源的浪费.
- Kafka:基于上面两种message queue的模式,kafka是一种高吞吐量的分布式发布订阅系统,他可以处理消费者规模的网站中的所有动作流数据,具有…(很强)的能力
3. kafka基本架构及术语介绍
补充:这里的中间件和边缘计算(kafka 是可以实现边缘计算的一个系统 )(kafka主要是实时的数据分析框架,边缘计算的受限资源环境下无法运行,)
整体来看,这里的kafka构成一个cluster
这幅图从左往右看:
Producer:生产者,也就是产生消息的(不一定是要同一个系统)
中间的kafka cluster:
- broker: kafka的实例对象,一个服务器可以有多个broker,但是Broker的编号必须不同,这里简化为一个broker对应了一个服务器
- 将broker分为不同的partition.在broker内partition的编号不同.partition表现为的是不同的文件夹,消息存放在partition里
- Topic:消息的类型,也就是消息的分类.消息按照topic不同存放在partition中.同一topic的数据可以存放在一个Broker的不同partition中,并且这些数据要是不能重复的.重复的数据(副本)放在哪里呢?
- Replication:对于某一个topic某一份数据的复制,防止某一个broker中的partition不能用,可以由其他的partition上的数据作为替补.kafka中规定,比如某一个服务器挂掉了,那么用其他服务器上的数据来进行替补,也就是这些备份(copy)不能在同一台机器上(要区分,不是broker,因为前面已经有说,同一个服务器上可以产生不同的broker)
- Leader和follower:
在同一个broker中只能有一个leader(还是对于同一个topic只能有一个leader?)
搞清楚leader和follower就是replication中的概念,前面提到备份不能在同一机器上就是为了防止服务器挂掉,那么leader和follower不能在同一个机器上.(但是后面实验的时候为了简单,只在一个机器上设置了)
partition的设置,是做负载,可以提高kafka的吞吐量,
右边
Consumer: 接收和处理消息的一端
Consumer group: 多个消费者组成的一个组,kafka在设计的时候对于同一个partition的数据只能被group的某一个消费者消费.同一个消费组的消费者可以消费同一个topic不同分区的数据.因此这提高了吞吐量.
Zookeeper:用于保存集群的元数据,保证系统的可用性.(在HDFS中,为了保证其高可用,zookeeper可以实现故障后数据的迁移)
4. 工作流程分析
4.1 发送数据:
在发送数据的时候永远是发送(push)给leader(对应某一个机器的partition)然后follower会自动的从leader那边pull(主动)数据,等每一个replication都做好之后就返回成功的消息.
具体过程如下图所示:
producer 将数据push到leader,就是直接append的过程,所以是顺序读,所以保证同一partition的数据是有序的.
Partition的作用:
- 方便扩展,因为一个topic 有多个partition (这里的意思应该是同一个topic 对于partition内容各不相同的),面对今后增加的数据量,可以在更多的机器(当然由于一个topic上的不同内容可以存在同一个服务器上,所以也可以说是从broker开始扩充)
- 提高并发, 之前有讲同一个consumer group中的consumer可以同一个topic的不同分区的数据(当然也可以是不同topic,只是这里是在将更快的读)所以可以提高并发
Kafka中的负载均衡
我们向服务器发送请求的时候,服务器可能会对请求做一个负载,将流量分配给不同的服务器,类似的:,在kafka中如果某个topic有多个partition那么producer将数据发送到哪个partition呢?
Kafka的原则:
- 有指定partition就到指定地点
- 没有就会用hash(key)来作为partition的编号
- 如果无指定,也没有key,通过轮询的方式选出一个partition.
(这里还有一个问题,这里只制定了partition的编号,但是没有指定对应的服务器(broker号),具体的leader是谁不也是不知道?)
(答:在具体实现的时候kafka时候,zookeeper会随机选择一个正常的partition作为leader,并将leader的变化告诉所有的follower)
发送数据写入还要保证消息不丢失(这是一种存储机制?要选择另外的服务器吗?)
前面讲到message queue其实在某一时刻一大串的数据,那么在这个过程中,前面讲到通过partition可以实现高吞吐量,实现并发,那么还得保证数据消息不会丢失,其实就是用ACK应答机制,在follower pull 得到写入数据之后,写入成功向leader返回ack.然后leader向producer返回ack这个过程是all机制,相应的有0 ,1机制.而对于初始化的时候或者写入的是2.
没有出现过的topic的时候kafka会自动创建一个新的topic
4.2 保存数据:
前面的问题现在可以展开:kafka将数据保存在磁盘(也就是要进行磁盘的读和写,可能会觉得有点耗时) kafka是会单独开辟出一块磁盘,然后顺序写入,因此效率要比随机写入的效率要高,
partition的结构:
在服务器上就是一个个的文件夹
其中log文件就是实际存储message的文件,log的大小都是相同的,但是里面存储的Message的数量可能是不同的,因为message的大小不相同.
关于message的结构:其中重要的是知道offset 消息大小(用于描述信息的大小)和消息体(被压缩过的消息数据)
存储策略:
Kafka会保留所有的信息,删除的策略是:
- 基于时间,默认配置是168小时(7天)。
- 基于大小,默认配置是1073741824。
需要注意的是,kafka读取特定消息的时间复杂度是O(1),所以这里删除过期的文件并不会提高kafka的性能!
4.3 消费数据
在消息存储在log文件之后,消费者就可以进行消费了. 在前面介绍message queue的时候有点对点模式和发布订阅模式,kafka用的是点对点模式(也就是和follower pull leader的数据一样),同样的这里消费数据的时候也是找leader去pull数据.
这里又要重复之前将consumer group的知识点,同一个group内的消费者可以消费相同(或不同)topic下的不同partition的数据,但是不会有同一个group内的消费者消费同一个partition的数据.
图中出现了某一个消费者消费多个partition的情况,因此处理速度会变慢,建议是group内的consumer数目和partition的数目一致.
再来讲一下具体怎么查找前面在partition上存储好的信息:
利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据,记录自己消费的位置:在新的版本中消费者消费到的offset已经直接维护在kafka集群的__consumer_offsets这个topic中!
5. kafka实战
参考链接:
0 1 2一个topic三个副本,正常启动
有一个节点失效
但仍然其余能正常工作
具体需要注意的:
- 关于杀死进程时,ps 命令本身就是一个进程了,因此杀死进程的时候进程名字一定要找对,不然会出现进程号总是会变,也就是杀不死进程的现象.
- 具体的kafka里面zookeeper的使用还需要更多的博客实战,这里只是最简单的情形;
附上参考链接:
(原理) https://zhuanlan.zhihu.com/p/84406642
(实战)