本文作者magiccao、littleorca，來自攜程消息隊(duì)列團(tuán)隊(duì)。目前主要從事消息中間件的開發(fā)與彈性架構(gòu)演進(jìn)工作，同時(shí)對(duì)網(wǎng)絡(luò)/性能優(yōu)化、應(yīng)用監(jiān)控與云原生等領(lǐng)域保持關(guān)注。

一、背景

QMQ延遲消息是以服務(wù)形式獨(dú)立存在的一套不局限于消息廠商實(shí)現(xiàn)的解決方案，其架構(gòu)如下圖所示。

QMQ延遲消息服務(wù)架構(gòu)

延遲消息從生產(chǎn)者投遞至延遲服務(wù)后，堆積在服務(wù)器本地磁盤中。當(dāng)延遲消息調(diào)度時(shí)間過期后，延遲服務(wù)轉(zhuǎn)發(fā)至實(shí)時(shí)Broker供消費(fèi)方消費(fèi)。延遲服務(wù)采用主從架構(gòu)，其中，Zone表示一個(gè)可用區(qū)(一般可以理解成一個(gè)IDC)，為了保證單可用區(qū)故障后，歷史投遞的待調(diào)度消息正常調(diào)度，master和slave會(huì)跨可用區(qū)部署。

1.1 痛點(diǎn)

此架構(gòu)主要存在如下幾點(diǎn)問題：

• 服務(wù)具有狀態(tài)，無法彈性擴(kuò)縮容;
• 主節(jié)點(diǎn)故障后，需要主從切換(自動(dòng)或手動(dòng));
• 缺少一致性協(xié)調(diào)器保障數(shù)據(jù)的一致性。

如果將消息的業(yè)務(wù)層和存儲(chǔ)層分離出來，各自演進(jìn)協(xié)同發(fā)展，各自專注在擅長的領(lǐng)域。這樣，消息業(yè)務(wù)層可以做到無狀態(tài)化，輕松完成容器化改造，具備彈性擴(kuò)縮容能力;存儲(chǔ)層引入分布式文件存儲(chǔ)服務(wù)，由存儲(chǔ)服務(wù)來保證高可用與數(shù)據(jù)一致性。

1.2 分布式文件存儲(chǔ)選型

對(duì)于存儲(chǔ)服務(wù)的選型，除了基本的高可用于數(shù)據(jù)一致性特點(diǎn)外，還有至關(guān)重要的一點(diǎn)：高容錯(cuò)與低運(yùn)維成本特性。分布式系統(tǒng)最大的特點(diǎn)自然是對(duì)部分節(jié)點(diǎn)故障的容忍能力，畢竟任何硬件或軟件故障是不可百分百避免的。因此，高容錯(cuò)與低運(yùn)維成本將成為我們選型中最為看重的。

2016年由雅虎開源貢獻(xiàn)給Apache的Pulsar，因其云原生、低延遲分布式消息隊(duì)列與流式處理平臺(tái)的標(biāo)簽，在開源社區(qū)引發(fā)轟動(dòng)與追捧。在對(duì)其進(jìn)行相關(guān)調(diào)研后，發(fā)現(xiàn)恰好Pulsar也是消息業(yè)務(wù)與存儲(chǔ)分離的架構(gòu)，而存儲(chǔ)層則是另一個(gè)Apache開源基金會(huì)的BookKeeper。

二、BookKeeper

BookKeeper作為一款可伸縮、高容錯(cuò)、低延遲的分布式強(qiáng)一致存儲(chǔ)服務(wù)已被部分公司應(yīng)用于生產(chǎn)環(huán)境部署使用，最佳實(shí)踐案例包括替代HDFS的namenode、Pulsar的消息存儲(chǔ)與消費(fèi)進(jìn)度持久化以及對(duì)象存儲(chǔ)。

2.1 基本架構(gòu)

BookKeeper基本架構(gòu)

• Zookeeper集群用于存儲(chǔ)節(jié)點(diǎn)發(fā)現(xiàn)與元信息存儲(chǔ)，提供強(qiáng)一致性保證;
• Bookie存儲(chǔ)節(jié)點(diǎn)，提供數(shù)據(jù)的存儲(chǔ)服務(wù)。寫入和讀取過程中，Bookie節(jié)點(diǎn)間彼此無須通信。Bookie啟動(dòng)時(shí)將自身注冊(cè)到Zookeeper集群，暴露服務(wù);
• Client屬于胖客戶端類型，負(fù)責(zé)與Zookeeper集群和BookKeeper集群直接通信，且根據(jù)元信息完成多副本的寫入，保證數(shù)據(jù)可重復(fù)讀。

