GitLab

chore: update gomod and gosum
chore: update gomod and gosum

v2.2.1_qc_sqlkv_perf
优化了在sqlkv模式下读写的性能。
读ReadObject：    采用RWMutex替代了原来的Mutex，性能提升100倍
写WriteBatch:    直接使用原生的sql.DB进行操作，更快。（性能提升不明显）
修改主要是子项目
https://git.code.tencent.com/ChainMaker/store-sqldb/commits/v2.2.1_qc
本项目主要是performance测试，更新go.mod

chore: update gomod and gosum
chore: update gomod and gosum

v2.2.1_qc_houfa

add store error const
add store error const

bugfix_20220413
主要修bug
1.log format 格式问题，做了修改。
2.bigfilter，增加了逻辑， 存储写 redis失败时，panic。(之前没有panic)

fix: log format
fix: log format
修改日志格式 输出bug

fix: Resolve non-robust error when redis is closed
fix: Resolve non-robust error when redis is closed
主要逻辑：
之前是，redis出故障后，txExist()从bigfilter 返回 error，然后把error返回给调用方
现在是，redis出故障后，txExist()从bigfilter 返回 error，再查一下db，然后把结果返回给调用方。

	exists, b, err := bs.bigFilterDB.TxExists(txId)
	//如果从bigfilter查询出错，直接查db
	if err != nil {
		bs.logger.Errorf("check tx exist by txid:[%s] in bigfilter error:[%s], we will try check from db",
			txId, err)
		return bs.txExistDB.TxExists(txId)
	}

bugfix_20220406
主要变更：
1.异常处理。  
对应这个bug https://www.tapd.cn/47654106/bugtrace/bugs/view?bug_id=1147654106001003259

rollingWindowCache在消费chan时，处理了异常，比如chan关闭会读出nil的情况。(进程关闭时才会关闭chan，所以只有主线程关闭了才会触发)
异常时，本该协程也该关闭退出，但是目前可能协程panic，写了 log，让用户误以为是存储的bug，
实际上是进程本身要退出了，导致这个错误报出来，
不是存储的问题，但会误以为是存储的panic导致crash。

真实的情况，目前推测 进程crash/退出时，存储的groutine还在运行，导致读channel 错误，然后报panic。
目前用defer recover 接住异常，打日志。
2.添加了注释。
加了好多，几个小时的注释^-^

feat: support enable_rwc  enable rollingWindowCache
主要变更
1.rollingWindowCache 增加 开启/关闭 的开关，默认关闭。配置文件中用 
storage:
  enable_rwc: true #默认关闭

update store provider to v2.2.1
update store provider to v2.2.1

bugfix: support mult chain and   add log
1.修bug, 支持多个链:
在redis的 过滤器和lastSavePoint  名字中，增加了 chainID 作为前缀。
这样，一个node，可以用一套redis，支持多个链。
9.134.212.9:7000> keys *
1) "chain1lastBigFilterNumKey"
2) "chain1bigfilter_0"

2.加了日志:
在txid 存在/出现假阳性可能存在 的情况下，输出日志。
可能会在极端情况下，输出太多日志，影响读性能。