Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to discuss the realization principle of WeChat red packet. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

I. background

The following content is based on a discussion summary of a high availability architecture group in QCon

When a student in the group asked about WeChat red packet's structure, Tencent Tenpay gave an answer. The following implementation principle is derived from the content of the dialogue and does not represent the official realization.

There are thousands of ways to realize it, not the replication of methods, but the thinking and summary of the derivation process. Finally, it turns to another implementation way of Sina Weibo Tim.

Second, the key design of WeChat red packet's realization principle.

Resist most requests through cache (whether red packets can be opened, etc.)

DB uses CAS operation to update red packet count record

DB and cache use sharding and can be scaled horizontally

1. New red packet

Add one record to DB and one to cache

two。 Grab the red packet

Request to access cache. If the number of remaining red packets is greater than 0, you can unpack the red packets.

3. Open red packets

Request to visit cache. If the number of remaining red packets is greater than 0, continue, and get the number and amount of red packets that can be snatched.

Calculate the amount (a random number from 1 point to 2 times the remaining average. If it is not the last red packet, the remaining amount is reserved at least 1 point for cas update failure, and the last person with the red packet)

Cas update database (update red packet count table record [number of remaining red packets, remaining red packet amount], insert collection record)

Update failed, repeat the above until the update is successful or has been collected

Update successful, update cache

DB implements the pseudo code for CAS operation (explain the function):

Click (here) to collapse or open

While (hadHongBao ()) {

/ / number of remaining red packets

Def remainCount = getRemainCount ()

/ / obtain the amount of red packets by real-time calculation

Def getAmount = calculateAmount ()

Def result = sql.excute ("update 'red packet calculation table' set balance=$ {total-getAmount}, remainCount=$ {remainCount-1} where remainCount=$ {remainCount} and id=$ {id}")

/ / if the update fails, it will continue to execute the cycle until the update is successful or has been collected, thus achieving the CAS effect.

If (result > 0) {

/ / updated successfully, perform subsequent operations such as updating cache

/ /.

Break

}

}

Main data structures of DB and cache

DB: red packet counting table [main fields: total amount of red packets, total number of red packets, number of remaining red packets, remaining amount of red packets]

Cache: red packet count record [main field: number of remaining red packets, remaining amount of red packets]

Other supplements

Note: DB and cache use sharding, the number of visits increases, and DB, cache and server can all be expanded horizontally.

III. FAQ

The above content explains the key implementation principle of red packet grabbing. For more details, please see the group record summary below (the following content is reproduced from: https://www.zybuluo.com/yulin718/note/93148)

When will the amount of Wechat be counted?

Answer: Wechat amount is calculated in real time when dismantled, not pre-allocated, using pure memory calculation, does not need budget space storage. no, no, no.

Take the consideration of real-time calculation: the budget needs to occupy the storage, the real-time efficiency is very high, the budget efficiency is low.

Real-time: why obviously snatched the red packet and found it after clicking on it?

A: the amount of the 2014 red packet will be known as soon as it is opened. It will be operated in two stages, first grabbing the amount, and then transferring the money.

The removal and robbery of red packets in 2015 are separate and need to be clicked twice, so there will be a situation of grabbing red packets, but telling them that they have been received after clicking on them. Entering the first page does not mean getting it, it only means that there are still red packets at that time.

Allocation: how to calculate the amount in the red packet? Why does the amount of each red packet vary greatly?

A: random, the quota is between 0.01 and the remaining average of 2.

For example: send 100 yuan, a total of 10 red packets, then the average is 10 yuan each, then the amount of red packets fluctuated between 0.01 yuan and 20 yuan.

When the first three red packets are received a total of 40 yuan, leaving 60 yuan, a total of 7 red packets, then the amount of these 7 red packets is between 0.01 ~ (60 prime 72) = 17.14.

Note: the algorithm here is that after each one is robbed, the rest will execute the above algorithm again (Mr. Tim also thinks that the above algorithm is too complex, I don't know what consideration it is based on).

If it goes on like this, it will exceed the total amount at the beginning, so if it is not enough at the end, the following algorithm will be adopted: to ensure that the remaining users can get at least one penny.

If the person in front is unlucky, then the more the balance behind, the more the red packet quota, so the actual probability is the same.

The design of red packet

A: Wechat takes the amount data Guo Lai from TenPay and puts the number / red packet type / amount in the redis cluster. The append puts the request for red packet ID in the request queue. If it is found that it exceeds the number of red packets, it will return directly. If the token request is successfully obtained according to the naked sacrifice processing of the red packet, Tenpay makes a consistent call. Like Bitcoin, the transaction records are kept on both sides, and the transaction is submitted to a third-party service for audit. If there are inconsistencies in the transaction process, it will be forced to return.

High concurrency processing: how to calculate red packets to be robbed?

A: cache will resist invalid requests and filter out invalid requests. The number of requests actually entering the background is small. Cache records the number of red packets, the number of atomic operations decreases gradually, and 0 means it has been robbed. Tenpay is prepared for 200000 transactions per second, but it is actually less than 80, 000 per second.

How does Tong maintain 8w writes per second?

Answer: multi-host sharding, horizontal expansion machine.

What is the capacity?

A: a red packet occupies only one record and is only valid for a few days, so it doesn't need much space.

Is there a lot of pressure to inquire about the allocation of red packets?

A: the number of people who snatched the red packets and the red packets are on the same cache record, so there is not much pressure to query.

A red packet, a queue?

Answer: there is no queue, one red packet and one data, and there is a counter field on the data.

Is there any data to prove that the probability of each red packet is equal?

A: either it is absolutely equal, or it is a simple algorithm for slapping the head.

Will there be two best in the head-slapping algorithm?

A: there will be the same amount of money, but there is only one with the best luck, and the one you get first is the best.

Do you update the data every time you receive a red packet?

Answer: every time you grab a red packet, cas updates the remaining amount and the number of red packets.

How do red packets be stored and accounted for?

The database accumulates the number and amount that have been received and inserts a collection record. Accounting is an asynchronous operation in the background.

What if I make an error in the account? For example, the number of red packets is gone, but there is still a balance?

A: there will be a take all operation at the end. There is also a reconciliation to protect it.

4. Another kind of realization

When discussing the implementation principle in the group, many people proposed the implementation of the pre-allocation amount (the amount of each person grabbed the red packet was allocated when the new red packet was built) to reduce the performance loss of real-time computing and CAS operation. Tenpay said that the pre-allocation amount also needs additional storage space (more importantly, the current implementation method has met the demand). Later, Sina Weibo Tim always proposed that the pre-allocation method does not take up additional storage space. For more information, please see:

The algorithm of WeChat red packet's amount allocation

Realization principle

To achieve the effect of pre-allocation by saving random seed, there is no need to record the remaining amount of red packets, only the remaining number of red packets

When grabbing the red packet, the DESC atomic operation is carried out for the remaining number of the red packet. When the remaining number of the red packet is 0, the red packet is snatched.

This is the end of the discussion on how to realize the principle of WeChat red packet. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.