kafka1

1 数据采集传输速率：
    cpu最快、内存其次、磁盘其次(机械每秒五六十M,固态每秒两三百M)、网速其次；
    磁盘：磁盘其次(三四千M的是因为磁盘有个顺序读写，常规是随机读写的所以达不到三四千M)
    网速(重点，及两方技术的每秒采集传输速度如flume采集小于100M/s，hadoop上传速度100m/s左右)
    100M的网，100M是100M的bit(位),不是100M的数据，
    所以100M的网对应网络传输速度是： 100M bit换算成byte即要除以8(位) = 12.5M/s ，人家有设带宽限制；
    12.5M/s是外网的速度，局域网不涉及到网络交换机，内网传输速度只跟你网络有关(百M还是千M网线)；
    搞活动的时候flume可能200M/s，flume也不止一台；
        hadoop的速率取决于hadoop的节点数量，hadoop 100m/s,hadoop也不止一台，
        如果上游flume采集速度大于下游hadoop的上传(处理)的速度，数据就积压了；
        所以中间加一个缓冲kafka集群(消息队列)，hadoop你慢慢传就行了；
2 队列：先进先出
  消息队列：kafka-activemq-rabbitmq-rocketmq  组件/框架 ，消息队列就是做缓冲的
  在大数据场景主要用kafka；
  在java开发中主要用RabbitMQ、RocketMQ;
  传统的消息队列主要用于：缓存/消峰、解耦和异步通信；
  不管是哪种消息队列都有点对点的功能；
3 消息队列的两种模式：
    1 点对点
        发消息的人会指定发的消息是发送给哪个人去接收的；后面这个人消费后会把消息队列中你发的这条消息删掉；
    2 发布/订阅(用的多)
        kafka是发布订阅模式的；
        发消息的人不知道要发给谁只知道我要发到哪个主题/栏目里面，后面这个人去订阅这个主题/栏目，
        它能把这个栏目里的数据全部读到；它订阅完后消息队列里的数据是不会被删除的；
4 实时处理/流时处理: 先给你10处数据你先给我算一下，一会儿给你加了一条数据你再给我算一下...
5 flume：把采集的数据写到一个地方去，比自已写好多了
6 秒杀：
    10亿人/s->一个人1k的数据存到消息队列，1T还是存的下的->秒杀只有100条(服务器处理能力1000/s),
    则在这1T数据中只取100条，其它的数据当场就给你删除掉了，服务器就没有压力了；
7 kafka解耦：flume->mq->hadoop  哪块出错改哪块
8 sparkstreaming和flink是做实时处理的；
9 异步通讯：用户把一个消息放到队列里，并不立即处理，在需要的时候再去处理它；
    同步：如你注册发送信息，你调用发送短信接口，你得等待你收到回复再点确定；用户体验差；
    异步：如你注册发送信息，你调用发送短信接口发送到消息队列里了，它这会会告诉你短信已发送，你一看还没收到；
         但这个时候它就给你响应注册成功了，它要等到消息队列拿到这一条短信才发送给你(即消息队列实现异步通讯)；
===
    大数据要完成的三件事：海量数据的传输、存储、计算，kafka也是用在传输上，相当于是管道；
    kafka是一个缓冲池，相当于是队列； 相当于水管；web页面的埋点；实时处理/流时处理；
1 官网： https://kafka.apache.org/
2 kafka当中消息的流向：
    流向：product到topics到group到consumer
    主题、分区、和副本；生产者、消费者组以及zk;**********
    producer：生产者(数据的发布者/消息的发布者)，将消息发送到topic中，
        broker接收到生产者发送的消息后，将该消息追加到当前用于追回数据的segment文件中。
        生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition;
    topics:   主题(数据发送到哪个主题位置或理解成队列名),相当于打了个标记；
        划分数据的类型的，如kafka是数据库的话，topic就是数据库当中的表
        为了能用到更多的资源(网络带宽)，提高它的扩展，主题就有了分区(如三个分区在三台上)，提高了吞吐量；
        多个partition组织起来再是一份完整理的topicA的数据;分区是为了实现分布式；
    consumer group组(CG)：分组，一个组去订阅一个主题里面的数据；
        一个组里的消费者和topic的partition数量一致，这个主题有几个分区则就对应有几个组；
        即组里的消费者1读topic的partition1,组里的消费者2读topic的partition2,组里的消费者3读topic的partition3,
        即消费者组里的每个消费者是消费不同分区的数据的；
        一个分区只能由一个组内消费者消费，消费者之间互不影响；
        同理，同一个broker上partition1不能存partition1的副本，可以存partition0或partition2的副本；
        多个partition组织起来再是一份完整理的topicA的数据;
        相当于消费者组逻辑上是一个订阅者；
    一个broker上一个分区，一个副本；
    replica: 副本,即分区的一个备份，副本不会被消费者消费；副本作用主要是为了防止数据的消失，主要是做数据备份的，就为了增加容错；
        副本要区分谁是leader谁是follower；注意是分区的副本；只有副本才有主从；
        只有leader再会接收生产者往里面写数据，消费者从里面读数据；
        leader:  partition有多个副本，其中有一个副本是它的leader，其它副本都是follower
                 leader是当前负责数据读写的partition;
                 comsumer消费的时候都是来读取的leader这个副本；
                 leader挂了会从副本follower当中重新选举；
        follower: 数据备份，leader挂了follower才有意义；
    brokers:  节点，kafka集群包含多个服务器，一个服务器就是一个节点，
        topic里的一个partition存储在一个broker(电脑)中，其余的broker是不再存这个partition；
        如果topic中有N个partition，但是集群当中的broker是少于partition的数量的，
           哪么就是说一个broker存储该topic的一个或多个partition，这样会导致kafka集群数据的一个不均衡；
           实际当中尽量避免这种情况出现，即kafka集群当中的broker数量一定要大于topic当中的partition数量；
    consumer: 消费者(消息的订阅者)，从broker当中读取数据，消费者可以消息多个topic当中的数据
            即读topic主题中的信息；
    zookeeper：
            在kafka集群当中负责维护和协调broker;
            zk中保存kafka集群的基础信息如brocker0里放了哪些主题哪些分区，但是没有生产者信息；
            kafka在2.8.0之后是可以配置不采用zk，它有一个自已的实现分布式的组件配置(/kafka/config/kraft文件中配置)，知道即可太新了用不到；
    ---------
    AR:       分区当中所有的副本统称为AR;
    ISR:      只有和leader保持同步的副本称为ISR;
    OSR:      除了ISR的副本称为OSR;即没有和leader同步的副本；
    HW：      高水位，即可以从某个位置开始进行消费消息，则这个位置就称为高水位
    LEO:      日志未端位移，记录该副本底层日志中下一条消息的伴移值；