Kafka--Storm

Storm讲师：陈博Storm+Kafka•Storm+Kafka介绍–storm为什么需要消息介绍–kafka是什么，有哪些特点–Storm+Kafka有什么好处•KafkaSpout•KafkaBolt•流式的进来，流式的出去•和DRPC不同，那个是一个请求一个相应为什么Storm需要一个消息队列？？？•答案很简单，解决和其他系统耦合的问题•如何获取输入数据–storm没有自己的接收器–而且从数据源拉（pull）可以更好地控制流量•如何把输出结果数据–storm没有自己的存储•消息列队正好解决了数据耦合问题•Storm本身自己是没有消息接收器的，DRPC本质上不是核心的东西，而是外围的工具，反过来它是通过Spout从外面拉数据的，拉数据可以很好的控制自己处理的流量，不至于上游产生数据量大产生雪崩•每个业务都去不同地方去取数据，会使得不通用，当业务产生数据的地方变化的话，你storm也要变，消息队列正好解决了这个问题了，进行了解耦，起到缓冲，当突发流量的时候，可以产生缓冲•各个业务把数据打到消息队列里面，这样storm从里面去拉，就很好的组合了，Storm没有自己的存储，放到KV里面去，当然有时候需要流式的产出到其他消息队列里面，然后需要看的人从消息队列里面去看数据，还有即使能写到Redis里面去，但是通常storm也不那么去做，当写后面KV失败的话，要么就丢，要不就重试，就会一级级的堵，一直堵到Spout去，这中间其实我们可以用消息队列里面做缓冲，然后再写入到KV里面去，这也是一种非常牛逼的模式Kafka是个什么东西？消息队列的特点？？？•消息列队的特点：•生产者消费者模式•先进先出（FIFO）顺序保证•可靠性保证–自己不丢数据–消费者不丢数据：“至少一次，严格一次”•至少一次就是可能会有两次，会重•严格一次机制就会负责一点消息列队常见场景•系统之间解耦合–queue模型–publish-subscribe模型•峰值压力缓冲•异步通信kafka是一个高吞吐的分部式消息系统•Apachekafkaispublish-subscribemessagingrethoughtasadistributedcommitlogkafka的架构•producer：消息生存者•consumer：消息消费者•broker：kafka集群的server，负责处理消息读、写请求，存储消息•topic：消息队列/分类•Queue里面有生产者消费者模型•broker就是代理，在kafkacluster这一层这里，其实里面是有很多个broker•topic就相当于queue•图里没有画其实还有zookeeper，这个架构里面有些元信息是存在zookeeper上面的，整个集群的管理也和zookeeper有很大的关系kafka的消息存储和生产消费模型•一个topic分成多个partition•每个partition内部消息强有序，其中的每个消息都有一个序号叫offset•一个partition只对应一个broker，一个broker可以管多个partition•消息不经过内存缓冲，直接写入文件•根据时间策略删除，而不是消费完就删除•producer自己决定往哪个partition写消息，可以是轮询的负载均衡，或者是基于hash的partition策略•接下来我们看kafka是怎么生产消息，消费消息，和怎么存储消息的，来看它精髓的地方•kafka里面的消息是有topic来组织的，简单的我们可以想象为一个队列，一个队列就是一个topic，然后它把每个topic又分为很多个partition，这个是为了做并行的，在每个partition里面是有序的，相当于有序的队列，其中每个消息都有个序号，比如0到12，从前面读往后面写，•一个partition对应一个broker，一个broker可以管多个partition，比如说，topic有6个partition，有两个broker，那每个broker就管3个partition•这个partition可以很简单想象为一个文件，当数据发过来的时候它就往这个partition上面append，追加就行，kafka和很多消息系统不一样，很多消息系统是消费完了我就把它删掉，而kafka是根据时间策略删除，而不是消费完就删除，在kafka里面没有一个消费完这么个概念，只有过期这样一个概念，这个模型带来了很多个好处，这个我们后面再讨论一下•这里producer自己决定往哪个partition里面去写，这里有一些的策略，譬如如果hash就不用多个partition之间去join数据了kafka的消息存储和生产消费模型•consumer自己维护消费到哪个offset•每个consumer都有对应的group•group内是queue消费模型–各个consumer消费不同的partition–因此一个消息在group内只消费一次•group间是publish-subscribe消费模型–各个group各自独立消费，互不影响–因此一个消息在被每个group消费一次kafka有哪些特点•消息系统的特点：生存者消费者模型，FIFO•高性能：单节点支持上千个客户端，百MB/s吞吐•持久性：消息直接持久化在普通磁盘上且性能好•分布式：数据副本冗余、流量负载均衡、可扩展•很灵活：消息长时间持久化+Client维护消费状态•消息系统基本的特点是保证了，有基本的生产者消费者模型，partition内部是FIFO的，partition之间呢不是FIFO的，当然我们可以把topic设为一个partition，这样就是严格的FIFO•接近网卡的极限•直接写到磁盘里面去，就是直接append到磁盘里面去，这样的好处是直接持久话，数据不会丢，第二个好处是顺序写，然后消费数据也是顺序的读，所以持久化的同时还能保证顺序，比较好，因为磁盘顺序读比较好•分布式，数据副本，也就是同一份数据可以到不同的broker上面去，也就是当一份数据，磁盘坏掉的时候，数据不会丢失，比如3个副本，就是在3个机器磁盘都坏掉的情况下数据才会丢，在大量使用情况下看这样是非常好的，负载均衡，可扩展，在线扩展，不需要停服务的•消费方式非常灵活，第一原因是消息持久化时间跨度比较长，一天或者一星期等，第二消费状态自己维护消费到哪个地方了，Queue的模型，发布订阅（广播）的模型，还有回滚的模型kafka与其他消息队列对比•RabbitMQ:分布式，支持多种MQ协议，重量级•ActiveMQ：与RabbitMQ类似•ZeroMQ：以库的形式提供，使用复杂，无持久化•redis：单机、纯内存性好，持久化较差•Kestrel：单机，持久化•kafka：分布式，较长时间持久化，高性能，轻量灵活•RabbitMQ也是常见的消息对列，它支持多种MQ的协议，jms啊，等多种协议等等，它的缺点比较重，erlang•另外一个ActiveMQ也和RabbitMQ类似，支持的协议比较多•ZeroMQ是一个socket的通信库，它是以库的形式提供的，所以说你需要写程序来实现消息系统，它只管内存和通信那一块，持久化也得自己写，还是那句话它是用来实现消息队列的一个库，其实在storm里面呢，storm0.9之前，那些spout和bolt，bolt和bolt之间那些底层的通信就是由ZeroMQ来通信的，它并不是一个消息队列，就是一个通信库，在0.9之后呢，因为license的原因，ZeroMQ就由Netty取代了，Netty本身就是一个网络通信库嘛，所以说更合适是在通信库这一层，不应该是MessageQueue这一层•Redis，本身是一个内存的KV系统，但是它也有队列的一些数据结构，能够实现一些消息队列的功能，当然它在单机纯内存的情况下，性能会比较好，持久化做的稍差，当持久化的时候性能下降的会比较厉害•Kestrel，这个也是在storm里面可以配合来使用的消息队列，是twitter开源的消息队列，也是单机，它提供的持久化是以日志的情况来写的，如果用的时候，你需要自己来搭建几台Kestrel的服务，自己处理负载均衡，自己去做容错•Kafka，的亮点，天生是分布式的，不需要你在上层做分布式的工作，另外有较长时间持久化，前面基本消费就干掉了，另外在长时间持久化下性能还比较高，顺序读和顺序写，另外还通过sendFile这样0拷贝的技术直接从文件拷贝到网络，减少内存的拷贝，还有批量读批量写来提高网络读取文件的性能，最后一点是比较轻量和灵活消费状态由谁维护纠结是什么样的概念？？？我们这点来深入探讨一下•消费状态谁来维护Clientvs.Server•有人可能会说kafka写磁盘，会不会是瓶颈，其实不会而且是非常好的，为什么是非常好的，因为kafka写磁盘是顺序的，所以不断的往前产生，不断的往后写，kafka还用了sendFile的0拷贝技术，提高速度，而且还用到了批量读写，一批批往里写，64K为单位，100K为单位，每一次网络传输量不会特别小，RTT（RTT:Round-TripTime往返时间）的开销就会微不足道，对文件的操作不会是很小的IO，也会是比较大块的IOstorm+kafka有什么好处•满足获取输入。产生输出数据的基本需求•kafka的分布式、产生输出数据的基本需求•kafka的分布式、高性能和storm吻合•pub-sub模型可以让多个storm业务共享输入数据•kafka灵活消费的模式能配合storm实现不丢不重（exactly-once）的处理模型•exactly-once，精准一次，这种模型在很多时候也是很有用的理解零拷贝•从WIKI的定义中，我们看到“零拷贝”是指计算机操作的过程中，CPU不需要为数据在内存之间的拷贝消耗资源。而它通常是指计算机在网络上发送文件时，不需要将文件内容拷贝到用户空间（UserSpace）而直接在内核空间（KernelSpace）中传输到网络的方式。•Non-ZeroCopy方式：•ZeroCopy方式：•从上图中可以清楚的看到，ZeroCopy的模式中，避免了数据在用户空间和内存空间之间的拷贝，从而提高了系统的整体性能。Linux中的sendfile()以及JavaNIO中的FileChannel.transferTo()方法都实现了零拷贝的功能，而在Netty中也通过在FileRegion中包装了NIO的FileChannel.transferTo()方法实现了零拷贝。