CMessaging的研究鄒論

摘 要：在實(shí)際的軟件開發(fā)過程中，經(jīng)常會(huì)碰到如下場(chǎng)景：某個(gè)模塊負(fù)責(zé)產(chǎn)生數(shù)據(jù)，這些數(shù)據(jù)由另一個(gè)模塊來負(fù)責(zé)處理（此處的模塊是廣義的，可以是類、函數(shù)、線程、進(jìn)程等）。產(chǎn)生數(shù)據(jù)的模塊，就形象地稱為生產(chǎn)者；而處理數(shù)據(jù)的模塊，就稱為消費(fèi)者。單單抽象出生產(chǎn)者和消費(fèi)者，還夠不上是生產(chǎn)者/消費(fèi)者模式。該模式還需要有一個(gè)緩沖區(qū)處于生產(chǎn)者和消費(fèi)者之間，作為一個(gè)中介。生產(chǎn)者把數(shù)據(jù)放入緩沖區(qū)，而消費(fèi)者從緩沖區(qū)取出數(shù)據(jù)。

關(guān)鍵詞：CMessaging；冪等性；HTTP

中圖分類號(hào)：TP393.06 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1674-7712 （2014） 18-0000-01

一、CMessaging的作用及使用場(chǎng)景

CMessaging是一個(gè)異步消息服務(wù)框架，通過對(duì)該服務(wù)框架的應(yīng)用，能夠起到讓消息的生產(chǎn)者和消費(fèi)者完全解耦，雙發(fā)無須了解彼此的細(xì)節(jié)，只要了解消息格式即可。CMessaging的架構(gòu)大量使用I/O異步編程，其目的是為了最大化增加服務(wù)器處理消息的能力以及減少不必要的服務(wù)器性能損耗。CMessaging的消息管道基于Database設(shè)計(jì)，雖然從性能和消息處理吞吐量上和第三方比較要有所遜色，但是優(yōu)點(diǎn)也比較明顯，可以充分利用Database的可靠性，可用性，事務(wù)，優(yōu)化的資源競(jìng)爭(zhēng)等特性來大幅度降低編程復(fù)雜度。CMessaging只保證消息的至少一次（At Least Once）語義，因此在使用的時(shí)候應(yīng)該考慮場(chǎng)景是否合適。

CMessaging主要適用于如下場(chǎng)景：調(diào)用者不關(guān)心發(fā)送結(jié)果；希望發(fā)送消息對(duì)業(yè)務(wù)流程不產(chǎn)生影響；需要長(zhǎng)時(shí)間處理的請(qǐng)求；消息的發(fā)布/訂閱。

CMessaging不建議使用場(chǎng)景：非冪等服務(wù)，消息必須滿足只能一次（Exactly once）；對(duì)順序非常敏感，且客戶端本身無法處理消息時(shí)序；對(duì)消息的時(shí)效性非常敏感。

二、CMessaging的作用及使用場(chǎng)景

為什么需要冪等性呢？我們先從一個(gè)例子說起，假設(shè)有一個(gè)從賬戶取錢的遠(yuǎn)程API（可以是HTTP的，也可以不是），我們暫時(shí)用類函數(shù)的方式記為：bool withdraw（account_id，amount）withdraw的語義是從account_id對(duì)應(yīng)的賬戶中扣除amount數(shù)額的錢；如果扣除成功則返回true，賬戶余額減少amount；如果扣除失敗則返回1，賬戶余額不變。值得注意的是：和本地環(huán)境相比，我們不能輕易假設(shè)分布式環(huán)境的可靠性。一種典型的情況是withdraw請(qǐng)求已經(jīng)被服務(wù)器端正確處理，但服務(wù)器端的返回結(jié)果由于網(wǎng)絡(luò)等原因被掉丟了，導(dǎo)致客戶端無法得知處理結(jié)果。如果是在網(wǎng)頁上，一些不恰當(dāng)?shù)脑O(shè)計(jì)可能會(huì)使用戶認(rèn)為上一次操作失敗了，然后刷新頁面，這就導(dǎo)致了withdraw被調(diào)用兩次，賬戶也被多扣了一次錢。

這個(gè)問題的解決方案一是采用分布式事務(wù)，通過引入支持分布式事務(wù)的中間件來保證withdraw功能的事務(wù)性。分布式事務(wù)的優(yōu)點(diǎn)是對(duì)于調(diào)用者很簡(jiǎn)單，復(fù)雜性都交給了中間件來管理。缺點(diǎn)則是一方面架構(gòu)太重量級(jí)，容易被綁在特定的中間件上，不利于異構(gòu)系統(tǒng)的集成；另一方面分布式事務(wù)雖然能保證事務(wù)的ACID性質(zhì)，而但卻無法提供性能和可用性的保證。

