Distributed Advanced (9) – Mall services – Order business

• Order confirmation page
• Feign remote call missing request header problem
• Feign asynchronous call missing request header problem
• Atomic authentication token: Redis Lua script
• Placing orders: order creation, token verification, price verification, inventory lock
• Local transactions
• Results demonstrate

Order business

Page environment construction

• Static resources are copied into nginx

  Order list, payment, details, order confirmation page resources under order

  

  

  Modify static resource reference addresses for HTML pages

  

  

• Configure the order service domain name

  C:\Windows\System32\drivers\etc\hosts

  

• Configure the gateway route and restart the gateway service

  

• The page display

  

The order center

• The e-commerce system involves three flows, namely information flow, capital flow and logistics, and the order system, as the center, integrates the three organically
• Order module is the hub of e-commerce system. In order, data and information of multiple modules are required to be obtained, and these information will be processed and then flow to the next link. This series constitutes the information flow of order

The order form

• Order composition diagram

  

• 1. User information

  The user information consists of the user account, user level, recipient address, recipient phone number, and recipient phone number. The user account must be bound to a mobile phone number, but the mobile phone number bound to the user may not be the phone number in the harvest information. Users can add a number of harvest information, user level information can be used to match with the promotion system, get commodity discounts, at the same time, user level can also get bonus points

• 2. Basic order information

  Order basic information is the core of order flow, including order type, parent/child order, order number, order status, order flow time and so on

  • Order types include physical goods orders and virtual goods orders, which are differentiated according to the types of goods and services in the mall
  • At the same time, all orders need to be processed by the father and son. Before, there was only one order in the start-up company, and it would be troublesome to disassemble orders in the later stage without the father and son order processing, especially in multi-merchant malls and goods in different warehouses. The father and son order is to prepare for disassembling orders in the later stage
  • There is no more to say about the order number. What needs to be emphasized is that both father and son orders need to have an order number, and each field of the order number can be defined and interpreted uniformly when it needs to be improved
  • Order status records the process of each order flow, followed by a separate explanation of the order status
  • Order flow time needs to record order time, payment time, delivery time, end time/close time, etc

• 3. Product information

  Commodity information Obtain SKU information, picture, name, attribute specifications, commodity unit price, merchant information of commodities from commodity database, user order quantity and total commodity price recorded by user order behavior, etc

• 4. Preferential information

  Preferential information Records users’ participation in preferential activities, including preferential promotional activities, such as full reduction, full gift, second kill, etc., user’s coupon information, coupons that meet the conditions need to be displayed by default, and virtual currency deduction information is recorded

• 5. Payment information

  • Payment bill number. This bill number really evokes the payment serial number returned by the payment channel to the e-commerce business platform after payment by the gateway. The financial department uses the order number and serial number to check accounts with the payment channel

  • Payment method Payment method used by users, such as wechat Pay, Alipay, wallet payment, express Payment, etc. Sometimes there may be two payment methods — balance payment + third-party payment

  • Total amount of goods, the sum of each commodity; Freight and logistics expenses; The total amount of discounts, including promotional activities and discount amount, discount amount of coupons, the amount deducted by virtual credits or virtual coins, and the sum of member discounts; The amount paid in real time, the amount that the user needs to pay

  • Actual amount paid by users = total amount of goods + freight – total amount of discount

• 6. Logistics information

  Logistics information includes distribution method, logistics company, logistics order number and logistics status. Logistics status can be obtained and displayed to users through third-party interfaces

The order status

• 1. To be paid

  After the user submits the order, the order will be pre-placed. At present, the mainstream e-commerce websites will call for payment, which is convenient for the user to complete the payment quickly. It should be noted that the inventory can be locked in the state of pending payment

• 2. Paid/awaiting shipment

  When the user completes the order payment, the order system shall record the payment time, and the payment flow number is convenient for checking accounts. The order shall be transferred to the WMS system, and the warehouse shall conduct operations such as allocation, distribution, sorting and warehousing

• 3. Goods to be received/shipped

  After the warehouse sends the goods out of the warehouse, the order enters the logistics link, and the order system needs to synchronize the logistics information, so that users can know the logistics status of the goods in real time

• 4. Completed

  After the user confirms receipt of goods, the order transaction is completed, and the subsequent payment will be settled. If there is any problem with the order, it will enter the after-sales state

