為保障執行個體穩定性和資料一致性，在使用全球多活功能時，有一些使用約束需要您注意。
使用限制
子執行個體需滿足以下條件：
部署模式為經典（原本地碟）。
儲存介質為記憶體型。
架構為標準架構或叢集架構。
說明請確保各子執行個體規格一致，如需進行變更配置，建議對所有子執行個體均進行相同變更配置。若各子執行個體的規格不一致，可能會出現效能或容量問題。
一個分布式執行個體中最多可包含三個子執行個體，且各子執行個體不能位於同一可用性區域。第一個子執行個體支援從已建立的執行個體進行轉換，第二、第三個子執行個體需新購。
一個分布式執行個體中的子執行個體必須都在中國內地或都在其他地區，若您需要在中國內地地區與其他地區之間進行資料同步，請使用DTS資料同步功能，更多資訊請參見申請跨境資料同步許可權。
成為分布式執行個體的子執行個體後，存在如下限制：
不支援變更執行個體所屬的可用性區域。
不支援變更執行個體架構，例如從叢集架構變更為標準架構等。
叢集執行個體變更配置時，單次僅支援變更配置分區數或分區規格，更多資訊請參見分布式叢集執行個體變更配置方案。
同步命令限制
FLUSHDB或FLUSHALL命令不會被同步。
如需清空資料：需對所有子執行個體執行FLUSHALL命令，否則會造成資料不一致。
如需重新同步：例如以A執行個體為源，重新對B執行個體進行同步，您需要在分布式執行個體中移除B執行個體、對B執行個體執行FLUSHALL命令，再重新將B執行個體接入分布式執行個體中，接入後即可自動重新同步。
Pub和Sub命令不會被同步，如需實現跨域通知的訊息複製，建議通過Stream資料結構來實現。
同步RESTORE命令時，如果目標子執行個體具備相同的Key，則不會被執行。
同步粒度限制
目前同步的粒度為執行個體級，即子執行個體的所有資料都會被同步，暫不支援同步子執行個體中的部分資料。
如需同步部分資料，需要通過商務邏輯來實現。
資料一致性限制
單寫情境下（例如用作災備情境），資料的一致性層級為最終資料一致。
多寫情境下（例如用作多活情境），業務上應避免多個子執行個體在同一時刻或相近的時間修改同一個Key，否則可能造成資料不一致（即無法保障Key的最終一致性）或者資料堆積（在Streaming情境下嚴格遞增產生的衝突），如下表所示。
說明全球多活暫不支援CRDT（Conflict-Free Replicated Data Type）約束，您需要從業務層面自行保障。
不一致情況
圖示
說明
value互換
子執行個體A在1.1時刻收到SET命令（key->value_A），並於1.2時刻將資料寫入資料庫。
子執行個體B在2.1時刻收到SET命令（key->value_B），並於2.2時刻將資料寫入資料庫。
在3.1時刻子執行個體A向子執行個體B同步資料（key->value_A），同時子執行個體B向子執行個體A同步資料（key->value_B）。
同步完成，兩個子執行個體中key對應的value發生了互換。
亂序或丟失
子執行個體A在1.1時刻收到命令（rpush key->value_A），並於1.2時刻將資料寫入至資料庫。
子執行個體B在2.1時刻收到命令（rpush key->value_B），並於2.2時刻將資料寫入至資料庫。
在3.1時刻子執行個體A向子執行個體B同步資料（rpush key->value_A），同時子執行個體B向子執行個體A同步資料（rpush key->value_B）。
當操作類型依賴value原始值時，在交換的情況下可能會出現亂序甚至丟失的情況。
說明可能造成類似問題的還有、
lpush，lpop、append、sort（store）、del、hdel、incr、xadd系列等操作。
類型不一致
子執行個體A在1.1時刻收到命令（key->T(hash)），並於1.2時刻將資料寫入至資料庫。
子執行個體B在2.1時刻收到命令（key->T(string)），並於2.2時刻將資料寫入至資料庫。
在3時刻子執行個體間執行資料同步將形成衝突。
寫入條件不滿足
子執行個體A在1.1時刻收到命令（setnx key->value_A），並於1.2時刻將資料寫入至資料庫。
子執行個體B在2.1時刻收到命令（setnx key->value_B），並於2.2時刻將資料寫入至資料庫。
在3時刻子執行個體間執行資料同步將形成衝突。
說明可能造成類似問題的還有
set(nx | xx)、hsetnx操作。