注意

  • 乍本子有了spring-kafka,一部分功力于spring-integration-kafka中改换出来了,但是除此之外官方使用外,网上资料十分少

https://github.com/spring-projects/spring-integration-samples/tree/master/basic/kafka

统计 1

单机集成环境

参考资料

http://colobu.com/2014/11/19/kafka-spring-integration-in-practice/
https://github.com/smallnest/spring-kafka-demo

通过spring boot来集成kafka

http://www.jianshu.com/p/048e954dab40

Github上一个所以spring-boot来集成kafka,mongodb,myibatis等等的事例:

https://github.com/xho22/spring-boot-dubbo-mongo-mybatis-kafka-liquibase

_WA_Sys_00000009_00000062:统计对象的名目。不同的机械名称不同,自动创建的统计信息都归因于_WA_Sys开头,00000009象征的是第几列,后面的一再是一个十六进制的再三,等于表的object_id,WA是华盛顿,是sql
server开发组所在地

question

  • partitions是何等分配的,是每个server上且有所有的partitions么,还是当每个server上但发生有平份partitions?
    如果是前者,如何节约磁盘空间的?

  • 每个分区,多独server, 一个leader,分区可以起差不多个备份。

  • 本质上kafka只支持Topic.每个consumer属于一个consumer
    group;反过来说,每个group中可产生多单consumer.发送及Topic的音,只会让订阅者Topic的每个group中之一个consumer消费.也就是说可以经group在里贯彻consumer的负荷均衡,在表面实现不同topic消息之隔断。

  • 每当kafka中,一个partition中的信息才会为group中之一个consumer消费;每个group中consumer消息消费互动独立;我们得当一个group是一个”订阅”者,一个Topic中之每个partions,只会受一个”订阅者”中的一个consumer消费,不过一个consumer可以花费基本上只partitions中之消息.kafka只能保证一个partition中的信给有consumer消费时,消息是逐一的.事实上,从Topic角度来说,消息据无是稳步的.

 

集成

SELECT * FROM SYS.stats

kafka使用

于kafka启动之上要以开动zookeeper和kafka server

令如下:

bin/kafka-server-start.sh config/server.properties

bin/zookeeper-server-start.sh config/zookeeper.properties

切切实实安排好改server.properties和zookeeper.properties.

假使出现下面的错,则是为没有启动kafka server.

Caused by: kafka.admin.AdminOperationException: replication factor: 1 larger than available brokers: 0
    at kafka.admin.AdminUtils$.assignReplicasToBrokers(AdminUtils.scala:70)
    at kafka.admin.AdminUtils$.createTopic(AdminUtils.scala:171)
    at org.springframework.integration.kafka.listener.KafkaTopicOffsetManager.createCompactedTopicIfNotFound(KafkaTopicOffsetManager.java:268)
    at org.springframework.integration.kafka.listener.KafkaTopicOffsetManager.afterPropertiesSet(KafkaTopicOffsetManager.java:210)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
    ... 22 more

创建topic

bin/kafka-topics.sh  --create --zookeeper 10.160.5.56:2181  --replication-factor 1 --partitions 1 --topic test

bin/kafka-topics.sh --zookeeper 10.160.5.56:2181 -list

生产者

bin/kafka-console-producer.sh  --broker-list  10.160.5.56:9092 --topic test

消费者

bin/kafka-console-consumer.sh --zookeeper 10.160.5.56:2181  --topic test --from-beginning

筹思路

1、持久性

kafka使用文件存储消息,这即一直决定kafka在性及严重依赖文件系统的本身特性.且无任何OS下,对文件系统本身的优化几乎从来不可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对准日记文件进行append操作,因此磁盘检索的支出是比较小之;同时为削减磁盘写副的次数,broker会将信息暂buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的不善数.

2、性能

