AWS 20 AWS_Integration_Messaging_SQS_SNS_Kinesis
作者：互联网
章节简介
•当我们开始部署多个应用程序时，它们将不可避免地需要相互通信
•应用程序通信有两种模式
1） 同步通信（应用到应用）
2） 异步/基于事件（应用程序到队列到应用程序）
章节简介
•如果存在以下情况，应用程序之间的同步可能会出现问题：突然的交通高峰
•如果你突然需要对1000个视频进行编码，但通常是10个呢？
•在这种情况下，最好将应用程序解耦，
•使用SQS：队列模型
•使用SNS：发布/订阅模式
•使用Kinesis：实时流媒体模型
•这些服务可以独立于我们的应用程序进行扩展！
------------------------------------------------------------------------------------
Amazon SQS–标准队列
•最古老的产品（超过10年）
•完全管理的服务，用于分离应用程序
•属性：
•无限吞吐量，队列中的消息数量不限
•邮件默认保留期：4天，最多14天
•低延迟（发布和接收时<10毫秒）
•每发送一封邮件限制256KB
•可能有重复消息（至少一次传递，偶尔）
•它也可能有无序信息（尽最大努力订购）
SQS–生成消息
•使用SDK（SendMessage API）向SQS生成
•该消息将保留在SQS中，直到消费者将其删除
•邮件保留：默认4天，最多14天
•示例：发送要处理的订单
•订单id
•客户id
•你想要的任何属性
•SQS标准：无限吞吐量
SQS–消费消息
•消费者（在EC2实例、服务器或AWS Lambda上运行）…
•轮询SQS以获取消息（一次最多接收10条消息）
•处理消息（例如：将消息插入RDS数据库）
•使用DeleteMessage API删除消息
SQS–多个EC2实例
•消费者同时接收和处理信息
•至少一次交付
•尽力而为的消息排序
•消费者在处理信息后删除信息
•我们可以横向扩展消费者，以提高处理吞吐量
SQS with Auto Scaling Group (ASG)
消息队列内容多，=> 通过CW 指标 队列长度 => 生产一个Alarm告警
=》 告警触发ASG =》 自动缩放ec2实例 =》 可以消费足够多的消息内容
亚马逊SQS-安全
•加密：
•使用HTTPS API的飞行中加密
•使用KMS密钥进行静态加密
•客户端加密，如果客户端希望自己执行加密/解密
•访问控制：IAM政策，以规范对SQS API的访问
•SQS访问策略（类似于S3存储桶策略）
•有助于跨账户访问SQS队列
•用于允许其他服务（SNS、S3…）写入SQS队列
------------------------------------------------------------------------------------
SQS队列访问策略
1. cross account access
2. publish s3 event notification to sqs queue
SQS–消息可见性超时
•消费者对信息进行调查后，其他消费者看不到该信息
•默认情况下，“消息可见性超时”为30秒
•这意味着该消息需要处理30秒
•消息可见性超时结束后，消息在SQS中“可见”
•如果在可视性超时时间内未处理消息，则会处理两次
•消费者可以调用ChangeMessageVisibility API来获得更多时间
•如果可见性超时很高（小时），并且消费者崩溃，重新处理将需要时间
•如果可见性超时太低（秒），我们可能会得到重复
Amazon SQS–死信队列 Dead Letter Queue
•如果消费者未能在可视性超时内处理消息…
消息返回队列！
•我们可以设置消息返回队列的次数阈值
•超过MaximumReceives阈值后，消息进入死信队列（DLQ）
•对调试有用！
•确保在DLQ中的消息过期之前对其进行处理：
•在DLQ中设置14天的保留期很好
Amazon SQS–延迟队列
•将信息延迟15分钟（消费者不会立即看到）
•默认值为0秒（信息立即可用）
•可以在队列级别设置默认值
•可以使用DelaySeconds参数覆盖发送时的默认设置
------------------------------------------------------------------------------------
Amazon SQS-长轮询
•当消费者从队列中请求消息时，如果队列中没有消息，它可以选择“等待”消息到达
•这称为长轮询
•LongPolling减少了对SQS的API调用数量，同时提高了应用程序的效率和延迟。
•等待时间可以在1秒到20秒之间（最好是20秒）
•长轮询优于短轮询
•可以在队列级别或API级别使用WaitTimeSeconds启用长轮询
SQS扩展客户端
•邮件大小限制为256KB，如何发送大邮件，例如1GB？
•使用SQS扩展客户端（Java库） 通过S3
SQS–必须了解API
•CreateQueue（MessageRetentionPeriod），DeleteQueue
•PurgeQueue：删除队列中的所有消息
•SendMessage (DelaySeconds), ReceiveMessage, DeleteMessage
•MaxNumberOfMessages：默认值为1，最大值为10（对于ReceiveMessage API）
•ReceiveMessageWaitTimeSeconds：长轮询
•ChangeMessageVisibility：更改消息超时
•SendMessage、DeleteMessage、ChangeMessageVisibility的批处理API有助于降低成本
------------------------------------------------------------------------------------
Amazon SQS – FIFO Queue
•FIFO=先进先出（队列中消息的排序）
•有限吞吐量：300味精/秒（不含配料），3000味精/秒（含配料）
•一次发送功能（通过删除重复项）
•消费者按顺序处理信息
SQS FIFO–重复数据消除
•重复数据消除间隔为5分钟
•两种重复数据消除方法：
•基于内容的重复数据消除：将对消息正文执行SHA-256哈希
•明确提供消息重复数据消除ID
SQS FIFO–消息分组
•如果在SQS FIFO队列中指定相同的MessageGroupID值，
•您只能有一个消费者，并且所有消息都是有序的
•要在消息子集级别获得排序，请指定不同的值对于MessageGroupID
•共享公共消息组ID的消息将在组内按顺序排列
•每个组ID可以有不同的使用者（并行处理！）
•不保证跨组排序
------------------------------------------------------------------------------------
Amazon SNS
•如果你想向多个接收者发送一条信息，该怎么办？
Amazon SNS
•事件制作人只向一个SNS主题发送消息
•尽可能多的“事件接收者”（订阅），只要我们想收听SNS主题通知
•主题的每个订阅者都将获得所有消息（注意：过滤消息的新功能）
•每个主题最多可订阅10000000次
•10万个主题限制
•订户可以是：
•SQS
•HTTP/HTTPS（具有传递重试次数——多少次）
•Lambda
•Emails
•短信SMS messages
•Mobile Notifications
SNS集成了许多AWS服务
•许多AWS服务可以直接向SNS发送数据以获取通知
•CloudWatch（用于报警）
•自动缩放组通知
•Amazon S3（关于bucket事件）
•CloudFormation（状态更改=>构建失败等）
•等等…
Amazon SNS——如何发布
•主题发布（使用SDK）
•创建一个主题
•创建订阅（或多个）
•发布主题
•直接发布（适用于移动应用SDK）
•创建平台应用程序
•创建平台端点
•发布到平台端点
•与谷歌GCM、苹果APNS、亚马逊ADM合作…
亚马逊SNS——安全
•加密：
•使用HTTPS API的飞行中加密
•使用KMS密钥进行静态加密
•客户端加密，如果客户端希望自己执行加密/解密
•访问控制：监管SNS API访问的IAM政策
•SNS访问策略（类似于S3 bucket策略）
•有助于跨账户访问SNS主题
•用于允许其他服务（S3…）写入SNS主题
------------------------------------------------------------------------------------
SNS + SQS: Fan Out 扇出
•在SNS中推送一次，在作为订户的所有SQS队列中接收
•完全解耦，无数据丢失
•SQS允许：数据持久性、延迟处理和重试工作
•能够随时间增加更多SQS订户
•确保您的SQS队列访问策略允许SNS写入
应用程序：将S3事件发送到多个队列
•对于相同的组合：事件类型（例如对象创建）和前缀
（例如images/）您只能有一个S3事件规则
•如果要向多个SQS队列发送相同的S3事件，请使用扇出
亚马逊SNS–先进先出主题
•FIFO=先进先出（主题中消息的排序）
•与SQS FIFO类似的功能：
•按消息组ID排序（同一组中的所有消息都已排序）
•使用重复数据消除ID或基于内容的重复数据消除
•只能将SQS FIFO队列作为订户
•有限的吞吐量（与SQS FIFO的吞吐量相同）
SNS FIFO+SQS FIFO：扇出
•如果您需要扇出+订购+重复数据消除
SNS——信息过滤
•用于过滤发送到SNS主题订阅的消息的JSON策略
•如果订阅没有筛选策略，它会接收每条消息
------------------------------------------------------------------------------------
Kinesis Overview 运动综述
•便于实时收集、处理和分析流媒体数据
•接收实时数据，例如：应用程序日志、指标、网站点击流、物联网遥测数据…
•Kinesis数据流 Kinesis Data Streams：捕获、处理和存储数据流
•Kinesis数据消防软管 Kinesis Data Firehose：将数据流加载到AWS数据存储中
•Kinesis数据分析Kinesis Data Analytics：使用SQL或Apache Flink分析数据流
•动态视频流Kinesis Video Streams：捕获、处理和存储视频流
Kinesis Data Streams
•计费是按碎片配置的，可以有任意多个碎片
•保留期在1天（默认）到365天之间
•能够重新处理（回放）数据
•一旦数据插入到Kinesis中，它就不能被删除（不变性）
•共享同一分区的数据进入同一个碎片（排序）
•制作人：AWS SDK、动觉制作人库（KPL）、动觉代理 Kinesis Producer Library (KPL)
•消费者：
•编写自己的：Kinesis客户端库（KCL），AWS SDK
•管理：AWS Lambda、Kinesis数据消防软管、Kinesis数据分析、，
数据流安全
•使用IAM策略控制访问/授权
•使用HTTPS端点进行实时加密
•使用KMS进行静态加密
•您可以在客户端实现数据加密/解密（更难）
•可供Kinesis在VPC内访问的VPC端点
•使用CloudTrail监控API调用
------------------------------------------------------------------------------------
运动生产者
•将数据记录放入数据流中
•数据记录包括：
•序列号Sequence number（碎片内每个分区密钥唯一）
•分区键Partition key （将记录放入流时必须指定）
•数据块（高达1MB）
•制作人：
•AWS SDK：简单生产者
•动觉生产者库Kinesis Producer Library (KPL)：C++、Java、批处理、压缩、重试
•运动代理 Kinesis Agent：监控日志文件
•写入吞吐量：每片1 MB/秒或1000条记录/秒
•PutRecord API
•将批处理与PutRecords API结合使用，以降低成本并提高吞吐量
Kinesis - ProvisionedThroughputExceeded
解决方案：
•使用高度分布式的分区密钥
•具有指数回退的重试
•增加碎片（缩放）
------------------------------------------------------------------------------------
Kinesis Data Streams Consumers
•从数据流中获取数据记录并进行处理
•AWS Lambda
•Kinesis Data Analytics 运动数据分析
•Kinesis Data Firehose 动力数据消防水带
•Custom Consumer (AWS SDK)——经典或增强型扇形输出
•Kinesis Client Library (KCL) Kinesis客户端库（KCL）：简化数据流读取的库
Shared (Classic) Fan-out Consumer
2 MB/sec per shard across all consumers
Enhanced Fan-out Consumer
2 MB/sec per consumer per shard
运动类型 Kinesis Consumers Types
共享（经典）扇出耗电元件
•消费应用程序数量少
•读取吞吐量：在所有用户中，每个碎片每秒2 MB
•每秒最多5次GetRecords API调用
•延迟约200毫秒
•最大限度地降低成本（美元）
•消费者使用GetRecords API调用从Kinesis轮询数据
•返回高达10 MB（然后节流5秒）或高达10000条记录
-拉出增强扇出耗电元件-推送
•同一流的多个消费应用程序
•每个用户每个碎片2 MB/秒
•延迟约70毫秒
•更高的成本（美元）
•Kinesis通过HTTP/2（SubscribeToShard API）向消费者推送数据
•每个数据流5个消费者应用程序（KCL）的软限制（默认）
------------------------------------------------------------------------------------------
Kinesis Consumers – AWS Lambda
•支持经典型和增强型扇出用户
•分批读取记录 => 保存 Amazon DynamoDB
•可以配置批次大小和批次窗口
•如果发生错误，Lambda将重试，直到成功或数据过期
•每个碎片最多可同时处理10批
------------------------------------------------------------------------------------------
Kinesis客户端库（KCL）
•一个Java库，帮助使用共享读取工作负载的分布式应用程序
•每个碎片只能由一个KCL实例读取
•4个碎片=最多4个KCL实例
•6个碎片=最多6个KCL实例
•进度检查点进入DynamoDB（需要IAM访问）
•使用DynamoDB跟踪其他工人并在碎片之间共享工作
•KCL可以在EC2、Elastic Beanstalk和本地运行
•在碎片级别按顺序读取记录
•版本：
•KCL 1.x（支持共享用户）
•KCL 2.x（支持共享和增强的扇出用户）
------------------------------------------------------------------------------------------
运动操作-碎片分割
•用于增加流容量（每个碎片1 MB/s数据）
•用于分割“热碎片”
•旧碎片已关闭，数据过期后将被删除
•无自动缩放（手动增加/减少容量）
•不能在一次操作中分裂成两个以上的碎片
运动操作-合并碎片
•降低流量，节约成本
•可用于分组两个低流量碎片（冷碎片）
•旧碎片已关闭，数据过期后将被删除
•一次操作不能合并两个以上的碎片
------------------------------------------------------------------------------------------
Kinesis Data Firehose
•完全管理的服务，无需管理，自动扩展，无服务器
•AWS:Redshift/Amazon S3/ElasticSearch
•第三方合作伙伴：Splunk/MongoDB/DataDog/NewRelic/…
•自定义：发送到任何HTTP端点
•为通过消防水带的数据付费
•近实时
•非完整批次的最小延迟时间为60秒
•或一次至少32 MB的数据
•支持多种数据格式、转换、转换和压缩
•支持使用AWS Lambda进行自定义数据转换
•可以将失败或所有数据发送到备份存储桶
Kinesis Data Streams vs Firehose
运动数据流
•大规模摄入的流媒体服务
•编写自定义代码（生产者/消费者）
•实时（约200毫秒）
•管理缩放（碎片分割/合并）
•数据存储1至365天
•支持重播功能
Kinesis Data Firehose
•将流数据加载到S3/Redshift/ES/3rd party/custom HTTP
•全面管理
•接近实时（缓冲时间至少60秒）
•自动缩放
•无数据存储
•不支持重播功能
------------------------------------------------------------------------------------------
Kinesis数据分析（SQL应用程序）
•使用SQL对运动流执行实时分析
•完全管理，无需配置服务器
•自动缩放
•实时分析
•按实际消费率付费
•可以从实时查询中创建流
•用例：
•时间序列分析
•实时仪表盘
•实时指标
将数据排序为运动
•想象一下，你有100辆卡车（卡车1、卡车2、卡车100）在路上定期向AWS发送GPS位置。
•您希望按顺序使用每辆卡车的数据，以便准确跟踪其移动。
•你应该如何将数据发送到Kinesis？
•回答：使用“卡车id”的“分区键”值发送
•同一个密钥将始终指向同一个碎片
将数据排序到SQS中
•对于SQS标准，无需订购。
•对于SQS FIFO，如果您不使用组ID，消息将在他们发送的订单只有一个消费者
•你想扩大消费者的数量，但你想在消息相互关联时对它们进行“分组”
•然后使用组ID（类似于Kinesis中的分区键）
运动vs SQS排序
•假设100辆卡车，5个动态碎片，1平方英尺FIFO
•运动数据流：
•平均每个碎片有20辆卡车
•卡车将在每个碎片中对其数据进行排序
•我们最多可同时拥有5名消费者
•可接收高达5 MB/s的数据
•SQS FIFO
•您只有一个SQS FIFO队列
•你将拥有100个团体ID
•最多可以有100个消费者（由于100组ID）
•每秒最多有300条消息（如果使用批处理，则为3000条）
------------------------------------------------------------------------------------------
SQS vs SNS vs Kinesis
SQS：
•消费者“拉动数据”
•数据被消耗后被删除
•可以拥有我们想要的任意数量的员工（消费者）
•无需提供吞吐量
•仅在FIFO队列上订购保证
•个人信息延迟能力
SNS：
•向许多订户推送数据
•多达12500000用户
•数据未持久化（如果未交付，则会丢失）
•Pub/Sub
•多达100000个主题
•无需提供吞吐量
•与SQS集成，形成扇出架构模式
•SQS FIFO的FIFO功能
运动：
•标准：拉取数据
•每个碎片2 MB
•增强的扇出：推送数据
•每个用户每个碎片2 MB
•重播数据的可能性
•用于实时大数据、分析和ETL
•在碎片级别订购
•数据在X天后过期
•必须提供吞吐量
------------------------------------------------------------------------------------------
标签：20,Kinesis,SQS,AWS,碎片,队列,SNS,数据 来源： https://www.cnblogs.com/ives-xu/p/16133465.html