Apache zookeeper Overview翻译

本文介绍了ZooKeeper的名称由来、设计目标、数据模型、命名空间及其实现机制。此外还探讨了ZooKeeper如何通过统一意见协议确保数据一致性,并展示了其在高并发场景下的性能表现。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


  • 名字由来
zookeeper:中文翻译动物园管理员,是用来协调分布式程序的服务框架。之所以起名zookeeper,是因为作者把这些分散的、分布式的系统协调任务看成是一个动物园管理员做的事情。
  • 设计目标
    • 操作简单:zookeeper主要用来协调处理分布式任务通过一个叫多层次的命名空间的东东,这个东东很类似文件系统。一个命名空间就是一个数据寄存器 - 称为znode,按照zookeeper的说法,多层次的命名空间就是文件与目录的关系。但zookeeper的数据是保存在内存中
    • 自我复制:像下面的这个分布式系统,zookeeper主要是在各个server间复制数据,zookeeper 服务必须彼此知道对方的存在。它们将维持同一个内存镜像,通过事务控制。只要大多数的zookeeper机器可以运行,zookeeper就可以提供正常的服务。当一个client需要服务是可通过tcp链接到一个server,如果这个server挂掉了,它就会自动链接另一个server
    • 有序:zookeeper通过更新一个计数器,来反映zookeeper的事务顺序,子操作可以通过这个这个计数器来实现更高层次的抽象,例如原语同步。
    • 快速:zookeeper尤其在读取时表现的性能更为强悍,因为zookeeper service可以同时有很多机器提供且读是写的速度的10倍;

  • 数据模型和多层次命名空间
        ZooKeeper 的多层次命名空间:zookeeper的命名空间就像常见的文件系统,每个节点的路径是唯一的,如下


  • 节点
  • zookeeper不像标准的文件系统,每个节点都会关联这个节点和它子节点相关的信息(zookeeper被设计主要是用来存储协调信息,比如状态信息,配置,zookeeper位置信息等)
  • 条件更新和观察
zookeeper支持观察的概念,客户端可以设置对一个节点的观察岗。如果节点发生改变将会触发观察事件同时移除观察事件。当一个观察岗发现一个节点发生变化,客户端就会收到一个消息包说这个节点发生改变了。假如这个客户端和服务器不能建立连接,客户端将会收到一个本地消息通知。
  • 数据保证机制
    • zookeeper的运行时非常快和简单的。尽管设计目标如此,但它是构造复杂服务的基础。例如异步,它可以提供很多保证机制
      • 顺序一致性-来自于客户端的更新请求将会按顺序被发送
      • 原子性 - 更新结果要么是成功要么是失败,没有其它可能性。
      • 单一系统映像 - 客户端不管连接到哪台服务器看到的结果都是一样的
      • 可靠性 - 一旦更新被运用,它将持续覆盖客户端。
      • 及时 - 客户端及时收到消息
  • 简单的API接口
    • zookeeper 设计要达到的目标之一是提供一个很简单的程序接口。正如下面的结果,它仅支持下面这些操作
      • create
        creates a node at a location in the tree
        delete
        deletes a node
        exists
        tests if a node exists at a location
        get data
        reads the data from a node
        set data
        writes data to a node
        get children
        retrieves a list of children of a node
        sync
        waits for data to be propagated
  • 实践
zookeeper 展现了自己高水平的组件服务,在允许一些请求异常外,组成zookeeper服务的每台服务器都会在彼此之间复制。

ZooKeeper Components


复制数据是在内存中维持整个数据树,更新的log被记录子啊磁盘上以便为了恢复,在它们更新的内存中数据库之前先被序列化到磁盘上,每个zookeeper服务器为好几个客户端提供服务,客户端连接到一台服务器上提交请求,提供服务的是本地服务的数据库,对于状态改变的数据请求和写入请求是按照一种叫做统一意见的协议。

统一意见协议是这样的,所有写入的请求都被送到一个统一的服务器,可以叫这台服务器为老大,其余的zookeeper服务器可以叫做小弟。老大发布信息,小弟们收到信息进行同步,信息传送层值关心小弟们是否成功更新,和数据是否和老大保持了一致。

zookeeper使用了常用的原子信息传送协议,正因为原子性,zookeeper才能保证各个小弟上得数据是无误的,当老大收到一条写入的数据的请求,它会计算整个系统的状态当数据被复制在各个小弟上,它把它作为一种事物并且捕获各个状态
  • 使用
zookeeper接口故意设计的很简单,但是你也可以实现更高水平的操作,例如,异步原语,分组等等,一些分布式程序已经开始这样这样干了
  • 性能
