多线程导出excel高并发_表格存储：使用TableStoreWriter进行高并发、高吞吐的数据写入-阿里云开发者社区...

概述

表格存储(原OTS)的一大特性是能够支撑海量数据的高并发、高吞吐率的写入，特别适合日志数据或物联网场景(例如轨迹追踪或溯源)数据的写入和存储。这些场景的特性是，会在短时间内产生大量的数据需要消化并写入数据库，需要数据库能够提供高并发、高吞吐率的写入性能，需要满足每秒上万行甚至上百万行的写入吞吐率。针对这些场景，我们在存储层做了很多的优化(本篇文章不赘述)，同时在SDK接口层也做了一些优化，专门提供了一个简单易用、高性能的数据导入接口。

TableStoreWriter是基于Java SDK的异步接口，封装的一层专门用于高并发、高吞吐率数据导入的接口。本篇文章主要会介绍TableStoreWriter的适用场景、底层架构以及如何使用。

适用场景

特性

如果你的应用场景，满足以下特点，则可以考虑使用TableStoreWriter来作为数据写入的入口：

特点一： 高并发，对吞吐率要求很高

需要高并发的数据写入，非写入行的吞吐率要求很高。例如日志场景，需要分布式的采集日志，采集点可能很多；需要在短时间内将这些产生的日志消费掉，导入到数据库中，衡量导入性能的指标是每秒消费多少MB的日志数据。

特点二：对单条数据的写入延迟没有要求

应用场景需要的是高写入吞吐率，而不是单条数据的写入延迟。还是拿日志场景举例，日志场景对写入的要求是每秒能处理多少条日志，而不在乎一条日志从产生到最终写入的延迟。这是典型的离线和在线场景的区别，在线场景要求反馈是及时的。从延迟的量级上来讲，在线场景可能要求数据写入在毫秒级别，而离线场景可能可以接受数据写入延迟在百毫秒级别。

为啥TableStoreWriter要求应用对单行导入的延迟没有要求？这与TableStoreWriter内部优化写入吞吐率相关，为了最大化利用存储层写入的性能，TableStoreWriter内部会做数据缓冲，尽量发送大的数据包，而数据缓冲需要数据从写入到发送有一个暂缓。

特点三：写入可异步化(可采用生产者消费者模型)

TableStoreWriter为提高写入吞吐率，做的一个优化即异步化。异步化有很多的好处，包括数据写入可以更聚集，可以提供更高的写入并发等。

所以对于应用层，需要能够接受写入异步化。异步化代表的意思是，数据写入的触发线程，不需要同步的等待该行数据是否写入成功还是失败的反馈，数据写入失败或成功的处理可以被异步的执行。

类似的架构为：生产者将数据写入一个队列，而不用管该数据何时被消费ÿ