Redis 从库对于键过期的处理，源码

一时失言乱红尘 2023-06-21 03:55 36阅读 0赞

我们都知道对于单实例或者主库实例中，带有过期属性的键，在过期后会有主动删除和惰性删除两种策略来处理。但是在从库，键过期以后，也会采用同样的方式来处理吗？  
先看一下官方的解释：  
**How expires are handled in the replication link and AOF file**  
In order to obtain a correct behavior without sacrificing consistency, when a key expires, a DEL operation is synthesized in both the AOF file and gains all the attached replicas nodes. This way the expiration process is centralized in the master instance, and there is no chance of consistency errors.

However while the replicas connected to a master will not expire keys independently (but will wait for the DEL coming from the master), they’ll still take the full state of the expires existing in the dataset, so when a replica is elected to master it will be able to expire the keys independently, fully acting as a master.  
总的来说，当主库采用主动或惰性删除过期键时，会同步一个DEL操作到从库，这样从库也可以删除过期键。但是，从库不会自己处理过期键，只会应用主库同步过来的DEL过期键操作，也就是说，即使键在从库已经过期了，从库也不会对其处理，过期后如果主库不同步DEL操作过来，那么从库并不会采用主动或惰性的方式去清理过期键。

那么，对于从库处理过期键的方式，就存在一个问题。就是当从库提供只读功能时，即使一个键已经过期了，如果主库对这个过期键的清理操作处理不及时，那么在从库仍然能读到这个键。  
这个问题确实在Redis3.2以下会存在，但是在Redis3.2以上，已经做出了优化：对于在从库中已经过期的键，在从库发起读取的时候，Redis会判断这个键是否已经过期，如果已经过期，那么将返回nil；但是对于这个过期的键，从库仍然不会自己采取清理措施，而是需要等主库发起对这个过期键的清理，然后同步DEL操作过来，从库才应用DEL操作对过期键进行删除。  
所以Redis3.2以上的优化总结来说，是屏蔽了从库中已经过期的键。  
可以从redis-4.0.14源码中看出：

* Note: this function also returns NULL is the key is logically expired
     * but still existing, in case this is a slave, since this API is called only
     * for read operations. Even if the key expiry is master-driven, we can
     * correctly report a key is expired on slaves even if the master is lagging
     * expiring our key via DELs in the replication link. */
    robj *lookupKeyReadWithFlags(redisDb *db, robj *key, int flags) {
        robj *val;
    
        if (expireIfNeeded(db,key) == 1) {
            /* Key expired. If we are in the context of a master, expireIfNeeded()
             * returns 0 only when the key does not exist at all, so it's safe
             * to return NULL ASAP. */
            if (server.masterhost == NULL) return NULL;
    
            /* However if we are in the context of a slave, expireIfNeeded() will
             * not really try to expire the key, it only returns information
             * about the "logical" status of the key: key expiring is up to the
             * master in order to have a consistent view of master's data set.
             *
             * However, if the command caller is not the master, and as additional
             * safety measure, the command invoked is a read-only command, we can
             * safely return NULL here, and provide a more consistent behavior
             * to clients accessign expired values in a read-only fashion, that
             * will say the key as non exisitng.
             *
             * Notably this covers GETs when slaves are used to scale reads. */
            if (server.current_client &&
                server.current_client != server.master &&           /*如果当前实例不是master*/
                server.current_client->cmd &&
                server.current_client->cmd->flags & CMD_READONLY)
            {
                return NULL;                    /*返回NULL，前端即nil*/
            }
        }