2.2 基本特性

a)基本概念

• Entry：數(shù)據(jù)載體的基本單元
• Ledger：entry集合的抽象，類似文件
• Bookie：ledger集合的抽象，物理存儲(chǔ)節(jié)點(diǎn)
• Ensemble：ledger的bookie集合

b)數(shù)據(jù)讀寫

BookKeeper數(shù)據(jù)讀寫

bookie客戶端通過創(chuàng)建而持有一個(gè)ledger后便可以進(jìn)行entry寫入操作，entry以帶狀方式分布在enemble的bookie中。entry在客戶端進(jìn)行編號(hào)，每條entry會(huì)根據(jù)設(shè)置的副本數(shù)(Qw)要求判定寫入成功與否;

bookie客戶端通過打開一個(gè)已創(chuàng)建的ledger進(jìn)行entry讀取操作，entry的讀取順序與寫入保持一致，默認(rèn)從第一個(gè)副本中讀取，讀取失敗后順序從下一個(gè)副本重試。

c)數(shù)據(jù)一致性

持有可寫ledger的bookie客戶端稱為Writer，通過分布式鎖機(jī)制確保一個(gè)ledger全局只有一個(gè)Writer，Writer的唯一性保證了數(shù)據(jù)寫入一致性。Writer內(nèi)存中維護(hù)一個(gè)LAC(Last Add Confirmed)，當(dāng)滿足Qw要求后，更新LAC。LAC隨下一次請(qǐng)求或定時(shí)持久化在bookie副本中，當(dāng)ledger關(guān)閉時(shí)，持久化在Metadata Store(zookeeper或etcd)中;

持有可讀ledger的bookie客戶端稱為Reader，一個(gè)ledger可以有任意多個(gè)Reader。LAC的強(qiáng)一致性保證了不同Reader看到統(tǒng)一的數(shù)據(jù)視圖，亦可重復(fù)讀，從而保證了數(shù)據(jù)讀取一致性。

d)容錯(cuò)性

典型故障場(chǎng)景：Writer crash或restart、Bookie crash。

Writer故障，ledger可能未關(guān)閉，導(dǎo)致LAC未知。通過ledger recover機(jī)制，關(guān)閉ledger，修復(fù)LAC;

Bookie故障，entry寫入失敗。通過ensemble replace機(jī)制，更新一條新的entry路由信息到Metadata Store中，保障了新數(shù)據(jù)能及時(shí)成功寫入。歷史數(shù)據(jù)，通過bookie recover機(jī)制，滿足Qw副本要求，夯實(shí)了歷史數(shù)據(jù)讀取的可靠性。至于副本所在的所有bookie節(jié)點(diǎn)全部故障場(chǎng)景，只能等待修復(fù)。

e)負(fù)載均衡

新擴(kuò)容進(jìn)集群的bookie，當(dāng)創(chuàng)建新的ledger時(shí)，便自動(dòng)均衡流量。

2.3 同城多中心容災(zāi)

上海區(qū)域(region)存在多個(gè)可用區(qū)(az，available zone)，各可用兩兩間網(wǎng)絡(luò)延遲低于2ms，此種網(wǎng)絡(luò)架構(gòu)下，多副本分散在不同的az間是一個(gè)可接受的高可用方案。BookKeeper基于Zone感知的ensemble替換策略便是應(yīng)對(duì)此種場(chǎng)景的解決方案。

基于Zone感知策略的同城多中心容災(zāi)

開啟Zone感知策略有兩個(gè)限制條件：a)E % Qw == 0;b)Qw > minNumOfZones。其中E表示ensemble大小，Qw表示副本數(shù)，minNumOfZones表示ensemble中的最小zone數(shù)目。

譬如下面的例子：

minNumOfZones = 2
desiredNumZones = 3
E = 6
Qw = 3
[z1, z2, z3, z1, z2, z3]

故障前，每條數(shù)據(jù)具有三副本，且分布在三個(gè)可用區(qū)中;當(dāng)z1故障后，將以滿足minNumOfZones限制生成新的ensemble：[z1, z2, z3, z1, z2, z3] -> [z3, z2, z3, z3, z2, z3]。顯然對(duì)于三副本的每條數(shù)據(jù)仍將分布在兩個(gè)可用區(qū)中，仍能容忍一個(gè)可用區(qū)故障。

DNSResolver

