Review the directory

• The business scenario | synchronous implementation: kill Redis in seconds kill function of practice
• Design patterns | a word understand design patterns
• Apache SkyWalking | SkyWalking advanced play
• Apache SkyWalking | SkyWalking Java plug-in contribution to practice
• A distributed job scheduling | HOME LINK distributed operation platform (recommended)

Use of Redis in resource kill scenarios

Summary of the business

• Kill resources: resources with a length of weeks.
• Each page will have a second kill resources, the number of 1 to 8, in a random form to show visitors.
• The price of the weekly second kill resource is calculated by the data department, and there is no one time point to snap up, such as 10 o ‘clock every Wednesday. Purchasers can snap up any number of seconds remaining.
• Whether the buyer has the right to snap up resources depends on the user interface information, account information, and other permission interfaces.
• The system generates the encrypted information of the buyer buying up the payment, jumps to the payment page, and then asynchronously returns to the payment page to determine whether the purchase is successful. If the purchase fails, the buyer needs to return the inventory of seconds to kill resources in time for others to purchase.

The business process

Redis node description

• Universal Redis: used for SSO to do unified login and non-seckill function.
• Cache Redis: a cache used to store the buyer’s warm-up data and snap up the query information.
• Core REDis: responsible for the realization of core businesses such as the remaining amount of resource inventory and the preemption of resources in seconds, the LRU strategy of Redis needs to be closed and the elimination of key in memory controlled by the program

Redis usage details

• Caching Redis – Data warm-up process ①② (Milk supply degradation Strategy)

  • Key pseudocode

    cacheRedis.setex(key,EXPIRE_TIME_7D,info);
    Copy the code

  • The peak of the second kill QPS is around 1W, but over 60% of the QPS request the query list method, so it is necessary to increase the cache of purchasable second kill resources.

  • Key pseudocode

    Public static String Builder (String prefix, Object) public static String Builder (String prefix, Object) objects) { String input = JSONObject.toJSONString(Arrays.asList(objects)); String output = Util.md5_16(input);return prefix+output;
    }
    cacheRedis.setex(key,EXPIRE_TIME_2S,info);
    Copy the code

  • Design advantages: use spring-data-redis to generalize the input parameters as objects… Serialization, and then compress JsonString Md5 to 16 bits, mainly because at the beginning of the second kill, there will be a large number of cache list data in redis data, redis stores 100W data with 32-bit value length and 16-bit key length, which needs 130MB memory. If the key length is 32 bits, about 160MB of memory is required, so it is necessary to compress the key length in this scenario.

• Core Redis – seckill resource seckill process ③

  • Each seckill resource has its own queue, completing multi-queue, low queue length seckill.

  • Key pseudocode

    String key = PURCHASING_PRODUCT + productId; Long count = coreRedis.llen(key); String[] values = (uuid+uid) * share; String[] values = (uuid+uid) * share;if(inventory - coreRedis.lpush(key, values)) < 0) { coreRedis.lrem(key, share, values); } for example: ID :1 second kill resource has 3 copies of the inventory, when llEN found that the second kill resource has no data in redis, the buyer 20XXXXx1 wants to buy 3 copies of this resource, then Lpush found that the oversold, LREM returned the inventory. Redis 127.0.0.1:6379> lrange XX_PRODUCT_1 0-1 1)"jali7xz20xxxxx1"
    2) "3whsh6b20xxxxx2"
    3) "3whsh6b20xxxxx2"
    4) "3whsh6b20xxxxx2"
    Copy the code

  • Design advantages: The time complexity of the core commands llEN and LPUSH is O(1), and the time complexity of LREM is O(N). The complexity given by the official LREM is O(N). However, I think lREM’s complexity should be infinite and close to O(count) under such scenarios, but the compensation operation is encapsulated as atomic. It also supports multiple, idempotent executions. Some getSet, setNx, pipelin, caching inventory into queues and then pop, transaction, etc. But performance, or robustness, is not as good in this scenario, and this approach immediately idempotent lREM seconds kill the order in the resource queue in the event of a payment failure or an unpaid query, and other eligible purchasers can continue to purchase.

Redis online usage

• Cache Redis

• Core redis

Redis uses summaries

• Using one master, one slave, RDB for the backup strategy of Redis architecture, QPS below 8W is no problem (the first phase of second kill resource second kill, in the case of redis multi-library load segmentation, and no optimization of the use of 5W QPS, there is no timeout link, or access to the connection pool resources, It is also related to the lack of transactions and the low complexity of the command implementation.)
• Like the list page cache, do not reduce the overhead of redis by putting every column of the database in Redis and querying the summary in Redis. For example, every seckill resource is stored in Redis, and it takes 10 Redis links to complete a list page. This will geometrically expand the server’S QPS to the QPS of Redis, causing the system to fail to obtain redis connection resources.
• If Redis is only used for caching data, and extreme performance is desired, the master can turn off memory snapshot and logging, and slave nodes do the work.
• Batch commands to reduce QPS can be replaced with Redisson, Lettuce, or lua scripts.