根据我自己的个人情况，我接触多的是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交互