根据我自己的个人情况,我接触多的是ssdb这种nosql,所以我想从ssdb入手分析下leveldb的使用,通过ssdb与leveldb的读写交互来熟悉下leveldb的流程,水平有限,错误难免,相互学习,共同进步,嘿嘿
以ssdb的视角分析leveldb的流程,主要分析leveldb的初始化,写数据操作,读数据操作的大致流程,和局部流程实现细节思考
SSDB::open()对leveldb进行一个open操作:leveldb::DB::Open(OPtions, dir, leveldb::DB*)
涉及的关键参数:
options:调控db的行为(压缩,文件自动创建,出错退出,写缓存大小, 错误日志信息记录, 最大打开的文件个数, 块缓存大小, 快照...)
struct Options//Options.h
我们先简单了解下ssdb的网络处理流程:
看一下ssdb的serve流程:
主要在Networker::serve()上:
初始化reader
初始化writer
监听端口,等待连接事件
假如这个时候一个客户端连接进来了,那就会进入
accept_link()环节并将这个link注册到fdes对象实例上,该实例是记录了ssdbserver打开的reader,writer,client的连接
接下来就调用proc进行cmd的处理了,这块主要是根据客户端传给server的信息,是info ,那server就去调用proc_info解析这个信息并给client生成一个response信息
好,接下来看下如何接受客户端的操作指令的,我info操作,看下serve在干啥:
可以看到这次的link对象不再是serv_link,serv_link是在netserver初始化的时候产生的一个listen link对象,这块就说明该连接不是新的连接了,这次当一个client 的非key-value数据请求处理
通过调试发现,在proc_client_event中,将该连接加入到ready_dict中,所以,该方法出来以后会再次执行:
proc里面会真正的解析指令调用相关的接口,后边我们的重点是关注该指令接口中对存储层的交互(ssdb->leveldb)
有没有发现,目前还是没有进入reader,writer的调用逻辑里面,也就是说,并没有真正的去通过指令接口访问leveldb层的key-value数据,好,那我们现在就写一条最简单的数据,set a 1:
还是走的这个逻辑,那什么时候走reader || writer呢,目前还没管观察到,后边有发现在,,,,
是一个可读事件并把它放到ready_dict里面,准备处理:
进networker的proc看看:
是我们client的请求指令
显然是一个写指令,
直接放在writer池子中了,放了一个job,
然后返回之后就在fdes上取消对这个link的监听了,因为writer已经知道了这个client的存在
这下是writer把link上的事件触发了,现在
看下woker如何处理:
worker直接处理了,这里关注一个东西,fdes如何重新获取这个link的
在这又放进去了,便于下一次触发相同的循环逻辑。
其实,我们会发现真正去调用指令接口和leveldb打交道的是worker也就是这里的writer已经做了,在这里我们看到的已经是writer返回的结果了(后边我们跟踪worker~~)
我们再get a执行,不出意外的话,和上边相似,先是走proc_client_event->reader
在proc中把job给了reader异步处理
后续的处理就是如上,如此重复下一篇章我们从worker的proc_xxx指令接口入手看下如何与leveldb交互