为什么使用表格存储过程中会有少量的500错误？

不少用户在使用表格存储的过程中偶尔会接到一些500错误，主要错误码如下。 HTTPStatus ErrorCode ErrorMsg 503 OTSPartitionUnavailable The partition is not available. 503 OTSServerUnavailable Server is not available. 503 OTSServerBusy Server is busy. 503 OTSTimeout Operation timeout.

这是由于表格存储是一个纯分布式的NoSQL服务，服务端会根据数据分区的数据量、访问情况做自动的负载均衡，这样就突破了单机服务能力的限制，实现了数据规模和访问并发的无缝扩展。

如下图所示，表格存储会按照第一个主键的顺序，将实际数据划分到不同的数据分区中，不同的数据分区会调度到不同的服务节点提供读写服务。

当某个数据分区的数据量过大，或者访问过热，如下图的数据分区P1，表格存储的动态负载均衡机制能够检测到这种情况的发生，并将数据分区分裂成两个数据分区P1和P5，并将该两个数据分区调度到负载较低的服务节点上。

表格存储使用上述的自动负载均衡机制实现表数据规模和访问并发的自动扩展，全程无需人工介入， 当然在数据表新建立时，只有一个数据分区，该表上能够提供的读写并发有限，自动负载均衡机制也有一定的延时性，所以可以直接联系到我们的工程师，预先将数据表划分成多个数据分区。

表格存储使用共享存储的机制，数据分区为逻辑单位，所以在负载均衡的过程中，不会有实际数据的迁移，仅仅是数据表元信息的变更，在元信息变更的过程中，为了保证数据的一致性，涉及到的数据分区会有短暂的不可用时间， 正常情况下影响时间为百毫秒级别，在数据分区负载较大时，可能会持续到秒级别， 在这个时间内对该分区的读写操作就有可能接到上述的错误，一般重试即可解决。在官方的SDK中默认提供了一些重试策略，在初始化Client端时就可以指定重试策略。

同时，表格存储提供的也是标准Restful API协议，由于网络环境的不可控，所有的读写操作也都建议增加重试策略，能够对网络错误等有一定的容错能力。 说明 批量读写操作BatchWriteRow及BatchGetRow读写的数据可能属于多张表或者一张表的多个数据分区，有可能某一个分区正好在分裂，所以整个操作是非原子性的，只能够保证每个单行操作的原子性，该操作返回码为200时仍然需要检查response中的getFailedRows() 是否有失败的单行操作。