https://www.rabbitmq.com/semantics.html
Broker Semantics
Here we describe the broker semantics. This should be read together with the AMQP specification.
Semantics of tx
Overall the behaviour of the AMQP tx class, and more so its implementation on RabbitMQ, is closer to providing a 'batching' feature than ACID capabilities known from the database world.
AMQP transactions only apply to publishes and acks. We have additionally made rejection transactional. Other operations such as resource creation/deletion are not transactional. Consequently the behaviour of transactions when any of the involved exchanges, queues or bindings are altered is undefined.
主要用于 publishes and acks. 连rejection也可以事务了。资源的创建和删除则不是事务的。并且，如果在事务中更改exchnage/queue/binding，则行为是未知的。
On the consuming side, the acknowledgements are transactional, not the consuming of the messages themselves. Hence no requeuing of consumed messages takes place on rollback; the client can still ack/reject these messages in subsequent transactions.
在消费端，acknowledgements是事务的，但是消费消息不是。因此，在回滚时不会将已经消费的消息重新加入队列，client可以自主选择是否接受下一个事务。
AMQP guarantees atomicity only when transactions involve a single queue, i.e. all the publishes inside the tx get routed to a single queue and all acks relate to messages consumed from the same queue. When multiple queues are involved it is possible that in the event of a broker failure during tx.commit the effects of the transaction are only visible in some of the queues. Furthermore, RabbitMQ provides no atomicity guarantees even in case of transactions involving just a single queue, e.g. a fault during tx.commit can result in a sub-set of the transaction's publishes appearing in the queue after a broker restart.
AMQP对于一个队列里的事务是原子的。但是对于多个队列则不是。
RabbitMq并不保证一个队列里的多个事务的原子性，比如commit时，子事务可能会在队列里，当 broker重启时。
AMQP does not specify when errors (e.g. lack of permissions, references to unknown exchanges) in transactional basic.publish and basic.ack commands should be detected. RabbitMQ performs the necessary checks immediately (rather than, say, at the time of commit), but note that both basic.publish and basic.ack are asynchronous commands so any errors will be reported back to the client asynchronously.
The situation is similar with basic.returns, though note the slight change in behaviour between earlier and recent versions of RabbitMQ. You will always receive any basic.returns before the tx.commit-ok.
AMQP does not specify when the effects of transactions should become visible following a tx.commit, e.g. when published messages will appear in queues and can be consumed from other clients, when persistent messages will be written to disk, etc. In RabbitMQ the tx.commit-ok indicates that all transaction effects are visible and that the broker has accepted responsibility for all the messages published in the transaction.
RabbitMq 认为 commit ok就是意味着事务是可见的，并且broker有责任接受事务里所有已经发布了的消息。
For acknowledgements, the receipt of a tx.commit-ok is an indicator that the acknowledgements have been received by the server, not that they have been processed, persisted, etc. Consequently it is possible for a subsequent server-side failure to "resurrect" the acknowledged messages, and for consuming clients to receive them again.
Message ordering guarantees
Section 4.7 of the AMQP 0-9-1 core specification explains the conditions under which ordering is guaranteed: messages published in one channel, passing through one exchange and one queue and one outgoing channel will be received in the same order that they were sent. RabbitMQ offers stronger guarantees since release 2.7.0.
rabbitmq在 2.7.0版本里：同一个channel,同一个exchange，一同一个quque，会有序。
Messages can be returned to the queue using AMQP methods that feature a requeue parameter (basic.recover, basic.reject and basic.nack), or due to a channel closing while holding unacknowledged messages. Any of these scenarios caused messages to be requeued at the back of the queue for RabbitMQ releases earlier than 2.7.0. From RabbitMQ release 2.7.0, messages are always held in the queue in publication order, even in the presence of requeueing or channel closure.
With release 2.7.0 and later it is still possible for individual consumers to observe messages out of order if the queue has multiple subscribers. This is due to the actions of other subscribers who may requeue messages. From the perspective of the queue the messages are always held in the publication order.
Exclusive queues, durability and mirroring
An exclusive queue is one which is deleted whenever the connection that declares it is closed. Although AMQP 0-9-1 allows you to declare a durable exclusive queue, the durability is meaningless since the queue will vanish anyway as soon as the broker stops. Therefore RabbitMQ will ignore the durable flag in a declaration of an exclusive queue and create an exclusive transient queue.
Similarly, there is no benefit to mirroring an exclusive queue, since such a queue will be deleted when the node it was declared on shuts down. Therefore RabbitMQ will never mirror exclusive queues.
https://www.rabbitmq.com/semantics.html