axunnnn

@Immortal 是这样的，各服务器都会起几个进程，redis 是生产消费者模式，大量 id 进入队列后每一条 id pop 出，在随机一台服务器生成视频，在生成的过程中不会重复生成。但是如果在第二段丢入上传队列时出错，再次上传时，未必能在当前服务器本地找到源视频，这时会再次就地重新生成。
2 对 位判断更简明。其实这里纠结的是是否要多出一重位判断(A)的步骤，因为业务字段（ B ）是必须的，trade off 不是 A or B 取舍，而是是否要额外加 A ，以及多一个步骤附带的可能的衔接处丢消息，空间开销等等。

@playniuniu 搜了一下 很厉害的样子 谢谢

@3dwelcome 是查到过回调的使用！但不熟且很多困惑就搁置了。那么如果用回调的话，我看一些系统设计的文章，都在讲视频上传这类耗费时间的事要用 mq 。那么用 mq 和直接回调标记的区别在哪呢？什么时候选用哪个呢？仅是场景规模大小的问题吗

@macrorules 你说的很对，感觉从另一个层次梳理了应做的事。那么这个记录需要是全局共享的，因为现在是有多个服务器来一起生成视频，对分布式还不太熟，有什么好 tools 建议吗

@Immortal 生成这步 也申请了多台服务器，并行进行的。所以其实导致了 上面提的一个问题，就是当这个视频在上传的过程中出错 被打回之后，它会去本地 server 找源视频，但好几台服务器 它只能找本地就不一定找得到，就又得重新生成，就尴尬
2 很机智哎感谢！但是其实 mysql 里相应列存的是它的 url ，比如封面图需要存 url 。只是顺便兼任 boolen 的判断。这里其实之前也有过纠结，需不需要再开一个或者再在哪里，单独记录一下状态呢？最后是没有建

@documentzhangx66 你说的对 受教