亟待考虑的震慑性点多多,除磁盘IO之外,我们还需要考虑网络IO,这一直关联及kafka的吞吐量问题.kafka并无提供最好多高明的技艺;对于producer端,可以以消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker;对于consumer端也是一模一样,批量fetch多条消息.不过消息量的分寸可以透过安排文件来因定.对于kafka
broker端,似乎有个sendfile系统调用可以潜在的升级网络IO的习性:将文件之多寡映射到系统内存中,socket直接读取相应的内存区域即可,而无论是需经过再copy和交换.
其实对producer/consumer/broker三者而言,CPU的支出应还无甚,因此启用消息压缩机制是一个了不起的方针;压缩需要吃少量底CPU资源,不过对于kafka而言,网络IO更应用考虑.可以拿其余在网及传的音都由此压缩.kafka支持gzip/snappy等多减少方式.

3、生产者

负载均衡: producer将会和Topic下具有partition
leader保持socket连接;消息由producer直接通过socket发送到broker,中间不见面经过任何”路由于层”.事实上,消息被路由于到哪个partition上,有producer客户端决定.比如可以使”random””key-hash””轮询”等,如果一个topic中起差不多个partitions,那么以producer端实现”消息均衡分发”是必需之.

中partition
leader的职务(host:port)注册于zookeeper中,producer作为zookeeper
client,已经注册了watch用来监听partition leader的更动事件.
异步发送:将多久信息暂还在客户端buffer起来,并拿他们批量之殡葬到broker,小数码IO太多,会延宕慢整体的网延迟,批量延迟发送事实上提升了网效率。不过这也产生一定之隐患,比如说当producer失效时,那些并未发送的信将会见丢。

4、消费者

consumer端向broker发送”fetch”请求,并告知其取得信息之offset;此后consumer将会见落肯定条数的信;consumer端也堪重置offset来重新消费消息.

以JMS实现中,Topic模型基于push方式,即broker将信息推送给consumer端.不过在kafka中,采用了pull方式,即consumer在和broker建立连接之后,主动去pull(或者说fetch)消息;这被模式有些长,首先consumer端可以依据自己之消费力量适时的去fetch消息并拍卖,且可以决定消息消费之快慢(offset);此外,消费者可可以的操纵消息消费的数码,batch
fetch.

另外JMS实现,消息消费的职位是来prodiver保留,以便避免再次发送信息还是用从未费成功的音重发等,同时还要控制消息的状态.这就算要求JMS
broker需要极多额外的工作.在kafka中,partition中的消息就生一个consumer在花费,且未有信息状态的控制,也远非复杂的音信确认机制,可见kafka
broker端是一定轻量级的.当消息被consumer接收后,consumer可以于地头保存最后消息之offset,并间歇性的朝zookeeper注册offset.由此可见,consumer客户端也异常轻量级.

应用状况

1.messaging

对于有些正常的音网,kafka是独正确的挑三拣四;partitons/replication和容错,可以要kafka具有优良的扩展性和属性优势.不了到目前为止,我们应当十分明白认识及,kafka并没有提供JMS中之”事务性””消息传担保(消息确认机制)””消息分组”等企业级特性;kafka只能以作为”常规”的消息网,在必然水平及,尚未确保信息的殡葬和吸纳绝对可靠(比如,消息重发,消息发送丢失等)

2.Websit activity tracking

kafka可以看做”网站活性跟踪”的特级工具;可以用网页/用户操作等消息发送到kafka中.并实时监察,或者离线统计分析等

3.Log Aggregation

kafka的特点决定它非常适合作为”日志收集中心”;application可以用操作日志”批量””异步”的出殡到kafka集众多被,而无是保留于地面或DB中;kafka可以批量付给信息/压缩消息等,这对producer端而言,几乎感觉不顶性的开支.此时consumer端可以使hadoop等任何系统化的囤积和分析系统.

kafka简介

参照网址

http://www.cnblogs.com/likehua/p/3999538.html
http://www.infoq.com/cn/articles/apache-kafka/
http://www.infoq.com/cn/articles/kafka-analysis-part-1
http://www.infoq.com/cn/articles/kafka-analysis-part-2
http://www.infoq.com/cn/articles/kafka-analysis-part-3
http://www.infoq.com/cn/articles/kafka-analysis-part-4
http://www.infoq.com/cn/articles/kafka-analysis-part-5
http://www.aboutyun.com/thread-12882-1-1.html