在超级分类账结构的交易流文档中，提到
"；订购服务不需要检查交易的整个内容来执行其操作，它只需从网络中的所有渠道接收交易，按渠道按时间顺序订购，并为每个渠道创建交易块">
，我有几个问题
-
什么是"；按时间排序"；意思是这是否意味着渠道的交易是根据在订购服务节点(Leader(收到的时间订购的？
-
如果两个客户端应用程序几乎同时提交账本上相同密钥的更新交易[让我们称它们为tx1(将密钥x更新为值p(、tx2(将密钥x更新为值q(]，则所有认可的对等方都将模拟更新交易提议，并在交易提议响应中返回写入集。当客户端将这些背书提议请求发送到订购服务节点时，这些更新事务将按哪个顺序在块中订购？。
块中事务的顺序可以是tx1、tx2或tx2、tx1，假设更新事务只有写入集而没有读取集，则两个顺序中的事务都是有效的。分类账[p或q]上的密钥的最终值是多少？
我试图了解x的最终值是否具有确定性，以及哪些因素会影响它
什么是"按时间排序"；意思是这是否意味着渠道的交易是根据在订购服务节点(Leader(收到的时间订购的？
通常，订购方不保证消息的交付顺序，只是保证消息将以相同的顺序交付给所有对等节点。
在实践中，以下内容通常适用于当前的订购者实现：
单独消息应该按照接收的顺序发送
Kafka消息应该按照每个订购者节点接收到它们的顺序来传递，通常甚至按照跨多个订购节点接收它们的顺序。
最新的结构版本也是如此。
如果两个客户端应用程序几乎同时提交账本上同一密钥的更新交易[让我们称它们为tx1(将密钥x更新为值p(、tx2(将密钥x更新为值q(]，则所有认可的对等方都将模拟更新交易提议，并在交易提议响应中返回写入集。当客户端将这些背书提议请求发送到订购服务节点时，这些更新事务将按哪个顺序在块中订购？。
提交事务时，对等方会生成一个读写集。当交易提交到分类帐时，将使用此读/写集。它包含要读取/写入的变量的名称及其读取时的版本。如果在集创建和提交之间的时间内，提交了不同的事务并更改了变量的版本，则在提交期间将拒绝原始事务，因为读取时的版本不是当前版本。
为了解决这个问题，您必须创建数据和事务结构，以避免同时编辑同一个键，否则您可能会出现MVCC_READ_CONFLICT错误。