[NEW] Add command to create empty list key which will not be deleted automaticly when it is empty

[chenjie199234]

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?

[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.

[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...

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