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

  • 时间:
  • 浏览:1

3. 日志服务写数据四种 是非幂等行为,之类在函数重复执行不可能 写入数据超时重试时不可能 引起数据重复。你这个问题根本上难以处里,降低重复概率的一个多多多多可选方案是:在函数计算里边将本次已处里的数据saved_cursor记录到结构系统(之类表格存储),不可能 函数超时后再次执行,从表格存储获取上次处里进度,跳过已处里的要素数据,从saved_cursor位置继续开始处里。  

现在的问题是FunctionComputeServer有总要time out失败,因此失败后数据任然是成功插入的。不过ETL认为任务失败,不断重试,最后是是因为插入大量重复的数据。 

2. 将日志服务触发器的触发间隔设置为3秒,函数计算的超时间隔设置得高你这个(比如2分钟)。我的考虑是:一般来说,函数偶尔超时,后续是时需慢慢赶上进度的(削峰填谷),大伙儿容忍偶尔的超时(计算+IO作业,延时不太可控)。但不可能 老是超时,说明shard流量不够(分裂shard处里)不可能 是计算繁杂度高(在函数端增加并发)。

建议处里方案:

我现在做的事情是把一个多多多多webtrack 的logstore 通过函数计算导入到另外一个多多多多logstore。函数计算的功能是把IP解析成地理位置和把UserAgent String解析成设备信息。 

现在一个多多多多多处里方案因此减少函数的输入数据,从前就时需处里超时,不过我有你这个问题。 

1. 将shard数目按照峰值请况进行预留

第5个问题:不可能 这是个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分裂来扩容。

第一个多多多多问题:唯一能影响函数的输入数据量的设置这么函数的执行频率吗?我想准确的指定输入量吗?

阿里答复:完备的触发器深度图应该是要共同支持:size-based trigger、time-based trigger四种 模式,但不可能 日志服务这么土辦法 从流式数据订阅接口获取准确的日志条数,你这个size-based trigger目前提供不了。抱歉。