KafkaZookeeper原理与应用场景介绍课件.pptVIP

KafkaZookeeper原理与应用场景介绍;Topic、Partition、Producer、Consumer 消息从producer到topic用push 消息从topic到consumer用pull ;partition、consumer group 每个topic的消息会广播给每个consumer group，但是每条消息在某个group内只有一个consumer能收到。 组内的消费者数量不要大于topic的分区数;Partition 每个分区内的数据保证数据的先后顺序，不同分区内的数据无法保证。;Partition、Replication 每个分区的外部读写都在leader上，所以不同分区 的leader会均衡分布在Broker集群上;Broker、Zookeeper Broker是kafka的服务实例，无中心节点，通过Zookeeper完成分区leader-follower的切换;日志收集 应用程序可以把日志集中发到kafka中，不需要记录到本地，再由专门的日志管理程序从kafka中取处理。对于多个进程读写同一个日志文件的场景，可以避免日志文件的加锁操作。 也可以对kafka中的日志进行实时分析。;消息队列 Kafka同一个partition内部的消息保证先进先出，并且每条消息可以保证至少被消费一次(at least once)，同一个topic内的消息可以被多个组的消费者接收。 可以实现发布订阅和普通的先进先出队列;数据Table记录转换为Stream 通过指定条件定时把表中新增或者变更的记录推到kafka中，实现用流式处理方式来处理数据库的数据 Kafka在0.9版本以后提供了JdbcSource Connector工具类用于把数据库数据写入kafka，目前支持自增ID列和时间列作为记录变化的条件，当然也可以用producer的api来实现;分布式事件驱动 把事件集中存储到kafka，并分别放入同一个topic下的多个分区，分区数量可以是事件处理客户端实例数的3-5倍以上，这样便于事件客户端动态增减和负载均衡。 客户端一次获取多个事件后，全部处理完成再commit offset以保证事件至少被处理一次，由于事件要求高可靠，在高可靠读写情况下Kafka的性能下降比较明显;高性能的分布式应用协调服务 ;Znode ZooKeeper数据模型的结构与文件系统很类似，每个节点称做一个Znode，ZooKeeper的各种功能特性都是通过Znode的操作和监控通知来实现，Znode有四种形式： 1、PERSISTENT 持久化目录节点，存储的数据不会丢失。 2、PERSISTENT_SEQUENTIAL ???序编号的持久化目录节点，根据当前已近存在的节点数自动加 1，节点名称在路径后+%010d，例如/root/path0000000001。 ;3、EPHEMERAL ?临时目录节点，一旦创建这个节点的客户端与服务器端口也就是session 超时，这种节点会被自动删除。 4、EPHEMERAL_SEQUENTIAL 临时自动编号节点。 ;Watcher Watcher用于监控ZNode的变化，ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client Watcher是一次性的，触发后需要重新设置才能继续监控Znode的变化 ;Session Client与ZooKeeper之间会维护一个Session，这个Session会有一个超时时间，Client通过定时心跳来保持Session。 当Session超时后，对应Client创建的临时节点和所有监视器都将失效; Zookeeper的操作主要是对Znode的操作 Create: 创建一个Znode Delete: 删除一个Znode Exists: 判断Znode是否存在 GetData: 获取Znode上的数据 SetData: 设置Znode的数据 GetChildren: 获取Znode下的所有子节点;分布式环境下的统一配置管理 在分布式系统中，不同主机节点的应用实例配置可以存储在zookeeper上，以方便统一配置，并且配置变更时可以实时通知应用，可以用在参数需要动态生效的场景中。 命名服务 每个znode可以做为一个唯一的标识，在SOA架构或者微服务架构中，zookeeper做为作为服务注册中心 ;成员管理与Leader选举 通过临时节点的监控来判断成员是否在线，通过创建最小编号的节点来进行Leader选举 可以使用zookeeper来监控各个应用实例是否在线，对于主备架构的可以在主实例离线时把备份实例升级为主实例，对于一主多从的架构中，可以进行leader选举，