消息中间件之Kafka

云软件组陈修恒消息中间件之kafkaKafka•一、MQ系统•二、Kafka架构•三、Kafka命令•四、配置文件MQ系统•一、Redis•二、ZeroMQ•三、ActiveMQ•四、RocketMQ•五、KafkaMQ系统•Redis–Redis是一个NoSQL数据库–处理小流量的消息队列–不适用于大流量的应用场景MQ系统•ActiveMQ–ActiveMQ•2007年发布第一个版本(同年JDK1.5发布)•被广泛应用于零售、银行、电子商务和政府等领域。•稳定性好，性能还过得去。•缺少异步JavaAPI和NIO支持，在高资源配置的计算机上扩展性不佳。–Apollo•重写了ActiveMQ内核，•Apache称其为最快、最强健的STOMP（StreamingTextOrientatedMessageProtocol，流文本定向消息协议）服务器。•github一年多没更新，网传Apollo项目已经失败MQ系统•ZeroMQ–不支持序列化，阅后即焚。如果服务器宕机，数据将丢失–ZeroMQ本身只是一个网络协议栈的实现库.使用过程中由应用服务器扮演服务器的角色–ZeroMQ的目标是，成为Linux内核的一部分–逆天的性能MQ系统KafakVSRocketMQ•定位–Kafak：由Linkin开源，用于即时的日志传输–RocketMQ：由淘宝开源，实现非日志的可靠消息传输，用于交易、订单、充值等场景•TPS性能–kafka单机写入TPS在百万条/秒，消息大小为10b–RocketMQ单机7万条/秒，消息大小为10b•队列数–kafak单机超过64个队列/分区，Load会发生明显的飙高现象–RocketMQ最高支持5万队列•实时性–Kafka使用短轮询方式，实时性取决于轮询间隔时间–RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。•成熟度–Kafka在日志领域比较成熟，操作系统Crash，会导致数据丢失–RocketMQ在阿里集团内部有大量的应用在使用，不会丢消息MQ系统•总结MQ系统特点RedisNO-SQL数据库，适用于处理少量MQ数据ActiveMQ久经沙场的老战士，稳定性好ZeroMQ一个网络通信协议栈性能超级强劲RocketMQ阿里出品标准MQ系统中性能最好的Kafka/Jafka专为日志收集设计非标准MQ系统，容灾能力弱，性能超过RocketMQ消息处理速度上限大约为100MB/sKafka架构系统结构kafkaclusterBroker1Broker2Broker3Producer-AProducer-BProducer-CConsumer-AConsumer-AConsumer-CZookeeper•基础架构Kafka架构•基本概念–主题：topic–分区：partition–消息：message–生产者：producer–消费者：consumergroup–消息队列：brokerProducerTopicConsumerGroupPartitionConsumer11..N11..NKafka架构•kafka消息流程图topic消息队列Producer-AProducer-BConsumerconsumergrouppartitionproducer本地磁盘注1：消息队列依赖于本地磁盘注2：默认情况下，磁盘存储会保存7天Kafka架构•kafka消息流程图topic消息队列Producer-AProducer-BConsumerconsumergrouppartitionproducer本地磁盘1本地磁盘2注1：在一个由6个7200rpm的SATA硬盘组成的RAID-5磁盘阵列上，线性写入的速度大约是300MB/秒，随机写入却只有50k/秒。注2：在某些情况下，顺序磁盘访问能够比【随机】内存访问还要快！Kafka架构•kafka集群运行流程图broker(1)broker(2)topic13741282109611Producer-AProducer-BConsumer-AConsumer-BConsumer-Cconsumergrouppartition1partition2partition3producerKafka架构•topic&partitiontopicbroker(1)13741282broker(2)109611Producer-AProducer-BConsumer-AConsumer-BConsumer-Cconsumergrouppartition1partition2partition3producerproducer怎么保证业务有序？1、每个partition对应一个文件（夹）2、分文件存储利于增加topic消息容量3、把partition放在不同磁盘上，可以提高读写性能4、把partition分散在不同机器上，支持负载均衡5、通过迁移单个partition，实现快速水平扩展6、partition内有序，partition间无序Kafka架构•producertopicbroker(1)13741282broker(2)109611Producer-AProducer-BConsumer-AConsumer-BConsumer-Cconsumergrouppartition1partition2partition3producerconsumer处理速度跟不上怎么办？1、自定义partitioner,保证同族消息保存在相同partition中，默认为hash算法随机分配2、异步提交时，会把多个消息合并，提高IO性能3、如果对topic进行水平扩容，producer需要重新获取broker列表，重新连接Kafka架构•consumertopicbroker(1)13741282broker(2)109611Producer-AProducer-BConsumer-AConsumer-BConsumer-Cconsumergrouppartition1partition2partition3producer不同的consumerGroup之间有什么关系？Thread-AThread-BThread-C1、一个partition只会被一个consumer线程连接；2、一个consumergroup由多个consumer线程组成；3、一个consumergroup可以同时被多个进程使用。Kafka架构•consumergroup注：GroupA和GroupB会收到的是完全相同的消息Kafka架构•kafka在zookeeper中的数据Kafka命令•数据分区和水平扩展–1、创建一个16分区，双备的topic./bin/kafka-topics.sh--create\--zookeeper10.100.10.200:2181\--replication-factor2\--partitions16--topicmy-topic\–2、水平扩展./bin/kafka-reassign-partitions.sh--execute\--manual-assignment-json-filepartitions-to-move.jsoncatpartitions-to-move.json:{partitions:[{topic:my-topic,partition:1,replicas:[1,4]}]}把一个partition的replica从broker1,2迁移到broker1,4上配置文件•producer配置文件•consumer配置文件•brokerKafka性能报告(A)1k,8K条/秒Kafka性能报告(B)1k,83MB/sQ&A提问答疑