客戶端在挑選bookie組成ensemble時(shí)，需要通過ip反解出對(duì)應(yīng)的zone信息，需要用戶實(shí)現(xiàn)解析器。考慮到zone與zone間網(wǎng)段是認(rèn)為規(guī)劃且不重合的，因此，我們落地時(shí)，簡單的實(shí)現(xiàn)了一個(gè)可動(dòng)態(tài)配置生效的子網(wǎng)解析器。示例給出的是ip精確匹配的實(shí)現(xiàn)方式。

public class ConfigurableDNSToSwitchMapping extends AbstractDNSToSwitchMapping {

    private final Map<String, String> mappings = Maps.newHashMap();

    public ConfigurableDNSToSwitchMapping() {
        super();
        mappings.put("192.168.0.1", "/z1/192.168.0.1"); // /zone/upgrade domain
        mappings.put("192.168.1.1", "/z2/192.168.1.1");
        mappings.put("192.168.2.1", "/z3/192.168.2.1");
    }

    @Override
    public boolean useHostName() {
        return false;
    }

    @Override
    public List<String> resolve(List<String> names) {
        List<String> rNames = Lists.newArrayList();
        names.forEach(name -> {
            String rName = mappings.getOrDefault(name, "/default-zone/default-upgradedomain");
            rNames.add(rName);
        });
        return rNames;
    }
}

可配置化DNS解析器示例

數(shù)據(jù)副本分布在單zone

當(dāng)某些原因(譬如可用區(qū)故障演練)導(dǎo)致只有一個(gè)可用區(qū)可用時(shí)，新寫入的數(shù)據(jù)的全部副本都將落在單可用區(qū)，當(dāng)故障可用區(qū)恢復(fù)后，仍然有部分歷史數(shù)據(jù)只存在于單可用區(qū)，不滿足多可用區(qū)容災(zāi)的高可用需求。

AutoRecovery機(jī)制中有一個(gè)PlacementPolicy檢測(cè)機(jī)制，但缺少恢復(fù)機(jī)制。于是我們打了個(gè)patch，支持動(dòng)態(tài)機(jī)制開啟和關(guān)閉此功能。這樣，當(dāng)可用區(qū)故障恢復(fù)后可以自動(dòng)發(fā)現(xiàn)和修復(fù)數(shù)據(jù)全部副本分布在單可用區(qū)從而影響數(shù)據(jù)可用性的問題。

三、彈性架構(gòu)落地

引入BookKeeper后，延遲消息服務(wù)的架構(gòu)相對(duì)漂亮不少。消息業(yè)務(wù)層面和存儲(chǔ)層面完全分離，延遲消息服務(wù)本身無狀態(tài)化，可以輕易伸縮。當(dāng)可用區(qū)故障后，不再需要主從切換。

延遲消息服務(wù)新架構(gòu)

3.1 無狀態(tài)化改造

存儲(chǔ)層分離出去后，業(yè)務(wù)層實(shí)現(xiàn)無狀態(tài)化成為可能。要達(dá)成這一目標(biāo)，還需解決一些問題。我們先看看BookKeeper使用上的一些約束：

• BookKeeper不支持共享寫入的，也即業(yè)務(wù)層多個(gè)節(jié)點(diǎn)如果都寫數(shù)據(jù)，則各自寫的必然是不同的ledger;
• 雖然BookKeeper允許多讀，但多個(gè)應(yīng)用節(jié)點(diǎn)各自讀取的話，進(jìn)度是相互獨(dú)立的，應(yīng)用必須自行解決進(jìn)度協(xié)調(diào)問題。

上述兩個(gè)主要問題，決定我們實(shí)現(xiàn)無狀態(tài)和彈性擴(kuò)縮容時(shí)，必需自行解決讀寫資源分配的問題。為此，我們引入了任務(wù)協(xié)調(diào)器。

我們首先將存儲(chǔ)資源進(jìn)行分片管理，每個(gè)分片上都支持讀寫操作，但同一時(shí)刻只能有一個(gè)業(yè)務(wù)層節(jié)點(diǎn)來讀寫。如果我們把分片看作資源，把業(yè)務(wù)層節(jié)點(diǎn)看作工作者，那么任務(wù)協(xié)調(diào)器的主要職責(zé)為：

• 在盡可能平均的前提下以粘滯優(yōu)先的方式把資源分配給工作者;
• 監(jiān)視資源和工作者的變化，如有增減，重新執(zhí)行職責(zé)1;
• 在資源不夠用時(shí)，根據(jù)具體策略配置，添加初始化新的資源。

由于是分布式環(huán)境，協(xié)調(diào)器自身完成上述職責(zé)時(shí)需要保證分布式一致性，當(dāng)然還要滿足可用性要求。我們選擇了基于ZooKeeper進(jìn)行選主的一主多從式架構(gòu)。

