一個高性能、輕量級的分佈式內存隊列系統--beanstalk

　　Beanstalk是一個高性能、輕量級的、分佈式的、內存型的消息隊列系統。最初設計的目的是想經過後臺異步執行耗時的任務來下降高容量Web應用系統的頁面訪問延遲。其實Beanstalkd是典型的類Memcached設計，協議和使用方式都是一樣的風格。其基本設計思想很簡單：高性能離不開異步，異步離不開隊列，而內部都是生產者-消費者模式的。

背景介紹：

　　如今市面上有不少消息隊列系統了。經常使用的有ActiveMQ, RabbitMQ,ZeroMA,Kafka,RocketMQ。Redis之父最近又開源了一個Disque。我以前在樂視用的是apache的qpid。可是之因此各個系統都在流行，還要看其側重點。

　　其中ActiveMQ能夠稱之爲傳統型，它們徹底支持JMS和AMQP規範。

 

　　JMS即Java消息服務(Java Message Service)應用程序接口。它是Java平臺上有關面向消息中間件（Message Oriented Middleware,縮寫爲MOM）的技術規範，它便於消息系統中的Java應用程序進行消息交換，而且經過提供標準的產生、發送、接收消息的接口簡化企業應用的開發。(*我這裏說了，JMS是應用程序接口，就是API，API就意味着是和編程語言綁定的)

　　JMS的體系架構由JMS提供者、JMS客戶、JMS生產者、JMS消費者、JMS消息、JMS隊列、JMS主題組成。

　　JMS對象模型包含：鏈接工廠、JMS鏈接、JMS會話、JMS目的、JMS生產者和消費者和JMS消息。其中你們最關心的是JMS消息的兩種模型：點對點(point to point, queue)和發佈/訂閱(publish/subscribe, topic)。這二者之間的區別就是點對點模式是生產者發送一條消息到queue，一個queue能夠有不少消費者，可是一個消息只能被一個消費者接收，當沒有消費者可用時，這個消息會被保存直到有一個可用的消費者，因此queue實現了一個可靠的負載均衡。而發佈訂閱模式是發佈者發送到topic的消息，只有訂閱了topic的訂閱者纔會收到消息。topic實現了發佈和訂閱，當你發佈一個消息，全部訂閱這個topic的服務都能獲得這個消息，因此從1到N個訂閱者都能獲得這個消息的拷貝。

　　

　　AMQP(高級消息隊列協議)，和JMS的區別在於：JMS只是java平臺的方案，AMQP是一個跨語言的協議。因爲跨語言的特色，下降了企業和系統集成的開銷。因此如今的消息隊列系統支持AMQP的多，支持JMS的少。

　　AMQP的特徵是面向消息，隊列化，消息模型（和JMS同樣：點對點和發佈訂閱），可靠性和安全性。它提供了三種消息傳遞保證方式：最多一次，至少一次和精確一次。　　

　　咱們常常在使用消息隊列的時候提到的broker是對實現了AMQP協議的服務端的稱呼。其基本結構以下圖。

 Beanstalk介紹：

　　那下面開始說beanstalk了。首先說beanstalk其實並非JMS規範的，也並不嚴格遵照AMQP協議。有人說Beanstalk之於RabbitMQ，就比如Nginx之於Apache。它更簡單，輕量級，高性能，易使用。可是相比kafka，數據處理能力仍是有差距，因此咱們如今其實在逐漸替代它。但它有些很易用的特殊功能，後面會講到。

　　Beanstalk主要包括4個部分。

　　1> job:一個須要異步處理的任務，須要放在一個tube中。

　　2> tube:一個有名的任務隊列，用來存儲統一類型的job，是producer和consumer操做的對象。

　　3> producer:job的生產者，經過put命令來將一個job放到一個tube中。

　　4> consumer:job的消費者，經過reserve、release、bury、delete命令來獲取job或改變job的狀態。

 

　　剛纔說Beanstalk有一些特殊的好用功能。那就是它支持任務優先級(priority)、延時(delay)、超時重發(time-to-run)和預留(buried)，可以很好的支持分佈式的後臺任務和定時任務處理。這些特性是和beanstalk工做過程密切相關。

　　Beanstalk的一個job的生命週期有READY、RESERVED、DELAYED、BURIED四種。

　　當producer直接put一個job時，job就是READY狀態，等待consumer來處理。若是選擇延遲put，job就先到DELAYED狀態，到指定時間再READY。consumer獲取了READY的job，此狀態就爲RESERVED。這樣其餘consumer不能再操做此job。當consumer完成該job後，能夠選擇delete、release或者bury。

　　delete以後，job不能再獲取。release的job能夠從新遷移或延遲遷移回READY。bury的job能夠被休眠，須要的時候再READY或者delete掉。

Beanstalk使用場景：

　　用做延時隊列：好比能夠用於若是用戶30分鐘內不操做，任務關閉。

　　用做循環隊列：用release命令能夠循環執行任務，好比能夠作負載均衡任務分發。

　　用做兜底機制：好比一個請求有失敗的機率，能夠用Beanstalk不斷重試，設定超時時間，時間內嘗試到成功爲止。

　　用做定時任務：好比能夠用於專門的後臺任務。

　　用做異步操做：這是全部消息隊列都最經常使用的，先將任務仍進去，順序執行。

 

跑題時間：

　　平時其實不愛聊閒天。可是和我家男神一塊兒，就會有以下場景：咱們去青島旅遊，火車站上上電梯，咱們各走一邊，而後相遇了。「咱倆太有緣分了，又遇到你了。」「你去哪裏啊，這麼巧，我也去。」「你家住哪裏啊，這麼巧，我也是。」……額，頓時以爲咱們是最有緣分和最無聊的人，卻樂此不疲。

　　還有更二的：

 

　　

　　除了胖到170斤那幾年，新到一個公司，總會有不少搭訕的，你們都特別熱情。直到我驕傲的介紹我家男神和小鮮肉。額~~，整個世界都清淨了~~