topic

前提条件： 在启动broker时候开启删除topic的开关，即在server.properties中添加： delete.topic.enable=true 命令： bin/kafka-topics.sh --zookeeper zk_host:port/chroot --delete --topic my_topic_name 这条命令其实就是在zookeeper（假设你的chroot就是/）的/admin/delete_topics下创建一个临时节点，名字就是topic名称，比如如果执行命令： bin/kafka-topics.sh --zookeeper zk_host:port/chroot --delete --topic test-topic 那么，命令返回后，zookeeper的/admin/delete_topics目录下会新创建一个临时节点test-topic 这条命令返回打印在控制台上的消息也说明了这点： Topic test-topic is marked for deletion. Note: This will have no impact if delete.topic.enable is not set to true. 这就是说，这条命令其实并不执行删除动作，仅仅是在zookeeper上标记该topic要被删除而已

创建kafka topic bin/kafka-topics.sh --zookeeper node01:2181 --create --topic t_cdr --partitions 30 --replication-factor 2 注： partitions指定topic分区数，replication-factor指定topic每个分区的副本数 partitions分区数: partitions ：分区数，控制topic将分片成多少个log。可以显示指定，如果不指定则会使用broker(server.properties)中的num.partitions配置的数量 虽然增加分区数可以提供kafka集群的吞吐量、但是过多的分区数或者或是单台服务器上的分区数过多，会增加不可用及延迟的风险。因为多的分区数，意味着需要打开更多的文件句柄、增加点到点的延时、增加客户端的内存消耗。 分区数也限制了consumer的并行度，即限制了并行consumer消息的线程数不能大于分区数 分区数也限制了producer发送消息是指定的分区。如创建topic时分区设置为1，producer发送消息时通过自定义的分区方法指定分区为2或以上的数都会出错的；这种情况可以通过alter –partitions 来增加分区数。 replication-factor副本 replication factor

为什么要有Kafka？ 在目前流量越来越大的时代，很多时候我们的服务器资源是没有利用到的，而是在某一瞬间才利用到这个资源，而这一瞬间正是服务器流量的高峰期，而如果没有先弄多几台服务器加强集群的性能，可能就在那一刻就挂了。 Kafka就是将这些流量进行一个排队缓存，一个一个来，相当于一个保安维护好整个秩序。 什么是kafka？ Kafka是由LinkedIn使用Scala开发的，而后很多Api使用Java来写，并捐给了Apache并开源。 Kafka是一个分布式消息队列，为了处理实时数据提供一个统一、高通量、低等待的平台，通常在流式计算中Kafka用来缓存数据，Storm消费Kafka的数据进行计算。 Kafka对消息保存时是根据Topic(主题)进行归类的，发送消息者称为Producer(生产者)，消息接收者称为Consumer(消费者)，此外Kafka集群中有多个Kafka实例组成，就是多个服务器，每个实例称为broker(经纪人)。 Kafka集群时依赖Zookeeper来保存一些元数据信息，从而保证系统的可用性。 组成 Broker ： 一台Kafka服务器就是一个broker。 一个集群可以由多个broker组成。 一个broker可以容纳多个Topic。 Partition( 分区)： 为了实现扩展性，一个非常大的Topic可以分布到多个Broker上

本文档是在本机上构建多节点的kafka集群 standalone版的请参考 https://www.cnblogs.com/pageBlog/p/11379364.html 1. 首先将配置文件拷贝多份 cp config/server.properties config/server-1.properties cp config/server.properties config/server-2.properties 2. 修改对应的配置文件 3. 启动这两个节点 bin/kafka-server-start.sh config/server-1.properties & bin/kafka-server-start.sh config/server-2.properties & 4. 创建一个新话题 bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 3 --partitions 1 --topic my-replicated-topic 5. 查看话题详细信息：bin/kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic my-replicated-topic 6.

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介：郑志彬，毕业于华南理工大学计算机科学与技术（双语班）。先后从事过电子商务、开放平台、移动浏览器、推荐广告和大数据、人工智能等相关开发和架构。目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务。擅长各种业务形态的业务架构、平台化以及各种业务解决方案。 博客地址： http://arganzheng.life 。 背景 最近要把原来做的那套集中式日志监控系统进行迁移，原来的实现方案是: Log Agent => Log Server => ElasticSearch => Kibana，其中Log Agent和Log Server之间走的是Thrift RPC，自己实现了一个简单的负载均衡(WRB)。 原来的方案其实运行的挺好的，异步化Agent对应用性能基本没有影响。支持我们这个每天几千万PV的应用一点压力都没有。不过有个缺点就是如果错误日志暴增，Log Server这块处理不过来，会导致消息丢失。当然我们量级没有达到这个程度，而且也是可以通过引入队列缓冲一下处理。不过现在综合考虑，其实直接使用消息队列会更简单。PRC，负载均衡，负载缓冲都内建实现了。另一种方式是直接读取日志，类似于logstash或者flume的方式

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介：郑志彬，毕业于华南理工大学计算机科学与技术（双语班）。先后从事过电子商务、开放平台、移动浏览器、推荐广告和大数据、人工智能等相关开发和架构。目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务。擅长各种业务形态的业务架构、平台化以及各种业务解决方案。 博客地址： http://arganzheng.life 。 背景 最近要把原来做的那套集中式日志监控系统进行迁移，原来的实现方案是: Log Agent => Log Server => ElasticSearch => Kibana，其中Log Agent和Log Server之间走的是Thrift RPC，自己实现了一个简单的负载均衡(WRB)。 原来的方案其实运行的挺好的，异步化Agent对应用性能基本没有影响。支持我们这个每天几千万PV的应用一点压力都没有。不过有个缺点就是如果错误日志暴增，Log Server这块处理不过来，会导致消息丢失。当然我们量级没有达到这个程度，而且也是可以通过引入队列缓冲一下处理。不过现在综合考虑，其实直接使用消息队列会更简单。PRC，负载均衡，负载缓冲都内建实现了。另一种方式是直接读取日志，类似于logstash或者flume的方式

