Using Redis for seckilling and throttling, and using redis for thinking

Using Redis for seckilling and throttling, and using redis for thinking
I have talked about seckilling and throttling in the group recently. I have never done similar applications, but I have encountered more data and concurrency at work.

Therefore, a simple model is proposed:

Var count = rds. inc (key );

If (count> 1000) throw "already available! "

Using the Redis single-threaded model, its inc is secure. Ensure that the result of adding one at a time is returned. If the original value is 234 and the value of 1 is 235, the returned value must be 235. In the middle, no other requests will be interrupted, resulting in the return of 236 or other requests.

In fact, we can understand that the business of inc is a pitfall queue, where each person occupies a pitfall. After receiving a ticket in the queue, we can see if the ticket is too high. Then we can output the second kill result from the business level, even more complex services.

The sixth article mentions throttling. It may be based on some consideration. If you want to limit the count corresponding to the key to around 1000, you can accept a 1% deviation.

So we have an improved model:

Var count = rds. inc (key );

'If (count> 1000 ){

Rds. dec (key );

Throw "exceeds the quota! "

}

I added a sentence. After exceeding the quota, I reduced the ticket to ^_^.

Using Redis has one benefit, for example, supporting many application servers to compete together ......

Of course, for a large number of seckilling, this model is not necessarily reasonable, for example, to gun 0.1 million mobile phones, and then 3 million users, instantly crowded up.

Here is a work und that you can try, that is, prepare 10 Redis instances, each with 10 thousand. When the user requests a random number or hash modulo, find the corresponding instance for flash sales.

In the same way, more users can be directly used. In general, when the data is large, the random and hash columns are statistically significant and relatively balanced.

The above is a simple scenario with a large number of seckilling. What about small data scenarios? For example, there are only tens of thousands of concurrent requests.

For small data scenarios and single-application instances, you can consider saving all Redis instances.

Primary model:

Interlocked. Increase (ref count );

If (count> = 1000) throw "It's amazing! "

Intermediate model:

Private volatile Int32 count;

Var old = 0;

Do {

Old = count;

If (old> = 1000) throw "it's time! "

} While (Interlocked. CompareExchange (ref count, old + 1, old )! = Old );

This CAS atomic operation is a good thing. Under the x86 instruction set, there is a dedicated Command CMPXCHG for processing, ensuring the atomicity of data comparison and exchange at the processor level. If most systems want to align with the threshold of 0.1 million tps to 1 million tps, they must implement the lock-free operation. CAS is the easiest to understand, although there are ABA problems sometimes, but we can find many solutions.

In actual use cases, there may be more complex requirements. In other words, here we can only make a few simple and easy-to-use models.