Skip to content

RediSearch: Client‑side routing & sticky cursors #3447

@a-TODO-rov

Description

@a-TODO-rov

Problem

Search commands in Cluster tend to stick to a single primary and cursor pagination can be misrouted when follow‑ups hit a different node than the one that created the cursor. We want behavior that matches RediSearch policies without client scatter/gather or client‑side result merging.


Goal

  • Sticky cursors: FT.CURSOR READ/DEL go to the node that created the cursor by propagating Cursor object.
  • Balanced routing: “Keyless” RediSearch commands spread across all nodes for fairness and throughput.
  • *Keep SUG key‑based:** Suggestion commands stay hash‑slot routed to the owning primary.

Commands covered (v1)

Balanced across all nodes (keyless policy):

  • FT.SEARCH, FT.AGGREGATE, FT.EXPLAIN, FT.LIST, FT.SPELLCHECK, FT.TAGVALS, FT.SYNDUMP, FT.DICTDUMP

Sticky cursor:

  • FT.CURSOR READ (route back to creator node)
  • FT.CURSOR DEL (route back to creator node)

Hash‑slot (unchanged, dictionary key):

  • FT.SUGGET, FT.SUGLEN, FT.SUGADD, FT.SUGDEL

Admin (primaries only):

  • FT.CREATE, FT.ALTER, FT.DROP*, FT.ALIAS*, FT.SYNUPDATE, FT.DICTADD, FT.DICTDEL

Policies (what & why)

  • Request policy

    • Keyless: May run on any primary → we balance calls for better throughput and fairness.
    • Hash‑slot: Must run on the slot owner primary (suggestion dictionary is a real key).
    • Sticky: Cursor follow‑ups must return to the same primary that created the cursor.
  • Response policy

    • Single‑node response. Any internal scatter/gather is handled by RediSearch; the client does not broadcast or merge results.

Why now: Improves reliability (cursors), spreads load, and aligns with RediSearch behavior—without risking correctness by doing client‑side fan‑out or reductions.


Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions