php项目下kafka的应用

Kafka主要设计目标如下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。

• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条(也就是100000条——十万)消息的传输。

• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。

• 同时支持离线数据处理和实时数据处理。

kafka角色:

1.topic  主题

Topic相当于传统消息系统MQ中的一个队列queue，producer端发送的message必须指定是发送到哪个topic，但是不需要指定topic下的哪个partition，因为kafka会把收到的message进行load balance，均匀的分布在这个topic下的不同的partition上（ hash(message) % [broker数量]  ）。物理上存储上，这个topic会分成一个或多个partition，每个partiton相当于是一个子queue。在物理结构上，每个partition对应一个物理的目录（文件夹），文件夹命名是[topicname]_[partition]_[序号]，一个topic可以有无数多的partition，根据业务需求和数据量来设置。在kafka配置文件中可随时更高num.partitions参数来配置更改topic的partition数量，在创建Topic时通过参数指定parittion数量。Topic创建之后通过Kafka提供的工具也可以修改partiton数量。

一般来说，（1）一个Topic的Partition数量大于等于Broker的数量，可以提高吞吐率。（2）同一个Partition的Replica尽量分散到不同的机器，高可用。

2.broker 节点

3.Partition 分区

3.groupid 消费组

4.replica 副本

-Partition Replica：每个partition可以在其他的kafka broker节点上存副本，以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。例如有5个kafka broker节点，某个topic有3个partition，每个partition存2个副本，那么partition1存broker1,broker2，partition2存broker2,broker3。。。以此类推（replica副本数目不能大于kafka broker节点的数目，否则报错。这里的replica数其实就是partition的副本总数，其中包括一个leader，其他的就是copy副本）。这样如果某个broker宕机，其实整个kafka内数据依然是完整的。但是，replica副本数越高，系统虽然越稳定，但是回来带资源和性能上的下降；replica副本少的话，也会造成系统丢数据的风险。

 

 

 

Broker：Kafka节点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。

Topic：一类消息，消息存放的目录即主题，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。

Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

Segment：partition物理上由多个segment组成，每个Segment存着message信息

Producer: 生产message发送到topic

Consumer: 订阅topic消费message, consumer作为一个线程来消费

Consumer Group：一个Consumer Group包含多个consumer, 这个是预先在配置文件中配置好的。各个consumer（consumer 线程）可以组成一个组（Consumer group ），partition中的每个message只能被组（Consumer group ） 中的一个consumer（consumer 线程 ）消费，如果一个message可以被多个consumer（consumer 线程 ） 消费的话，那么这些consumer必须在不同的组。Kafka不支持一个partition中的message由两个或两个以上的consumer thread来处理，即便是来自不同的consumer group的也不行。它不能像AMQ那样可以多个BET作为consumer去处理message，这是因为多个BET去消费一个Queue中的数据的时候，由于要保证不能多个线程拿同一条message，所以就需要行级别悲观所（for update）,这就导致了consume的性能下降，吞吐量不够。而kafka为了保证吞吐量，只允许一个consumer线程去访问一个partition。如果觉得效率不高的时候，可以加partition的数量来横向扩展，那么再加新的consumer thread去消费。这样没有锁竞争，充分发挥了横向的扩展性，吞吐量极高。这也就形成了分布式消费的概念。

 

kafka特点:

消息会按固定时间，默认7天，固定保存。

消费者根据读取消息的offset来确定消费的位置。

这2个特点，使Kafka consumers非常的轻量级：它们可以在不对集群和其他consumer造成影响的情况下读取消息。

 

一个topic主题可以有多个分区，这样保证了可以通过增加分区，每个节点的消费能力能横向扩展。

每个分区都有一个服务器作为“leader”，零或若干服务器作为“followers”,leader负责处理消息的读和写，followers则去复制leader.如果leader down了，followers中的一台则会自动成为leader。集群中的每个服务都会同时扮演两个角色：作为它所持有的一部分分区的leader，同时作为其他分区的followers，这样集群就会据有较好的负载均衡。

特点综合如下:

