为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
+-----------------------+
| version() |
+-----------------------+
| 5.7.25-TiDB-v5.0.0-rc |
+-----------------------+
【问题描述】
1. Async commit 开启后什么情况下发生“事务的外部不一致”？
在 PingCAP 官网 5.0.0-rc 特性介绍 中，指出 tidb_guarantee_external_consistency 变量用来确保外部最终一致性，可是就 2PC 原理来说 TIDB 5.0 的 Async Commit 特性以 2PC Prewrite 阶段完成为标准，Prewrite 的完成也就代表 commit(keys,commit_ts,start_ts)) 函数还没有执行成功，因为这时还没有从 PD 获取 commit_ts；
这个问题会引发 “外部不一致”，当前 txn 对于其他 session 的 txn 来说还没有完成，因为没有 commit_ts,但是对于自己的 session 的 txn 来说却已经执行成功，因为 Prewrite 已经执行完成；其他 session 通过 MVCC 获取数据时会出现 官方文档-参数介绍： tidb_guarantee_external_consistency 中提到的 “如果两个事务修改的内容没有交集，其他事务观测到它们的提交顺序可能与它们实际的提交顺序不一致”，因为不相交的两个 txn 不一定谁先获取的 commit_ts 在前，不一定谁先 prewrite 完成，在某些情况下可能违背 “事务的外部一致性”，即：本 txn 相对于自己 txn 已完成只是没有获取 commit_ts,相对于其他 txn 还没有完成；
以上对于 Async commit 的理解对吗？
2. tidb_guarantee_external_consistency 变量如何保证事务的外部一致性？
Async Commit Issue 链接 中 “so only clients who try to read before that message happens will go through the recovery procedure” 指出普遍情况下，发起 2PC 经历过 prewrite 后会很快提交，所以只有想要读取消息（含有 commit_ts 的事务提交消息）发生之前的客户端会处于 recovery procedure。
- Async Commit Issue 链接中提到的 recovery procedure 是什么？
- recovery procedure 可以理解为 tidb_guarantee_external_consistency 开启后，其他 session 查询数据时，类似于遇到锁类似的内部不断重试吗？
- before that message happens 应该 指在获取 commit_ts 之前发生的数据，如果有其他 session 想要获取数据时只能以 txn 未结束的 TSO 参考 MVCC 获取数据吧？
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