zookeeper设计特点是高性能。下面是雅虎开发团队研究的结果,特别是在读和写做对比时,zookeeper表现出了更高的性能,因为写操作是在所有的zookeeper服务器上同步数据状态

       ZooKeeper Throughput as the Read-Write Ratio Varies


  • 可靠测试
下面是zookeeper运行在7台服务器上发生错误时的行为记录,我们运行饱和测试,写入的速读的30%,下面是保守的数据测试

Reliability in the Presence of Errors


从上面这个图表中可以看到几点重要的观测,假如同步失败并且立马恢复,zookeeper也是能保持在一个非常高的吞吐量。更重要的是,老大选择的算法允许整个系统快速的恢复并在不影响吞吐量的情况下。zookeeper不在选出一个新老大时耗时超过200ms。第三,zookeeper在恢复后可以立马处理请求。
  • 使用zookeeper的项目
zookeeper已经成功的运行在很多商业项目中。在雅虎中,用来协调和失败恢复


### Kafka 3.9 KRaft Mode SASL Configuration and Setup Guide #### Overview of KRaft Mode Apache Kafka introduced the KRaft (Kafka Raft Metadata) protocol as an alternative to ZooKeeper for managing cluster metadata starting from version 2.8, with improvements continuing through later versions including 3.9. In this new mode, all brokers participate directly in electing leaders for partitions responsible for storing topic data and internal metadata. #### Prerequisites Before Installation Before proceeding with setting up a Kafka cluster using KRaft mode along with SASL security configurations: - Ensure Java Development Kit is installed on each node. - Verify network connectivity between nodes within the intended Kafka cluster. - Confirm that firewalls allow traffic over required ports such as `9092` for client connections or `9093` when SSL/TLS encryption is enabled[^1]. #### Installing Kafka Without Zookeeper Support To deploy Kafka without relying on ZooKeeper, download the appropriate tarball specifically built for KRaft operation instead of traditional packages which include dependencies on ZooKeeper services. For example: ```bash wget https://archive.apache.org/dist/kafka/3.9.0/kafka_2.13-3.9.0.tar.gz tar -xf kafka_2.13-3.9.0.tar.gz cd kafka_2.13-3.9.0/ ``` Modify the startup script similar to what was done previously but ensure paths point towards correct locations where JAAS files reside relative to your installation directory structure[^2]: ```bash sed -i 's|exec $base_dir/kafka-run-class.sh.*$|exec $base_dir/kafka-run-class.sh \ -Djava.security.auth.login.config=$base_dir/config/kraft/server.properties \ kafka.Kafka "$@"|' bin/kafka-server-start.sh ``` #### Configuring Security Settings Using SASL Mechanisms For securing communication channels among broker peers plus external clients connecting into topics hosted inside clusters running under KRaft control plane management, apply settings outlined below per server properties file located typically at `$KAFKA_HOME/config/kraft/server.properties`. Enable listener authentication mechanisms by specifying desired protocols like PLAINTEXT/SASL_PLAINTEXT depending upon whether encrypted transport layer protection will be utilized alongside message-level confidentiality measures provided via GSSAPI/Kerberos tickets exchange mechanism or SCRAM-SHA algorithms family members supporting password-based exchanges securely authenticated against remote LDAP directories etc.[^4]: ```properties listeners=SASL_PLAINTEXT://:9092 listener.name.sasl_plaintext.scram-sha-512.sasl.enabled.mechanisms=SCRAM-SHA-512 security.inter.broker.protocol=SASL_PLAINTEXT sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512 authorizer.class.name=kafka.security.authorizer.AclAuthorizer allow.everyone.if.no.acl.found=true super.users=User:admin;User:kafka ``` Create corresponding entries inside `/etc/kafka/jaas.conf`, adjusting principal names according to actual usernames defined earlier during ACL rules creation process[^3]: ```conf KafkaServer { org.apache.kafka.common.security.scram.ScramLoginModule required username="admin" password="yourpassword"; }; Client { org.apache.kafka.common.security.plain.PlainLoginModule required username="clientuser" password="anothersecret"; }; ``` After completing these steps restart affected daemons ensuring changes take effect properly before attempting any further operations involving producer/consumer applications interacting programmatically across secured endpoints established above. --related questions-- 1. How does one verify successful deployment after configuring Kafka Cluster in KRaft mode? 2. What are common pitfalls encountered while enabling SASL authentication methods on Apache Kafka installations? 3. Can you provide guidance regarding performance tuning parameters available once switching away from legacy ZooKeeper coordination service models toward modernized approaches offered since recent releases? 4. Is there support for mutual TLS verification combined together with other forms of access controls implemented through custom plugin extensions developed externally outside official distributions?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值