01A client sends one command split across three TCP reads. Which object remembers the unfinished command, and why should the database not know about it?introScenarioA client's command arrives fragmented across multiple TCP reads on a busy server.AThe kernel socket buffer holds the fragments until the full command arrives, so Redis only ever reads complete commands, exactly as it reassembles fragmented packets before delivering them.BThe event loop keeps one global staging buffer shared by all clients, flushed whenever any command completes.CThe database stores a partial entry for the command, finalizing it when the remaining bytes arrive.DThe client object remembers the unfinished input in its input buffer; the database should only see complete commands and server state.
02A socket write accepts only 10 bytes of a 100-byte reply. What state must be preserved before the event loop returns?introScenarioThe server is flushing a large reply and the socket accepts only part of it before returning would-block.AThe server should keep writing in a loop until all 100 bytes are sent, since replies must never be split across loop iterations.BThe client output buffer must keep the remaining 90 bytes and the connection must stay registered for writable progress.CNothing needs saving; the reply can be regenerated from the command result on the next loop tick.DThe 90 bytes can be dropped, because RESP clients detect truncated replies and reissue the original command.
03Compare a normal client, a transaction-building client, and a subscribed client. Which dispatch decisions change for each?appliedScenarioThree connections are open, one normal, one mid-MULTI, and one subscribed to a channel.AAll three dispatch commands identically; only the format of the replies differs between the modes.BA transaction client executes commands immediately but withholds replies until EXEC, while a subscribed client buffers its commands until UNSUBSCRIBE, so that EXEC and UNSUBSCRIBE can release the held results in a single batch.CA normal client dispatches commands immediately, a transaction-building client queues queueable commands, and a subscribed client accepts only subscription-mode commands.DA subscribed client can run any command but also receives pushes, while a transaction client rejects everything except EXEC.
04A disconnected Pub/Sub client still appears in a channel subscriber set. What symptom will this cause later?appliedScenarioA Pub/Sub client's connection died, but its cleanup never removed it from the channel's subscriber set.ALater publishes will try to push messages to a dead client, causing stale fanout entries, wasted work, or output-buffer errors.BPublishes to that channel will start failing with an error until the dead entry is removed from the set.CNew subscribers will be blocked from joining the channel because the dead client still occupies its registration slot until the dead one times out and its slot is reclaimed.DNothing observable happens, because delivery checks liveness before each push and silently skips closed clients.
05Which cleanup steps are mandatory when closing a client with pending output and Pub/Sub subscriptions?advancedScenarioYou are writing the teardown path for a client that has pending output, watched keys, and active subscriptions.AFreeing the client object is enough, since event registrations and index entries are reclaimed automatically with it.BFlush all pending output to the socket first, then free the object; side indexes clean themselves on the next publish.COnly the socket must be closed; per-client state is reset lazily when the file descriptor number is reused by a new connection.DClosing must stop file events, release pending output, remove the client from Pub/Sub side indexes, clear watched or transaction state, and free the client object.
fivenines