Fabric 默认配置中tls证书有效期为一年，相信挖了不少的坑，我前段时间写了篇文章介绍了下解决的思路，但是自己真解决起来还是没解决问题，这种分布式企业架构太复杂。

最近有遇到一个奇怪的问题，小伙伴写的存证数据，在上链时，10条数据中只能上链2-3条，总是会遇到txid exists问题，而且这个问题似乎只在他的批量程序中出现。

 大过年的遇到这种问题真是让人大为光火，但是一点解决思路都没有。

憋了几天之后，只能继续往下查业务问题，结果发现，业务层因为存储时间精度问题，导致了链上数据每个客户每秒中只能存一条数据，这是因为智能合约中，设置CompositeKey是这么设置的：

key, err := ctx.GetStub().CreateCompositeKey(OwnerId, []string{
		strconv.FormatInt(ExecAt, 10),
	})

我们知道Fabric是用键值对的形式存储数据，而上面这个key是由ownerid和时间戳构成的，原本以为业务层的时间戳是到毫秒级别，对于小型业务还没有问题，但是却发现因为MySQL中的默认的datatime类型所控制的精度是不包含到毫秒，导致传入的其实只有秒。

而开发测试的数据又是由几个样本数据复制出来的，导致大量key值重复。

这个问题解决了之后，txid exists的问题也没有了……

由此我怀疑是不是txid是由交易导致的数据变化hash出来的，查了下fabric sdk java

TransactionContext.java里txid是由一个随机的nonce拼接后缀生成的，按道理应该是每次交易随机的。

 //TODO right now the server does not care need to figure out
private final ByteString nonce = ByteString.copyFrom(Utils.generateNonce());


……

ByteString no = getNonce();

ByteString comp = no.concat(identity.toByteString());

byte[] txh = cryptoPrimitives.hash(comp.toByteArray());

//    txID = Hex.encodeHexString(txh);
txID = new String(Utils.toHexString(txh));

但是这个随机数上面的注释说：TODO right now the server does not care need to figure out（服务器不care这个信息，需要解决。

难道服务器的id生成有我说的问题？我没有继续往下查，项目组都在TODO状态，我们也没法查下去了，如果有遇到txid exists问题的小伙伴记得查一下合约有没有数据重复问题，如果也有，可能还真有这个问题。