自建投入生产使用过一段时间的 TD ，当时使用的版本是 3.0.2.x ，碰到过好几个问题：
1. 乱序、重复写入数据会导致性能下降
2. 业务上是在 TD 的子表查询，某些子表出现过以下问题：
- 由于数据涉及到更新（覆盖写入），导致数据无法查询最新状态
- 查询总数量 COUNT(*) 失败
3. 3 个节点的集群出现过宕机，集群无法恢复工作
4. 数据设置了 TTL 后只是逻辑删除，数据还是保留在磁盘上，需要手动执行命令才会清空磁盘

-----------------------------

以上问题目前最新版本可能已经修复了（未关注）。由于是自建集群，碰到问题后只能升级版本解决，但是线上环境升级数据库是个风险很大的操作，而且不可能每次一有问题就升级版本，折腾了一段时间最后还是停用了 TD 。
选择什么数据库要考虑数据类型、数据量、数据写入、查询方式以及运维成本，如果 OP 想要自建，考虑好遇到问题要怎么升级版本。

楼主后续选了什么方案，遇到相似的场景，方便加个 qq 么。base64: MTU1MjkzNzAwMA==

求拉，感谢：MTU1MjkzNzAwMA==

@Reficul 嗯 谢谢，在这之前没想到网络传输的问题，单纯地想并发写入磁盘就会变快（太年轻了...）

@flyingghost 感谢老哥回复那么多。

一开始确实没考虑那么多，只是想开多个协程看看能不能将多个文件并发写入磁盘，从而加快速度（单 client ），没想到多个 client 上传的场景（项目都是一些小服务，并发很小，所以没考虑到多个 client 的情况）

要是有 n 个 client 上传 m 个文件的话，传输失败率的确得考虑，好像听说有遇到这样的事（不是我负责的服务），要是采用多文件分开多个链接传输的方式的话，客户应该不怎么会接受吧？毕竟还是想要“方便”...

使用 MultipartForm 的原因是文件也不大，还要求可以多文件上传（貌似写入缓冲会提升速度?）。

@encro 明白了，就像 7 楼说的写入到不同的磁盘会提升速度那样。所以这里的瓶颈就是在于磁盘，不是开多几个线程就能解决的，多谢~

@zhshch 所以说时间大部分都是消耗在传输上了，如果忽略传输时间，那么开多个线程对磁盘写入会提升速度吗？

@reus 好的，多谢

@reus 所以意思是说时间大部分都是消耗在传输上，文件越多传输得也自然就越慢了。还有一个问题就是这里确实是并发将文件写入磁盘了吗（忽略传输时间）？换句话说开不开 goroutine 对磁盘写入有没有影响。

@encro 明白了 谢谢。

@reus 可能会限制一下一次性能上传多少个文件。虽然是顺序传输到服务器，服务器不是拿到全部文件后再写入磁盘的？

@encro 这里 disk I/O 的影响，也就是说还是要一个个排队写入 disk 么？

@Reficul 是一个个排队发送的原因吗，后台不是拿到全部文件后再写入磁盘的？

@TypeErrorNone
@forcecharlie
谢谢

@lbp0200 在本地测试的，一样结果

@Hanggi
@ChristopherWu
@Carseason
@guonaihong
谢谢大家，问题解决了，是由于我用了 301 重定向导致的。改了一下貌似没问题了

@lanjz 看了一下确实是用了 301(没有改回来)。现在改了一下好像可以了。感谢

@lanjz 清完缓存又是正常的，不会出现路由问题，但是不能每次都 Disable cache 吧...