1.解耦：
　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2.冗余：
　　消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3.扩展性：
　　因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
4.灵活性 & 峰值处理能力：
　　在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5.可恢复性：
　　系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6.顺序保证：
　　在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个 Partition 内的消息的有序性）
7.缓冲：
　　有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
8.异步通信：
　　很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

 

php 基于rdkafka扩展的示例代码

$conf = new \RdKafka\Conf();
function rebalance(\RdKafka\KafkaConsumer $kafka, $err, array $partitions = null) {
    global $offset;
    switch ($err) {
        case RD_KAFKA_RESP_ERR__ASSIGN_PARTITIONS:
            echo "Assign: ";
            $kafka->assign();
//            $kafka->assign([new RdKafka\TopicPartition("qkl01", 0, 0)]);
            break;

        case RD_KAFKA_RESP_ERR__REVOKE_PARTITIONS:
            echo "Revoke: ";
            var_dump($partitions);
            $kafka->assign(NULL);
            break;

        default:
            throw new \Exception($err);
    }
}

// Set a rebalance callback to log partition assignments (optional)
//$conf->setRebalanceCb(function(\RdKafka\KafkaConsumer $kafka, $err, array $partitions = null) {
//    rebalance($kafka, $err, $partitions);
//});

// Configure the group.id. All consumer with the same group.id will consume
// different partitions.
$conf->set('group.id', 'xxxxx');

//鉴权,若无可忽略
$conf->set('security.protocol','SASL_PLAINTEXT');
$conf->set('sasl.mechanism','PLAIN');
$conf->set('sasl.username','xxxxx');
$conf->set('sasl.password','xxxxx');

// Initial list of Kafka brokers
$conf->set('metadata.broker.list', 'xxxxx');

$topicConf = new \RdKafka\TopicConf();

$topicConf->set('request.required.acks', -1);

//在interval.ms的时间内自动提交确认、建议不要启动
//$topicConf->set('auto.commit.enable', 0);
//$topicConf->set('auto.commit.enable', 0);
$topicConf->set('auto.commit.interval.ms', 100);

// 设置offset的存储为file
//$topicConf->set('offset.store.method', 'file');
//$topicConf->set('offset.store.path', __DIR__);

// 设置offset的存储为broker
// $topicConf->set('offset.store.method', 'broker');

// Set where to start consuming messages when there is no initial offset in
// offset store or the desired offset is out of range.
// 'smallest': start from the beginning
$topicConf->set('auto.offset.reset', 'smallest');

// Set the configuration to use for subscribed/assigned topics
$conf->setDefaultTopicConf($topicConf);

$consumer = new \RdKafka\KafkaConsumer($conf);

//$KafkaConsumerTopic = $consumer->newTopic('qkl01', $topicConf);

// Subscribe to topic 'test'
$consumer->subscribe(['xxxxx']);
echo "Waiting for partition assignment... (make take some time when\n";
echo "quickly re-joining the group after leaving it.)\n";
while (true) {
    $message = $consumer->consume(120*1000);
    switch ($message->err) {
        case RD_KAFKA_RESP_ERR_NO_ERROR:
            var_dump($message);
//            $consumer->commit($message);
//            $KafkaConsumerTopic->offsetStore(0, 20);
            break;
        case RD_KAFKA_RESP_ERR__PARTITION_EOF:
            echo "No more messages; will wait for more\n";
            break;
        case RD_KAFKA_RESP_ERR__TIMED_OUT:
            echo "Timed out\n";
            break;
        default:
            throw new \Exception($message->errstr(), $message->err);
            break;
    }
}

注意:

1. 如果consumer比partition多，是浪费，因为kafka的设计是在一个partition上是不允许并发的，所以consumer数不要大于partition数
2. 如果consumer比partition少，一个consumer会对应于多个partitions，这里主要合理分配consumer数和partition数，否则会导致partition里面的数据被取的不均匀
最好partiton数目是consumer数目的整数倍，所以partition数目很重要，比如取24，就很容易设定consumer数目
3. 如果consumer从多个partition读到数据，不保证数据间的顺序性，kafka只保证在一个partition上数据是有序的，但多个partition，根据你读的顺序会有不同
4. 增减consumer，broker，partition会导致rebalance，所以rebalance后consumer对应的partition会发生变化
5. High-level接口中获取不到数据的时候是会block的

 

