зеркало из
1
0
Форкнуть 0
This commit is contained in:
Philo 2021-02-01 14:38:10 -08:00 коммит произвёл GitHub
Родитель 3d42976c5c
Коммит dbf09d67c2
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: 4AEE18F83AFDEB23
1 изменённых файлов: 1 добавлений и 1 удалений

2
FAQ.md
Просмотреть файл

@ -4,4 +4,4 @@
Higher latencies in your client application could be due to how the client library and client application is handling retries under the hood. It's important to note that network blips can happen due to unplanned events as well as planned maintenance, so applications should be designed and implemented in a way that's resilient to brief cache connection loss. The resilience may take the form of retrying commands and connections, circuit breaker patterns that redirect traffic away from impacted caches, or other strategies.
For example, Lettuce automatically retries commands that land on a temporarily broken connection during a network blip. While the retry should happen very quickly, some configuration settings can be tweaked to get a faster response. A colleague found that tweaking Lettuce config with settings like these may help with recovery times when using clustered caches: [Lettuce Best Practices.md](https://github.com/microsoft/AzureCacheForRedis/blob/main/Lettuce%20Best%20Practices.md#creating-a-client-with-the-above-mapping-and-cluster-specific-settings)
For example, Lettuce automatically retries commands that land on a temporarily broken connection during a network blip. While the retry should happen very quickly, some configuration settings can be tweaked to get a faster response. A colleague found that tweaking Lettuce config with settings like these may help with recovery times when using clustered caches: [Lettuce Best Practices.md](Lettuce%20Best%20Practices.md#creating-a-client-with-the-above-mapping-and-cluster-specific-settings)