接触 kafka 有一段时间了，一个人的力量实在有限，国内 rocketmq 的生态确实更好，最终决定换方向。 rocketmq 文档地址： http://rocketmq.cloud/zh-cn/docs/bestpractice-broker.html windows 环境下测试， 启动 nameserver： mqnamesrv.cmd -n localhost:9876 启动 broker： mqbroker.cmd -n localhost:9876 创建 topic，创建的 topic 默认 8 个分区： mqadmin.cmd updateTopic -n localhost:9876 -b localhost:10911 -t TopicTest 查看 topic 分区信息： mqadmin.cmd topicStatus -n localhost:9876 -t TopicTest 根据分区 offset 查询消息： mqadmin.cmd queryMsgByOffset -n localhost:9876 -b za-zhangzejiang -i 0 -o 30 -t TopicTest 来源： https://www.cnblogs.com/allenwas3/p/11376010.html

config.properties server.properties server.1=172.28.92.39:2888:3888 server.2=172.28.92.37:2888:3888 server.3=172.28.92.38:2888:3888 server start ./bin/zookeeper-server-start.sh -daemon ./config/zookeeper.properties stop ./bin/kafka-server-start.sh -daemon ./config/server.properties 分区 修改分区 ./bin/kafka-topics.sh --zookeeper 127.0.0.1:2181 --alter --partitions 3 --topic monitor-log 消费 手动消费 ./bin/kafka-console-consumer.sh --bootstrap-server 172.28.92.37:9092,172.28.92.38:9092,172.28.92.39:9092 --topic monitorlog --from-beginning ./bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic

松耦合架构 概述 使用独立的组件设计架构，降低相互依赖，当一个组件出现故障时，其他不受影响 利用ELB和SQS来打破传统服务器各层的关联，成为各层之间的中介，各层的故障和扩展均由中介自助处理 系统的耦合程度越低，系统的扩展就越轻松，容错能力越高 托管的无服务架构 设计服务，而不是设计服务器 通过托管服务和无服务器架构可以提高环境的可靠性和效率 在需要时优先考虑无服务器解决方案 使用消息队列处理应用程序之间的通信 在静态资产存储在外部 ， 如S3 使用IAM处理用户身份验证和用户状态存储 面向服务的架构（SOA） 服务是独立的功能单元 应用程序通过通信协议为其他组件提供服务 微服务架构 概念 SOA中的小型、独立进程 每个进程专注于执行一个小型任务 不同进程之间通过与语言无关的API进行通信 微服务可以独立扩展，可以轻松的扩展或收缩组件而其他组件保持不变。 微服务还可以轻松应对故障，因为不会出现级联故障而提高容错能力，所以可以将系统可用性适当降低。 微服务是易于交换的，只需要用一个组件替换另一个组件就可以完成升级 将功能拆分成不同组件 迭代小型部件 缩小测试界面区 受益于更低的变更风险 使用水平扩展的各个组件 意味着成本、规模和更改风险均降低，从而提高效率 微服务边界上下文 每个业务域都分为多个上下文，业务域可是任何完整的业务流程，他是被多个数据块结合构建

环境搭建 1.创建maven项目(jar) 2.pom.xml添加依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.4.0.RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-activemq</artifactId> </dependency> </dependencies> 3.编写引导类