• 5. Cancelled

  Cancellation of an order prior to payment, including overdue payment or cancellation of an order by the user or merchant, will result in this order status

• 6. After sale

  The user applies for a refund after payment, or the user applies for a refund or replacement after the merchant delivers the goods

  After-sales also exists all kinds of state, when a service generated after service orders, order status after approval, waiting for the business review, order status changes after businesses has been verified to be return, waiting for the user to send goods back to business after receiving the order status changes to be refund, a refund to the user after the original account update order for customer success

Order process

• Order process from order to complete the transfer process, thus formed a set of standard process rules, and different type of products or business types in the system process will differ in thousands ways, such as the above mentioned online physical and virtual order process, online sample orders and O2O orders, etc., so you need to build according to different types of order process

• No matter what the type of order is, it includes forward and reverse processes. The corresponding scene is the purchase of goods and the return and exchange process. Forward process is a normal online shopping step: order generation > pay order > seller deliver goods > confirm receipt of goods > successful transaction

  Behind each step, how the order flows between multiple systems can be summarized in the following figure

  

Order creation and payment

• 1. Preview the order and select the receiving information before creating the order
• 2, order creation needs to lock inventory, inventory can be created, otherwise it cannot be created
• 3. If the order is not paid due to timeout after creation, the inventory shall be unlocked
• 4, after the successful payment, need to open the bill, according to the packaging method of goods, warehouse, logistics, etc
• 5. Each flow of payment shall be recorded for audit.
• 6, order creation, payment success and other status need to send messages to MQ, convenient for other systems to sense the subscription

The reverse process

• 1. Modify the order. If the user does not submit the order, he can modify some information of the order, such as delivery information, discount information and other contents that can be modified in the range of the order
• 2. In case of order cancellation, the user actively cancels the order or the user fails to pay over time. In both cases, the order will be cancelled, and in case of timeout, the system automatically closes the order

Idempotent processing

What is idempotency

• The idempotence of the interface means that the results of one or multiple requests initiated by users for the same operation are consistent, and there will be no side effects due to multiple clicks. For example, the payment scenario, the user purchased the goods payment deduction success, but the return results of the network is abnormal, at this time the money has been deducted, the user click the button again, at this time will be a second deduction, the return result is successful, the user query balance found more than the deduction, the flow record has become two… This is not guaranteed idempotency of the interface

What needs to be prevented

• The user clicks the button multiple times
• The user page is rolled back and submitted again
• Microservices call each other. The request fails due to a network problem, and Feign triggers the retry mechanism
• Other Business Information

When do you need idempotent

