目前在Flink里用了29个CEP规则，并行度设置为了10。当taskmanager slot的数目为1，taskmanager number的数目为10时，总是容易fail，而且报的错是apache.flink.runtime.rpc.messages.RemoteRpcInvocation。

看起来就是远端的rpc请求远端taskmanager没有及时的得到响应。

 

翻看了一下flink相关的文档，taskmanager可以理解为一个JVM进程，taskmanager slots则可以认为是进程里的线程，每个线程都可以处理一个管道的task。一个简单的示例就是(source->map->sink)，那么每一个subtask source->map->sink 都可以被一个taskmanager slots执行。

因为29个规则公用了一个source，所以它们都被归为一个pipeline。所以如果并行度定义为10，其实只有10个并行的task，每个task里则可能有29个subtask，所以总共的任务个数为290个。

这样看来，我的资源分配其实并没有什么问题。但是不知道为什么，job就是fail，而如果我把taskmanager slots的个数给调大了，那么就可以正常执行，并不会fail。

后来看了一封邮件，里面讲到还可以用调大akka的时长来规避掉此问题的方法。然后我配置了akka.ask.timeout: 600s

然后使用taskmanager slot的数目为1，taskmanager number的数目为10，application也是正常的。

目前觉得flink的资源分配和任务调度可能还是存在一定的问题的，在某些情况下会触发akka的请求时长大于默认的时长。