axunnnn

lz 好耐心回所有人哈哈人真好。倒是楼里几个，ex 也投喂半年了，上来就是污蔑人身攻击。自私势利，难评。

感谢楼主受益匪浅。有一个小问题，就是这个项目描述和工作描述，分开写应该如何写？总是写重？看你的例子这部分也没办法借鉴， 工作部分写的"设计并实现数据库优化"，项目又是一个完全不同的项目，也没有写 detail 部分应该写什么？困扰就是当其实是同一个项目的时候，工作部分写什么，项目部分又写哪些呢？这部分特别困扰

@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 你说的对 受教