Hello, everyone, I’m the black brother downstairs ~
I haven’t written a payment related article for a long time. Today I continue to do my old job ~
The money was deducted from the article last time, but the order was not successful! The most complete solution mentioned that the payment process will appear to drop the order, card, this situation for the user, the experience is very poor, clearly they paid, deduct the money, but the order is not successful.
In the last article, we briefly talked about the solution. This time, the black brother gave two detailed design solutions based on the actual production situation:
- Timing polling compensation scheme
- Delay message compensation scheme
You can refer to it selectively according to the actual situation of your system.
Of course, the following design solutions may not be perfect, if you have other solutions, please comment, discuss and grow together
Welcome to pay attention to my public account: xiao Hei 11:30, get daily dry goods push. If you are interested in my topics, you can also follow my blog: studyidea.cn
Timing polling compensation scheme
The whole process
This scheme mainly adopts timed tasks and batch query of single drop records, so as to drive the query of specific payment results and then update internal orders.
The overall program flow chart is as follows:
There is nothing to say about the first three steps of the process. As for the normal payment process, let’s talk in detail about the following steps.
After the third step uses the payment channel, if the payment channel side returns that the payment has been accepted successfully or the payment is being processed, we need to call the fourth step to insert this kind of order into the drop table.
If the payment is directly successful, then the normal process can be returned.
As a review, gateway payment, such as Alipay, wechat pay and e-bank payment, in this payment mode, the payment channel only returns the payment acceptance success, and the specific payment result needs to receive the payment notification at the payment channel end. We call this kind of payment asynchronous payment.
Corresponding to the synchronous payment, such as bank card payment, wechat, Alipay withholding payment, this kind of payment, synchronization can return the payment results.
Fifth step, the order replacement application will periodically query the database, batch query single records.
The sixth step is to use a thread pool to initiate a single drop query asynchronously.
Step 7, call the payment channel payment query interface.
If the seventh step payment result query is in the following state:
- The result of payment is successful deduction
- The result of payment is definite failure
- The number of lost records reached the upper limit
Step 8 will delete the single record.
Finally, if the single drop query is still being processed, then after a certain delay, repeat the fifth step, again until the single drop compensation is successful or the query reaches the maximum number of times.
Issues related to
Why create a new drop table? Can’t use the payment order table directly to query unsuccessful orders?
This problem, in fact, can actually directly use the payment order table, and then batch query the day of the unsuccessful order, fill the single program launched payment query.
So why create a new drop table?
Mainly because of the database query efficiency, because the payment order table will be a large number of new records every day, as time, this table records will be more and more, bigger and bigger.
The more payment records, the batch range query efficiency will be lower, the query speed will be slower.
So in order to query efficiency, create a drop table.
This table only records orders that failed to be paid, so the amount of data is small and the query is efficient.
In addition, the records in the drop table will not be permanently saved, but temporary. When the query of payment result is successful, or the payment result is clearly failed, or the query times reaches the specified maximum number, the single record will be deleted.
This is why you need to drop the single table in step 8.
If you need to save the details of each drop table query, you are advised to create another drop table to save the query records of each drop table.
If you have any other questions about this project, please leave a comment.
Advantages and disadvantages of the scheme
The biggest advantage of the periodic polling compensation scheme may be that the system architecture scheme is relatively simple and easy to implement.
Then the disadvantage of this scheme mainly lies in the scheduled task.
The scheduled task polling scheme naturally has the following shortcomings:
-
Polling is less efficient
-
Every time the database is queried, the records that have been executed will still be scanned (the replenishment program will decide whether to initiate payment channel query according to certain policies), which is suspected of double calculation
-
Timeliness is not good enough. If you poll every hour, the time error can reach 1 hour in the worst case
-
In order to solve the timeliness problem and increase the query efficiency of scheduled task, the problem of double calculation between query efficiency in 1 and query efficiency in 2 will be more obvious.
Delay message compensation scheme
The following is another compensation scheme for dropped orders, delayed message compensation scheme. The overall process of this scheme is similar to that of scheduled task scheme, but the biggest difference may be that it changes from a pull mode to a push mode.
The overall program flow chart is as follows:
The main process of this scheme is similar to the timing scheme, with the main difference being the fourth step, the fifth step and the eighth step.
The process in step 4 changes from inserting drop tables to sending drop messages to the delay queue.
The fifth step, the reorder program receives the reorder message and triggers the reorder query.
Step 8, if the query of the payment result in step 7 is as follows:
- The result of payment is successful deduction
- The result of payment is definite failure
- The number of lost records reached the upper limit
The replenishment program will inform the delay queue that the purchase was successful, and the delay queue will delete the drop order message.
The other states will tell you that the consumption has failed, and the delay queue will send the drop message again after a certain delay, and then continue to repeat step 5.
Delays in the queue
The delay queue here needs to be implemented by itself, and the complexity is relatively high. Here we recommend several implementation schemes:
The first is to implement delay queue based on Redis SortedSet. Check out the awesome implementation at tech.youzan.com/queuing_del…
Second, based on the time wheel algorithm (TimingWheel) to achieve delay queue, specific can refer to Kafka delay queue.
The third is based on RocketMQ delayed messages.
The first two schemes need to be developed again, so they are more complex.
This focuses on the third solution, which RocketMQ already supports and is relatively easy to use out of the box.
RocketMQ delayed messages support 18 levels, as follows:
1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
Copy the code
The message sender can specify the delay level in the following ways, corresponding to the delay time above.
Message#setDelayTimeLevel
Copy the code
Message consumer, if consumption fails, the default delay level of the message sender is increased by 1. If message consumers need to specify additional latency levels, they can do so as follows:
ConsumeConcurrentlyContext#setDelayLevelWhenNextConsume
Copy the code
RocketMQ delay messages support is fairly basic and simple, with no support for custom latency. This is fine for the drop order compensation scenario, but if you need to customize the delay, you have to use another solution.
Advantages and disadvantages of the scheme
The scheme of delayed message is compared with the scheme of timed polling:
- No need to query all orders, high efficiency
- Timeliness is better
However, the delayed message scheme, which needs to be based on the delay queue, is more complicated to implement, and there are few open source implementations at present.
summary
We can use the scheme of asynchronous compensation to solve this problem.
The following two asynchronous compensation schemes can be used:
- Timing polling compensation scheme
- Delay message compensation scheme
The timing polling compensation scheme is simple to implement, but its timeliness is a little poor.
The delay message compensation scheme is excellent in general, but it is more complicated to implement. If you don’t have the need for a custom delay time, you can just use RocketMQ to delay messages quickly and easily.
In addition, the use of delay queue is more, not only can be used in the drop of compensation, but also can be used to pay off the order and other scenarios. So teams capable of development can develop a generic delay queue,
Well, that’s all for today’s article.
I am downstairs little black brother, see you in the next article, 886~
Welcome to pay attention to my public account: xiao Hei 11:30, get daily dry goods push. If you are interested in my topics, you can also follow my blog: studyidea.cn
History payment articles recommended
- The money was taken, but the order didn’t go through! Pay off the most complete solution for abnormal orders
- One order, but two payments were made by mistake! How should this kind of repeated payment abnormal solve after all?
- Receivables! The principle of interpretation of polymerization of yards behind the original |
- How is it possible to pay when your phone is off the Internet? | original
- A quick swipe, instant deduction, and the principle behind the payment code don’t you want to know? | original
- Evolution of payment channel routing system
- Design reconciliation system from scratch
- Wechat Alipay access daquan
- Design of multi-payment channel routing gateway
- What’s going on behind card payments?