我的书签
添加书签
移除书签RocketMQ proxy
Apache RocketMQ is a distributed messaging system, which is composed of four types of roles: producer, consumer, name server and broker server. The former two are embedded into user application in form of SDK; whilst the latter are standalone servers.
A message in RocketMQ carries a topic as its destination and optionally one or more tags as application specific labels.
Producers are used to send messages to brokers according to their topics. Similar to many distributed systems, producers need to know how to connect to these serving brokers. To achieve this goal, RocketMQ provides name server clusters for producers to lookup. Namely, when producers attempts to send messages with a new topic, it first tries to lookup the addresses(called route info) of brokers that serve the topic from name servers. Once producers get the route info of the topic, they actively cache them in memory and renew them periodically thereafter. This mechanism, though simple, effectively keeps service availability high without demanding availability of name server service.
Brokers provides messaging service to end users. In addition to various messaging services, they also periodically report health status and route info of topics currently served to name servers.
Major role of the name server is to serve querying of route info for a topic. Additionally, it also purges route info entries once the belonging brokers fail to report their health info for a configured period of time. This ensures clients almost always connect to brokers that are online and ready to serve.
Consumers are used by application to pull message from brokers. They perform similar heartbeats to maintain alive status. RocketMQ brokers support two message-fetch approaches: long-pulling and pop.
Using the first approach, consumers have to implement load-balancing algorithm. The pop approach, in the perspective of consumers, is stateless.
Envoy RocketMQ filter proxies requests and responses between producers/consumer and brokers. Various statistical items are collected to enhance observability.
At present, pop-based message fetching is implemented. Long-pulling will be implemented in the next pull request.
Statistics
Every configured rocketmq proxy filter has statistics rooted at rocketmq.
Name | Type | Description |
|---|---|---|
request | Counter | Total requests |
request_decoding_error | Counter | Total decoding error requests |
request_decoding_success | Counter | Total decoding success requests |
response | Counter | Total responses |
response_decoding_error | Counter | Total decoding error responses |
response_decoding_success | Counter | Total decoding success responses |
response_error | Counter | Total error responses |
response_success | Counter | Total success responses |
heartbeat | Counter | Total heartbeat requests |
unregister | Counter | Total unregister requests |
get_topic_route | Counter | Total getting topic route requests |
send_message_v1 | Counter | Total sending message v1 requests |
send_message_v2 | Counter | Total sending message v2 requests |
pop_message | Counter | Total poping message requests |
ack_message | Counter | Total acking message requests |
get_consumer_list | Counter | Total getting consumer list requests |
maintenance_failure | Counter | Total maintenance failure |
request_active | Gauge | Total active requests |
send_message_v1_active | Gauge | Total active sending message v1 requests |
send_message_v2_active | Gauge | Total active sending message v2 requests |
pop_message_active | Gauge | Total active poping message active requests |
get_topic_route_active | Gauge | Total active geting topic route requests |
send_message_pending | Gauge | Total pending sending message requests |
pop_message_pending | Gauge | Total pending poping message requests |
get_topic_route_pending | Gauge | Total pending geting topic route requests |
total_pending | Gauge | Total pending requests |
request_time_ms | Histogram | Request time in milliseconds |
