現(xiàn)象

不少用戶在使用表格存儲的過程中偶爾會接到一些500錯誤，主要錯誤碼如下：

這是由于表格存儲是一個純分布式的NoSQL服務，服務端會根據(jù)數(shù)據(jù)分區(qū)的數(shù)據(jù)量、訪問情況做自動的負載均衡，這樣就突破了單機服務能力的限制，實現(xiàn)了數(shù)據(jù)規(guī)模和訪問并發(fā)的無縫擴展。

如下圖所示，表格存儲會按照第一個主鍵的順序，將實際數(shù)據(jù)劃分到不同的數(shù)據(jù)分區(qū)中，不同的數(shù)據(jù)分區(qū)會調(diào)度到不同的服務節(jié)點提供讀寫服務。

當某個數(shù)據(jù)分區(qū)的數(shù)據(jù)量過大，或者訪問過熱，如下圖的數(shù)據(jù)分區(qū)P1，表格存儲的動態(tài)負載均衡機制能夠檢測到這種情況的發(fā)生，并將數(shù)據(jù)分區(qū)分裂成兩個數(shù)據(jù)分區(qū)P1’和P5，并將該兩個數(shù)據(jù)分區(qū)調(diào)度到負載較低的服務節(jié)點上。

表格存儲使用上述的自動負載均衡機制實現(xiàn)表數(shù)據(jù)規(guī)模和訪問并發(fā)的自動擴展，全程無需人工介入， 當然在數(shù)據(jù)表新建立時，只有一個數(shù)據(jù)分區(qū)，該表上能夠提供的讀寫并發(fā)有限，自動負載均衡機制也有一定的延時性，所以可以直接聯(lián)系到我們的工程師，預先將數(shù)據(jù)表劃分成多個數(shù)據(jù)分區(qū)。

表格存儲使用共享存儲的機制，數(shù)據(jù)分區(qū)為邏輯單位，所以在負載均衡的過程中，不會有實際數(shù)據(jù)的遷移，僅僅是數(shù)據(jù)表元信息的變更，在元信息變更的過程中，為了保證數(shù)據(jù)的一致性，涉及到的數(shù)據(jù)分區(qū)會有短暫的不可用時間， 正常情況下影響時間為百毫秒級別，在數(shù)據(jù)分區(qū)負載較大時，可能會持續(xù)到秒級別， 在這個時間內(nèi)對該分區(qū)的讀寫操作就有可能接到上述的錯誤，一般重試即可解決。在官方的SDK中默認提供了一些重試策略，在初始化Client端時就可以指定重試策略。

同時，表格存儲提供的也是標準Restful API協(xié)議，由于網(wǎng)絡環(huán)境的不可控，所有的讀寫操作也都建議增加重試策略，能夠?qū)W(wǎng)絡錯誤等有一定的容錯能力。

說明：批量讀寫操作BatchWriteRow及BatchGetRow讀寫的數(shù)據(jù)可能屬于多張表或者一張表的多個數(shù)據(jù)分區(qū)，有可能某一個分區(qū)正好在分裂，所以整個操作是非原子性的，只能夠保證每個單行操作的原子性，該操作返回碼為200時仍然需要檢查response中的getFailedRows() 是否有失敗的單行操作。