springboot

nacos 单机8850

1. 服务的注册与发现
2. 配置中心
   alibaba-nacos-config-client

mysql安装

mysqld -initialize --user=mysql
mysqld -install
mysql -u root -p
use mysql;
update mysql.user set authentication_string=password(“1234”) where user=“root”;
flush privileges;
quit;

nacos集群

8851 8852 8853
集群配置失败是因为没有按照下载配置里面的jdbc驱动格式啊
默认的是最好的

sentinel接口限流

java -jar sentinel-dashboard-1.6.0.jar
sentinel
sentinel

sentinel Dashboard中修改规则同步到Nacos

@Qualifter避免歧义

SentinelResource使用详解

需要限流的层面不仅限于接口，可能对于某个方法的调用限流，对于外部资源的调用限流
我们不希望抛出生硬的错误，会做一些特殊的处理
Hystrix熔断理解：
设置超时
如果对某个微服务的请求有大量超时，就没必要再去请求依赖的服务
断路器可理解为对容易导致错误的操作代理。这种代理能够统计一段时间内调用失败的次数，并决定是正常请求依赖的服务还是直接返回
断路器还可以自动诊断依赖的服务
当依赖的服务不正常时，打开断路器时快速失败，从而防止雪崩效应，当发现断路器状态恢复正常，又会恢复请求。 ===== 不是知道原理，而是用技术实现功能。
Dubbo只是服务治理与RPC实现方案

SpringCloud

	Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中涉及的配置管理、
	服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了
	一种简单的开发方式。
	Spring Cloud Config、
	Spring Cloud Netflix、
	Spring Cloud0 CloudFoundry、
	Spring Cloud AWS、
	Spring Cloud Security、
	Spring Cloud Commons、
	Spring Cloud Zookeeper、
	Spring Cloud CLI等项目
	
	微服务架构就是将一个完整的应用从数据存储开始垂直拆分成多个不同的服务，每个服务都能独立部署、独立维护、
	独立扩展，服务与服务间通过诸如RESTful API的方式互相调用
	
	微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，
	并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。
	这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。
	
	这样的整体服务（monolithic server）是一种构建系统很自然的方式。虽然你可以利用开发语基础特性把应用程序划分成类、
	函数、命名空间，但所有你处理请求的逻辑都运行在一个单独的进程中。在某些场景中，开发者可以在的笔计本上开发、测试应用，
	然后利用部署通道来保证经过正常测试的变更，发布到产品中。你也可以使用横向扩展，通过负载均衡将多个应用部署到多台服务器上。
	
	微服务架构风格（microservice architectural style）的出现：把应用程序构建为一套服务。事实是，服务可以独立部署和扩展
	，每个服务提供了一个坚实的模块边界，甚至不同的服务可以用不同的编程语言编写。它们可以被不同的团队管理。

• 组件化（Componentization ）与服务（Services）
  微服务架构（Microservice architectures）会使用库（libraries），但组件化软件的主要方式是把它拆分成服务。
  我们把库（libraries）定义为组件，这些组件被链接到程序，并通过内存中函数调用（in-memory function calls）
  来调用，而服务（services ）是进程外组件（out-of-process components），他们利用某个机制通信，比如
  WebService 请求，或远程过程调用（remote procedure call）。组件和服务在很多面向对象编程中是不同的概念。
• 围绕业务功能的组织
• 产品不是项目
• 分散数据管理
• 基础设施自动化

注册中心和服务发现组件 --nacos zookeeper Eureka

	注册上-发现调用(Rest)

客户端负载均衡–Ribbon Feign 客户端几种消费方式–Feign WebClient RestTemplate

	一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置
	ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。
	它使得编写Web服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。
	它具备可插拔的注解支持，包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。
	Spring Cloud Feign还扩展了对Spring MVC注解的支持，同时还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。
	
	eureka-server作为服务注册中心、eureka-client作为服务提供者

