github.com/Jeffail/benthos/v3@v3.65.0/website/docs/components/outputs/redis_hash.md

---
title: redis_hash
type: output
status: stable
categories: ["Services"]
---

<!--
     THIS FILE IS AUTOGENERATED!

     To make changes please edit the contents of:
     lib/output/redis_hash.go
-->

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';


Sets Redis hash objects using the HMSET command.


<Tabs defaultValue="common" values={[
  { label: 'Common', value: 'common', },
  { label: 'Advanced', value: 'advanced', },
]}>

<TabItem value="common">

```yaml
# Common config fields, showing default values
output:
  label: ""
  redis_hash:
    url: tcp://localhost:6379
    key: ""
    walk_metadata: false
    walk_json_object: false
    fields: {}
    max_in_flight: 1
```

</TabItem>
<TabItem value="advanced">

```yaml
# All config fields, showing default values
output:
  label: ""
  redis_hash:
    url: tcp://localhost:6379
    kind: simple
    master: ""
    tls:
      enabled: false
      skip_cert_verify: false
      enable_renegotiation: false
      root_cas: ""
      root_cas_file: ""
      client_certs: []
    key: ""
    walk_metadata: false
    walk_json_object: false
    fields: {}
    max_in_flight: 1
```

</TabItem>
</Tabs>

The field `key` supports
[interpolation functions](/docs/configuration/interpolation#bloblang-queries), allowing
you to create a unique key for each message.

The field `fields` allows you to specify an explicit map of field
names to interpolated values, also evaluated per message of a batch:

```yaml
output:
  redis_hash:
    url: tcp://localhost:6379
    key: ${!json("id")}
    fields:
      topic: ${!meta("kafka_topic")}
      partition: ${!meta("kafka_partition")}
      content: ${!json("document.text")}
```

If the field `walk_metadata` is set to `true` then Benthos
will walk all metadata fields of messages and add them to the list of hash
fields to set.

If the field `walk_json_object` is set to `true` then
Benthos will walk each message as a JSON object, extracting keys and the string
representation of their value and adds them to the list of hash fields to set.

The order of hash field extraction is as follows:

1. Metadata (if enabled)
2. JSON object (if enabled)
3. Explicit fields

Where latter stages will overwrite matching field names of a former stage.

## Performance

This output benefits from sending multiple messages in flight in parallel for
improved performance. You can tune the max number of in flight messages with the
field `max_in_flight`.

## Fields

### `url`

The URL of the target Redis server. Database is optional and is supplied as the URL path. The scheme `tcp` is equivalent to `redis`.


Type: `string`  
Default: `"tcp://localhost:6379"`  

```yaml
# Examples

url: :6397

url: localhost:6397

url: redis://localhost:6379

url: redis://:foopassword@redisplace:6379

url: redis://localhost:6379/1

url: redis://localhost:6379/1,redis://localhost:6380/1
```

### `kind`

Specifies a simple, cluster-aware, or failover-aware redis client.


Type: `string`  
Default: `"simple"`  

```yaml
# Examples

kind: simple

kind: cluster

kind: failover
```

### `master`

Name of the redis master when `kind` is `failover`


Type: `string`  
Default: `""`  

```yaml
# Examples

master: mymaster
```

### `tls`

Custom TLS settings can be used to override system defaults.

**Troubleshooting**

Some cloud hosted instances of Redis (such as Azure Cache) might need some hand holding in order to establish stable connections. Unfortunately, it is often the case that TLS issues will manifest as generic error messages such as "i/o timeout". If you're using TLS and are seeing connectivity problems consider setting `enable_renegotiation` to `true`, and ensuring that the server supports at least TLS version 1.2.


Type: `object`  

### `tls.enabled`

Whether custom TLS settings are enabled.


Type: `bool`  
Default: `false`  

### `tls.skip_cert_verify`

Whether to skip server side certificate verification.


Type: `bool`  
Default: `false`  

### `tls.enable_renegotiation`

Whether to allow the remote server to repeatedly request renegotiation. Enable this option if you're seeing the error message `local error: tls: no renegotiation`.


Type: `bool`  
Default: `false`  
Requires version 3.45.0 or newer  

### `tls.root_cas`

An optional root certificate authority to use. This is a string, representing a certificate chain from the parent trusted root certificate, to possible intermediate signing certificates, to the host certificate.


Type: `string`  
Default: `""`  

```yaml
# Examples

root_cas: |-
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----
```

### `tls.root_cas_file`

An optional path of a root certificate authority file to use. This is a file, often with a .pem extension, containing a certificate chain from the parent trusted root certificate, to possible intermediate signing certificates, to the host certificate.


Type: `string`  
Default: `""`  

```yaml
# Examples

root_cas_file: ./root_cas.pem
```

### `tls.client_certs`

A list of client certificates to use. For each certificate either the fields `cert` and `key`, or `cert_file` and `key_file` should be specified, but not both.


Type: `array`  
Default: `[]`  

```yaml
# Examples

client_certs:
  - cert: foo
    key: bar

client_certs:
  - cert_file: ./example.pem
    key_file: ./example.key
```

### `tls.client_certs[].cert`

A plain text certificate to use.


Type: `string`  
Default: `""`  

### `tls.client_certs[].key`

A plain text certificate key to use.


Type: `string`  
Default: `""`  

### `tls.client_certs[].cert_file`

The path to a certificate to use.


Type: `string`  
Default: `""`  

### `tls.client_certs[].key_file`

The path of a certificate key to use.


Type: `string`  
Default: `""`  

### `key`

The key for each message, function interpolations should be used to create a unique key per message.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `string`  
Default: `""`  

```yaml
# Examples

key: ${!meta("kafka_key")}

key: ${!json("doc.id")}

key: ${!count("msgs")}
```

### `walk_metadata`

Whether all metadata fields of messages should be walked and added to the list of hash fields to set.


Type: `bool`  
Default: `false`  

### `walk_json_object`

Whether to walk each message as a JSON object and add each key/value pair to the list of hash fields to set.


Type: `bool`  
Default: `false`  

### `fields`

A map of key/value pairs to set as hash fields.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `object`  
Default: `{}`  

### `max_in_flight`

The maximum number of messages to have in flight at a given time. Increase this to improve throughput.


Type: `int`  
Default: `1`