本篇内容介绍了“如何使用MQTT与函数计算做热力图”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
1． 数据通道的连接能力：数据通道随着业务的扩展，机器人的投放也会同步增加，对于数据通道有足够的扩展灵活性，可以按需进行扩展，同时连接的级别能够支持10W+级别的扩展。
2． 简洁数据清洗的能力：对于数据的处理，本质上就是对数据的归纳统计，逻辑实现上并不复杂。对于数据本身的峰谷变化，能有最简单有效的匹配扩缩处理能力即可，在清洗上不希望为此引入复杂的传统大数据级别的笨重方案。
3． 弹性数据访问的能力：这里提到的的热力图信息，以后会考虑开放给终端用户访问，访问量都是动态变化的，随着不同的时间、节日、突发事件等都会有不可预知的幅度变化，所以在此业务中要求有弹性的访问能力。业务方不希望通过限流方式来实现，因为会对业务量本身造成影响。
4． 性能优越的存储能力：此场景下，数据写入与读取并发量都高，客户希望使用NoSQL的方式进行存储。NoSQL 类型能最好支持排序的功能，本文介绍的方案中使用Redis，不再做更多的分析介绍。
数据通道的连接能力
自建Kafka
优点：
Kafka作为通用的数据收集信息通道，使用面广泛，接入方式多样化。社区完善，学习成本低。
Kafka本身搭建容易，与下游的大数据处理产品协调方案成熟。
缺点：
动态处理Kafka的扩容复杂。
需要搭建额外处理集群的稳定性配套方案。
外网网络流量管理需要配合额外的方案。
主流方案是作为连接应用的收集能力，对于终端的连接能力没有规模级别的案例验证。
优点：
支持百万级别的连接，完成可以覆盖业务发展的诉求，为业务留足了扩展空间。
MQTT的协议非常简洁，在端与服务间的传输中有优势。支持各种消息触达的QoS质量。
支持各种客户端接入实现语言。
可实时观测客户端的连接情况，方便发现异常情况。
缺点：
处理大数据的实践没有Kafka成熟，下游产品选型受一定的限制。
弹性数据清洗的能力
大数据方案（Storm、Spark、Flink等）
优点：
开源的通用方案，资料众多，方案成熟。
缺点：
搭建运维复杂，需要提供额外的监控与恢复手段。
需要学习接受各种组件方式（下图是以Storm为例）。
提前评估资源使用情况，无法按照实时数据量进行相应的扩缩使用。
优点：
按需进行扩缩，百毫秒级的伸缩能力，适合数据量的脉冲峰谷变化。
不需要进行清洗环境的管理。
概念简单，学习成本低。
其它优点参考下图：
缺点：
函数计算是各个云厂商的产品。要求一定需要在云上运行。
优点：
作为业务的一部分嵌在某个应用实现中，技术成熟，学习成本低。
缺点：
需要自实现根据业务请求量来进行弹缩处理，或者很多时候采用评估的方式进行资源冗余处理。
优点：
根据客户的请求量实时进行弹缩处理。按需使用，不为高峰时段烦恼，不会闲置付费。
自动附带专业的访问监控大盘。
缺点：
需要少量的学习成本。
在这个热力图信息收集清选与访问业务中，可以参考使用下图的解决方案完美实现。
MQTT到函数计算的介绍
请参考函数计算的微消息队列MQTT服务集成方案。
详情请参考API网关函数触发实例。
以Node.js为例：
module.exports.handler = function(event, context, callback) {
var event = JSON.parse(event); var content = {
path: event.path,
method: event.method,
headers: event.headers,
queryParameters: event.queryParameters,
pathParameters: event.pathParameters,
body: event.body // 您可以在这里编写您自己的逻辑。
// 从Redis提取数据的逻辑
} var response = {
isBase64Encoded: false,
statusCode: '200',
headers: { 'x-custom-header': 'header value'},
body: content
};
callback(null, response)
};“如何使用MQTT与函数计算做热力图”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
