|
| 1 | +--- |
| 2 | +categories: |
| 3 | +- docs |
| 4 | +- develop |
| 5 | +- stack |
| 6 | +- oss |
| 7 | +- rs |
| 8 | +- rc |
| 9 | +- oss |
| 10 | +- kubernetes |
| 11 | +- clients |
| 12 | +description: Learn how to use Redis pipelines and transactions |
| 13 | +linkTitle: Pipelines/transactions |
| 14 | +title: Pipelines and transactions |
| 15 | +weight: 2 |
| 16 | +--- |
| 17 | + |
| 18 | +Redis lets you send a sequence of commands to the server together in a batch. |
| 19 | +There are two types of batch that you can use: |
| 20 | + |
| 21 | +- **Pipelines** avoid network and processing overhead by sending several commands |
| 22 | + to the server together in a single communication. The server then sends back |
| 23 | + a single communication with all the responses. See the |
| 24 | + [Pipelining]({{< relref "/develop/use/pipelining" >}}) page for more |
| 25 | + information. |
| 26 | +- **Transactions** guarantee that all the included commands will execute |
| 27 | + to completion without being interrupted by commands from other clients. |
| 28 | + See the [Transactions]({{< relref "/develop/interact/transactions" >}}) |
| 29 | + page for more information. |
| 30 | + |
| 31 | +## Execute a pipeline |
| 32 | + |
| 33 | +To execute commands in a pipeline, you first create a pipeline object |
| 34 | +and then add commands to it using methods that resemble the standard |
| 35 | +command methods (for example, `Set()` and `Get()`). The commands are |
| 36 | +buffered in the pipeline and only execute when you call the `Exec()` |
| 37 | +method on the pipeline object. |
| 38 | + |
| 39 | +The main difference with the pipeline commands is that their return |
| 40 | +values contain a valid result only after the pipeline has finished executing. |
| 41 | +You can access the result using the `Val()` method instead of |
| 42 | +`Result()` (note that errors are reported by the `Exec()` method rather |
| 43 | +than by the individual commands). |
| 44 | + |
| 45 | +{{< clients-example pipe_trans_tutorial basic_pipe Go >}} |
| 46 | +{{< /clients-example >}} |
| 47 | + |
| 48 | +You can also create a pipeline using the `Pipelined()` method. |
| 49 | +This executes pipeline commands in a callback function that you |
| 50 | +provide and calls `Exec()` automatically after it returns: |
| 51 | + |
| 52 | +{{< clients-example pipe_trans_tutorial basic_pipe_pipelined Go >}} |
| 53 | +{{< /clients-example >}} |
| 54 | + |
| 55 | +## Execute a transaction |
| 56 | + |
| 57 | +A transaction works in a similar way to a pipeline. Create a |
| 58 | +transaction object with the `TxPipeline()` method, call command methods |
| 59 | +on that object, and then call the transaction object's |
| 60 | +`Exec()` method to execute it. You can access the results |
| 61 | +from commands in the transaction after it completes using the |
| 62 | +`Val()` method. |
| 63 | + |
| 64 | +{{< clients-example pipe_trans_tutorial basic_trans Go >}} |
| 65 | +{{< /clients-example >}} |
| 66 | + |
| 67 | +There is also a `TxPipelined()` method that works in a similar way |
| 68 | +to `Pipelined()`, described above: |
| 69 | + |
| 70 | +{{< clients-example pipe_trans_tutorial basic_trans_txpipelined Go >}} |
| 71 | +{{< /clients-example >}} |
| 72 | + |
| 73 | +## Watch keys for changes |
| 74 | + |
| 75 | +Redis supports *optimistic locking* to avoid inconsistent updates |
| 76 | +to different keys. The basic idea is to watch for changes to any |
| 77 | +keys that you use in a transaction while you are are processing the |
| 78 | +updates. If the watched keys do change, you must restart the updates |
| 79 | +with the latest data from the keys. See |
| 80 | +[Transactions]({{< relref "/develop/interact/transactions" >}}) |
| 81 | +for more information about optimistic locking. |
| 82 | + |
| 83 | +The code below reads a string |
| 84 | +that represents a `PATH` variable for a command shell, then appends a new |
| 85 | +command path to the string before attempting to write it back. If the watched |
| 86 | +key is modified by another client before writing, the transaction aborts. |
| 87 | +The `Watch()` method receives a callback function where you execute the |
| 88 | +commands you want to watch. In the body of this callback, you can execute |
| 89 | +read-only commands before the transaction using the usual client object |
| 90 | +(called `rdb` in our examples) and receive an immediate result. Start the |
| 91 | +transaction itself by calling `TxPipeline()` or `TxPipelined()` on the |
| 92 | +`Tx` object passed to the callback. `Watch()` also receives one or more |
| 93 | +`string` parameters after the callback that represent the keys you want |
| 94 | +to watch. |
| 95 | + |
| 96 | +For production usage, you would generally call code like the following in |
| 97 | +a loop to retry it until it succeeds or else report or log the failure: |
| 98 | + |
| 99 | +{{< clients-example pipe_trans_tutorial trans_watch Go >}} |
| 100 | +{{< /clients-example >}} |
0 commit comments