微服务应用构建消息驱动能力的框架–Spring Cloud Stream-kafka

	如何实现对配置信息的实时更新。虽然，我们已经能够通过/refresh接口和Git仓库的Web Hook
	来实现Git仓库中的内容修改触发应用程序的属性更新。但是，若所有触发操作均需要我们手工去维护
	Web Hook中的应用位置的话，这随着系统的不断扩张，会变的越来越难以维护，而消息代理中间件是
	解决该问题最为合适的方案。是否还记得我们在介绍消息代理中的特点时有提到过这样一个功能：
	消息代理中间件可以将消息路由到一个或多个目的地。
	发布-订阅、消费组以及消息分区
	通过使用Spring Cloud Stream，可以有效地简化开发人员对消息中间件的使用复杂度，
	让系统开发人员可以有更多的精力关注于核心业务逻辑的处理。由于Spring Cloud Stream基于Spring Boot实现，
	所以它秉承了Spring Boot的优点，实现了自动化配置的功能帮忙我们可以快速的上手使用，
	但是目前为止Spring Cloud Stream只支持下面两个著名的消息中间件的自动化配置：kafka RabbitMQ

我们通过使用Spring Cloud Bus与Spring Cloud Config的整合，并以kafka作为消息代理，实现了应用配置的动态更新。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BeHBC4vL-1575446193922)(springboot_files/1.jpg)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LFb67Rpp-1575446193923)(springboot_files/2.jpg)]

统一管理微服务配置–Spring Cloud Config

Spring Cloud Config为服务端和客户端提供了分布式系统的外部化配置支持。
配置服务器为各应用的所有环境提供了一个中心化的外部配置。
它实现了对服务端和客户端对Spring Environment和PropertySource抽象的映射，所以它除了适用于Spring构建的应用程序，
也可以在任何其他语言运行的应用程序中使用。作为一个应用可以通过部署管道来进行测试或者投入生产，
我们可以分别为这些环境创建配置，并且在需要迁移环境的时候获取对应环境的配置来运行。

配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工
具来方便的管理和访问配置内容。当然他也提供本地化文件系统的存储方式

/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties

一个服务端一个客户端,可以调用服务端的配置文件啊!!!!

采用数据库存储配置信息
构建一个通过数据酷来存储配置内容的配置中心了，下面我们可以通过配置中心暴露的端点来尝试读取配置		

微服务的容错处理与检测–Hystrix,Sentinel

	[对比](https://www.cnblogs.com/zhyg/p/11474406.html)

微服务网关–gateway zuul

底层是用Servlet实现的
通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，
它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，
为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，
使得服务集群主体能够具备更高的可复用性和可测试性。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kTXzpKHB-1575446193923)(springboot_files/5.jpg)]
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
路由服务相关内容

服务过滤

	不仅仅实现了路由功能来屏蔽诸多服务细节，更实现了服务级别、均衡负载的路由。
	实现了接口权限校验与微服务业务逻辑的解耦。通过服务网关中的过滤器，在各生命
	周期中去校验请求的内容，将原本在对外服务层做的校验前移，保证了微服务的无状态性，
	同时降低了微服务的测试难度，让服务本身更集中关注业务逻辑的处理。
	实现了断路器，不会因为具体微服务的故障而导致服务网关的阻塞，依然可以对外服务。
	
	
	虽然使用Swagger可以为Spring MVC编写的接口生成了API文档，但是在微服务化之后，这些API文档都离散在各个微服务中，
	是否有办法将这些接口都整合到一个文档中
	
	swagger2与网关的结合。。。

分布式服务跟踪–Spring Cloud Sleuth

通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果，
在复杂的微服务架构系统中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，
在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。
这时候对于每个请求全链路调用的跟踪就变得越来越重要，通过实现对请求调用的跟踪可以帮助
我们快速的发现错误根源以及监控分析每条请求链路上的性能瓶颈等好处

