這篇文章會介紹一下oslo.messaging組件的實現原理。相關的學習網站是：
http://docs.openstack.org/developer/oslo.messaging/index.html
http://docs.openstack.org/developer/nova/devref/rpc.html
http://lynnkong.iteye.com/blog/1699299
https://wiki.openstack.org/wiki/Oslo/Messaging
http://blog.csdn.net/gaoxingnengjisuan/article/details/11468061
另外可以看下這裏，有對AMQP的一些學習。
1.簡介
nova使用了direct, fanout, topic-based這三種exchange（好像也就這三種），而和其它組件（如Object Store）則是通過RestFUL API溝通。雖然現在的nova使用的RabbitMQ或QPID都是AMQP的，但以後可能會引入其它非AMQP的組件。
nova有兩個rpc的方法：rpc.call和rpc.cast。都是基於AMQP實現的。rpc.call是同步的，會等待result返回。rpc.cast是異步的，並且不需要result。
nova還有一個notify的方法。
nova使用了kombu來做RabbitMQ消息的具體底層交互模塊。關於kombu可以看這裏。
由於支持多種MQ，所以這裏的一個框架就是註冊driver，具體調用的時候調用具體driver的特定方法。所以我們分析下rabbitmq這個方法就能知道其具體有哪些對象以及對象
2.RabbitMQ實現的基本對象
首先根據kombu的那個文章，我們知道kombu中有兩個對象producer和consumer，前者向exchange發送message，後者從queue取出message。oslo這裏的rabbitmq實現會的對這些東西做個封裝（這一點很重要，記住oslo就是做了個封裝，要看原理去看kombu的，否則還是不能很好的理解其實現）。
具體的對象直接的關係如下（不怎麼會畫UML。。。）
3.rpc的實現例子分析（call方法）
先來看看用法，我們拿nova-api這裏的例子來說這個。下面的幾行首先是初始化一個用於rpc的client，看下其實現：
[nova/network/rpcapi.py]
|
1
2
3
4
5
6
7
8
|
def __init__(self,
topic=None): super(NetworkAPI, self).__init__() topic = topic or CONF.network_topic target = messaging.Target(topic=topic,
version='1.0') version_cap = self.VERSION_ALIASES.get(CONF.upgrade_levels.network, CONF.upgrade_levels.network) serializer = objects_base.NovaObjectSerializer() self.client = rpc.get_client(target,
version_cap, serializer) |
首先是獲取一個topic，這個topic就是network的consumer監聽的queue的binding-key，從這個圖可以看到：
在這裏，是這個東西：
|
1
2
|
#
The topic network nodes listen on (string value)#network_topic=network |
然後是獲取一個target，我們看下這個target是啥，代碼不長，我就都複製下來了：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
class Target(object): """Identifies
the destination of messages. A
Target encapsulates all the information to identify where a message should
be sent or what messages a server is listening for. Different
subsets of the information encapsulated in a Target object is relevant
to various aspects of the API: creating
a server: topic
and server is required; exchange is optional an
endpoint's target: namespace
and version is optional client
sending a message: topic
is required, all other attributes optional Its
attributes are: :param
exchange: A scope for topics. Leave unspecified to default to the control_exchange
configuration option. :type
exchange: str :param
topic: A name which identifies the set of interfaces exposed by a server.
Multiple servers may listen on a topic and messages will be dispatched
to one of the servers in a round-robin fashion. :type
topic: str :param
namespace: Identifies a particular interface (i.e. set of methods) exposed
by a server. The default interface has no namespace identifier and
is referred to as the null namespace. :type
namespace: str :param
version: Interfaces have a major.minor version number associated with
them. A minor number increment indicates a backwards compatible change
and an incompatible change is indicated by a major number bump. Servers
may implement multiple major versions and clients may require indicate
that their message requires a particular minimum minor version. :type
version: str :param
server: Clients can request that a message be directed to a specific server,
rather than just one of a pool of servers listening on the topic. :type
server: str :param
fanout: Clients may request that a message be directed to all servers
listening on a topic by setting fanout to ``True``, rather than just
one of them. :type
fanout: bool """ def __init__(self,
exchange=None,
topic=None,
namespace=None, version=None,
server=None,
fanout=None): self.exchange = exchange self.topic = topic self.namespace = namespace self.version = version self.server = server self.fanout = fanout def __call__(self, **kwargs): kwargs.setdefault('exchange', self.exchange) kwargs.setdefault('topic', self.topic) kwargs.setdefault('namespace', self.namespace) kwargs.setdefault('version', self.version) kwargs.setdefault('server', self.server) kwargs.setdefault('fanout', self.fanout) return Target(**kwargs) def __eq__(self,
other): return vars(self) == vars(other) def __ne__(self,
other): return not self == other def __repr__(self): attrs = [] for a in ['exchange', 'topic', 'namespace', 'version', 'server', 'fanout']: v = getattr(self,
a) if v: attrs.append((a,
v)) values = ',
'.join(['%s=%s' % i for i in attrs]) return '<Target
' + values + '>' |
從註釋可以看到，target有兩種含義，對於發送者來說，其表示message應該發送到哪裏。對於接受者來說，其表示應該接收何種消息。看下構造函數的幾個方法：
exchange：用於指定exchange，如果沒有指定，那麼就是配置文件裏的control_exchange
topic：就是binding key。如果多個consumer（在註釋裏也叫server）監聽同一個queue，那麼會使用round-robin來發配消息
namespace：某些方法會用到這個，默認是空，具體作用我們後面如果遇到了再看
version：consumer（也就是server）是由版本號的，發送的message的版本要和consumer的版本兼容才行。版本號是major.mirror的形式。major號相同則兼容
server：特定的consumer。相當於direct的轉發了，就是發送者指定特定的consumer，然後由它處理，而不是像topic裏的解釋那樣，用round-robin來分發消息
fanout：表明消息會廣播，忽略topic，只要consumer允許接收fanout消息即可
在我們的例子裏，exchange使用默認的exchange（從這裏我們可以直達，其名字是nova）。topic就是network（配置文件裏都會寫清楚topic的名字是什麼，看下那些XXX_topic的選項就可以了），version就是1.0。所以我們可以知道，現在或之後，broker上應該有一個叫做nova的exchange，並且有至少有一個queue綁定在上面，綁定的key是network。
我們繼續看下面的代碼，這一行就開始獲取一個client了，並且由於知道了target，所以我們也知道這個client的信息會發往何處。
|
1
|
self.client = rpc.get_client(target,
version_cap, serializer) |
|
1
2
3
4
5
6
7
|
def get_client(target,
version_cap=None,
serializer=None): assert TRANSPORT is not None serializer = RequestContextSerializer(serializer) return messaging.RPCClient(TRANSPORT, target, version_cap=version_cap, serializer=serializer) |
TRANSPORT的信息可以看這裏，serializer可以看這裏，總之前者是發送消息的具體driver，後者是個用於格式化消息格式的東西。重點在於RPCClient，我們來看下這個。代碼很長，所以我們慢慢看：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
class RPCClient(object): """A
class for invoking methods on remote servers. The
RPCClient class is responsible for sending method invocations to remote servers
via a messaging transport. A
default target is supplied to the RPCClient constructor, but target attributes
can be overridden for individual method invocations using the prepare()
method. A
method invocation consists of a request context dictionary, a method name and
a dictionary of arguments. A cast() invocation just sends the request and
returns immediately. A call() invocation waits for the server to send a
return value. This
class is intended to be used by wrapping it in another class which provides
methods on the subclass to perform the remote invocation using call()
or cast():: class
TestClient(object): def
__init__(self, transport): target
= messaging.Target(topic='testtopic', version='2.0') self._client
= messaging.RPCClient(transport, target) def
test(self, ctxt, arg): return
self._client.call(ctxt, 'test', arg=arg) An
example of using the prepare() method to override some attributes of the default
target:: def
test(self, ctxt, arg): cctxt
= self._client.prepare(version='2.5') return
cctxt.call(ctxt, 'test', arg=arg) RPCClient
have a number of other properties - for example, timeout and version_cap
- which may make sense to override for some method invocations, so
they too can be passed to prepare():: def
test(self, ctxt, arg): cctxt
= self._client.prepare(timeout=10) return
cctxt.call(ctxt, 'test', arg=arg) However,
this class can be used directly without wrapping it another class. For
example:: transport
= messaging.get_transport(cfg.CONF) target
= messaging.Target(topic='testtopic', version='2.0') client
= messaging.RPCClient(transport, target) client.call(ctxt,
'test', arg=arg) but
this is probably only useful in limited circumstances as a wrapper class
will usually help to make the code much more obvious. """ def __init__(self,
transport, target, timeout=None,
version_cap=None,
serializer=None): """Construct
an RPC client. :param
transport: a messaging transport handle :type
transport: Transport :param
target: the default target for invocations :type
target: Target :param
timeout: an optional default timeout (in seconds) for call()s :type
timeout: int or float :param
version_cap: raise a RPCVersionCapError version exceeds this cap :type
version_cap: str :param
serializer: an optional entity serializer :type
serializer: Serializer """ self.conf = transport.conf self.conf.register_opts(_client_opts) self.transport = transport self.target = target self.timeout = timeout self.version_cap = version_cap self.serializer = serializer or msg_serializer.NoOpSerializer() super(RPCClient, self).__init__() _marker = _CallContext._marker |
小秦我最喜歡貼註釋，所以這次還是老規矩，註釋都貼上來了。註釋寫的很清楚，這個東西用來發消息，發到哪裏呢？發到target。怎麼個發法呢？通過rpc發。rpc是啥呢？這個就百度去啦。
構造函數沒什麼可講的，就是賦值。所以我們繼續看下面的代碼，看下怎麼調用rpc的call方法吧（再複習一下，call是同步的，需要等結果返回）。我們挑一個看看：
|
1
2
3
|
def get_fixed_ip_by_address(self,
ctxt, address): return self.client.call(ctxt, 'get_fixed_ip_by_address', address=address) |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
def call(self,
ctxt, method, **kwargs): """Invoke
a method and wait for a reply. Method
arguments must either be primitive types or types supported by the
client's serializer (if any). Similarly, the request context must be
a dict unless the client's serializer supports serializing another type. The
semantics of how any errors raised by the remote RPC endpoint method
are handled are quite subtle. Firstly,
if the remote exception is contained in one of the modules listed
in the allow_remote_exmods messaging.get_transport() parameter, then
it this exception will be re-raised by call(). However, such locally
re-raised remote exceptions are distinguishable from the same exception
type raised locally because re-raised remote exceptions are modified
such that their class name ends with the '_Remote' suffix so you
may do:: if
ex.__class__.__name__.endswith('_Remote'): #
Some special case for locally re-raised remote exceptions Secondly,
if a remote exception is not from a module listed in the allowed_remote_exmods
list, then a messaging.RemoteError exception is raised
with all details of the remote exception. :param
ctxt: a request context dict :type
ctxt: dict :param
method: the method name :type
method: str :param
kwargs: a dict of method arguments :type
kwargs: dict :raises:
MessagingTimeout, RemoteError """ return self.prepare().call(ctxt,
method, **kwargs) |
註釋說了一大堆，主要是關於異常的。乾的事情很簡單啦，調用prepare生成的對象的call方法，參數中ctxt是restful請求的request的上下文（就把它看成是request好了），method是調用的遠程對象要執行的方法，kwargs是傳遞個method的方法。我們看下prepare是啥：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
def prepare(self,
exchange=_marker,
topic=_marker,
namespace=_marker, version=_marker,
server=_marker,
fanout=_marker, timeout=_marker,
version_cap=_marker): """Prepare
a method invocation context. Use
this method to override client properties for an individual method invocation.
For example:: def
test(self, ctxt, arg): cctxt
= self.prepare(version='2.5') return
cctxt.call(ctxt, 'test', arg=arg) :param
exchange: see Target.exchange :type
exchange: str :param
topic: see Target.topic :type
topic: str :param
namespace: see Target.namespace :type
namespace: str :param
version: requirement the server must support, see Target.version :type
version: str :param
server: send to a specific server, see Target.server :type
server: str :param
fanout: send to all servers on topic, see Target.fanout :type
fanout: bool :param
timeout: an optional default timeout (in seconds) for call()s :type
timeout: int or float :param
version_cap: raise a RPCVersionCapError version exceeds this cap :type
version_cap: str """ return _CallContext._prepare(self, exchange,
topic, namespace, version,
server, fanout, timeout,
version_cap) |
繼續看_CallContext，從註釋我們知道，prepare就是爲了準備一個rpc的上下文：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
@classmethoddef _prepare(cls,
base, exchange=_marker,
topic=_marker,
namespace=_marker, version=_marker,
server=_marker,
fanout=_marker, timeout=_marker,
version_cap=_marker): """Prepare
a method invocation context. See RPCClient.prepare().""" kwargs = dict( exchange=exchange, topic=topic, namespace=namespace, version=version, server=server, fanout=fanout) kwargs = dict([(k,
v) for k,
v in kwargs.items() if v is not cls._marker]) target = base.target(**kwargs) if timeout is cls._marker: timeout = base.timeout if version_cap is cls._marker: version_cap = base.version_cap return _CallContext(base.transport,
target, base.serializer, timeout,
version_cap) |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
class _CallContext(object): _marker = object() def __init__(self,
transport, target, serializer, timeout=None,
version_cap=None): self.conf = transport.conf self.transport = transport self.target = target self.serializer = serializer self.timeout = timeout self.version_cap = version_cap super(_CallContext, self).__init__() |
可以看到，這也不過是對一些對象在合併一下（所以說，context是個很簡單的東西，就是一大堆雜七雜八的大集合）。
會過去看call吧，call會的最終調用這個上下文的call方法，也就是下面的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
def call(self,
ctxt, method, **kwargs): """Invoke
a method and wait for a reply. See RPCClient.call().""" msg = self._make_message(ctxt,
method, kwargs) msg_ctxt = self.serializer.serialize_context(ctxt) timeout = self.timeout if self.timeout is None: timeout = self.conf.rpc_response_timeout if self.version_cap: self._check_version_cap(msg.get('version')) try: result = self.transport._send(self.target,
msg_ctxt, msg, wait_for_reply=True,
timeout=timeout) except driver_base.TransportDriverError
as ex: raise ClientSendError(self.target,
ex) return self.serializer.deserialize_entity(ctxt,
result) |
ok了，我們快要接近call的核心了。一開始的兩個主要是爲了格式化一下消息的格式，然後附加點內容，不是重點。然後是有關於超時的，這個也可以不看。然後會檢查一下version，這個也暫時不看。最後的這個就是我們的send了，這個我們要好好看看：
|
1
2
3
4
5
|
try: result = self.transport._send(self.target,
msg_ctxt, msg, wait_for_reply=True,
timeout=timeout)except driver_base.TransportDriverError
as ex: raise ClientSendError(self.target,
ex) |
transport上面提到過了，所以我們知道它裏邊的driver就是一個消息的具體實現。我們來看看其send方法：
|
1
2
3
4
5
6
7
|
def _send(self,
target, ctxt, message, wait_for_reply=None,
timeout=None): if not target.topic: raise exceptions.InvalidTarget('A
topic is required to send', target) return self._driver.send(target,
ctxt, message, wait_for_reply=wait_for_reply, timeout=timeout) |
通過這裏，我們很容易知道具體的_driver是什麼：
|
1
|
<oslo.messaging._drivers.impl_qpid.QpidDriver
object at 0x2e38a90> |
不過小秦我我們假設用的是rabbitmq，我們來看下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
class RabbitDriver(amqpdriver.AMQPDriverBase): def __init__(self,
conf, url, default_exchange=None, allowed_remote_exmods=[]): conf.register_opts(rabbit_opts) conf.register_opts(rpc_amqp.amqp_opts) connection_pool = rpc_amqp.get_connection_pool(conf,
Connection) super(RabbitDriver, self).__init__(conf,
url, connection_pool, default_exchange, allowed_remote_exmods) def require_features(self,
requeue=True): pass |
也就是說，這裏的send方法其實存在在amqpdriver.AMQPDriverBase中。後者是個很重要的方法，其是所有MQ client的一個父類，提供了公共的接口。我們來看下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
class AMQPDriverBase(base.BaseDriver): def __init__(self,
conf, url, connection_pool, default_exchange=None,
allowed_remote_exmods=[]): super(AMQPDriverBase, self).__init__(conf,
url, default_exchange, allowed_remote_exmods) self._server_params = self._server_params_from_url(self._url) self._default_exchange = default_exchange #
FIXME(markmc): temp hack if self._default_exchange: self.conf.set_override('control_exchange', self._default_exchange) self._connection_pool = connection_pool self._reply_q_lock = threading.Lock() self._reply_q = None self._reply_q_conn = None self._waiter = None |
這裏的初始化現在沒什麼好看的，主要還是賦值。我們看下send吧：
|
1
2
|
def send(self,
target, ctxt, message, wait_for_reply=None,
timeout=None): return self._send(target,
ctxt, message, wait_for_reply, timeout) |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
def _send(self,
target, ctxt, message, wait_for_reply=None,
timeout=None, envelope=True,
notify=False): #
FIXME(markmc): remove this temporary hack class Context(object): def __init__(self,
d): self.d = d def to_dict(self): return self.d context = Context(ctxt) msg = message if wait_for_reply: msg_id = uuid.uuid4().hex msg.update({'_msg_id':
msg_id}) LOG.debug('MSG_ID
is %s' % (msg_id)) msg.update({'_reply_q': self._get_reply_q()}) rpc_amqp._add_unique_id(msg) rpc_amqp.pack_context(msg,
context) if envelope: msg = rpc_common.serialize_msg(msg) if wait_for_reply: self._waiter.listen(msg_id) try: with self._get_connection()
as conn: if notify: conn.notify_send(target.topic,
msg) elif target.fanout: conn.fanout_send(target.topic,
msg) else: topic = target.topic if target.server: topic = '%s.%s' % (target.topic,
target.server) conn.topic_send(topic,
msg, timeout=timeout) if wait_for_reply: result = self._waiter.wait(msg_id,
timeout) if isinstance(result,
Exception): raise result return result finally: if wait_for_reply: self._waiter.unlisten(msg_id) |
終於，小秦我終於看到真真切切的send了！看之前在明確一下，這裏的send會發送一個消息給exchange，然後根據routing key，exchange會轉發給具體的queue，在那個queue上有人在等着拿東西。那個人拿完並處理後會返回結果給我們，所以我們也必須建立一個接收返回消息的queue連接在exchange上，並且這個queue的routing key必須放在message裏告知對方，讓他們知道返回值往哪裏發。具體的可以看這裏。
懂了上面的這些後，就開始看代碼吧：
首先設置msg_id，同時生成一個返回的queue（就是我們上面講的那個接收返回消息的queue）：
|
1
2
3
4
5
|
if wait_for_reply: msg_id = uuid.uuid4().hex msg.update({'_msg_id':
msg_id}) LOG.debug('MSG_ID
is %s' % (msg_id)) msg.update({'_reply_q': self._get_reply_q()}) |
來看看這個reply queue：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
def _get_reply_q(self): with self._reply_q_lock: if self._reply_q is not None: return self._reply_q reply_q = 'reply_' + uuid.uuid4().hex conn = self._get_connection(pooled=False) self._waiter = ReplyWaiter(self.conf,
reply_q, conn, self._allowed_remote_exmods) self._reply_q = reply_q self._reply_q_conn = conn return self._reply_q |
可以看到queue的名字就是reply_加上一個隨機的東東，並且根據上面的代碼，可以知道這個名字鐵定會放在msg裏（msg.update({‘_reply_q’: self._get_reply_q()})）。看下這個waiter吧：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
class ReplyWaiter(object): def __init__(self,
conf, reply_q, conn, allowed_remote_exmods): self.conf = conf self.conn = conn self.reply_q = reply_q self.allowed_remote_exmods = allowed_remote_exmods self.conn_lock = threading.Lock() self.incoming = [] self.msg_id_cache = rpc_amqp._MsgIdCache() self.waiters = ReplyWaiters() conn.declare_direct_consumer(reply_q, self) |
重點是最後一句，這裏聲明瞭一個consumer。我們知道從上面的對象圖知道，有consumer就有它監聽的queue，來看下這個是個什麼consumer（具體的實現在impl_XXX中，小秦我這裏是impl_rabbit）：
|
1
2
3
4
5
6
|
def declare_direct_consumer(self,
topic, callback): """Create
a 'direct' queue. In
nova's use, this is generally a msg_id queue used for responses
for call/multicall """ self.declare_consumer(DirectConsumer,
topic, callback) |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
def declare_consumer(self,
consumer_cls, topic, callback): """Create
a Consumer using the class that was passed in and add
it to our list of consumers """ def _connect_error(exc): log_info = {'topic':
topic, 'err_str': str(exc)} LOG.error(_("Failed
to declare consumer for topic '%(topic)s': " "%(err_str)s") % log_info) def _declare_consumer(): consumer = consumer_cls(self.conf, self.channel,
topic, callback, six.next(self.consumer_num)) self.consumers.append(consumer) return consumer return self.ensure(_connect_error,
_declare_consumer) |
ok啦，我們看到，這裏的reply queue就是一個DirectConsumer。這個DirectConsumer從上面的對象圖中可以知道，就是對kombu的consumer一個封裝（簡單的說建立一個consumer就是建立一個queue，然後過會會在上面不停的監聽罷了（不過這裏我們還不會去監聽））。
好啦，reply queue看好了，可以繼續看_send方法了。現在我們知道的事情是：消息往exchang=nova的exchange發，並且topic=network。同時我建立了一個叫做reply_XXX的隊列，用於接收返回值。繼續看吧：
|
1
2
|
if wait_for_reply: self._waiter.listen(msg_id) |
這裏就是監聽隊列了。msg_id就是監聽的key。
接下來就是發送消息了：
|
1
2
3
4
5
6
7
8
9
10
11
|
try: with self._get_connection()
as conn: if notify: conn.notify_send(target.topic,
msg) elif target.fanout: conn.fanout_send(target.topic,
msg) else: topic = target.topic if target.server: topic = '%s.%s' % (target.topic,
target.server) conn.topic_send(topic,
msg, timeout=timeout) |
在我們這裏就是conn.topic_send(topic, msg, timeout=timeout)了。另外可以看到，如果target明確指定了server，那麼就會發送給特定的server！否則則是通過round-robin算法來分配消息。至於conn.topic_send做的事情就很簡單啦，創建個Publisher然後發送，具體的可以看看博客裏的kombu的那個文章（也就是說，我發消息的時候是先建立接收隊列再發送消息。如果是call的調用，會生成一個Topic Publisher和一個Direct Consumer，同時會生成一個msg_id爲名字的exchange和一個msg_id爲key的queue）。
最後幾行就很簡單了：
|
1
2
3
4
5
6
7
8
|
if wait_for_reply: result = self._waiter.wait(msg_id,
timeout) if isinstance(result,
Exception): raise result return resultfinally: if wait_for_reply: self._waiter.unlisten(msg_id) |
如果需要等返回，那麼我就等。如果返回的是異常，那麼就拋出異常。最後別忘了取消監聽就好。當然啦，如果壓根就不要要等返回值的話，那麼也就不用搞這麼麻煩了。
最後，我們再來看看這裏rpc的callback方法吧。我們知道我們調用了call後，就會在reply queue上監聽，那麼當消息到達後會如何處理呢？我們來看下：通過result = self._waiter.wait(msg_id, timeout)，我們可以得到result，所以wait是我們的切入點：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
def wait(self,
msg_id, timeout): # #
NOTE(markmc): we're waiting for a reply for msg_id to come in for on #
the reply_q, but there may be other threads also waiting for replies #
to other msg_ids # #
Only one thread can be consuming from the queue using this connection #
and we don't want to hold open a connection per thread, so instead we #
have the first thread take responsibility for passing replies not #
intended for itself to the appropriate thread. # final_reply = None while True: if self.conn_lock.acquire(False): #
Ok, we're the thread responsible for polling the connection try: #
Check the queue to see if a previous lock-holding thread #
queued up a reply already while True: reply,
ending, empty = self._check_queue(msg_id) if empty: break if not ending: final_reply = reply else: return final_reply #
Now actually poll the connection while True: reply,
ending = self._poll_connection(msg_id,
timeout) if not ending: final_reply = reply else: return final_reply finally: self.conn_lock.release() #
We've got our reply, tell the other threads to wake up #
so that one of them will take over the responsibility for #
polling the connection self.waiters.wake_all(msg_id) else: #
We're going to wait for the first thread to pass us our reply reply,
ending, trylock = self._poll_queue(msg_id,
timeout) if trylock: #
The first thread got its reply, let's try and take over #
the responsibility for polling continue if not ending: final_reply = reply else: return final_reply |
代碼很長，很大一部分是由於在reply_q上可能有其它線程在等待不同的消息（原因應該是由於不希望每個線程都開一個connection，而是要開大家公用一個connection。這麼說吧，如果我rpclient建立好了，這個時候弄了個多線程，那麼會有多個reply_q，但根據我下面會說道的incoming列表，這些reply_q上的消息都會的放到同一個列表中，所以我們這裏要做區分。這裏的多線程應該是我們的協程，這個在之後的文章裏會寫到這個）。關鍵的代碼是這句：
|
1
|
reply,
ending = self._poll_connection(msg_id,
timeout) |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
def _poll_connection(self,
msg_id, timeout): while True: while self.incoming: message_data = self.incoming.pop(0) incoming_msg_id = message_data.pop('_msg_id', None) if incoming_msg_id == msg_id: return self._process_reply(message_data) self.waiters.put(incoming_msg_id,
message_data) try: self.conn.consume(limit=1,
timeout=timeout) except rpc_common.Timeout: raise messaging.MessagingTimeout('Timed
out waiting for a ' 'reply
to message ID %s' % msg_id) |
實現很簡單，如果拿到了消息，就看下是不是我們要的那個消息（更具msg_id），如果不是，則放回reply_q（其實這裏已經不是reply_q了，具體的看了下面的incoming列表就知道了），如果是，則調用self._process_reply(message_data)進行處理。而後者其實很簡單，看看返回的data裏有沒有錯，沒錯就返回具體的返回值就好了：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
def _process_reply(self,
data): result = None ending = False self.msg_id_cache.check_duplicate_message(data) if data['failure']: failure = data['failure'] result = rpc_common.deserialize_remote_exception( failure, self.allowed_remote_exmods) elif data.get('ending', False): ending = True else: result = data['result'] return result,
ending |
那爲什麼返回的message會的到message_data裏呢？通過之前關於kombu的文章裏寫的東西，我們知道當一個消息來了後consumer會的調用callback，那這個callback是什麼呢？我們來看下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
class ReplyWaiter(object): def __init__(self,
conf, reply_q, conn, allowed_remote_exmods): self.conf = conf self.conn = conn self.reply_q = reply_q self.allowed_remote_exmods = allowed_remote_exmods self.conn_lock = threading.Lock() self.incoming = [] self.msg_id_cache = rpc_amqp._MsgIdCache() self.waiters = ReplyWaiters() conn.declare_direct_consumer(reply_q, self) |
中的在這行代碼：conn.declare_direct_consumer(reply_q, self)，這裏的self的__call__方法就是我們的callback，看下其實現吧：
|
1
2
3
|
def __call__(self,
message): message.acknowledge() self.incoming.append(message) |
現在清楚啦，當消息來了後其實什麼都不做，只是把它放到incoming這個list裏等着之後慢慢拿出來罷了。另外這裏也會發送ack消息給broker。
4.小結一下rpc的call方法
大部分服務，如果其會的監聽消息（也就是扮演rpc的接收端角色），那麼一般都會提供一個rpcapi.py的文件，裏邊有一個XXXAPI的類（如ConsoleAuthAPI，NetworkAPI），這個類代表着一個RPCClient，並且初始化的時候會的把對應的topic賦值給它（ruconsole，network）。這個RPCClient有call和cast方法，調用這個RPCClient的call方法就會往對應的topic發送信息。其它服務如果要和某個服務rpc通信，那麼只需要建立一個XXXAPI的對象即可。
當第一次使用call的時候，由於需要得到返回數據，因此會的建立一個reply_XXX的exchange，還會的建立一個reply_XXX的queue，其topic就是reply_XXX。注意，只有第一次調用call的時候會建立這些東西，此後再次調用call都不會建立了，而是複用這些exchange，queue，通過msg_id來區分接收到的消息是哪個線程發送的。
RPCClient最終是調用AMQPDriverBase中的_send方法去發送消息（RPCClient擁有TRANSPORT這個屬性，後者擁有AMQPDriverBase這個屬性，所以一個NetworkAPI含有一個AMQPDriverBase對象），具體的發送消息的動作由TRANSPORT中的_driver實現（比如RabbitMQ、QPID）。由於RPCClient只有一個（因爲XXXAPI的類只有一個），所以reply_XXX這個queue就是AMQPDriverBase的一個屬性。
AMQPDriverBase有一個屬性是ReplyWaiter（含義是reply的等待者，這個等待者是針對RPCClient這個大的東西來說的，類似於manager），後者有一個屬性是ReplyWaiters（也是reply的等待者，但這個等待的含義只的是等待的message，或者說一個ReplyWaiters就是一個調用了call方法並在等待reply的線程的集合）。
reply_XXX隊列上的Consumer是DirectConsumer，其收到消息後會的把消息放在ReplyWaiter的incoming列表中，同時發送消息的ack確認。
接收消息這個動作是在call方法調用_send後，_send調用ReplyWaiter的wait來實現的。
wait的實現很簡單，首先獲取一個線程鎖，確保某一個時候只有一個線程可以訪問reply_XXX。
如果某個線程獲取了這個鎖：那麼其會的查看ReplyWaiter的incoming列表，在裏邊取出消息，然後比較消息的msg_id是不是我這個線程需要的msg_id，如果不是，那麼就把這個消息放到ReplyWaiters的一個字典中，這個字典的key是msg_id，value就是消息。如果取完了incoming中的消息發現都沒有這個線程需要的，那麼這個這個線程就會調用DirectConsumer的consume方法，參數是(limit=1,timeout=timeout)，含義是等待最多timeout秒，並且只取一個消息。如果超時，那麼就報錯。如果取到了，那麼和上面一樣判斷是不是自己需要的msg，是的話就去做處理，不是的話就放到ReplyWaiters的一個字典中，讓別的沒有取得線程鎖的線程處理。
如果某個線程沒有獲取這個鎖，那麼其會的查看ReplyWaiters的字典，看看自己需要的消息是不是已經有人從incoming中取出來並放到這裏了。如果是那麼就處理，如果不是那麼就等一會然後再去嘗試獲取鎖，做類似的操作。
對於消息的處理其實很簡單，如果有值那麼就返回，如果有錯那麼就報錯。
比如我現在有三個線程，都調用了call方法往network組件發送了一個消息，那麼這三個線程都是共用一個NetworkAPI對象的（因爲線程的建立在這個對象初始化之後才調用），這個NetworkAPI對象就是一個RPCClient，後者有TRANSPORT對象，知道消息發往的目的地是它的TARGET對象，同時TRANSPORT對象有AMQPDriverBase這個對象，後者有ReplyWaiter對象，ReplyWaiter有ReplyWaiters對象。
這三個線程都調用了call方法，只有第一個call方法會的創建一個reply_XXX exchange和一個topic是reply_XXX的queue，並且這三個線程（或者說這個RPCClient上後續所有的RPC調用）都會的使用這個reply_XXX exchange和reply_XXX queue。這三個線程發送的消息分別是msg_01,msg_02,msg_03(所以reply的消息id也應該是msg_01,msg_02,msg_03)。當他們發送完後，都會調用wait方法。由於只有一個線程可以取到鎖，所以這三個線程中有兩個線程會去ReplyWaiters的字典中看看那個取到鎖的線程有沒有把消息取來放到這個字典裏。而那個取到鎖的線程則是去看incoming列表，從中取消息。如果取到的是自己要的消息（比如msg_01），那麼就釋放鎖並處理消息後返回消息中的返回值。如果不是自己需要的消息那麼這個線程會把這個消息（比如msg_02，並不是它想要的msg_01）放到ReplyWaiters的字典中（添加一個條目：msg_01:MSG_DATA），繼續從incoming中取消息。如果incoming中已經沒有消息了，那麼就調用reply_XXX上的consumer的consume方法，從reply_XXX中取消息放到incoming中，然後再去做相同的操作。
。
幾個對象的關係（不是UML。。。瞎畫的。。。）：