為保障執行個體的穩定和資料一致性，在使用全球多活功能時，有一些使用約束需要您注意。
使用限制
子執行個體為記憶體型。
請確保各子執行個體規格一致，如需進行變更配置，建議對所有子執行個體均進行相同變更配置。若各子執行個體的規格不一致，可能會出現效能或容量問題。
一個分布式執行個體中最多可包含三個子執行個體，且各子執行個體不能位於同一可用性區域。第一個子執行個體支援從已建立的執行個體進行轉換，第二、第三個子執行個體需新購。
一個分布式執行個體中的子執行個體必須都在中國內地或都在其他地區，若您需要在中國內地地區與其他地區之間進行資料同步，請使用DTS資料同步功能，更多資訊請參見申請跨境資料同步許可權。
成為分布式執行個體的子執行個體後，存在如下限制：
不支援變更執行個體所屬的可用性區域。
不支援變更執行個體架構，例如從叢集架構變更為標準架構等。
叢集執行個體變更配置時，單次僅支援變更配置分區數或分區規格，更多資訊請參見分布式叢集執行個體變更配置方案。
經典執行個體需確保未開通直連地址（釋放直連地址），雲原生執行個體無此限制。
同步命令限制
不會同步FLUSHDB或FLUSHALL命令。
如需清空資料：需對所有子執行個體執行FLUSHALL命令，否則會造成資料不一致。
如需重新同步：例如以A執行個體為源，重新對B執行個體進行同步，您需要在分布式執行個體中移除B執行個體、對B執行個體執行FLUSHALL命令，再重新將B執行個體接入分布式執行個體中，接入後即可自動重新同步。
不會同步SWAPDB命令。
不會同步SCRIPT LOAD、SCRIPT FLUSH、FUNCTION LOAD、FUNCTION DELETE、FUNCTION RESTORE、FUNCTION FLUSH等指令碼相關的命令。
不會同步Pub和Sub命令，如需實現跨域通知的訊息複製，建議通過Stream資料結構來實現。
不會同步由資料逐出（Evict）和資料到期（Expire）產生的DEL命令。
同步粒度限制
目前同步的粒度為執行個體級，即子執行個體的所有資料都會被同步，暫不支援同步子執行個體中的部分資料。
如需同步部分資料，需要通過商務邏輯來實現。
資料一致性限制
單寫情境下（例如用作災備情境），資料的一致性層級為最終資料一致。以下情況可能導致資料不一致：
由於同步延遲等原因，對帶到期時間（TTL）的Key進行操作可能會導致資料不一致。例如在子執行個體A上成功執行了EXPIRE命令完成續期，但同步到子執行個體B時資料已到期等。如果對資料一致性要求較高，則不建議在全球多活執行個體中設定到期時間。
各子執行個體中資料逐出的Key是相互獨立、隨機播放的。請確保記憶體佔用不超過執行個體規格，以避免觸發資料逐出。
多寫情境下（例如用作多活情境），業務上應避免多個子執行個體在同一時刻或相近的時間修改同一個Key，否則可能造成資料不一致（即無法保障Key的最終一致性）或者資料堆積（在Streaming情境下嚴格遞增產生的衝突）。
說明全球多活暫不支援CRDT（Conflict-Free Replicated Data Type）約束，您需要從業務層面自行保障。
不一致情況
圖示
說明
Key續期失敗
在t1時刻，子執行個體 A 和 B都持有帶到期時間的Key，該Key將於t3時刻到期。
在t2時刻，子執行個體A執行PEXPIREAT命令將該Key續期至t5時刻。
在t3時刻，由於網路延遲等原因，子執行個體B尚未收到來自子執行個體A的PEXPIREAT同步命令，此時子執行個體B中的Key因到期被刪除。
在t4時刻，子執行個體B收到該Key的續期命令，但Key已被到期刪除，故續期命令執行失敗。此時，子執行個體A仍持有Key，子執行個體B中的Key已丟失。
因到期時間導致命令執行結果不一致
以SMOVE命令為例。
在t1時刻，子執行個體A和B均持有Key1（將於t3時刻到期）、Key2（未設定到期時間）。
在t2時刻，子執行個體A執行
SMOVE Key1 Key2 "foo"命令，將"foo"成員移動至Key2中。在t3時刻，由於網路延遲等原因，子執行個體B尚未收到來自子執行個體A的同步命令。同時，子執行個體A和B中的Key1因到期被刪除。
在t4時刻，子執行個體B收到SMOVE命令，但由於Key1已被到期刪除，SMOVE命令執行失敗。此時子執行個體A中的Key2包含“foo”成員，但子執行個體B中的Key2不包含“foo”成員。
資料隨機逐出
在t1時刻，子執行個體A和B均持有Key1、Key2。
在t2時刻，子執行個體A記憶體佔滿，觸發資料逐出，隨機刪除Key2。
在t3時刻，子執行個體B記憶體佔滿，觸發資料逐出，隨機刪除Key1。
由於預設資料逐出策略是volatile-lru，且資料逐出的刪除操作不會同步，因此子執行個體A和B資料不一致。
多寫-Value互換
多個子執行個體同時對同一個Key進行寫操作，可能導致資料不一致。
在t1時刻，子執行個體A寫入
Key:ValA。在t2時刻，子執行個體B寫入
Key:ValB。在t3時刻，子執行個體A向子執行個體B同步資料（
Key:valA），同時子執行個體B向子執行個體A同步資料（Key:valB）。兩個子執行個體中Key對應的值發生了互換。
多寫-資料類型衝突
在t1時刻，子執行個體A寫入
Key，為Hash資料類型。在t2時刻，子執行個體B寫入
Key，為String資料類型。在t3時刻同步命令時，會因資料類型衝突而導致失敗。
多寫-寫入條件不滿足
在t1時刻，子執行個體A寫入
SETNX Key ValA。在t2時刻，子執行個體B寫入
SETNX Key ValB。在t3時刻同步命令時，會因不滿足寫入條件而導致同步失敗。
說明HSETNX、SET[NX | XX]等命令也會造成類似問題。
多寫-亂序或丟失
在t1時刻，子執行個體A寫入
RPUSH Key valA。在t2時刻，子執行個體B寫入
RPUSH Key valB。在t3時刻同步命令時，會導致資料亂序或丟失。
說明LPUSH、APPEND、DEL、HDEL、INCR、XADD等系列命令也會造成類似問題。