我们已经为trace-1和trace-2引入了Spring Cloud Sleuth的基础模块spring-cloud-starter-sleuth，
实现了为各微服务的日志信息中添加跟踪信息的功能。但是，由于日志文件都离散的存储在各个服务实例的文件
系统之上，仅仅通过查看日志文件来分析我们的请求链路依然是一件相当麻烦的差事，所以我们还需要一些工具
来帮助我们集中的收集、存储和搜索这些跟踪信息。引入基于日志的分析系统是一个不错的选择，比如：ELK平台，
它可以轻松的帮助我们来收集和存储这些跟踪日志，同时在需要的时候我们也可以根据Trace ID来轻松地搜索出
对应请求链路相关的明细日志。

ELK平台主要有由ElasticSearch、Logstash和Kiabana三个开源免费工具组成：
ELK应用情况分析

Elasticsearch是个开源分布式搜索引擎，它的特点有：
分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash是一个完全开源的工具，他可以对你的日志进行收集、过滤，并将其存储供以后使用。
Kibana 也是一个开源和免费的工具，它Kibana可以为 Logstash 和 ElasticSearch 提供的
日志分析友好的 Web 界面，可以帮助您汇总、分析和搜索重要数据日志。


有些时候就是版本不兼容的问题

下载windows下相对于的版本，然后直接解压
下载1

下载2

下载3

参考帖子

非常简单 不再详述

swagger

swagger
当下很多公司都采取前后端分离的开发模式，前端和后端的工作由不同的工程师完成。
在这种开发模式下，维持一份及时更新且完整的Rest API文档将会极大的提高我们的工作效率。
传统意义上的文档都是后端开发人员手动编写的，相信大家也都知道这种方式很难保证文档的及时性，这种文档久而久之也就会失去
其参考意义，反而还会加大我们的沟通成本。而Swagger给我们提供了一个全新的维护 API 文档的方式，
下面我们就来了解一下它的优点：
代码变，文档变。只需要少量的注解，Swagger 就可以根据代码自动生成API文档，很好的保证了文档的时效性。
跨语言性，支持 40 多种语言。
Swagger UI 呈现出来的是一份可交互式的 API 文档，我们可以直接在文档页面尝试 API 的调用，
省去了准备复杂的调用参数的过程。
还可以将文档规范导入相关的工具（例如 SoapUI）, 这些工具将会为我们自动地创建自动化测试
学习网站

微服务框架大致就是这些东西,接下来就是根据我所写的springcloud的组进行扩展和一些项目管理上的学习

热部署

	略 并不是很通用

kafka

安装zookeeper

安装成功：welome to zookeeper!

kafka win10报错：wmic…

%SystemRoot%;%SystemRoot%\system32;%SystemRoot%\System32\Wbem 在环境变量里面的Path里面添加

然后重新cmd打开即可 输入命令即可

快速开始

1. 创建主题
   topic:一组消息，一个主题就是消息的一个分类。生产者将消息发送到特定主题，消费者订阅主题或主题的某些分区进行消费

kafka-topics.bat --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test
然后输入下面命令会看到test
kafka-topics.bat --list --bootstrap-server localhost:9092
你也可以通过配置brokers自动发布主题

2. 生产者发送消息（Send messages）
   消息:是kafka通信的基本单位，由一个固定长度的消息头和一个可变长度的消息体构成。
   由Java重新实现的客户端中，每一条消息称为Record
   kafka-console-producer.bat --broker-list localhost:9092 --topic test
   D:\kafka\kafka_2.12-2.3.0\bin\windows>kafka-console-producer.bat --broker-list localhost:9092 --topic test
   This is a message from wxl
   this is another message from wxl

默认：每一行只发送一个单独的消息

3. 启动消费者
   D:\kafka\kafka_2.12-2.3.0\bin\windows>kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test --from-beginning
   This is a message from wxl
   this is another message from wxl

部署kafka集群

暂时不部署 略

