Hyperledger Fabric client cache, how？

前言

这是一篇探讨性质的文章

为什么要这样做？

我们一般要在性能和脏读之间做取舍。之所以引入cache，就是为了通过接受一定条件的脏读来提高系统整体的性能。

脏读

如图，鉴于区块链同步数据存在时间差，当我们去请求某个数据时，如果我们去请求某个尚未同步最新数据的节点。那么我们实际上请求的不是最新的数据，也就产生了脏读。
​​

Cache

那么我们在代码实际调用sdk访问区块链网络前加入一层cache，如果命中则通过cache返回数据。既然脏读“不可避免”，那么这样做既提高了性能，又对于脏读情况下的数据返回值在结果上没有影响。

怎么做？

Plan A

那么很简单，对于fabric而言，我在query的时候加一层cache，
key：query的chaincode名称，channel，user，parameter的string，
value： query的结果
timeout按照时间来。
如：
key： queryAmyccadmin,
value：90，
timeout：30s

Plan B

plan B相对复杂一些，做两层cache。
1层cache和plan A一致。
2层cache将1层的key作为value存储，key为block中对于某条记录如A读写集的记录。
除了超时过期之外，
还要有因为invoke操作中含有该读写集而摧毁这两层cache的处理。

Plan C

和Plan B类似，不过cache的摧毁逻辑不同。
在客户端实现一个监听机制，当落块事件触发时，根据块里的内容来摧毁cache。