好贷网好贷款

小伙伴们的ceph源码分析三——monitor消息处理流程

发布时间:2016-12-4 14:33:34 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"小伙伴们的ceph源码分析三——monitor消息处理流程",主要涉及到小伙伴们的ceph源码分析三——monitor消息处理流程方面的内容,对于小伙伴们的ceph源码分析三——monitor消息处理流程感兴趣的同学可以参考一下。

原文链接:http://blog.csdn.net/kakaxi8891/article/details/10935595 笔者在读代码初期非常想理清楚的就是ceph这么个系统在服务端与客户端是怎么响应与发起请求的。 本人主要负责monitor部分,而且追了一会cephx认证的代码,所以拿这块举例,后续osd部分主要是对同事分享的学习。 本篇会讲到src/mon/monitor.cc中 class Monitor : public Dispatcher class MonClient : public Dispatcher  以及src/tools/ceph.cc 这三者的关系: 前一篇讲到ceph-mon.cc中启动了monitor的进程,而启动的过程伴随着一些消息队列的启动: void SimpleMessenger::ready() {   ldout(cct,10) << "ready "<< get_myaddr()<< dendl;   dispatch_queue.start();//消息接收队列启动   lock.Lock();   if (did_bind)     accepter.start();//套接字启动(如前一篇所说)   lock.Unlock(); } 1. monitor: 细节就不多说了,在entry()中我们可以看到有个while循环轮训监听,处理monitor接受到的请求,接下来是monitor对单条消息的处理: 2. monclient monclient与monitor对应,monitor为服务端,monclient为客户端,最初的猜想是所有需要和monitor打交道的程序都要实例化一个monclient,但是实际上monclient只处理一些特定的消息:   // we only care about these message types   switch (m->get_type()) {   case CEPH_MSG_MON_MAP:   case CEPH_MSG_AUTH_REPLY:   case CEPH_MSG_MON_SUBSCRIBE_ACK:   case CEPH_MSG_MON_GET_VERSION_REPLY:   case MSG_MON_COMMAND_ACK:   case MSG_LOGACK:     break;   default:     return false;   } 3. src/tools/ceph.cc 说到这里,ceph.cc还没出场,这里引入一个容易混淆的概念: 比如说我在终端输入ceph mon dump,这个时候发生了什么?这是一个向monitor请求的命令,而且是客户端发起的,是不是会实例化一个monclient,这个命令如何对应到代码中? 答案是,这个命令直观的看,跟monclient没有半毛钱关系(其实后面认证的时候有关系),它的入口是src/tools/ceph.cc(其实0.65版本之后不是了,后面会说明),这段代码的逻辑如下: 4. 总结 src/tools/ceph.cc是命令行的入口,而monclient是一个抽象的概念,在需要跟monitor打交道的时候,而且是处理上面所说的那几种消息的时候才会用到。 另外,从0.65版本后ceph.cc弃用了,你可以file /usr/bin/ceph  或者是/usr/local/bin/ceph,变成了个python脚本,但是处理逻辑差不多

上一篇:判断0-9
下一篇:算法导论笔记第一章

相关文章

相关评论