4. 集群意义：

    概念和mongo的副本集和分片类似
    分区：kafka将一组消息归纳为一个主题，而每个主题又被分成一个或多个分区。每个分区由一系列有序、不可变的消息组成，
    是一个有序队列。
    每个主题对应的分区数可以在Kafka启动时所加载的配置文件中配置，也可以在创建主题时指定。
    当然，客户端还可以在主题创建后修改主题的分区数。
    分区使得kafka在并发处理上变得更加容易，分区数越多吞吐量越高。
    分区也是kafka保证消息被顺序消费以及对消息进行负载均衡的基础。
    Kafka只能保证一个分区之内消息的有序性，并不能保证跨分区消息的有序性。
    每条消息被追加到相应的分区中，是顺序写磁盘，因此效率高，这是kafaka
    高吞吐率的一个重要保证。kafka不会立即删除已被消费的消息，由于磁盘的限制消息也不会一直被存储。
    kafka提供两种删除老数据的策略，一是基于消息已被存储的时间长度，二是基于分区的大小。
    通过配置文件进行配置。
    
    副本：每个分区有一至多个副本，分区的副本分布在集群的不同代理上，以提高可用性。
    分区的每个副本在逻辑上抽象为一个日志(Log)对象，即分区的副本与日志对象是一一对应的。
    Leader副本和Follower副本，Kafka选择该分区的一个副本作为Leader副本，而该分区的其他副本即为Follower副本，
    只有Leader副本才负责处理客户端读/写请求，
    Follower副本从Leader副本同步数据。如果没有Leader副本。那就需要所有副本都同时负责读/写请求处理，
    一致性和有序性难以保证
   

5. 使用kafka connect导入导出数据
   D:\kafka\kafka_2.12-2.3.0\bin\windows>echo foo> test.txt

    D:\kafka\kafka_2.12-2.3.0\bin\windows>echo bar>> test.txt
   
    D:\kafka\kafka_2.12-2.3.0\bin\windows>connect-standalone.bat ../../config/connect-standalone.properties ../../config/connect-file-source.properties ../../config/connect-file-sink.properties
    D:\kafka\kafka_2.12-2.3.0\bin\windows>kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic connect-test --from-beginning
    {"schema":{"type":"string","optional":false},"payload":"foo"}
    {"schema":{"type":"string","optional":false},"payload":"bar"}
   

运行kafka Streams演示应用程序

#### 编写客户端
#### 准备输入topic并启动kafka生产者
		Created topic "streams-plaintext-input".
				kafka-topics.bat --create \  --bootstrap-server localhost:9092 \ --replication-factor 1 \ --partitions 1 \ --topic streams-plaintext-input
		Created topic "streams-plaintext-output".
				kafka-topics.bat --create \ --bootstrap-server localhost:9092 \ --replication-factor 1 \ --partitions 1 \ --topic streams-wordcount-output \ --config cleanup.policy=compact
		kafka-topics.bat --bootstrap-server localhost:9092 --describe
