支付寶系統(tǒng)架構(gòu)概況

典型處理默認(rèn)

資金處理平臺(tái)

財(cái)務(wù)會(huì)計(jì)

支付清算

核算中心

交易

柔性事務(wù)

支付寶的開源分布式消息中間件--Metamorphosis(MetaQ)

Metamorphosis (MetaQ) 是一個(gè)高性能、高可用、可擴(kuò)展的分布式消息中間件，類似于LinkedIn的Kafka，具有消息存儲(chǔ)順序?qū)?、吞吐量大和支持本地和XA事務(wù)等特性，適用于大吞吐量、順序消息、廣播和日志數(shù)據(jù)傳輸?shù)葓鼍埃谔詫毢椭Ц秾氂兄鴱V泛的應(yīng)用，現(xiàn)已開源。

Metamorphosis是淘寶開源的一個(gè)Java消息中間件。關(guān)于消息中間件，你應(yīng)該聽說過JMS規(guī)范，以及一些開源實(shí)現(xiàn)，如ActiveMQ和HornetQ等。Metamorphosis也是其中之一。

Metamorphosis的起源是我從對(duì)linkedin的開源MQ--現(xiàn)在轉(zhuǎn)移到apache的kafka的學(xué)習(xí)開始的，這是一個(gè)設(shè)計(jì)很獨(dú)特的MQ系統(tǒng)，它采用pull機(jī)制，而不是一般MQ的push模型，它大量利用了zookeeper做服務(wù)發(fā)現(xiàn)和offset存儲(chǔ)，它的設(shè)計(jì)理念我非常欣賞并贊同，強(qiáng)烈建議你閱讀一下它的設(shè)計(jì)文檔，總體上說metamorphosis的設(shè)計(jì)跟它是完全一致的。但是為什么還需要meta呢？

簡單概括下我重新寫出meta的原因：

• Kafka是scala寫，我對(duì)scala不熟悉，并且kafka整個(gè)社區(qū)的發(fā)展太緩慢了。

• 有一些功能是kakfa沒有實(shí)現(xiàn)，但是我們卻需要：事務(wù)、多種offset存儲(chǔ)、高可用方案(HA)等

Meta相對(duì)于kafka特有的一些功能：

• 文本協(xié)議設(shè)計(jì)，非常透明，支持類似memcached stats的協(xié)議來監(jiān)控broker

• 純Java實(shí)現(xiàn)，從通訊到存儲(chǔ)，從client到server都是重新實(shí)現(xiàn)。

• 提供事務(wù)支持，包括本地事務(wù)和XA分布式事務(wù)

• 支持HA復(fù)制，包括異步復(fù)制和同步復(fù)制，保證消息的可靠性

• 支持異步發(fā)送消息

• 消費(fèi)消息失敗，支持本地恢復(fù)

• 多種offset存儲(chǔ)支持，數(shù)據(jù)庫、磁盤、zookeeper，可自定義實(shí)現(xiàn)

• 支持group commit，提升數(shù)據(jù)可靠性和吞吐量。

• 支持消息廣播模式

• 一系列配套項(xiàng)目：python客戶端、twitter storm的spout、tail4j等。

因此meta相比于kafka的提升是巨大的。meta在淘寶和支付寶都得到了廣泛應(yīng)用，現(xiàn)在每天支付寶每天經(jīng)由meta路由的消息達(dá)到120億，淘寶也有每天也有上億的消息量。

Meta適合的應(yīng)用：

• 日志傳輸，高吞吐量的日志傳輸本來就是kafka的強(qiáng)項(xiàng)

• 消息廣播功能，如廣播緩存配置失效。

• 數(shù)據(jù)的順序同步功能，如mysql binlog復(fù)制

• 分布式環(huán)境下（broker,producer,consumer都為集群）的消息路由，對(duì)順序和可靠性有極高要求的場景。

• 作為一般MQ來使用的其他功能

總體結(jié)構(gòu)：

內(nèi)部結(jié)構(gòu)：

來源【fd2012】

支付圈今天推薦一下我們的備用號(hào)，你可以點(diǎn)擊添加，更多信息盡在關(guān)注！