In flash sale scenarios where the sales period or product quantity is limited, you must handle traffic peaks that occur before, during, and after the sale period. You must also make sure that the number of purchase orders accepted does not exceed the number of products in stock. To handle these challenges, performance-enhanced instances of ApsaraDB for Redis Enhanced Edition (Tair) offer the TairString data structure that provides a simple and efficient way to implement bounded counters. You can use bounded counters to ensure that the accepted purchase orders do not exceed the upper limit. The solutions described in this topic are also applicable to other scenarios where rate limiting or throttling is required.

Bounded counters for flash sales

Based on the integration with Alibaba Tair, performance-enhanced instances of ApsaraDB for Redis Enhanced Edition (Tair) provide the TairString data structure. TairString is more powerful than the native Redis String data structure. TairString offers all the features of Redis String except bit operations.

The EXINCRBY and EXINCRBYFLOAT commands for TairStrings have similar functions to the INCRBY and INCRBYFLOAT commands for native Redis strings. You can use these commands to increment or decrement values. The EXINCRBY and EXINCRBYFLOAT commands support more options than the two commands for native Redis strings. These options include EX, NX, VER, MIN, and MAX. For more information, see TairString commands. The solution described in this topic uses the MIN and MAX options. The following table describes the two options.

Option Description
MIN Specifies the minimum TairString value.
MAX Specifies the maximum TairString value.

If you use native Redis strings to handle the challenges of flash sales, the required code is complex and difficult to manage. This may lead to excess purchase orders, where users are able to make successful purchases of items even after these items have already been sold out. TairString allows you to compile and run simple code to limit the exact number of purchase orders. Sample pseudocode:

if(EXINCRBY(key_iphone, -1, MIN:0) == "would overflow")
    run_out();

Bounded counters for throttling

As with Bounded counters for flash sales, you can specify the MAX option of the EXINCRBY command to implement bounded counters for throttling. Sample pseudocode:

if(EXINCRBY(rate_limitor, 1, MAX:1000) == "would overflow")
    traffic_control();

Bounded counters for throttling can be used for various purposes such as limiting the number of concurrent requests, access frequency, and number of password changes. For example, in concurrency limiting scenarios, the number of concurrent requests suddenly exceeds the system performance threshold. To prevent service failures that cause severe consequences, you can use a bounded counter as a temporary solution to control the number of concurrent requests. This solution can respond to concurrent requests in a timely manner. If you want to limit the number of queries per second (QPS), you can compile and run simple code by using the EXINCRBY command for TairStrings to set a bounded counter for concurrent requests.

public boolean tryAcquire(Jedis jedis,String rateLimitor,int limiter){
    try {
        jedis.sendCommand(TairCommand.EXINCRBY,rateLimitor,"1","EX","1","MAX",String.valueOf(limiter), "KEEPTTL");
        // Set a bounded counter. EX 1 indicates that the rate limiter expires after 1 second. MAX limiter indicates that the upper limit is limiter. KEEPTTL indicates that the time-to-live (TTL) of an existing exstring is not modified. 
        return true;
    }catch (Exception e){
        if(e.getMessage().contains("increment or decrement would overflow")){    // Check whether the returned result contains error messages. 
            return false;
        }
        throw e;
    }
}