1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        阿里-測試開發(fā)面經(jīng)(八)

        共 4175字,需瀏覽 9分鐘

         ·

        2021-05-09 22:18

        點擊藍(lán)字關(guān)注我們,獲取更多面經(jīng)








        消息隊列的特性




        rabbitMQ:

            RabbitMQ是基于Erlang語言編寫的開源消息隊列,通過Erlang的Actor模型實現(xiàn)了數(shù)據(jù)的穩(wěn)定可靠傳輸。

            RabbitMQ遵循AMQP協(xié)議,RabbitMQ的broker由Exchange,Binding,queue組成,其中exchange和binding組成了消息的路由  鍵;

            客戶端Producer通過連接channel和server進(jìn)行通信,Consumer從queue獲取消息進(jìn)行消費(fèi)(長連接,queue有消息會推送到consumer端,consumer循環(huán)從輸入流讀取數(shù)據(jù))。rabbitMQ以broker為中心;有消息的確認(rèn)機(jī)制。

            因為其可擴(kuò)展性,可以通過插件的形式使用STOMP、XMPP、AMQP 1.0,還可以通過插件使用HTTP這種非消息的傳輸協(xié)議。所以,RabbitMQ可以說是適應(yīng)性非常強(qiáng)的一個消息隊列中間件了。

            當(dāng)然,不僅是協(xié)議支持的多,還因為它實現(xiàn)了代理(Broker)架構(gòu),意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點上排隊。此特性使得RabbitMQ易于使用和部署,適宜于很多場景如路由、負(fù)載均衡或消息持久化等,用消息隊列只需幾行代碼即可搞定。但是,這使得它的可擴(kuò)展性差,速度較慢,因為中央節(jié)點增加了延遲,消息封裝后也比較大,如需配置RabbitMQ則需要在目標(biāo)機(jī)器上安裝Erlang環(huán)境。

            rabbitMQ支持miror的queue,主queue失效,miror queue接管。

            rabbitMQ的負(fù)載均衡需要單獨(dú)的load balance來實現(xiàn).

            rabbitMQ在吞吐量方面稍遜于kafka,他們的出發(fā)點不一樣,rabbitMQ支持對消息的可靠的傳遞,支持事務(wù),不支持批量的

            操作;基于存儲的可靠性的要求存儲可以采用內(nèi)存或者硬盤。

            總的來說,RabbitMQ在數(shù)據(jù)一致性、穩(wěn)定性和可靠性方面比較優(yōu)秀,而且直接或間接的支持多種協(xié)議,對多種語言支持良好。但是其性能和吞吐量差強(qiáng)人意,由于Erlang語言本身的限制,二次開發(fā)成本較高。


        kafka:

            Kafka是LinkedIn于2010年12月開發(fā)并開源的一個分布式流平臺,現(xiàn)在是Apache的頂級項目,是一個高性能跨語言分布式

            Publish/Subscribe消息隊列系統(tǒng),以Pull的形式消費(fèi)消息。

            具有以下特性:快速持久化,可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化;高吞吐,在一臺普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率;完全的分布式系統(tǒng),Broker、Producer、Consumer都原生自動支持分布式,自動實現(xiàn)復(fù)雜均衡。因為設(shè)計之初是作為日志流平臺和運(yùn)營消息管道平臺,所以實現(xiàn)了消息順序和海量堆積。

            kafka遵從一般的MQ結(jié)構(gòu),producer,broker,consumer,以consumer為中心,消息的消費(fèi)信息保存的客戶端consumer上,consumer根據(jù)消費(fèi)的點,從broker上批量pull數(shù)據(jù);無消息確認(rèn)機(jī)制。

            kafka具有高的吞吐量,內(nèi)部采用消息的批量處理,zero-copy機(jī)制,數(shù)據(jù)的存儲和獲取是本地磁盤順序批量操作,具有O(1)的復(fù)雜度,消息處理的效率很高。

            kafka的broker支持主備模式。

            kafka采用zookeeper對集群中的broker、consumer進(jìn)行管理,可以注冊topic到zookeeper上;通過zookeeper的協(xié)調(diào)機(jī)制,producer保存對應(yīng)topic的broker信息,可以隨機(jī)或者輪詢發(fā)送到broker上;并且producer可以基于語義指定分片,消息發(fā)送到broker的某分片上。

            支持Hadoop數(shù)據(jù)并行加載,對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng),但又要求實時處理的限制,這是一個可行的解決方案。Kafka通過Hadoop的并行加載機(jī)制來統(tǒng)一了在線和離線的消息處理。

            Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng),除了性能非常好之外,還是一個工作良好的分布式系統(tǒng)。

            

            Kafka自身服務(wù)與消息的生產(chǎn)和消費(fèi)都依賴于Zookeeper,使用Scala語言開發(fā)。因為其消息的消費(fèi)使用客戶端Pull方式,消息可以被多個客戶端消費(fèi),理論上消息會重復(fù),但是不會丟失(除非消息過期)。因此比較常用的場景是作為日志傳輸?shù)南⑵脚_。


        ZeroMQ:

            ZeroMQ號稱是“史上最快的消息隊列”,尤其針對大吞吐量的需求場景,基于c語言開發(fā)的,可以在任何平臺通過任何代碼連接,通過inproc、IPC、TCP、TIPC、多播傳送消息,支持發(fā)布-訂閱、推-拉、共享隊列等模式,高速異步I/O引擎。

            ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復(fù)雜的隊列,但是開發(fā)人員需要自己組合多種技術(shù)框架,技術(shù)上的復(fù)雜度是對這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個獨(dú)特的非中間件的模式,你不需要安裝和運(yùn)行一個消息服務(wù)器或中間件,因為你的應(yīng)用程序?qū)缪萘诉@個服務(wù)角色。你只需要簡單的引用ZeroMQ程序庫,可以使用NuGet安裝,然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。

            但是ZeroMQ僅提供非持久性的隊列,也就是說如果down機(jī),數(shù)據(jù)將會丟失。

            根據(jù)官方的說法,ZeroMQ是一個簡單好用的傳輸層,像框架一樣的可嵌入的socket類庫,使Socket編程更加簡單、簡潔、性      能更高,是專門為高吞吐量/低延遲的場景開發(fā)的。ZeroMQ與其他MQ有著本質(zhì)的區(qū)別,它根本不是消息隊列服務(wù)器,更類似      與一個底層網(wǎng)絡(luò)通訊庫,對原有Socket API進(jìn)行封裝,在使用的使用引入對應(yīng)的jar包即可,可謂是相當(dāng)靈活。

            同時,因為它的簡單靈活,如果我們想作為消息隊列使用的話,需要開發(fā)大量代碼。而且,ZeroMQ不支持消息持久化,其定位并不是安全可靠的消息傳輸,所以還需要自己編碼保證可靠性。簡而言之一句話,ZeroMQ很強(qiáng)大,但是想用好需要自己實現(xiàn)。


        ActiveMQ:

            是Apache下的一個子項目,介于ZeroMQ和RabbitMQ之間。類似于ZeroMQ,它能夠以代理人和點對點的技術(shù)實現(xiàn)隊列,可以部      署于代理模式和P2P模式。同時類似于RabbitMQ,它少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景而且只需付出低消耗。被譽(yù)為消息中間件的“瑞士軍刀”。

            支持OpenWire、Stomp、AMQP v1.0、MQTT v3.1、REST、Ajax、Webservice等多種協(xié)議;完全支持JMS1.1和J2EE 1.4規(guī)      范(事務(wù)、持久化、XA消息);支持持久化到數(shù)據(jù)庫。但是ActiveMQ不夠輕巧,而且對于隊列較多的情況支持不好,據(jù)說還有丟消息的情況。

            目前已經(jīng)有了其下一代消息產(chǎn)品Apollo。

            RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、Php、 Ruby等。  


        rocketMQ:

            RocketMQ是阿里開源的消息中間件,目前在Apache孵化,使用純Java開發(fā),具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點。RocketMQ思路起源于Kafka,但并不是簡單的復(fù)制,它對消息的可靠傳輸及事務(wù)性做了優(yōu)化,目前在阿里集團(tuán)被廣泛應(yīng)用于交易、充值、流計算、消息推送、日志流式處理、binglog分發(fā)等場景,支撐了阿里多次雙十一活動。

            因為是阿里內(nèi)部從實踐到產(chǎn)品的產(chǎn)物,因此里面很多接口、api并不是很普遍適用。其可靠性毋庸置疑,而且與Kafka一脈相(甚至更優(yōu)),性能強(qiáng)勁,支持海量堆積。不過據(jù)說,沒有在mq核心上實現(xiàn)JMS,但是也無傷大雅。  


        總結(jié):

            rabbitMQ穩(wěn)定,可靠,數(shù)據(jù)一致,支持多協(xié)議,有消息確認(rèn),性能一般,基于erlang語言,二次開發(fā)困難.

            kafka高吞吐,高性能,快速持久化,無消息確認(rèn),無消息遺漏,可能會有有重復(fù)消息,依賴于zookeeper,成本高.

            ZeroMQ靈活快速,不支持持久化,需要大量編碼來實現(xiàn)穩(wěn)定可靠.

            ActiveMQ不夠靈活輕巧,對隊列較多情況支持不好.

            rocketMQ性能好,高吞吐,高可用性,支持大規(guī)模分布式.








        更多面經(jīng)





        360-測試開發(fā)面經(jīng)(一)


        百度-測試開發(fā)面經(jīng)(一)


        字節(jié)跳動-測試開發(fā)面經(jīng)(一)


            掃描二維碼

           獲取更多面經(jīng)

          扶搖就業(yè)  


        瀏覽 42
        點贊
        評論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            亚洲一二三四区 | 日韩精品啪啪啪 | 9超碰| 日本性色爽歪歪网 | 青青草久久草 | 国产精品毛片无遮挡高清 | 艳妇臀荡h乳欲伦交换漫画 | 亚洲午夜精品视频 | 99国产欧美 | 亚洲午夜免费视频 |