When operating Redis in a Singapore server environment, the seemingly simple removal of keys can cause cascading problems due to data size, network latency, or misoperation. From an e-commerce platform mistakenly deletes the user session cache, resulting in 10,000 login failures, to the financial system triggering master/slave synchronization blocking when clearing invalid orders in batches, the standardization of key management directly affects the stability of services. Based on the server operation and maintenance experience in the Asia-Pacific region, this paper explains the core logic, risk control and performance optimization of Redis key deletion, and provides directly reusable code fragments.

The standard way to delete a single key is the DEL command, but its synchronous execution nature can cause other requests to be blocked when large values are deleted:

redis  
DEL user:1001:cart  

If the value associated with the key is large (such as storing a JSON array or serialized object), the non-blocking UNLINK command is recommended. This command marks the key as being deleted and the memory is asynchronously reclaimed by the background thread, significantly reducing the impact on the main thread:

redis  
UNLINK user:1001:cart  

When removing 1GB Hash keys, UNLINK reduced the main thread blocking time from 230ms to less than 3ms.

Avoid using the KEYS command directly when you need to clean up keys that match a particular pattern, such as all temporary data starting with temp:. This command scans the entire database, which may cause performance jitter or even service interruption. The correct approach is to combine SCAN iterative traversal with batch deletion:

redis  
EVAL "local cursor = 0 repeat local result = redis.call('SCAN', cursor, 'MATCH',  'temp:') cursor = tonumber(result[1]) for _,key in ipairs(result[2]) do redis.call('UNLINK',  key) end until cursor == 0" 0  

This Lua script deletes keys in batches using cursors to ensure smooth memory operations. For tens of millions of key-value pairs, the deletion efficiency can reach 120,000 times per second.

If a key is associated with a complex data structure (such as a field in a Hash or a Sorted Set member), be careful about the integrity of the deletion. For example, delete all time-out items in the user's shopping cart (Hash type) :

redis  
EVAL "redis.call('HSCAN', KEYS[1], 0, 'MATCH', '') local fields = {} for i,  v in ipairs(result[2]) do if i % 2 == 1 then table.insert(fields, v) end end for _,  field in ipairs(fields) do redis.call('HDEL', KEYS[1], field) end" 1 user:1001:cart  

The script implements fine-grained cleaning by traversing Hash fields to avoid the loss of valid data caused by directly deleting the entire key.

In a high-concurrency scenario, the deletion may result in disastrous results. It is recommended that you add the existence check and operation logs before the deletion:

redis  
EVAL "if redis.call('EXISTS', KEYS[1]) == 1 then redis.call('UNLINK', KEYS[1]) redis.call('LPUSH', 'operation_log',  'DELETED_KEY:'.. KEYS[1].. ':TIMESTAMP:'.. ARGV[1]) return 1 else return 0 end" 1 user:1001:cart 1712345678  

This script records the timestamp to the list operation_log when the key is deleted for subsequent audit or rollback. Also, an EXISTS check is used to avoid invalid operations.

Transnational network delays on servers in Singapore can amplify the impact of a deletion operation. Optimization suggestions include:

Reduce the number of network round trips and send multiple delete commands as a package:

bash  
(echo "UNLINK key1";  echo "UNLINK key2";  sleep 1) | rediscli p 6379 pipe  
Use connection pools to avoid frequent connections and set reasonable timeouts:
python  
import redis  
pool = redis.ConnectionPool(host='sg1.redis.com', port=6379, max_connections=10)  
r = redis.Redis(connection_pool=pool, socket_timeout=5)  
r.unlink('user:1001:cart')  

After mass deletion, manually trigger memory reclamation:

redis  
CONFIG SET activedefrag yes  
MEMORY PURGE  

Legal compliance: Special requirements for data privacy in Singapore

Under Singapore's Personal Data Protection Act (PDPA), deletion is required to ensure that sensitive information is not recoverable. If the key value contains user identity information, only DEL or UNLINK is insufficient to ensure physical data clearing. AOF rewriting or RDB persistent file encryption erasure should be enabled:

bash  
Generate a new RDB file and replace the old one
rediscli BGSAVE  
openssl enc aes256cbc salt in dump.rdb out dump.enc pass pass:YourSecureKey  
rm f dump.rdb && mv dump.enc dump.rdb  

Redis key removal is not a simple execution of a command, but a system engineering that requires integration of data structures, business scenarios, and infrastructure characteristics. From the selection of non-blocking commands to legally compliant encryption erases, from scripted batch operations to network layer optimization, rigor and foresight are injected into every aspect. Especially in a multinational business hub like Singapore, the balance between server response speed and data security is even more critical. Only by incorporating the deletion operation into the global operation and maintenance system can Redis maintain a smooth and stable service state while supporting high concurrency services.