#### 启动应用程序
	package org.apache.kafka.streams.examples.wordcount;

		import org.apache.kafka.clients.consumer.ConsumerConfig;
		import org.apache.kafka.common.serialization.Serdes;
		import org.apache.kafka.streams.KafkaStreams;
		import org.apache.kafka.streams.StreamsBuilder;
		import org.apache.kafka.streams.StreamsConfig;
		import org.apache.kafka.streams.kstream.KStream;
		import org.apache.kafka.streams.kstream.KTable;
		import org.apache.kafka.streams.kstream.Produced;

		import java.util.Arrays;
		import java.util.Locale;
		import java.util.Properties;
		import java.util.concurrent.CountDownLatch;

		/**
		 * Demonstrates, using the high-level KStream DSL, how to implement the WordCount program
		 * that computes a simple word occurrence histogram from an input text.
		 * <p>
		 * In this example, the input stream reads from a topic named "streams-plaintext-input", where the values of messages
		 * represent lines of text; and the histogram output is written to topic "streams-wordcount-output" where each record
		 * is an updated count of a single word.
		 * <p>
		 * Before running this example you must create the input topic and the output topic (e.g. via
		 * {@code bin/kafka-topics.sh --create ...}), and write some data to the input topic (e.g. via
		 * {@code bin/kafka-console-producer.sh}). Otherwise you won't see any data arriving in the output topic.
		 */
		public final class WordCountDemo {

			public static void main(final String[] args) {
				final Properties props = new Properties();
				props.put(StreamsConfig.APPLICATION_ID_CONFIG, "streams-wordcount");
				props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
				props.put(StreamsConfig.CACHE_MAX_BYTES_BUFFERING_CONFIG, 0);
				props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName());
				props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass().getName());

				// setting offset reset to earliest so that we can re-run the demo code with the same pre-loaded data
				// Note: To re-run the demo, you need to use the offset reset tool:
				// https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+Application+Reset+Tool
				props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

				final StreamsBuilder builder = new StreamsBuilder();

				final KStream<String, String> source = builder.stream("streams-plaintext-input");

				final KTable<String, Long> counts = source
						.flatMapValues(value -> Arrays.asList(value.toLowerCase(Locale.getDefault()).split(" ")))
						.groupBy((key, value) -> value)
						.count();

				// need to override value serde to Long type
				counts.toStream().to("streams-wordcount-output", Produced.with(Serdes.String(), Serdes.Long()));

				final KafkaStreams streams = new KafkaStreams(builder.build(), props);
				final CountDownLatch latch = new CountDownLatch(1);

				// attach shutdown handler to catch control-c
				Runtime.getRuntime().addShutdownHook(new Thread("streams-wordcount-shutdown-hook") {
					@Override
					public void run() {
						streams.close();
						latch.countDown();
					}
				});

				try {
					streams.start();
					latch.await();
				} catch (final Throwable e) {
					System.exit(1);
				}
				System.exit(0);
			}
		}
	kafka-console-producer.bat --broker-list localhost:9092 --topic streams-plaintext-input	
	kafka-console-consumer.bat --bootstrap-server localhost:9092 \ --topic streams-wordcount-output \ --from-beginning \ --formatter kafka.tools.DefaultMessageFormatter \ --property print.key=true \ --property print.value=true 
>asssassas
>a is dog

asssassas       1
a       1
is      1
dog     1


	源节点KSTREAM-SOURCE-0000000000和宿节点KSTREAM-SINK-0000000001。 
	KSTREAM-SOURCE-0000000000持续从Kafka主题中读取记录，
	streams-plaintext-input并将它们传送到其下游节点KSTREAM-SINK-0000000001; 
	KSTREAM-SINK-0000000001会将其收到的每个记录写入另一个Kafka主题streams-pipe-output 
	（-->和<--箭头指示该节点的下游和上游处理器节点，即拓扑图中的“子级”和“父级”）

Line Split 行拆分

	由于每个源流的记录都是一个String类型化的键-值对,因此我们把值字符串 看作一个文本行将其拆分为单词通过运用FlatMapValues
	
	Topologies:
	Sub-topology: 0
	Source: KSTREAM-SOURCE-0000000000 (topics: [streams-plaintext-input])
	  --> KSTREAM-FLATMAPVALUES-0000000001
	Processor: KSTREAM-FLATMAPVALUES-0000000001 (stores: [])
	  --> KSTREAM-SINK-0000000002
	  <-- KSTREAM-SOURCE-0000000000
	Sink: KSTREAM-SINK-0000000002 (topic: streams-plaintext-output)
	  <-- KSTREAM-FLATMAPVALUES-0000000001

word count

	Topologies:
    Sub-topology: 0
	Source: KSTREAM-SOURCE-0000000000 (topics: [streams-plaintext-input])
	  --> KSTREAM-FLATMAPVALUES-0000000001
	Processor: KSTREAM-FLATMAPVALUES-0000000001 (stores: [])
	  --> KSTREAM-KEY-SELECT-0000000002
	  <-- KSTREAM-SOURCE-0000000000
	Processor: KSTREAM-KEY-SELECT-0000000002 (stores: [])
	  --> KSTREAM-FILTER-0000000005
	  <-- KSTREAM-FLATMAPVALUES-0000000001
	Processor: KSTREAM-FILTER-0000000005 (stores: [])
	  --> KSTREAM-SINK-0000000004
	  <-- KSTREAM-KEY-SELECT-0000000002
	Sink: KSTREAM-SINK-0000000004 (topic: counts-store-repartition)
	  <-- KSTREAM-FILTER-0000000005

  Sub-topology: 1
	Source: KSTREAM-SOURCE-0000000006 (topics: [counts-store-repartition])
	  --> KSTREAM-AGGREGATE-0000000003
	Processor: KSTREAM-AGGREGATE-0000000003 (stores: [counts-store])
	  --> KTABLE-TOSTREAM-0000000007
	  <-- KSTREAM-SOURCE-0000000006
	Processor: KTABLE-TOSTREAM-0000000007 (stores: [])
	  --> KSTREAM-SINK-0000000008
	  <-- KSTREAM-AGGREGATE-0000000003
	Sink: KSTREAM-SINK-0000000008 (topic: streams-wordcount-output)
	  <-- KTABLE-TOSTREAM-0000000007
	  
	这个还不是很理解