• In SQL, for example, some operations are naturally idempotent

  SELECT * FROM table WHERE id=? UPDATE table1 SET col1=1 WHERE col2=2 UPDATE table1 SET col1=1 WHERE col2=2 DELETE FROM USER WHERE userid=1 INSERT into USER (userid,name) VALUES (1,'a') ---------------------------- UPDATE tab1 SET col1=col1+1 WHERE col2=2. The result of each operation will change. INSERT into user(userid,name) values (1,'a') INSERT into user(userid,name) values (1,'a'Copy the code

Idempotent solution

1. Token mechanism

• 1.1. The server provides an interface for sending tokens. When analyzing services, we must obtain the tokens before executing the services, and the server will save the tokens in Redis

• 1.2. When invoking the business interface request, the token is carried over and generally placed in the header of the request

• 1.3. The server checks whether the token exists in redis and deletes the token for the first time

• If the token does not exist in redis, it indicates that the operation is repeated, and the repeated token is directly returned to the client, thus ensuring that the business code will not be executed repeatedly

• Risk:

  • Whether to delete the token first or later

    • If the request is deleted first, the service may not be executed, and the request still cannot be executed due to anti-redesign
    • After the token is deleted, the service is successfully processed. However, the service is interrupted intermittently and a timeout occurs. The token is not deleted successfully
    • The best design is to delete the token first, and if the business call fails, get the token again and request again

  • Token acquisition, comparison, and deletion must be atomic

    • Get (token), token.equals (token), and redis. Del (token) if the two operations are not atomic, they may get the same data in high concurrency

    • You can do this with a Lua script in Redis

      if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end
      Copy the code

2. Various locking mechanisms

• 2.1 database pessimistic locking

  SELECT * FROM xxxx WHERE id=1 for UPDATE

  Pessimistic locks are generally used together with transactions, and the data lock time may be very long. Therefore, you need to select pessimistic locks based on the actual situation. Note also that the ID field must be the primary key or unique index, otherwise it may result in a lock table, which can be very troublesome to handle

• 2.2 optimistic database locking

  This approach works well in newer scenarios

  Update t_goods set count = count-1,version = version +1 WHERE good_id=2 and version =1 In other words, the version number of the current product should be obtained before operating the inventory, and the version number should be carried during the operation. Let’s sort it out. When we operated the inventory for the first time, the version was 1, and the version changed to 2 when we called the inventory service. The order service invokes the inventory service again. If the order service passes version 1, the SQL statement above will not be executed. Since version has changed to 2, the WHERE condition does not hold. This ensures that no matter how many times the call is made, it will actually be processed once. Optimistic locking is mainly used to deal with the problem of reading too much and writing too little

• 2.3 Distributed locking at the business layer

  If multiple machines may process the same data at the same time, for example, multiple machines have received the same data processing for timed tasks, we can add distributed lock to lock the data, release the lock after the processing is completed, and the lock must determine whether the data has been processed

3. Various unique constraints

• 3.1 Database unique constraints

  Insert data, which should be inserted according to a unique index, such as the order number; it is impossible to insert two records for the same order. We prevent duplication at the database level

  This mechanism takes advantage of the unique primary key constraint of the database to solve the idempotent problem in the INSERT scenario, but the primary key requirement is not increment primary key, so the business needs to generate globally unique primary key

  In the scenario of separate databases and tables, routing rules must ensure that the same request is landed in the same database and table; otherwise, the database primary key constraint will not be effective, because different databases and table primary keys are unrelated

• 3.2 redis set anti-weight

  A lot of data needs to be processed and can only be processed once. For example, we can calculate the MD5 of the data and put it into the set of Redis. Each time, we can process the data and check whether the MD5 already exists

4, anti-weight table

• The order number orderNo is used as the unique index of the rescheduling table, and the unique index is inserted into the rescheduling table before the business operation, and they are in the same transaction. This ensures that repeated requests will fail because of the unique constraint of the rescheduling table, thus avoiding the idempotency problem. It is important to note that the deduplicated table and the business table should be in the same library. This ensures that the deduplicated table data will be rolled back even if the business operation fails in the same transaction. This is a good way to ensure data consistency
• Before said redis anti – weight also count

5, global request unique ID

• When the interface is called, a unique ID is generated, and Redis saves the data to the collection (de-duplication), which is processed as it exists; You can use nginx to set a unique ID for each request;

  proxy_set_header X-Request-Id $request_id
  Copy the code

Order business

Order confirmation page

• You can find the order settlement page containing the following information:

  • 1, consignee information: there are more addresses, that is, there are multiple delivery addresses, including a default delivery address
  • 2, payment method: cash on delivery, online payment, no need to provide background
  • 3. Delivery list: delivery method (not done) and list of goods (query in database according to skuId selected by shopping cart)
  • 4. Invoice: no
  • 5, discount: query the user received coupons (do not do) and can be integral

  OrderConfirmvo.classCopy the code

• Remotely query all shipping addresses

  Remotely query all selected items in the shopping cart

  Query user credits

Feign remote call missing request header problem

• Feign constructs the request before making a remote call, invoking many interceptors

  RequestInterceptor interceptor:requestInterceptors

  

  

  

Feign asynchronous case lost context problem

• Multiple remote calls, time consuming, asynchronously choreographed optimizations, and then a null context in the request interceptor

  

• Asynchronous mode, multiple threads in a thread pool, and ThreadLocal cannot share data across threads

  Thread print condition

  

  

• Workaround: Get the first context before entering the request interceptor, and re-set the context for each asynchronous thread

  

Overall process of order confirmation page

• The flow chart

  

  

Create the order

Order flow chart

• Submit order process: Validate token – create order number

  

  

Atomic validation token

• If you use Redis to validate the deletion token, you must ensure atomicity

  You can use lua scripts to verify atomicity

  • If the Lua script is not used, the authentication may be successful for multiple times

    

  • Use Lua scripts to ensure atomicity

    

Constructing order data

• Data required for the order submitted by the user

  

Locking the inventory

• Logical flow chart for locking inventory