实时计算之kafka的高可用保证探讨.ppt

kakfa集群介绍 01 kakfa服务的故障与恢复 02 kafka的HA机制 03 CONTENTS kafka集群简单介绍 kafka集群有4个kakfa集群 cdn集群：40台 user-action集群：30台 性能测试集群：10台 cdn老集群：60台 （即将淘汰） kafka服务的不稳定因素 磁盘损坏 会造成kafka服务异常退出。 服务器故障 kafka服务退出；两台以上故障：kafka数据丢失等问题。 zookeeper服务 之前所有的kafka和共用一套zookeeper服务，现已经分拆。 kafka服务器进程监控 目前的监控方式：使用crontab定时扫描监测kafka服务进程， 如kafka服务不存在，自动拉起，并短信报警给相关人员。 缺点：时效性不高。 其他方式：daemontools监控。 KAFKA磁盘故障自动恢复 由于kafka服务器磁盘开销很大，随着集群规模的增大， 出现磁盘故障的可能性大大提高，为了减少维护的成本， 我们开发了磁盘故障的自动处理程序。 通过mysql来管理损坏磁盘； 自动剔除故障磁盘。 自动恢复磁盘 服务器运行日志目录重新选举。 磁盘故障报警通知。 kafka备份池 kafka备份池：安装了3台kafka服务，平时不启动，线上kafka服务器故障时，从备份池中取出一台备份服务器接替，同时通知IT及时维修故障的服务器。 由于目前的kafka的topic副本数为2；当kafka服务器故障超过两台时，就会造成数据丢失；当kafka服务器故障时，可根据需要启动备份服务器。 kafka备份机策略可行性测试 检验备份机策略是否可行，同时为了检验服务器故障对服务的影响，检验kafka备份机切换对集群和服务的影响，做了如下测试。 测试方案： step1:部署3台测试集群的kafka集群备份机。 step2: 创建一个测试的topic，只有一个分区，备份数为2 的test_bak_kafka step3: 编写一个发送消息的生产者程序，不停的发送消息， 启动一个消费者，实时消费消息。 step4:关闭一个正在写入消息的broker的主节点 stop5:启动被关闭的节点。 step6: 关闭主节点，启动 备份节点 kafka的zk元数据信息介绍 关闭topic分区的leader节点 现象： 生产者 写消息的生产者会报如下异常退去，不可恢复。 上层应用需要考虑重试机制 消费者： 不受影响。 kafka服务器： topic的备份节点切换成了leader 当异常的broker节点退出时,leader也会重新选举，而异常节点加入时，不会重新选举。 如果故障退出的为follower节点，则生产者和消费者都不会受到影响。 启动备份节点 步骤 操作 结果 stop1： 修改备份节点的borker.id为故障节点ID 需提前配置备份节点到/etc/host stop2： 启动备份节点 正常启动 stop3： 观察zk中brokerid的变化 zk中/brokers/ids 的出现brokerid的节点 stop4： 观察生产者和消费者的状态 没有影响 stop5： 观察备份节点的数据同步状态 数据没有同步过来，等待一段时间后，可以恢复同步。 数据同步效率：1个磁盘：16分钟 53G的数据。 54M/s topic的zk的状态变化 在kafka节点异常，备份节点恢复过程中，topic的zk状态变化如下： 关闭主节点：kafka的leader发生切换 启动备份节点： 正常状态： 一台broker故障后： 备份broker恢复后： kafka的Leader Election kafka的partition的leader算法没有使用常用的“Majority Vote”；而是采用在ZK中动态维护了一个ISR，这个ISR里的所有Replica都需要跟上了leader，只有ISR里的成员才有被选为Leader的可能。 优点： N+1个Replica，容忍N个replica失败 容忍N个Replica的失败，比“Majority Vote”少近一半的replica 缺点： 需要等待最慢的Broker，但是可以通过Producer选择是否被commit阻塞来改善（request.required.acks）。 kafka的Leader Election 实现：kafka通过Controller节点来选举各个partition的leader。 kafka的Leader Election 1.controller在ZK的/brokers/ids节点上注册Watch 2.broker宕机，