问答:

1.为什么kafka的读写都是通过leader节点，不像mysql,redis是写主读从

因为kafka不像mysql,redis在高并发下读压力过大，kafka都是通过消费进程读取，并发较小，redis等在业务场景有高并发请求。

反而如果follower节点也可进行读操作，消费者可从follower接收消息，那需要follower和leader节点进行实时的数据同步操作，代价较大，只通过leader来负责读写，可以比较简单的方式实现数据的一致性，而follower仅用在高可用上，作为副本使用。

2.为什么kafka中订阅某主题的消费者组中的消费者不能超过该主题的分区数

kafka在设计的时候就是要保证分区下消息的顺序性，也就是说消息在一个分区中的顺序是怎样的，那么消费者在消费的时候看到的就是什么样的顺序,那么要做到这一点就首先要保证消息是由消费者主动拉取的，其次还要保证一个分区只能由一个消费者负责。

如果两个消费者消费同一个分区，consumer端进行多人的index维护，那么就得引入中心的概念，大家都在中心去获得当前的index，这会增加复杂性。如果在consumer端维护单人index，可以方便的pull数据。牺牲了分区的分布式消费。由于可以有多个分区，权衡之下是较为合理的方案。

3.消费者消费的分区实现

Kafka新版本consumer默认提供了两种分配策略：range和round-robin。当然Kafka采用了可插拔式的分配策略，你可以创建自己的分配器以实现不同的分配策略。实际上，由于目前range和round-robin两种分配器都有一些弊端，Kafka社区已经提出第三种分配器来实现更加公平的分配策略，只是目前还在开发中。我们这里只需要知道consumer group默认已经帮我们把订阅topic的分区分配工作做好了就行了。

range策略针对于每个topic，各个topic之间分配时没有任何关联，分配步骤如下： 
1. topic下的所有有效分区平铺，例如P0, P1, P2, P3… … 
2. 消费者按照字典排序，例如C0, C1, C2 
3. 分区数除以消费者数，得到n 
4. 分区数对消费者数取余，得到m 
5. 消费者集合中，前m个消费者能够分配到n+1个分区，而剩余的消费者只能分配到n个分区。

所以对于某个topic来说： 
如果有5个分区（P0, P1, P2, P3, P4），且订阅这个topic的消费者组有2个消费者（C0, C1）。那么P0, P1, P2将被C0消费，P3, P4将被C1消费。 
如果有4个分区（P0, P1, P2, P3），且订阅这个topic的消费者组有2个消费者（C0, C1）。那么P0, P1将被C0消费，P3, P4将被C1消费。
 

对于kafka的consumer接口，提供两种版本

一种high-level版本，比较简单不用关心offset, 会自动的读zookeeper中该Consumer group的last offset 
参考，https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Group+Example

另一种是SimpleConsumer，名字起的，以为是简单的接口，其实是low-level consumer，更复杂的接口

参考，https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+SimpleConsumer+Example

什么时候用这个接口?

1. Read a message multiple times
2. Consume only a subset of the partitions in a topic in a process
3. Manage transactions to make sure a message is processed once and only once

 

当然用这个接口是有代价的，即partition,broker,offset对你不再透明，需要自己去管理这些，并且还要handle broker leader的切换，很麻烦 
所以不是一定要用，最好别用

1. You must keep track of the offsets in your application to know where you left off consuming.
2. You must figure out which Broker is the lead Broker for a topic and partition
3. You must handle Broker leader changes

4. 使用SimpleConsumer的步骤：

5. Find an active Broker and find out which Broker is the leader for your topic and partition
6. Determine who the replica Brokers are for your topic and partition
7. Build the request defining what data you are interested in
8. Fetch the data
9. Identify and recover from leader changes

10. 首先，你必须知道读哪个topic的哪个partition 

11. 然后，找到负责该partition的broker leader，从而找到存有该partition副本的那个broker 
    再者，自己去写request并fetch数据 
    最终，还要注意需要识别和处理broker leader

参考:  https://www.cnblogs.com/fxjwind/p/3794255.html