在做web项目的时候，我们可以看到在进行点赞，评论和关注等功能的时候系统会想你发送消息。
事实上我们很容易想象在一个微博大V在发微博的短短几秒中，可能就有成千上万的人就进行了点赞，那如果按照传统办法的话：生产者和消费者直接连接，生产者（你进行点赞，服务器接收你的点赞）需要和消费者处理完（服务器接收到点赞，生成点赞提示消息）都得完成才能进行下一个点赞行为处理，这是效率很低的。（因为生产者和消费者处理速度不同，互相等待在大数据量背景下慢而且浪费资源，因为互相等待期间该方法依然占用资源）
阻塞队列：在生产者和消费者之间我们不直接相连，在之间放一个队列。
生产者生产消息put进队列，同时消费者从队列中take数据，如果说生产比消费快，那么队列满了之后生产会进入阻塞，停止消耗cpu；如果消费比生产快，那么队列空了之后消费进入阻塞，停止消耗cpu。
我们很容易看到其中的优势，在消息产生的高峰期间，生产、消费并发进行、异步处理（而不需要生产和消费互相等待才能继续处理）。速度快的一方可以迅速处理（一般是消费者更快，因此提高消费者响应速度）并且降低服务器压力（队列空的时候，消费者阻塞）
消息队列由于两者之间不是直接连接，降低了耦合度。
Kafka简介：到目前为止我自己都认为自己还没有完全理解
https://www.jianshu.com/p/d3e963ff8b70
这个老师讲的应该说是很全面详细也很生动了，mark一下以后多看看
上面的阻塞队列，就是典型的一对一的模式，一个生产者，一个消费者。这显然还不能满足我们的需求。更为常用的是发布-订阅模式，一个生产者（接收用户点赞信息，生产出对应信息）生产消息，多个消费者（处理信息）订阅消息。
Kafka简介：Kafka是一个分布式的流媒体平台。应用：消息系统、日志收集、用户行为追踪、流式处理。（大部分情况下只使用消息系统）
- 高吞吐量：处理TB级的数据，消息持久化支持的
- 消息持久化：消息存在硬盘上而非内存（而且是顺序读写硬盘，性能很高）
- 高可靠性：分布式保证的，partition机制和replication机制，使消息的传递有着很高的可靠性。
- 高扩展性：加服务器是很方便的。partition机制。
Kafka总体数据流程情况
这个图也来自上面的链接的作者。
Broker：kafka集群由一个或多个kafka server组成，每个server即Broker。
ZooKeepr：是一个集群管理软件，关于broker、topics、partitions的一些元信息用zk来存，监控和路由啥的也都会用到zk。
Topic：发布的主题，也是指发布的空间
Partiion：一个Topic会有多个分区，这个是为了做水平扩展，当数据量到达瓶颈的时候我可以通过增加broker来增加partition来增加kafka中队列的容量。
生产者
这是生产者的流程，生产者会将请求发送给相应的topic和指定的partition。
这里我们可以看到，同一个topic同一个partition会有多个，红色的我们称为Leader Replica，黑色的称为Follower Replica。只有红色的参与操作，黑色的只是同步拷贝。但是当红色的挂掉了，kafka会从黑色的里面选出一个称为Leader。（这就是他的高可靠性）
Leader和Follow会被尽量的分配到不同的broker上。
消费者
还是看这个图，消费者是按照消费者组来进行的topic订阅。一个消费组里面可以有多个消费者。同一个消费组中的两个消费者，不会同时消费一个partition。换句话来说，就是一个partition，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费。
因此，如果消费组内的消费者如果比partition多的话，那么就会有个别消费者一直空闲。
一个消费组消费partition，需要保存offset(偏移量）记录消费到哪，在0.10版本后，kafka把这个offset的保存，从zk总剥离，保存在一个名叫__consumeroffsets topic的topic中。写进消息的key由groupid、topic、partition组成，value是偏移量offset。
这个存offset的partition所在的broker也同时用作consumer的分配。这个具体分配方式暂时没有弄明白。
京公网安备 11010502036488号