ぶぽめつせ

已更新。

感谢提醒，这两天更新一下

大佬，新版本如果所有副本死了好像改用了第一种策略
This is a simple tradeoff between availability and consistency. If we wait for replicas in the ISR, then we will remain unavailable as long as those replicas are down. If such replicas were destroyed or their data was lost, then we are permanently down. If, on the other hand, a non-in-sync replica comes back to life and we allow it to become leader, then its log becomes the source of truth even though it is not guaranteed to have every committed message. By default from version 0.11.0.0, Kafka chooses the first strategy and favor waiting for a consistent replica. This behavior can be changed using configuration property unclean.leader.election.enable, to support use cases where uptime is preferable to consistency.

我分别在虚拟机和master容器用nc -lk 9092接收数据，用java发消息，都可以收到，路由应该没问题？

    try {
        socket = new Socket("master", 9092);
        String message = "\n你叫搜集的备份节点开发板的百分比时刻的部分看都不看分不开的";
        OutputStream os = socket.getOutputStream();
        os.write(message.getBytes("GBK"));
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        try {
            socket.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

文档的Efficiency小节讲述了一个问题：kafka如何设计达到高吞吐量、低延迟？
kafka消息发送时，
a) kafka每次写入操作都只是把数据写入到操作系统的页缓存中，由操作系统自己把页缓存中的数据写回磁盘。操作系统页缓存是在内存中分配，消息写入速度非常快。
b) kafka写入操作采用追加方式，只能在日志文件末尾追加写入新的消息，且不允许修改已写入的消息，而磁盘顺序访问操作速度可与内存的随即访问相媲美。
kafka消费端消费时，kafka在读取消息时会首先尝试从OS的页缓存中读取，如果命中便把消息经页缓存直接发送到网络的socket上。
概括的讲，
a) 大量使用操作系统页缓存，内存操作速度快且命中率高
b) Kafka不直接参与物理I/O操作，而是交由最擅长此事的操作系统来完成
c) 采用追加写入方式，摒弃了缓慢地磁盘随机读/写操作
d) 使用以sendfile为代表的零拷贝技术加强网络间的数据传输效率
————摘自《Apache kafka实战》

我虚拟机是使用NAT模式的，是不是要改一下呢？

“还有非常多的其它编程语言的客户端。”这个链接协议https多了一个s

快夸我。