如圖所示，協(xié)調(diào)器對(duì)等部署在業(yè)務(wù)層應(yīng)用節(jié)點(diǎn)中。運(yùn)行時(shí)，協(xié)調(diào)器通過基于ZooKeeper的leader競選機(jī)制決出leader節(jié)點(diǎn)，并由leader節(jié)點(diǎn)負(fù)責(zé)前述任務(wù)分配工作。

協(xié)調(diào)器選舉的實(shí)現(xiàn)參考ZooKeeper官方文檔，這里不再贅述。

3.2 持久化數(shù)據(jù)

原有架構(gòu)將延遲消息根據(jù)調(diào)度時(shí)間按每10分鐘桶存儲(chǔ)在本地，時(shí)間臨近的桶加載到內(nèi)存中，使用HashedWheelTimer來調(diào)度。該設(shè)計(jì)存在兩個(gè)弊端：

• 分桶較多(我們支持2年范圍的延遲，理論分桶數(shù)量達(dá)10萬多);
• 單個(gè)桶的數(shù)據(jù)(10分鐘)如不能全部加載到內(nèi)存，則由于桶內(nèi)未按調(diào)度時(shí)間排序，可能出現(xiàn)未加載的部分包含了調(diào)度時(shí)間較早的數(shù)據(jù)，等它被加載時(shí)已經(jīng)滯后了。

弊端1的話，單機(jī)本地10萬+文件還不算多大問題，但改造后這些桶信息以元信息的方式存儲(chǔ)在ZooKeeper上，我們的實(shí)現(xiàn)方案決定了每個(gè)桶至少占用3個(gè)ZooKeeper節(jié)點(diǎn)。假設(shè)我們要部署5個(gè)集群，平均每個(gè)集群有10個(gè)分片，每個(gè)分片有10萬個(gè)桶，那使用的ZooKeeper節(jié)點(diǎn)數(shù)量就是1500萬起，這個(gè)量級(jí)是ZooKeeper難以承受的。

弊端2則無論新老架構(gòu)，都是個(gè)潛在問題。一旦某個(gè)10分鐘消息量多一些，就可能導(dǎo)致消息延遲。往內(nèi)存加載時(shí)，應(yīng)該有更細(xì)的顆粒度才好。

基于以上問題分析，我們參考多級(jí)時(shí)間輪調(diào)度的思路，略加變化，設(shè)計(jì)了一套基于滑動(dòng)時(shí)間分桶的多級(jí)調(diào)度方案。

如上表所示，最大的桶是1周，其次是1天，1小時(shí)，1分鐘。每個(gè)級(jí)別覆蓋不同的時(shí)間范圍，組合起來覆蓋2年的時(shí)間范圍理論上只需286個(gè)桶，相比原來的10萬多個(gè)桶有了質(zhì)的縮減。

同時(shí)，只有L0m這一級(jí)調(diào)度器需要加載數(shù)據(jù)到HashedWheelTimer，故而加載粒度細(xì)化到了1分鐘，大大減少了因不能完整加載一個(gè)桶而導(dǎo)致的調(diào)度延遲。

多級(jí)調(diào)度器以類似串聯(lián)的方式協(xié)同工作。

每一級(jí)調(diào)度器收到寫入請(qǐng)求時(shí)，首先嘗試委托給其上級(jí)(顆粒度更大)調(diào)度器處理。如果上級(jí)接受，則只需將上級(jí)的處理結(jié)果向下返回;如果上級(jí)不接受，再判斷是否歸屬本級(jí)，是的話寫入桶中，否則打回給下級(jí)。

每一級(jí)調(diào)度器都會(huì)將時(shí)間臨近的桶打開并發(fā)送其中的數(shù)據(jù)到下一級(jí)調(diào)度器。比如L1h發(fā)現(xiàn)最小的桶到了預(yù)加載時(shí)間，則把該桶的數(shù)據(jù)讀出并發(fā)送給L0m調(diào)度器，最終該小時(shí)的數(shù)據(jù)被轉(zhuǎn)移到L0m并展開為(最多)60個(gè)分鐘級(jí)的桶。

四、未來規(guī)劃

目前bookie集群部署在物理機(jī)上，集群新建、擴(kuò)縮容相對(duì)比較麻煩，未來將考慮融入k8s體系;bookie的治理與平臺(tái)化也是需要考慮的;我們目前只具備同城多中心容災(zāi)能力，跨region容災(zāi)以及公/私混合云容災(zāi)等高可用架構(gòu)也需要進(jìn)一步補(bǔ)強(qiáng)。