IO
基于字节流和字符流，每次读一个或多个字节直至读取all字节，没有缓存
各种流也是阻塞的，当一个线程调用read或write，被阻塞直到有数据被读取或数据完全写入，期间不能做其他的事情
NIO
核心：channel通道、buffer缓冲、selector多路复用器，基于channel、buffer
数据从通道读取到缓冲区，或从缓冲区写入到通道中：缓冲区离用户近
NIO线程从某通道发送请求读取数据、仅能得到可用的数据、如果目前无可用数据则说明都不会获取，直到该数据变得可用读取之前，该线程可继续做其他时区
于字节流和字符流，每次读一个或多个字节直至读取all字节，没有缓存
kafka
O(1)时间复杂度提供消息持久化能力，log和index文件
https://blog.csdn.net/qq_41568597/article/details/82501738；高吞吐率，支持server间消息分区、分布式消费，partion内顺序传输
一致性和可靠性
producer往broker发送新消息,,主题对应分区、分区多个副本
可靠性：消息确认机制，配置
request.required.acks
-
acks = 0：意味着如果生产者能够通过网络把消息发送出去，那么就认为消息已成功写入 Kafka 。在这种情况下还是有可能发生错误，比如发送的对象无能被序列化或者网卡发生故障，但如果是分区离线或整个集群长时间不可用，那就不会收到任何错误。在 acks=0 模式下的运行速度是非常快的（这就是为什么很多基准测试都是基于这个模式），你可以得到惊人的吞吐量和带宽利用率，不过如果选择了这种模式， 一定会丢失一些消息。
-
acks = 1：意味若 Leader 在收到消息并把它写入到分区数据文件（不一定同步到磁盘上）时会返回确认或错误响应。在这个模式下，如果发生正常的 Leader 选举，生产者会在选举时收到一个 LeaderNotAvailableException 异常，如果生产者能恰当地处理这个错误，它会重试发送悄息，最终消息会安全到达新的 Leader 那里。不过在这个模式下仍然有可能丢失数据，比如消息已经成功写入 Leader，但在消息被复制到 follower 副本之前 Leader发生崩溃。
-
acks = all（这个和 request.required.acks = -1 含义一样）：意味着 Leader 在返回确认或错误响应之前，会等待所有同步副本都收到悄息。如果和 min.insync.replicas 参数结合起来，就可以决定在返回确认前至少有多少个副本能够收到悄息，生产者会一直重试直到消息被成功提交。不过这也是最慢的做法，因为生产者在继续发送其他消息之前需要等待所有副本都收到当前的消息。
发生模式：同步producer.type=sync或异步async
leader选举
分区leader维护ISR in-sync-replicas列表，follower的broker编号，replica.lag.time.max.ms配置：副本复制消息最大延迟时间
综上所述，为了保证数据的可靠性，我们最少需要配置一下几个参数：
-
producer 级别：acks=all（或者 request.required.acks=-1），同时发生模式为同步 producer.type=sync一般是async批量压缩发送，提高吞吐量
-
topic 级别：设置 replication.factor>=3，并且 min.insync.replicas>=2；
-
broker 级别：关闭不完全的 Leader 选举，即 unclean.leader.election.enable=false；
数据一致性
老的新的leader，consumer都能读到一样的数据
https://blog.csdn.net/qq_41568597/article/details/82501738
来源：oschina
链接：https://my.oschina.net/u/4414570/blog/4671564