Kafka核心技术与实战 01

本是古典何须时尚 2023-01-22 15:49 83阅读 0赞

### 消息的编码方式 ###

*  CSV
 *  XML
 *  JSON
 *  Protocol Buffer
    
    > Kafka它使用的是纯二进制的字节序列。当然消息还是结构化的，只是在使用之前都要将其转换成  
    > 二进制的字节序列

### 消息传输协议 ###

*  点对点模型
 *  发布/订阅模型

### Kafka与JMS的关系 ###

JMS 是 Java Message Service，  
它也是支持上面这两种消息引擎模型的。严格来说它并非传输协议而仅仅是一组 API 罢  
了。不过可能是 JMS 太有名气以至于很多主流消息引擎系统都支持 JMS 规范，比如  
ActiveMQ、RabbitMQ、IBM 的 WebSphere MQ 和 Apache Kafka。当然 Kafka 并未  
完全遵照 JMS 规范，相反，它另辟蹊径，探索出了一条特有的道路。

## 常见问题 ##

*  怎么解决实时结果响应问题呢？比如秒杀商品，生产者产生订单，消费者处理订单结果，那这结果如何实时返回给用户呢？

这个场景使用Kafka Streams比较适合，它就是为read-process-write场景服务的

*  讲一讲Kafka和别的mq的区别和最佳选择方法么？例如什么时候选择RabbitMQ什么时候选择Kafka等等

RabbitMQ属于比较传统的消息队列系统，支持标准的消息队列协议（AMQP, STOMP，MQTT等），如果你的应用程序需要支持这些协议，那么还是使用RabbitMQ。另外RabbitMQ支持比较复杂的consumer Routing，这点也是Kafka不提供的。

*  有些业务用mq来做异步处理，为了削峰填谷，是不是上游发送消息成功就认为业务成功了，可能下游过很久去消费，那实时性要求很高的业务怎么办呢，比如生成了订单但是一直不处理也不好吧。mq和rpc调用的区别是什么呢？

实时性要求高的应该是同步的rpc，mq是异步的。

通常来说，两个进程进行数据流交互的方式一般有三种：  
\\1. 通过数据库：进程1写入数据库；进程2读取数据库  
\\2. 通过服务调用：比如REST或RPC，而HTTP协议通常就作为REST方式的底层通讯协议  
\\3. 通过消息传递的方式：进程1发送消息给名为broker的中间件，然后进程2从该broker中读取消息。消息传输协议属于这种模式

mq和rpc的区别往大了说属于数据流模式（dataflow mode）的问题。我们常见的数据流有三种：

1.  通过数据库；
2.  通过服务调用（REST/RPC）;
3.  通过异步消息传递（消息引擎，如Kafka）

> RPC和MQ是有相似之处的，毕竟我们远程调用一个服务也可以看做是一个事件，但不同之处在于：
> 
>  *  MQ有自己的buffer，能够对抗过载（overloaded）和不可用场景
>  *  MQ支持重试
>  *  允许发布/订阅模式  
>     当然它们还有其他区别。应该这样说RPC是介于通过数据库和通过MQ之间的数据流模式。

*  用消息引擎的这种数据流数据方式，上游是不是就无法得知处理结果了，甚至是无法将返回值传回上游了？

因为这种通信方式一般是异步且是单向的，如果你需要这种回馈机制，最好使用服务调用 的方式

*  现在消息中间件很多，想要了解kafka和其他消息中间件的优劣点，系统选型时需要考虑什么？

如果是以实现高吞吐量为主要目标，Kafka是不错的首选；如果是以实现业务系统为主要目标，特别是金融类业务，可以考虑应用Kafka的流处理组件Kafka Streams。不过坦率说目前将Kafka应用于纯业务系统的并不多，但是前景依然可期：）

*  卡夫卡的消息超过了log.retention.bytes以后可以拒绝生产者的消息么，现在默认好像直接删除

不能拒绝。这个是留存策略。一旦超过阈值开启老消息删除，而不是拒绝新消息。

*  kafka说的写磁盘高性能是由于是顺序写，但是多个进程写多个文件时候这种顺序写的高性能还存在不？

如果分区过多的确会拉低顺序写的性能，因为要向不同的路径下写入消息

*  现在在做商城业务，我们使用的mysql+es存储数据，开始时，用的双写模式，即先写mysql，在刷es，这样tps上不去，后来改成异步消费，借助大数据，他们监听binlog文件，监听订单的变化，然后放入kafka，我们监听kafka，异步刷新es，但是延迟有点高，最后发展成，自己开发了一套canel，监听mysql主库，刷新es，对于要求实时性比较高的查询，先走数据库搂一把，，，之后再去搂es，我一直没搞清楚，为什么kafka的消息有时候会延迟那么大，期待老师后面的内容有所涉及，，，以便真正理解原理，，，不至于出了问题一脸懵逼。。。。

延时大可能有很多种因素，producer、broker、consumer任何一端都可能引入较长的延时。最好还是先定位发生延时的组件再进行调优

## 相关名词解释 ##

*  **consesus algorithm**，在区块链中多翻译为共识算法，而在其它领域多被翻译为一致性算法，个人觉得共识算法表意更清楚。
 *  **削峰填谷**，实际上就是流量整形的形象表达，主要还是为了应对上游瞬时大流量的冲击，避免出现流量毛刺现象，保护下游应用和数据库不被大流量打垮。

声明：从极客时间上整理的地址如下

*  https://time.geekbang.org/column/article/98948