传统的序列化

spring kafka序列化配置 kafka消息序列化_spring kafka序列化配置

 

很明显这种序列化有一个问题，虽然能满足append的存储模式，但无法从中读取第n个对象，每次得从第一个开始读。

kafka作为一种C-S架构，C端需要和S端进行通信，批量向S端传送序列化的对象，达到batch.size(8K)或者时间达到linger.ms(5ms)向server端传送数据，据此推断C端和S端的通信应该使用的是长连接，而不会是每次传送数据打开一个socket，并且还支持压缩，高效稳定的通信和存储是这类软件必备的特质之一。

除此以外还有一种提交的情况，那就是事务提交了。。。。。。

spring kafka序列化配置 kafka消息序列化_spring kafka序列化配置_02

spring kafka序列化配置 kafka消息序列化_大数据_03

spring kafka序列化配置 kafka消息序列化_kafka_04

 

可以看出key和value都被序列化为byte[]，每跳过length个byte就是跳过了一组key-value，因此可以根据这个进行寻找第offset个key-value

如何将一个Object序列化为byte[] ，很明显需将Object的所有字段进行序列化，进而最终转化为基本数据类型和String等的序列化。

spring kafka序列化配置 kafka消息序列化_spring kafka序列化配置_05

 

以下是将Double进行序列化和反序列化

spring kafka序列化配置 kafka消息序列化_大数据_06

spring kafka序列化配置 kafka消息序列化_序列化_07

 

相比较而言使用kafka的序列化，一个Double占用8个字节， 

而使用writeDouble进行序列化则占用了14个字节

 

spring kafka序列化配置 kafka消息序列化_kafka_08

而使用writeObject进行序列化则占用了84个字节。务必请慎用，占用大量字节，进而占内存和带宽。。。

spring kafka序列化配置 kafka消息序列化_json_09

 

也许序列化的本质就是将对象转换为可识别的字节流。

有时会想为什么不这样存储？

key1

value1

key2

value2

key3

value3

 

首先这种存储面临一个问题， 换行回车符号需进行转义存储。二是这种存储和读取高效么，一行一行进行处理。仅仅是推测，具体实现是不是这样没有考究。一行一行的读取无非是一个一个字节的读取，读到\n便是一行，这种读取方式应该不是很高明。