ShineSmile

git clean -xfd
git submodule foreach --recursive git clean -xfd
git reset --hard
git submodule foreach --recursive git reset --hard
git submodule update --init --recursive

ShineSmile

注意：本文内容适用于 Tmux 2.3 及以上的版本，但是绝大部分的特性低版本也都适用，鼠标支持、VI 模式、插件管理在低版本可能会与本文不兼容。

Tmux 快捷键 & 速查表

启动新会话：

tmux [new -s 会话名 -n 窗口名]

恢复会话：

ShineSmile

Azure Redis Patching Explained

Occationally customers will experience connection related errors in their client applications talking to Redis. Most often these errors are caused by one of the following:

1. Redis was patched or a master/slave failover occurred.
2. A client-side network configuration change was made. See below for details

In this article we will quickly discuss how patching works in Azure Redis and how this impacts clients. While this article talks mostly about patching, the experience is more or less the same when a failover occurs.

Redis Patching and Failover Details

ShineSmile

Best Practices for Azure Redis

Below are a set of best practices that I recommend for most customers. This information is based on my experience helping hundreds of Azure Redis customers investigate various issues.

Configuration and Concepts

1. Use Standard or Premium Tier for Production systems. The Basic Tier is a single node system with no data replication and no SLA. Also, use at least a C1 cache. C0 caches are really meant for simple dev/test scenarios since they have a shared CPU core, very little memory, are prone to "noisy neighbor", etc.
2. Remember that Redis is an In-Memory data store. Read this article so that you are aware of scenarios where data loss can occur.
3. Configure your client library to use a "connect timeout" of at least 10 to 15 seconds, giving the system time to connect even under higher CPU conditions. If your client or server tend to be under high load