@Meekdai 博客 ui 好评，看着很舒服

[scpw]( https://github.com/T-TRz879/scpw) 基于 Golang 的 SCP 终端系统。经常需要 SCP 的文件配置一次后可反复方便使用。

看两个 explain 后的都是走 sid_datetime 的索引，最可能的原因是 in(20,21,22)中数据 datetime 很散。如果是 20 的 datetime 严格小于或等于 21 那就很快（但显然不太现实），数据库在内存中又自己把(20,21,22)按照 datetime 排了一遍，看 in 的那个 explain 中的 TempSpc 大概是用来排序了

@jiezhi hdfs 复写也可以复写一段范围的数据吧

@Ashe007 试一下 [文件] -> [内存] -> [oss-sdk] 。你分段上传的 [源文件] 是分片好的吗，如果是已经切好片了你把 file 丢给 sdk 也没问题，它也会一点点传走

用户用下载软件最终肯定是想看到 [一个] 文件，而不是多个小文件

@lsk569937453 那是你逻辑设计有问题。哥们

还有一个方向，还在 oss 上，只不过可以把不常用的放入 [低频存储] 中。费用会降低，只是读取不方便

@guochenglong 可以试一下 seaweedfs

@L0L 是的 我看过 jdk 里面的线程池，还是可以的

https://github.com/T-TRz879/scpw 。这是我之前写过一个 scp 的客户端，个人工作需要经常传包，每次 server 和包都比较固定，懒得敲那么多。OP 的 ssx 很不错

@morenacl 是的，计算签名的时候需要保证这点。但 A 和 B 都是从 request 中取出 uri 进行计算的，经过 nginx 转发后，B 拿出的 uri 中的括号就不是%28%29 了。但直连是正常的，所以怀疑 nginx 哪里配置没对

@morenacl 我按照 11 楼给出的建议，把 trailing slash 去掉后就正常了

@dasenlin 到时候第一个 @你 哈哈哈哈

@phithon Thanks!!!! ：）

@yinmin 主要 A 服务器的签名方法是用的 sdk ，里面是把 uri 先 encode 后再签的，这样()就会变成%28%29 。其实直连 B 服务器是签名能过，但为了负载加了 nginx 后就有()签名不过的场景。想的是在 nginx 加什么配置能解决

@julyclyde 我试着去掉看看，一开始加上没报错就没管了

@ysc3839 这个是后来加上的，去掉也试过