主题+客户端
-
<李>
发布订阅的对象是<强>主题
(主题) 李 <李>向主题发布消息的客户端应用程序称为<强>生产者(生产者),生产者可以持续不断地向<强>多个主题强发送消息
李 <李>订阅这些主题消息的客户端应用程序称为<>强消费者(消费者),消费者能够同时订阅<强>多个主题强的消息
李 <李>生产者和消费者统称为<强>客户端服务端
-
<李>
卡夫卡的服务端由被称为<强>代理的服务进程构成,一个卡夫卡集群由多个代理组成
李 <李>代理负责<强>接收和处理客户端发送过来的请求,以及对消息进行<强>持久化
李 <李>多个代理进程能够运行在同一台机器上,但更常见的做法是将不同的经纪人<强>分散运行在不同的机器上-
<李>这样如果集群中某一台机器宕机了,即使在它上面运行的所有代理进程都挂掉了李
<李>其他机器上的代理也依然能够对外提供服务,这是卡夫卡提供<强>高可用强的手段之一李
备份
-
<李>
实现<强>高可用的另一个手段是<强>备份机制(复制)
李 <李>备份:把<强>相同的数据拷贝到多台机器上,这些相同的数据拷贝在卡夫卡中被称为<强>副本(复制品)
李 <李>副本的数量是可以配置的,卡夫卡定义了两类副本:<强>领导者副本(领袖复制品)和<强>追随者副本(从动件副本)-
<李>领导者副本:<>强对外提供服务强,对外指的是与客户端程序进行交互李
<李>生产者总是向领导者副本写消息李
<李>消费者总是从领导者副本读消息李
<李>追随者副本:<>强被动地追随领导者副本强,不能与外界交互李
<李>向领导者副本发送请求,请求领导者副本把最新生产的消息发给它,进而与领导者副本保持同步李
<李> MySQL的从库是可以处理读请求的李
<李>主从=比;被领导李
-
<李>如果领导者副本积累了太多的数据以至于单台代理机器无法容纳,该如何处理?李
<李>可以把数据分割成多份,然后保存在不同的代理上,这种机制就是<>强分区 (分区)
<李> MongoDB, Elasticsearch分片李
<李> HBase——地区李
分区
-
<李>
卡夫卡中的分区机制是将每个<强>主题划分成多个<强>分区(分区),每个分区是<强>一组有序的消息日志
李 <李>生产者生产的每条消息只会被发送到一个分区中,卡夫卡的分区编号是从0开始的
李 <李>副本是在分区这个层级定义的,每个分区下可以配置N个副本,只能有1个领导者副本和N - 1个追随者副本
李 <李>生产者向分区(<强>分区的领导者副本)写入消息,每条消息在分区中的位置由<强>位移(抵消)来表征,而<强>分区位移总是从0开始
李 <李>三层消息架构李-
<李>第一层是<强>主题层,每个主题可以配置M个分区,而每个分区又可以配置N个副本李
<李>第二层是<强>分区层
<李>每个分区的N个副本中只能有1个领导者副本,<强>对外提供服务
<李>其他n - 1个副本是追随者副本,只能提供<强>数据冗余
<李>第三层是消息层,分区中包含若干条消息,每条消息的位移从0开始,依次递增李
<李>最后,客户端程序只能与<强>分区的领导者副本强进行交互李
持久化
-
<李>卡夫卡使用消息<强>日志(日志)来保存数据,一个日志是磁盘上一个<强>只能追加写(扩展)消息的物理文件
-
<李>只能追加写入,避免了缓慢的随机IO操作,改为性能较好的<>强顺序IO操作
