.. _envoy_api_file_envoy/config/filter/network/redis_proxy/v2/redis_proxy.proto:

Redis Proxy
===========

Redis Proxy :ref:`configuration overview <config_network_filters_redis_proxy>`.

.. _envoy_api_msg_config.filter.network.redis_proxy.v2.RedisProxy:

config.filter.network.redis_proxy.v2.RedisProxy
-----------------------------------------------

`[config.filter.network.redis_proxy.v2.RedisProxy proto] <https://github.com/envoyproxy/envoy/blob/v1.10.0/api/envoy/config/filter/network/redis_proxy/v2/redis_proxy.proto#L17>`_


.. code-block:: json

  {
    "stat_prefix": "...",
    "cluster": "...",
    "settings": "{...}",
    "latency_in_micros": "..."
  }

.. _envoy_api_field_config.filter.network.redis_proxy.v2.RedisProxy.stat_prefix:

stat_prefix
  (`string <https://developers.google.com/protocol-buffers/docs/proto#scalar>`_, *REQUIRED*) The prefix to use when emitting :ref:`statistics <config_network_filters_redis_proxy_stats>`.
  
  
.. _envoy_api_field_config.filter.network.redis_proxy.v2.RedisProxy.cluster:

cluster
  (`string <https://developers.google.com/protocol-buffers/docs/proto#scalar>`_, *REQUIRED*) Name of cluster from cluster manager. See the :ref:`configuration section
  <arch_overview_redis_configuration>` of the architecture overview for recommendations on
  configuring the backing cluster.
  
  
.. _envoy_api_field_config.filter.network.redis_proxy.v2.RedisProxy.settings:

settings
  (:ref:`config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings <envoy_api_msg_config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings>`, *REQUIRED*) Network settings for the connection pool to the upstream cluster.
  
  
.. _envoy_api_field_config.filter.network.redis_proxy.v2.RedisProxy.latency_in_micros:

latency_in_micros
  (`bool <https://developers.google.com/protocol-buffers/docs/proto#scalar>`_) Indicates that latency stat should be computed in microseconds. By default it is computed in
  milliseconds.
  
  
.. _envoy_api_msg_config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings:

config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings
----------------------------------------------------------------

`[config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings proto] <https://github.com/envoyproxy/envoy/blob/v1.10.0/api/envoy/config/filter/network/redis_proxy/v2/redis_proxy.proto#L27>`_

Redis connection pool settings.

.. code-block:: json

  {
    "op_timeout": "{...}",
    "enable_hashtagging": "..."
  }

.. _envoy_api_field_config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings.op_timeout:

op_timeout
  (`Duration <https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration>`_) Per-operation timeout in milliseconds. The timer starts when the first
  command of a pipeline is written to the backend connection. Each response received from Redis
  resets the timer since it signifies that the next command is being processed by the backend.
  The only exception to this behavior is when a connection to a backend is not yet established.
  In that case, the connect timeout on the cluster will govern the timeout until the connection
  is ready.
  
  
.. _envoy_api_field_config.filter.network.redis_proxy.v2.RedisProxy.ConnPoolSettings.enable_hashtagging:

enable_hashtagging
  (`bool <https://developers.google.com/protocol-buffers/docs/proto#scalar>`_) Use hash tagging on every redis key to guarantee that keys with the same hash tag will be
  forwarded to the same upstream. The hash key used for determining the upstream in a
  consistent hash ring configuration will be computed from the hash tagged key instead of the
  whole key. The algorithm used to compute the hash tag is identical to the `redis-cluster
  implementation <https://redis.io/topics/cluster-spec#keys-hash-tags>`_.
  
  Examples:
  
  * '{user1000}.following' and '{user1000}.followers' **will** be sent to the same upstream
  * '{user1000}.following' and '{user1001}.following' **might** be sent to the same upstream