Formatted the document

_docs/25-rmq-transaction-example.md

@@ -18,33 +18,25 @@ Transactional message ensures that the execution of local transaction and the se
 ### Usage Constraint
 
 (1) Messages of the transactional have no schedule and batch support. 
-
 (2) In order to avoid a single message being checked too many times and lead to half queue message accumulation， we limited the number of checks for a single message to 15 times by default, but users can change this limit by change the "transactionCheckMax" parameter in the configuration of the broker， if one message has been checked over "transactionCheckMax" times， broker will discard this message and print an error log at the same time by default. Users can change this behavior by override the "AbstractTransactionCheckListener" class. 
-
-(3) A transactional message will be checked after a certain period of time that determined by parameter "transactionMsgTimeout" in the configuration of the broker. And users also can change this limit by set user property "CHECK_IMMUNITY_TIME_IN_SECONDS" when sending transactional message, this parameter takes precedence over the "transactionMsgTimeout" parameter. 
-
-(4) A transactional message maybe checked or consumed more than once. 
-
-(5) Committed message reput to the user's target topic may fail. Currently, it depends on the log record. High availability is ensured by the high availability mechanism of RocketMQ itself. If you want to ensure that the transactional message isn't lost and the transaction integrity is guaranteed, it is recommended to use synchronous double write. mechanism. 
-
+(3) A transactional message will be checked after a certain period of time that determined by parameter "transactionMsgTimeout" in the configuration of the broker. And users also can change this limit by set user property "CHECK_IMMUNITY_TIME_IN_SECONDS" when sending transactional message, this parameter takes precedence over the "transactionMsgTimeout" parameter. 
+(4) A transactional message maybe checked or consumed more than once. 
+(5) Committed message reput to the user's target topic may fail. Currently, it depends on the log record. High availability is ensured by the high availability mechanism of RocketMQ itself. If you want to ensure that the transactional message isn't lost and the transaction integrity is guaranteed, it is recommended to use synchronous double write. mechanism. 
 (6) Producer IDs of transactional messages cannot be shared with producer IDs of other types of messages. Unlike other types of message, transactional messages allow backward queries. MQ Server query clients by their Producer IDs. 
 
 ### Application
 
 1、 Transactional status
 
- There are three type of status for transactional message:
-
- (1) TransactionStatus.CommitTransaction: commit transaction，it means that allow consumers to consume this message.
-
- (2) TransactionStatus.RollbackTransaction: rollback transaction，it means that the message will be deleted and not allowed to consume.
-
- (3) TransactionStatus.Unknow: intermediate state，it means that MQ is needed to check back to determine the status.
+ There are three states for transactional message: 
+ (1) TransactionStatus.CommitTransaction: commit transaction，it means that allow consumers to consume this message. 
+ (2) TransactionStatus.RollbackTransaction: rollback transaction，it means that the message will be deleted and not allowed to consume. 
+ (3) TransactionStatus.Unknown: intermediate state，it means that MQ is needed to check back to determine the status.
 
 2、Send transactional message 
 
  （1）Create the transactional producer 
- Use TransactionMQProducer class to create producer client, and specify a unique producerGroup, and you can set up a custom thread pool to process check requests. After executing the local transaction, you need to reply to MQ according to the execution result，and the reply status is described in the above section.
+ Use TransactionMQProducer class to create producer client, and specify a unique producerGroup, and you can set up a custom thread pool to process check requests. After executing the local transaction, you need to reply to MQ according to the execution result，and the reply status is described in the above section. 
 
  import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer;
  import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;
@@ -95,8 +87,8 @@ Transactional message ensures that the execution of local transaction and the se
 
 
  （2）Implement the TransactionListener interface 
- The "executeLocalTransaction" method is used to execute local transaction when send half message succeed. It returns one of three transaction status mentioned in the previous section.
- The "checkLocalTransaction" method is used to check the local transaction status and respond to MQ check requests. It also returns one of three transaction status mentioned in the previous section.
+ The "executeLocalTransaction" method is used to execute local transaction when send half message succeed. It returns one of three transaction status mentioned in the previous section. 
+ The "checkLocalTransaction" method is used to check the local transaction status and respond to MQ check requests. It also returns one of three transaction status mentioned in the previous section. 
 
   import ...
   

_posts/2018-07-13-the-design-of-transactional-message.md

@@ -38,11 +38,14 @@ Network disconnection or producer application restart may result in the loss of
 Just as the figure shows, in order to mask the underlying implementation of storage, all transactional message operations focus on the transaction service interface.
 RocketMQ provides a default implementation with its own storage system，and we used a transaction bridge to implement our transactional storage logic，instead of modify RocketMQ's storage layer directly. 
 
-> Sending transactional message：
+> Sending transactional message: 
 
 ![screenshot](/assets/images/blog/sending-transactional-message.png) 
-This figure describes the sending transactional message timing relationships. From this figure, we can clearly understand how transaction messages are submitted in two phases.
-> Checking transactional message：
+This figure describes the timing relationships of sending transactional message. From this figure, we can clearly see that how transactional messages are committed in two phases. 
+
+> Checking transactional message: 
 
 ![screenshot](/assets/images/blog/checking-transactional-message.png) 
-This figure describes the checking logic for transactional messages，when MQ server finds that a message remains a half message for a long time，it will send a request to the message producer，to get the status of the current transaction.
+This figure describes the checking logic for transactional messages，when MQ server finds that a message remains a half message for a long time，it will send a request to the message producer，to get the status of the current transaction.
+
+> Design Motivation: