在Node中使用RabbitMQ和Redis

EventEmitter本質上是一個觀察者模式的實現。這種模式是一種可以幫助擴展Node在多個進程或者網路中運行的模式。接下來的技巧介紹了一些由Node社區創建更受歡迎的替代方案。EventEmitter有非常好的API，但有時一個問題需要一個不同的解決方案。讓我們來探索一些其他方案來替代EventEmitter。正在嘗試解決一個EventEmitter不能很好處理的問題？這取決於你試圖解決的問題的確切性質，有幾種EventEmitter的替代方案：發布/訂閱、AMQP和js-signals，是Node一些很好支持的流行的替代品。

該EventEmitter類是觀察者模式的實現。一個類似的模式是發布/訂閱，發布者在這裡發送消息而不需要知道訂閱者具體是如何實現的。發布/訂閱模式在需要水平擴展的情況下非常有用。如果你需要在多個伺服器上運行多個Node進程，像AMQP和MQ這樣的技術可以幫助實現這一點。它們都專門設計來解決這一類問題，假如你已經使用Redis，那可能沒有像Redis的publish/subscribe那樣方便。 如果你需要水平擴展一個分布式的集群，那麼一個AMQP比如RabbitMQ將非常好用。rabbitmq-nodejs-client模塊有一個publish/subscribe的API。下面的例子顯示了一個使用RabbitMQ的簡單例子。

當收到消息時候列印消息。MQ在Node社區中更受歡迎。Justin Tulloss和TJ Holowaychuk的zeromq.node模塊是一個比較受歡迎的實現。下面的例子顯示這個API是多麼簡單

假如你已經在node中使用Redis了，那麼值得嘗試一下它的pub/sub API。下面展示了使用Node redis客戶端的例子。

當使用Redis模塊時候，確保關閉客戶端連接。最後，如果publish/subscribe不是你要找的，那麼你可能想看看js-signal。該模塊是一個消息系統，不使用字元串作為信號名稱、派遣或監聽那些尚不存在的事件，會引發錯誤。顯示了js-signal如何發送和接收消息。注意signals是一個對象的屬性，而不是字元串，那些監聽器可接收任意數量的參數。

在已啟動的信號量上綁定一個監聽；使用兩個參數分發信號。js-signals提供了一種使用屬性作為信號名稱的方法，但分發事件到沒有註冊的監聽器會引發異常。這種方法更像強類型的事件，和其他大多數的pub/sub實現有著很大的不同。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！