核心概念

	kafka Stream是一个客户端库,用于处理和分析存储在kafka中的数据.它建立在重要的流处理概念上.
	正确区分事件时间和处理时间,窗口支持以及简单而有效的管理和应用程序状态查询.
	
	Some highlights of Kafka Streams:
	
	Designed as a simple and lightweight client library, which can be easily embedded in any Java application and integrated with any existing packaging, deployment and operational tools that users have for their streaming applications.
	Has no external dependencies on systems other than Apache Kafka itself as the internal messaging layer; notably, it uses Kafka's partitioning model to horizontally scale processing while maintaining strong ordering guarantees.
	Supports fault-tolerant local state, which enables very fast and efficient stateful operations like windowed joins and aggregations.
	Supports exactly-once processing semantics to guarantee that each record will be processed once and only once even when there is a failure on either Streams clients or Kafka brokers in the middle of processing.
	Employs one-record-at-a-time processing to achieve millisecond processing latency, and supports event-time based windowing operations with late arrival of records.
	Offers necessary stream processing primitives, along with a high-level Streams DSL and a low-level Processor API.
	
	卡夫卡流的一些亮点:
	
	作为一个简单和轻量级的客户端库设计，它可以很容易地嵌入到任何Java应用程序中，并与任何现有的打包、部署和操作工具集成，这些工具是用户用于他们的流应用程序的。
	除Apache Kafka本身作为内部消息层外，对系统没有外部依赖;
	值得注意的是，它使用Kafka的分区模型来水平扩展处理，同时保持强大的排序保证。
	支持容错的本地状态，从而支持非常快速和有效的有状态操作，如窗口连接和聚合。
	支持精确的一次处理语义，以确保每条记录将被处理一次，且仅被处理一次，即使流客户端或Kafka代理在处理过程中出现故障也是如此。
	使用一次一个记录的处理来实现毫秒级的处理延迟，并支持基于事件时间的窗口操作，以延迟记录的到来。
	提供必要的流处理原语，以及高级流DSL和低级处理器API。
	
	核心概念:
		流是Kafka流提供的最重要的抽象:它表示一个无界的、持续更新的数据集。
		流是一个有序的、可重放的、容错的不可变数据记录序列，其中数据记录被定义为键值对。
		
	Source Processor: A source processor is a special type of stream processor that does 
	not have any upstream processors. It produces an input stream to its topology from one 
	or multiple Kafka topics by consuming records from these topics and forwarding them to
	 its down-stream processors.
	源处理器是一种特殊类型的流处理器，它没有任何上游处理器。它通过使用来自这些主题的记录并将它们转发给
	它的主题，从而从一个或多个Kafka主题生成一个拓扑的输入流
	Sink Processor: A sink processor is a special type of stream processor that does not have
	 down-stream processors. It sends any received records from its up-stream processors to a
	 specified Kafka topic.
	 接收处理器是一种特殊类型的流处理器，它没有下游处理器。它将来自上游处理器的所有接收记录
	 发送到指定的Kafka主题。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-33GjGnhl-1575446193924)(springboot_files/3.jpg)]

	事件时间 -事件或数据记录发生的时间点，即最初是在“源”上创建的。示例：如果事件是汽车中GPS
	传感器报告的地理位置变化，则关联的事件时间将是GPS传感器捕获位置变化的时间。
	
	处理时间 -事件或数据记录恰好由流处理应用程序处理的时间点，即记录被消耗时的时间点。
	处理时间可能比原始事件时间晚几毫秒，几小时或几天。
	示例：设想一个分析应用程序读取并处理从汽车传感器报告的地理位置数据，
	并将其呈现给车队管理仪表板。在这里，分析应用程序中的处理时间可能是事件发生后的毫秒或秒
	（例如，基于Apache Kafka和Kafka Streams的实时管道）或数小时（
	例如，基于Apache Hadoop或Apache Spark的批处理管道）
	
	摄取时间 -Kafka代理将事件或数据记录存储在主题分区中的时间点。
	事件时间的区别在于，摄取记录是在Kafka代理将记录添加到目标主题时生成的，
	而不是在“源头”创建记录时生成的。处理时间的区别在于处理时间是流处理应用程序处理记录的时间。
	例如，如果一条记录从未被处理过，则没有处理时间的概念，但是它仍然具有提取时间。
	
	集合体
	一个聚合操作需要一个输入流或表，并且由多个输入记录组合为单个输出记录产生的新表。
	聚合的示例是计算计数或总和。
	
	在Kafka Streams DSL，的输入流aggregation可以是KStream或KTable，但输出流将始终是KTable。
	这使得Kafka Streams在生成和发出值之后，如果进一步的记录延迟到达，则可以更新汇总值。
	当此类延迟到达发生时，聚合的KStream或KTable会发出新的聚合值。由于输出是一个KTable，
	因此在后续处理步骤中，新值将被视为使用相同的键覆盖旧值。
	
	加窗
	窗口允许用户控制以具有相同的密钥组记录的状态操作，
	如aggregations或joins成所谓的窗口。每个记录键都跟踪Windows。
	
	Windowing operations在中可用Kafka Streams DSL。
	使用窗口时，可以指定窗口的保留期限。
	该保留期限控制着Kafka Streams将等待给定窗口乱序或迟到的数据记录的时间。
	如果记录在经过窗口的保留期后到达，则记录将被丢弃，并且不会在该窗口中进行处理。
	
	迟到记录在现实世界中总是可能的，并且应在您的应用程序中适当考虑。
	这取决于有效的time semantics 后期记录处理方式。
	在处理时间的情况下，语义是“正在处理记录时”，
	这意味着延迟记录的概念不适用，因为根据定义，没有记录可以延迟。
	因此，对于事件时间或摄取时间语义，只能将迟到记录视为这样（即“迟到”）。
	在这两种情况下，Kafka Streams都能正确处理迟到的记录。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RndYSZXJ-1575446193924)(springboot_files/4.jpg)]
用途:
Kafka works well as a replacement for a more traditional message broker.
Message brokers are used for a variety of reasons
(to decouple processing from data producers, to buffer unprocessed messages, etc).
In comparison to most messaging systems Kafka has better throughput,
built-in partitioning, replication, and fault-tolerance
which makes it a good solution for large scale message processing applications.
In our experience messaging uses are often comparatively low-throughput,
but may require low end-to-end latency and often depend on the strong
durability guarantees Kafka provides.
In this domain Kafka is comparable to traditional messaging systems such
as ActiveMQ or RabbitMQ.

通过看文档让人晓得,一个架构被开发出来是大而全的,而使用时只是需要其中的一部分功能就可以,

没有必要去统一的全部的学习,学习新知识一定要与自己的做的和实际联系起来

nce messaging uses are often comparatively low-throughput,
but may require low end-to-end latency and often depend on the strong
durability guarantees Kafka provides.
In this domain Kafka is comparable to traditional messaging systems such
as ActiveMQ or RabbitMQ.

通过看文档让人晓得,一个架构被开发出来是大而全的,而使用时只是需要其中的一部分功能就可以,

没有必要去统一的全部的学习,学习新知识一定要与自己的做的和实际联系起来

安全级别 linux的安全控制