The problem/use-case that the feature addresses

use list like a message queue. consumer create empty list and blpop block on it,and cyclely update it's expire time publisher use rpushx to add data publisher can notice the end of this message queue by the rpushx's result,and the push event can stop

scene: there are one client and one hundred servers one client blpop on one list,all server rpushx into the list if the empty list will deleted automaticly,all servers have to use rpush,and servers will not get the leave event of the client if the empty list will not deleted automaticly,all servers can get the leave event of the client by rpushx,and can stop self

Description of the feature

add command to create a list which will not deleted automaticly when it is empty. use this new list which will not be deleted automaticly when it is empty to work with lpushx/rpushx let user to control the list's life maybe add a field into the quicklist struct as a marker can solve this problem?

Comment From: madolson

Streams will soon support this with the nomkstream option. Can you see if you could use that to solve your use case?

I'm a little hesitant to say that lists should support this, since it breaks a major assumption about redis data structures, in that empty keys == empty collections. Can you explain a bit more for why you don't want the servers pushing data onto the list if the client isn't listening? It sort of seems like you should always be using rpush.

Comment From: chenjie199234

@madolson this may be the normal code to use list as a mq: app client:blpop on key:"client" app server:rpush and expire the key:"client"

the problem is, the server can't known the leave of the client, server is always push data to that list and the list will take more and more memory

so the code has to be app client:blpop on key:"client" and cyclely setex another key:"client exist" to update the expire time app server:check exists key:"client exist" then rpush and expire the key:"client"

but if the list will not delete it self when it is empty, the code become app client:blpop on key:"client" and cyclely expire the key:"client" app server:rpushx the key:"client" code become more simple, and use only one key

this is a normal architecture can be used on game,on live stream,on chat room... Untitled Diagram database record the user's login gateway, and each gateway has a unique id so if server want to broadcast data to user, server just need to push data to the unique id normally, this can use like Kafka,but redis can be more fast and more simple to use.

if empty list will delete it self, and server use rpush to push data: when gateway1 crash, servers are still push data to that unique id, and the list will take more and more memory