MQ在分布式场景下的应用已经非常广泛了。可是在全部的MQ使用场景中,大多都要求不能丢消息。意味着必须有持久化的能力,传统行业经常使用的activemq、rabbitmq尽管有持久化能力,无奈的是性能太低。扩展性太差。对于互联网公司来说,要么就去基于他们去扩展,要么就是自己研发一个新的MQ。自从kafka横空出世。唤醒了人们对高性能 MQ的追求。
实际上kafka0.8版本号已经脱胎换骨,再也不仅仅是适合日志收集的场景了,kafka在可靠性方面做了非常多改进。实际上kafka已经能够用在企业级应用里面了。
怎样达到高性能?
1、 顺序写
磁盘的IO是全部应用性能的万恶之源。磁盘的顺序写能达到几百M每秒,而随机写仅仅有几十K,假设是一个千兆网卡,真实性能也就百M左右,可见,磁盘顺序写的威力巨大。
2、 零拷贝
某些情况下,数据的传输是不须要经过应用程序的,能够降低数据在用户空间和系统空间的缓冲区进行copy,降低对cpu和网卡的消耗,这样能够获得非常好的性能。Linux下提供此功能的系统调用主要有sendfile、mmap、splice。
3、 扩展性
假设要想突破单机的性能,必须拥有良好的扩展性,kafka能够在topic下建立partition,partition才是kafka的最小单位。这样就意味着同一个topic能够持久化到N台物理机上,仅仅要有足够的分区。
Kafka天生的分布式特性,差点儿能够无限的扩展。
实际上,kafka的吞吐量能够达到几万TPS,性能很高。而且扩展性如此高。在大并发、大数据量的场景下很适合。
怎么保证不丢消息?
丢消息主要有下面几个地方:
1、生产者发送消息。Kafka是採用ack机制保障的,假设消息没法送成功。也不会返回ack,所以。只要在生产者端做好重试机制就好。
怎样做好重试机制。又是一个很大的话题,此处不扩展开来。
Kafka服务端收到消息后能够直接拷贝到其它分片。成功后再通知生产者确定收到消息。就算不做同步的持久化,假设有三个节点,除非三个物理机同一时候宕机才会丢失数据。注意,这里假设不过kafka进程挂掉是不会丢数据的,操作系统会把数据持久化到磁盘。
2、Kafka存储的消息会不会丢失?kafka有定时删除策略,不以是否消费为前提,也就意味着没有经过消费的消息删除后就丢了,由于磁盘足够大。几天不删应该不是问题,假设几天的数据没有被消费你都没发现,那仅仅能怪你的监控系统太弱。或者你的应用量太小。出问题都没人发现,那也没有必要使用kafka。
3、消费消息。假设使用high level的api,全部消费者的信息都是存储在zookeeper中的,zookeeper的可靠性此处不必赘述。假设採用simple api。offset的可靠性要依赖于存储。务必小心。最好做充足的备份方案。
不管哪种方式,假设不能正常消费,你能够不去移动offset,这个地方全然能够自己控制。
有反复的消息怎么办?
尽管这样造成了反复消息的问题,可是这是非常难避免的,试想。像activeMQ那样,就算在服务端做了去重,消费时一样有可能会反复消费,不仅仅是在MQ中,就算你调用一个普通的服务接口,也有可能反复调用,最好的办法是通过业务尽量实现幂等性。比如添加唯一键。
从这些角度考虑。在互联网和大并发的企业级应用中,kafka会越来越重要,会被很多其它的人重视。就算是不用kafka,也会有跟kafka类似的架构模式、原理几乎相同的MQ,类似于rocketMQ。如今差的,就是被很多其它的企业使用。更复杂的场景证明。