开发者社区> 264971589117404837> 正文

函数计算因为数据量过大超时的解决方案

简介: 我现在做的事情是把一个webtrack 的logstore 通过函数计算导入到另外一个logstore。函数计算的功能是把IP解析成地理位置和把UserAgent String解析成设备信息。 现在的问题是FunctionComputeServer有时会time out失败,但是失败后数据任然是成功插入的。
+关注继续查看
我现在做的事情是把一个webtrack 的logstore 通过函数计算导入到另外一个logstore。函数计算的功能是把IP解析成地理位置和把UserAgent String解析成设备信息。 
现在的问题是FunctionComputeServer有时会time out失败,但是失败后数据任然是成功插入的。不过ETL认为任务失败,不断重试,最后导致插入大量重复的数据。 
现在有一个解决方案就是减少函数的输入数据,这样就可以避免超时,不过我有一些问题。 
第一个问题:唯一能影响函数的输入数据量的设置只有函数的执行频率吗?我可以准确的指定输入量吗?
阿里答复:完备的触发器角度应该是要同时支持:size-based trigger、time-based trigger两种模式,但因为日志服务没有办法从流式数据订阅接口获取准确的日志条数,所以size-based trigger目前提供不了。抱歉。
第二个问题:因为这是个webtrack logstore,每个时间点的logstore产生量是不稳定的。我如何评估产生的shard数目和大小?有没有什么地方可以查看?有没有什么办法可以提前测试函数计算的 performance这样可以帮助我觉得合适的内存和超时设置?如果靠生产环境里面的情况来做决定,我只能等出了问题在尝试修改,那个时候已经太晚了。 
阿里答复: 一个shard支持5MB/s的数据写入,logstore的流量指标可以在这里看到:https://help.aliyun.com/document_detail/28971.html?spm=a2c4g.11174283.6.693.6IikRd。云监控中的指标应该可以通过sdk方式获取的,你可以基于这个值提前做shard分裂来扩容。


建议解决方案:
1. 将shard数目按照峰值情况进行预留
2. 将日志服务触发器的触发间隔设置为3秒,函数计算的超时间隔设置得高一些(比如2分钟)。我的考虑是:一般来说,函数偶尔超时,后续是可以慢慢赶上进度的(削峰填谷),我们容忍偶尔的超时(计算+IO作业,延时不太可控)。但如果一直超时,说明shard流量过高(分裂shard解决)或者是计算复杂度高(在函数端增加并发)。
3. 日志服务写数据本身是非幂等行为,例如在函数重复执行或者写入数据超时重试时可能引起数据重复。这个问题根本上难以解决,降低重复概率的一个可选方案是:在函数计算里面将本次已处理的数据saved_cursor记录到外部系统(例如表格存储),如果函数超时后再次执行,从表格存储获取上次处理进度,跳过已处理的部分数据,从saved_cursor位置继续开始处理。  

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
函数计算助力高德地图平稳支撑亿级流量高峰
2020 年的“十一出行节”期间,高德地图创造了记录 ——截止 2020 年 10 月 1 日 13 时 27 分 27 秒,高德地图当日活跃用户突破 1 亿,比 2019 年 10 月 1 日提前 3 时 41 分达成此记录。 期间,Serverless 作为其中一个核心技术场景,平稳扛住了流量高峰期的考验。值得一提的是,由 Serverless 支撑的业务在流量高峰期的表现十分优秀,每分钟函数调用量接近两百万次。这再次验证了 Serverless 基础技术的价值,进一步拓展了技术场景。
3514 0
Cocos2d-x 3.2编译生成Android程序出错的解决方案
      最近升级到Cocos2d-x 3.2正式版,iOS程序编译没任何问题,结果使用cocos compile -p android编译生成APK程序,结果悲剧了,出现以下错误。
1024 0
412
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
OceanBase 入门到实战教程
立即下载
阿里云图数据库GDB,加速开启“图智”未来.ppt
立即下载
实时数仓Hologres技术实战一本通2.0版(下)
立即下载