另一種更輕量級(jí)的解決方案是冪等設(shè)計(jì)。我們可以通過一些技巧把withdraw變成冪等的，比如：

int create_ticket（）

bool idempotent_withdraw（ticket_id，account_id，amount）

create_ticket的語義是獲取一個(gè)服務(wù)器端生成的唯一的處理號(hào)ticket_id，它將用于標(biāo)識(shí)后續(xù)的操作。idempotent_withdraw和withdraw的區(qū)別在于關(guān)聯(lián)了一個(gè)ticket_id，一個(gè)ticket_id表示的操作至多只會(huì)被處理一次，每次調(diào)用都將返回第一次調(diào)用時(shí)的處理結(jié)果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次調(diào)用。

基于冪等性的解決方案中一個(gè)完整的取錢流程被分解成了兩個(gè)步驟：1.調(diào)用create_ticket（）獲取ticket_id；2.調(diào)用idempotent_withdraw（ticket_id，account_id，amount）。雖然create_ticket不是冪等的，但在這種設(shè)計(jì)下，它對(duì)系統(tǒng)狀態(tài)的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由于網(wǎng)絡(luò)等原因失敗或超時(shí)，客戶端都可以重試，直到獲得結(jié)果。

和分布式事務(wù)相比，冪等設(shè)計(jì)的優(yōu)勢(shì)在于它的輕量級(jí)，容易適應(yīng)異構(gòu)環(huán)境，以及性能和可用性方面。在某些性能要求比較高的應(yīng)用，冪等設(shè)計(jì)往往是唯一的選擇。

三、深入冪等性

冪等性是系統(tǒng)的接口對(duì)外一種承諾（而不是實(shí)現(xiàn)），承諾只要調(diào)用接口成功，外部多次調(diào)用對(duì)系統(tǒng)的影響是一致的。聲明為冪等的接口會(huì)認(rèn)為外部調(diào)用失敗是常態(tài)，并且失敗之后必然會(huì)有重試。

HTTP協(xié)議本身是一種面向資源的應(yīng)用層協(xié)議，但對(duì)HTTP協(xié)議的使用實(shí)際上存在著兩種不同

的方式：一種是RESTful的，它把HTTP當(dāng)成應(yīng)用層協(xié)議，比較忠實(shí)地遵守了HTTP協(xié)議的各種規(guī)定；另一種是SOA的，它并沒有完全把HTTP當(dāng)成應(yīng)用層協(xié)議，而是把HTTP協(xié)議作為了傳輸層協(xié)議，然后在HTTP之上建立了自己的應(yīng)用層協(xié)議。本文所討論的HTTP冪等性主要針對(duì)RESTful風(fēng)格的，不過正如上一節(jié)所看到的那樣，冪等性并不屬于特定的協(xié)議，它是分布式系統(tǒng)的一種特性；所以，不論是SOA還是RESTful的Web API設(shè)計(jì)都應(yīng)該考慮冪等性。

我認(rèn)為冪等性是有作用范圍的，我們可以將整個(gè)對(duì)象聲明成冪等性（也就是說承諾所有對(duì)外公布的接口都是冪等性性的），也可以只將對(duì)象的部分接口（這種情況一般是只想讓外部影響對(duì)象的部分屬性）聲明成冪等性。

四、結(jié)束語

CMessage起到了解耦的作用。假設(shè)生產(chǎn)者和消費(fèi)者分別是兩個(gè)類。如果讓生產(chǎn)者直接調(diào)用消費(fèi)者的某個(gè)方法，那么生產(chǎn)者對(duì)于消費(fèi)者就會(huì)產(chǎn)生依賴（也就是耦合）。將來如果消費(fèi)者的代碼發(fā)生變化，可能會(huì)影響到生產(chǎn)者。而如果兩者都依賴于某個(gè)緩沖區(qū)，兩者之間不直接依賴，耦合也就相應(yīng)降低了。

參考文獻(xiàn)：

[1]弗里曼.Head First[J].設(shè)計(jì)模式，2012.

[2]David.HTTP[J].指南，2011（01）.

[作者簡(jiǎn)介]胡文琪（1987-），男，上海人，本科在讀，研究方向：軟件架構(gòu)與設(shè)計(jì)模式、asp.net、大數(shù)據(jù)。