JD Order-to-weight problem: On the principle of domain driven design in Distributed transaction processing

Original article: http://www.csdn.net/article/2015-01-15/2823577

Order number deduplication problem: Suppose a node sends a new order request to the B node, but the network is likely to fail, it is possible that the distributed transaction has been executed successfully on the B node, but a failed, causing the order request to be re-sent, resulting in duplicate orders

Point: The key issue is the order number of the ID information to prevent duplicate generation, if the ID number can be generated in advance, you can send this ID information each time, so that each processing of the request to idempotent.

Therefore, JD's current program is equivalent to the B node based on commodity information, customer information and so on, made a reverse mapping to the order ID, but this scheme is not flexible, assuming that the customer is to be in 1 seconds in succession to 2 orders???

So, the simpler scenario is to have the browser side generate this order ID number directly: Based on the user ID and item list;

In other words, a simple principle of distributed transaction processing is to ensure idempotent so that the transaction requester generates the transaction ID directly. Note: The order number is not sensitive, so you do not actually need to generate it on the server side. Or, you need an initial virtual order number that prevents "duplicates," and then the server backend can map the build itself, which is fine.

This transaction ID is not actually global, if a sends a transaction request to B, and b needs to send a child transaction request to C during processing, B needs to generate its own child transaction ID

This is actually some idea of domain-driven design in there.

JD Order-to-weight problem: On the principle of domain driven design in Distributed transaction processing