老师上课讲distributed transaction都是跟钱有关，which makes sense，但是如果对于某些其他应用场景，比如youtuber上传视频
需要 1) metadata存database 2) video存s3 3）video clip之后给encoding service（以及其他service）处理
感觉这三步也是all or nothing的关系，所以也需要distributed transaction吗？
谢谢
不一定需要，虽然希望 all or nothing，但是极端情况下，比如服务器在存储完 metadata 后宕机，出现上传的视频处在 half-bake 的状态。确实不理想，但我们只要允许用户重新上传也就可以了，不会很影响用户体验。
在跟钱有关的应用里就更敏感一些。
谢谢老师回复！
可是如果用户重新上传，metadata 数据库里就有两条data；在处理后续请求，比如列出用户所有上传记录的时候就有可能出错，对吗？
我感觉绝大部分（如果不是所有）的写操作 都需要保证idempotency, 否则就会出现duplicate data的可能性。
单一写操作，如果worker die了request timeout，我们根本无法知道它是写完了数据库die了还是写之前die了，如果是写完挂了重试就会导致duplicate data;
更别说还有一些情况是一个操作需要写数据库，再写S3，再send a message to Kakfa这种分几步的情况，如果机器挂了没有response，重试就问题更复杂了。这种应该怎么处理呢？
问：可是如果用户重新上传，metadata 数据库里就有两条data；在处理后续请求，比如列出用户所有上传记录的时候就有可能出错，对吗？
答：我们考虑一下怎么容错 - 视频上传失败之后，我们做重试，不必重复再写 metadata 了，因为再次写的时候发现同样的 metadata 已经写过了，可以通过存一个视频文件的hash来分辨。
问：我感觉绝大部分（如果不是所有）的写操作 都需要保证idempotency, 否则就会出现duplicate data的可能性。
答：能够保证idempotency肯定是最好，有的时候极端情况下有duplicate data在用户体验上是可以接受的。
问：更别说还有一些情况是一个操作需要写数据库，再写S3，再send a message to Kakfa这种分几步的情况，如果机器挂了没有response，重试就问题更复杂了。这种应该怎么处理呢？
答：这要看需求，如果说我们必须保证这三步一起发生，那么就需要 distributed transaction。如果问题不大，那么可以考虑在应用层做一些重试来补救。