消息队列一

day2

场景带入

1.系统崩溃

2.服务处理有限

3.链路耗时长

4.日志如何处理

怎么办？

解决方案：解耦，削峰，异步

那么谁可以呢？

那就是MQ啦，支持高吞吐，高并发，高可用的消息队列

常用消息队列

Kafka

使用场景：

日志信息，Metrics数据，用户行为等

如何使用：

创建集群->新增Topic->编写生产者逻辑->编写消费者逻辑

基本组成：

Topic:逻辑队列，不同Topic可以建立不同的

Topic Cluster:物理集群，每个集群中可以建立多个不同的

Topic Producer:生产者，负责将业务消息发送到Topic中

Consumer:消费者，负责消费Topic中的消息

ConsumerGroup:消费者组，不同组

Consumer消费进度互不干涉

简单来说就是生产者将消息发送给逻辑队列（即消息队列主体），然后消息队列将消息发给消费者，消费者组就相当于消费者的集群，用来消费类消息。

具体架构：

zookeeper是一个注册中心，具体作用如上图

从一个消息的视角看看为什么kafka能支撑这么多吞吐

producer:批量发送，进行数据压缩，减小消息大小

broker:进行顺序写，以提高写入效率，寻找索引的用了二分的思想，

发送给consumer时采用了零拷贝技术，使得其减少了用户态与内核态之间的切换减少了开销

在consumer上，采取了一个coordinator的机制，实现了自动的Rebalance操作

kafka的弊端：

1.运维成本高

2.对于负载不均衡的场景，解决方案复杂

3.没有自己的缓存，完全依赖Page Cache

4.Controller 和Coordinator和Broker在同一进程中，大量IO会造成其性能下降

小结

今天主要学习了消息队列出现的原因以及kafka的相关知识，课上讲了kafka的整体架构以及一些细节，之前有学过关于消息队列的相关知识也了解过一些，但有些内容还是有点难懂，没有搞清楚。但是收获蛮多的，学习了一些新的名词，以及有种“原来还有这种操作”的感觉。以后还要多多学习相关知识，一是有用，二是学的东西还不够多以至于课程内容没有完全搞懂。