初步的思考了一下，仅供参考：

1. 首先，提一下索引，相信这个你应该加了索引。
2. 有个问题确认一下，mongodb最新版本中的锁粒度还是Database级别吧，不知道你用的哪个版本，还没到锁表(Collection)这个粒度，所以写并发大的情况下比较糟糕，不过应该性能也不至于糟到像你描述的那样啊？不解，建议考虑任务分库的可能性？
3. 能否考虑把子任务的状态和主任务的状态分开保存。子任务的状态，可以放到redis，主任务只负责自己本身的状态，这样每个主任务更新频率降为1/N，可大大减少mongodb中主任务表的压力。
4. 子任务完成或超时后，可否考虑后台异步单线程顺序同步mongodb的主任务状态？

个人认为题主提到的MongoDB数组查询和更新的性能问题，很可能是Schema设计上的问题。但题主并没有给出具体的设计，所以我就提出几个值得关注的点仅供参考：

1. 索引，正如楼上所说，你应该已经为数组加上了索引。但是值得注意的是，数组字段的索引比普通字段的索引体积要大很多（具体取决于数组的大小，数组越大，索引所占的空间越大）。这样就可能会导致一个问题：索引并不（完全）在内存里！ 后果是，每次查询都需要涉及到额外的IO操作，性能会急剧下降。
2. 查询返回文档的大小。如果每次返回查询的文档数据量较大，而且客户端与mongodb并不处于同一机器上，那就会增加了网络传输所需的时间（不要小看这点时间），所以尽可能只返回所需要的字段。
3. update-in-place. 由于schemaless的特性，mongodb会为每条文档记录预留一些空间给增加额外的字段或数据时使用，提高update的性能。但如果你文档的大小频繁地扩展（增加字段，增加数组长度等），那就会导致写的性能问题：mongodb需要把增长了的文档移动（move）到别的地方。（相当于从硬盘的一个位置移动另一个更空闲的位置）这时候的性能会大大下降。

mongodb是一个内存型的数据库，如果你的热点数据都在内存上，它的性能会非常优异，而这很大程度取决与你的Schema设计。

PS：mongodb一直标榜的Schemaless优点误导了很多人，其实这个更多是想说明mongodb是动态的schema，而并不是不需要设计schema。

任务队列可以考虑 rabbitmq 另外mongodb不应该这么慢吧，没加索引？或者试试capped collection.