快速网站推广优化,合肥小程序开发,wordpress怎么去调用文章图片,视觉设计师培训转载自http://blog.chinaunix.net/uid-20196318-id-2420884.html Kafka[1]是linkedin用于日志处理的分布式消息队列#xff0c;linkedin的日志数据容量大#xff0c;但对可靠性要求不高#xff0c;其日志数据主要包括用户行为#xff08;登录、浏览、点击、分享、喜欢…转载自http://blog.chinaunix.net/uid-20196318-id-2420884.html Kafka[1]是linkedin用于日志处理的分布式消息队列linkedin的日志数据容量大但对可靠性要求不高其日志数据主要包括用户行为登录、浏览、点击、分享、喜欢以及系统运行日志CPU、内存、磁盘、网络、系统及进程状态。 当前很多的消息队列服务提供可靠交付保证并默认是即时消费不适合离线。高可靠交付对linkedin的日志不是必须的故可通过降低可靠性来提高性能同时通过构建分布式的集群允许消息在系统中累积使得kafka同时支持离线和在线日志处理。 注本文中发布者publisher与生产者producer可以互换订阅者subscriber与消费者consumer可以互换。 Kafka的架构如下图所示 Kafka存储策略 kafka以topic来进行消息管理每个topic包含多个partition每个part对应一个逻辑log有多个segment组成。每个segment中存储多条消息见下图消息id由其逻辑位置决定即从消息id可直接定位到消息的存储位置避免id到位置的额外映射。每个part在内存中对应一个index记录每个segment中的第一条消息偏移。发布者发到某个topic的消息会被均匀的分布到多个part上随机或根据用户指定的回调函数进行分布broker收到发布消息往对应part的最后一个segment上添加该消息当某个segment上的消息条数达到配置值或消息发布时间超过阈值时segment上的消息会被flush到磁盘只有flush到磁盘上的消息订阅者才能订阅到segment达到一定的大小后将不会再往该segment写数据broker会创建新的segment。 发布与订阅接口 发布消息时kafka client先构造一条消息将消息加入到消息集set中kafka支持批量发布可以往消息集合中添加多条消息一次行发布send消息时client需指定消息所属的topic。 订阅消息时kafka client需指定topic以及partition num每个partition对应一个逻辑日志流如topic代表某个产品线partition代表产品线的日志按天切分的结果client订阅后就可迭代读取消息如果没有消息client会阻塞直到有新的消息发布。consumer可以累积确认接收到的消息当其确认了某个offset的消息意味着之前的消息也都已成功接收到此时broker会更新zookeeper上地offset registry后面会讲到。 高效的数据传输 发布者每次可发布多条消息将消息加到一个消息集合中发布 sub每次迭代一条消息。不创建单独的cache使用系统的page cache。发布者顺序发布订阅者通常比发布者滞后一点点直接使用linux的page cache效果也比较后同时减少了cache管理及垃圾收集的开销。使用sendfile优化网络传输减少一次内存拷贝。 无状态broker Broker没有副本机制一旦broker宕机该broker的消息将都不可用。Broker不保存订阅者的状态由订阅者自己保存。无状态导致消息的删除成为难题可能删除的消息正在被订阅kafka采用基于时间的SLA(服务水平保证)消息保存一定时间通常为7天后会被删除。消息订阅者可以rewind back到任意位置重新进行消费当订阅者故障时可以选择最小的offset进行重新读取消费消息。 Consumer group 允许consumer group包含多个consumer如一个集群同时消费对一个topic进行消费不同的consumer group之间独立订阅。为了对减小一个consumer group中不同consumer之间的分布式协调开销指定partition为最小的并行消费单位即一个group内的consumer只能消费不同的partition。 Zookeeper 协调控制 1. 管理broker与consumer的动态加入与离开。 2. 触发负载均衡当broker或consumer加入或离开时会触发负载均衡算法使得一 个consumer group内的多个consumer的订阅负载平衡。 3. 维护消费关系及每个partion的消费信息。 Zookeeper上的细节 每个broker启动后会在zookeeper上注册一个临时的broker registry包含broker的ip地址和端口号所存储的topics和partitions信息。每个consumer启动后会在zookeeper上注册一个临时的consumer registry包含consumer所属的consumer group以及订阅的topics。每个consumer group关联一个临时的owner registry和一个持久的offset registry。对于被订阅的每个partition包含一个owner registry内容为订阅这个partition的consumer id同时包含一个offset registry内容为上一次订阅的offset。 消息交付保证 kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。kafka提供at-least-once delivery,即当consumer宕机后有些消息可能会被重复delivery。因每个partition只会被consumer group内的一个consumer消费故kafka保证每个partition内的消息会被顺序的订阅。Kafka为每条消息为每条消息计算CRC校验用于错误检测crc校验不通过的消息会直接被丢弃掉。 Linkedin的应用环境 如下图左边的应用于日志数据的在线实时处理右边的应用于日志数据的离线分析现将日志pull至hadoop或DWH中。 Kafka的性能 测试环境 2 Linux machines, each with 8 2GHz cores, 16GB of memory, 6 disks with RAID 10. The two machines are connected with a 1Gb network link. One of the machines was used as the broker and the other machine was used as the producer or the consumer. 测试评价(by me)1环境过于简单不足以说明问题。2对于producer持续的波动没有进行分析。3只有两台机器zookeeper都省了 测试结果如下图完胜其他的message queue单条消息发送每条200bytes,能到50000messages/sec50条batch方式发送平均为400000messages/sec. Kafka未来研究方向 1. 数据压缩节省网络带宽及存储空间 2. Broker多副本 3. 流式处理应用 参考资料 【1】 http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf 【2】 https://cwiki.apache.org/KAFKA/kafka-papers-and-presentations.data/Kafka-netdb-06-2011.pdf转载于:https://www.cnblogs.com/scott19820130/p/4736089.html
