Kafka消息中间件（一）（基本概念与安装）-创新互联
将一些主流程不需要返回的数据交给中间件处理，以并行的方式，可以提高系统的并发量、吞吐量和响应时间。
可以将发送短信和发送邮件交给消息中间件去处理。
2.应用解耦消息中间件在一定程度上符合了应用的解耦操作，将不同功能的应用分布到不同的系统，使用消息中间件来进行互相调用，可以保证一台系统宕机的情况下，不影响到其他的系统。
示例：订单系统调用库存系统若订单系统宕机，库存系统也同样无法服务
在高并发的情况下，当有大批量的请求访问服务，一台服务器无法承受过多的请求，可能会使服务器宕机，影响服务的正常运行。
我们可以引入消息队列，将并发比较高的请求放入消息队列，分批次的去处理，这样可以保证服务器的正常运行，保证服务器的性能不会受到影响，缓解服务器的压力。
秒杀活动并发访问量较大，可能会使服务器宕机，可以引入消息队列，控制活动的人数，防止短时间内高访问搞垮服务器。
二、Kafka的优势 1.优势- 支持分布式，可以以集群的方式运行
- 可以按要求保存数据，保存多久都可以
- 流式处理将数据处理的层次提示到了新高度，消息系统只会传递数据，Kafka的流式处理能力可以让我们用很少的代码就能动态地处理派生流和数据集。所以Kafka不仅仅是个消息中间件。
消息是kafka的数据单元，以字节数组（byte[]）组成，还可以有键（可选元数据，也是字节数组），用来对消息选取分区。
为了提高效率，可以分批次写入kafka，多个消息组成一个批次，一个批次就是一组消息，一组消息属于一个主题和分区。如果每一个消息都单独传递，会占用大量的网络开销，分批次可以减少网络开销。
2.主题和分区Kafka的消息选用主题（Topic）进行分类（像Mysql的表），一个主题下可以有多个分区（Partition）（像数据库的分表技术），当有生产者生产新消息时，会以文件的形式存储到分区，消费者按照顺序进行消费分区内的文件信息。
当有多个分区时，生产者将消息均匀的分布到不同的分区，可以提高kafka的吞吐量，保证多个消费者同时进行消费，但是这样就不能保证消费者的顺序消费，当消费者必须要按照顺序消费时，我们只能在每个主题下设置一个分区。
消费者订阅一个或多个主题（Topic），按照消息生产的顺序进行读取，消费者通过检查分区中的偏移量，从而确定该消息有没有被读取过，是一个不断递增的整数值，创建消息的时候，kafka会将偏移量加入消息中。在一个主题的一个分区中，消息的偏移量是唯一的，每个分区读取的消息的偏移量最终会存储到kafka或zookeeper的文件中，因此当服务重启后，消息是不会丢失的。
多个消费者可以组成一个消费者群组，共同读取一个主题中的消息，可以保证每个分区只被一个消费者进行读取。
一个独立的kafka服务就是一个Broke，主要为生产者提供服务，接收生产者的消息，设置偏移量，将生产者的消息存储到磁盘中；为消费者提供服务，为消费者响应消息。kafka可以在上千个分区中响应百万级的消息量（在合适的硬件配置中和JVM调优）。
多个broker可以组成一个集群。每个集群中broker会选举出一个集群控制器。控制器会进行管理，包括将分区分配给broker和监控broker。集群里，一个分区从属于一个broker，这个broker被称为首领。但是分区可以被分配给多个broker，这个时候会发生分区复制。集群中Kafka内部一般使用管道技术进行高效的复制。
在一定期限内保留消息是Kafka的一个重要特性，Kafka broker默认的保留策略是：要么保留一段时间（7天），要么保留一定大小（比如1个G）。到了限制，旧消息过期并删除。但是每个主题可以根据业务需求配置自己的保留策略（开发时要注意，Kafka不像Mysql之类的永久存储）。
四、kafka的安装与配置 1.安装Kafka需要Zookeeper保存集群的元数据信息和消费者信息。Kafka一般会自带Zookeeper，但是从稳定性考虑，应该使用单独的Zookeeper，而且构建Zookeeper集群。
下载解压wget https://downloads.apache.org/kafka/3.3.1/kafka_2.13-3.3.1.tgz
tar -xf kafka_2.13-3.3.1.tgzcd kafka_2.13-3.3.1/bin
./zookeeper-server-start.sh ../config/zookeeper.properties
./kafka-server-start.sh ../config/server.properties./kafka-storage.sh random-uuid
./kafka-storage.sh format -t [生成的uuid]-c ../config/kraft/server.properties./kafka-server-start.sh ../config/kraft/server.properties
配置文件放在Kafka目录下的config目录中，主要是server.properties文件
4.1.1.broker.id在单机时无需修改，但在集群下部署时往往需要修改。它是个每一个broker在集群中的唯一表示，要求是正数。当该服务器的IP地址发生改变时，broker.id没有变化，则不会影响consumers的消息情况。
4.1.2.listeners监听列表(以逗号分隔 不同的协议(如plaintext,trace,ssl、不同的IP和端口)),hostname如果设置为0.0.0.0则绑定所有的网卡地址；如果hostname为空则绑定默认的网卡。如果没有配置则默认为java.net.InetAddress.getCanonicalHostName()。
如：PLAINTEXT://myhost:9092,TRACE://:9091或 PLAINTEXT://0.0.0.0:9092,
4.1.3.zookeeper.connectzookeeper集群的地址，可以是多个，多个之间用逗号分割。（一组hostname:port/path列表,hostname是zk的机器名或IP、port是zk的端口、/path是可选zk的路径，如果不指定，默认使用根路径）
4.1.4.log.dirsKafka把所有的消息都保存在磁盘上，存放这些数据的目录通过log.dirs指定。可以使用多路径，使用逗号分隔。如果是多路径，Kafka会根据“最少使用”原则，把同一个分区的日志片段保存到同一路径下。会往拥有最少数据分区的路径新增分区。
4.1.5.num.recovery.threads.per.data.dir每数据目录用于日志恢复启动和关闭时的线程数量。因为这些线程只是服务器启动（正常启动和崩溃后重启）和关闭时会用到。所以完全可以设置大量的线程来达到并行操作的目的。注意，这个参数指的是每个日志目录的线程数，比如本参数设置为8，而log.dirs设置为了三个路径，则总共会启动24个线程。
4.1.6.auto.create.topics.enable是否允许自动创建主题。如果设为true，那么produce（生产者往主题写消息），consume（消费者从主题读消息）或者fetch metadata（任意客户端向主题发送元数据请求时）一个不存在的主题时，就会自动创建。缺省为true。
4.1.7.delete.topic.enable=true删除主题配置，默认未开启
5.主题配置新建主题的默认参数
5.1.1.num.partitions每个新建主题的分区个数（分区个数只能增加，不能减少 ）。这个参数一般要评估，比如，每秒钟要写入和读取1000M数据，如果现在每个消费者每秒钟可以处理50MB的数据，那么需要20个分区，这样就可以让20个消费者同时读取这些分区，从而达到设计目标。（一般经验，把分区大小限制在25G之内比较理想）
5.1.2.log.retention.hours日志保存时间，默认为7天（168小时）。超过这个时间会清理数据。bytes和minutes无论哪个先达到都会触发。与此类似还有log.retention.minutes和log.retention.ms，都设置的话，优先使用具有最小值的那个。（提示：时间保留数据是通过检查磁盘上日志片段文件的最后修改时间来实现的。也就是最后修改时间是指日志片段的关闭时间，也就是文件里最后一个消息的时间戳）
5.1.3.log.retention.bytestopic每个分区的大文件大小，一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限制。log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除。(注意如果是log.retention.bytes先达到了，则是删除多出来的部分数据)，一般不推荐使用大文件删除策略，而是推荐使用文件过期删除策略。
5.1.4.log.segment.bytes分区的日志存放在某个目录下诸多文件中，这些文件将分区的日志切分成一段一段的，我们称为日志片段。这个属性就是每个文件的大尺寸；当尺寸达到这个数值时，就会关闭当前文件，并创建新文件。被关闭的文件就开始等待过期。默认为1G。
如果一个主题每天只接受100MB的消息，那么根据默认设置，需要10天才能填满一个文件。而且因为日志片段在关闭之前，消息是不会过期的，所以如果log.retention.hours保持默认值的话，那么这个日志片段需要17天才过期。因为关闭日志片段需要10天，等待过期又需要7天。
5.1.5.log.segment.ms作用和log.segment.bytes类似，只不过判断依据是时间。同样的，两个参数，以先到的为准。这个参数默认是不开启的。
5.1.6.message.max.bytes表示一个服务器能够接收处理的消息的大字节数，注意这个值producer和consumer必须设置一致，且不要大于fetch.message.max.bytes属性的值(消费者能读取的大消息,这个值应该大于或等于message.max.bytes)。该值默认是1000000字节，大概900KB~1MB。如果启动压缩，判断压缩后的值。这个值的大小对性能影响很大，值越大，网络和IO的时间越长，还会增加磁盘写入的大小。
Kafka设计的初衷是迅速处理短小的消息，一般10K大小的消息吞吐性能最好（LinkedIn的kafka性能测试）
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
文章名称：Kafka消息中间件（一）（基本概念与安装）-创新互联
本文URL：http://azwzsj.com/article/djsghj.html
