# 簡介 beanstalkd ，一個輕量級、分布式的內存隊列系統。 # 概念 - Tube 這是一個「管道」的概念，「管道」就是指「隊列」，一個隊列系統，并非只能有一個「隊列」，就像我們一個數據庫系統，不止一個庫一樣。 不同的「管道」，代表著不同的內容類型，比如，舉前面下單功能中的實際例子，我們發短信、發郵件兩種類型的任務，就需要有兩個分別處理他們的消費者，自然，這條任務（消息）也就需要存儲在兩個「管道」中。 > 但是，這里的隊列一詞，我們不能把它與數據結構「隊列」畫上等號，這里的隊列，類似于分類，用于區分 Job 的種類，而 beanstalkd 在底層根據 Job 狀態進行存儲時所用的「隊列」才是數據結構上的隊列。 這里，你可以把 Tube 想象成一個書架，專門用于存放某一類書本。而書架內部，又被分為好幾個區域，分別用于存放看過和沒看過的書。 其中，書架就是 Tube ，區域就是數據結構之隊列。 - Job 「任務」的概念，就是指「消息」，它指存儲在隊列中的每一個具體成員，在前面的 demo 中，我們有設置一個 Job class ，那就是一個 Job 在代碼中的呈現形式。 > 生產者生成 Job ，將它放入特定的 Tube 中，再由消費者監聽（訂閱）特定的 Tube ，從中接收 Job 。 # 特性 > 在介紹 beanstalkd 的特性之前，我們應確保，已經讀 Tube 和 Job 有了比較深刻的認知。 beastalkd 擁有以下特性： - 優先級（priority） beanstalkd 支持設置 Job 的優先級。 我們知道消息隊列會根據 Job 被放入的先后順序，將 Job 發送給消費者，它們就像是一群排著隊買票的人，誰先進去，誰先買票。 但是，beanstalkd 支持優先級的特性，賦予了 Job 插隊的能力。 設定 Job 優先級之后，可以讓該 Job 在一堆 Job 中，更優先被消費者接收。（當然，如果你設置的優先級更低，則更晚被接收） > 可以聯想到實際場景：vip 和 普通用戶，我們可以為 vip 用戶設置更高的優先級，讓它優先被消費者消費。 - 延遲（delay） beanstalkd 支持為 Job 設置延遲接收的屬性，通常而言，生產者往消息隊列中放入一條消息，只要有消費者空閑，就會被立馬接收。 但 beanstalkd 的延遲特性，可以讓 Job 在指定時間才被接收。 > 比如，你希望用戶下單成功時，大約五分鐘之后，才給它發送短信通知。 **這里需要注意，被消費者執行的時間，不僅僅取決于延遲特性，同樣也受消費者接收頻率影響** - 預留（bury） beanstalkd 支持設置 Job 的狀態為預留，處于預留狀態時，它不允許被消費，也不會被消費者接收。 > 比如，我們想實現順序消費：先發短信，再發郵件，此時，我們可以在郵件消費者中，檢查該 Job 是否已經發送過短信（存在短信發送記錄），如果還沒發送過，就把它設置為預留狀態，等到之后條件滿足（存在短信發送記錄）后，再進行消費。 - 持久化（persistent data） beanstalkd 還可通過日志實現持久化，這樣我們可以不必擔心數據丟失，提升了消息可靠性。 至于如何操作，在后文會有介紹。 - 超時重發（ time-to-run ，ttr ） beanstalkd 擁有 TTR 的特性，在前文《使用消息隊列的注意事項》中有所提及。 ttr 也是提升消息可靠性的一種手段。 它指，在消費者接收到 Job 之后，沒能在一定時間內處理完畢，此時，beanstalkd 會認為該 Job 處理失敗，將它從 reserved 的狀態重新調整到 ready 狀態。 **這也是導致出現消息重復被消費的問題，因為消費者響應超時，可能由其它原因引起，比如網絡原因，并不一定是真的處理失敗了。** # 任務狀態 - ready 此狀態代表 Job 隨時可以被消費者接收 - reserved 此狀態指 Job 已被消費者接收，但消費者那邊還沒有給出反饋（還未執行結束），它不會被消費者接收 - delayed 此狀態指 Job 處于延遲狀態，等到時間到了，會轉為 ready ，只有轉為ready之后，才能被消費者接收 - buried 此狀態指 Job 處于預留狀態，它不會被消費者接收 - deleted 此狀態指 Job 已經從 Tube 中被刪除，實際上，它已經不存在了 # 安裝 beanstalkd linux 安裝 beanstalkd 并不難。 我們知道，linux 自定義安裝（編譯安裝），一般經歷這么幾步： - wget （或者壓縮包已經在目錄下了） - tar 解壓 - make && make install 那么，我們只需要下載你需要的版本的 beanstalkd 壓縮包到，再解壓，再編譯安裝，就行了。 這里，記錄一下我安裝的過程： ``` wget https://github.com/beanstalkd/beanstalkd/archive/v1.10.zip tar xzvf beanstalkd-1.10.zip cd beanstalkd-1.10 make && make install beanstalkd -v ``` 最后一個命令執行之后如果能夠反饋給你 beanstalkd 的版本號，說明安裝成功了，接下來就是啟動 beanstalkd 的服務： ``` beanstalkd -l 0.0.0.0 -p 11300 -b /log/beanstalkd/binlog -F ``` **-l 指綁定的 ip ，默認為 127.0.0.1** **-p 指綁定的端口，默認端口 11300** -b 指開啟 binlog 進行持久化，用于斷電后恢復數據 -F 不把內存文件寫入磁盤 更多的選項，可以通過 beanstalkd -h 查看 > 當然，你還可以直接使用 yum 或者 apt-get 來安裝，更加方便。 **如果重復運行 beanstalkd -l -p 的命令，可以讓 beanstalkd 同時監聽多個 ip 和端口。** # 分布式 beanstalkd 的分布式，需要通過客戶端自己實現。 即，比如你有 10 臺消息隊列服務器，此時，你需要全部部署上 beanstalkd ，并且，自己編寫分布式的中間代碼。 這就跟 memcached 的分布式一樣。 # 重要提醒 默認情況下，我們的 beanstalkd 沒有開啟 binlog 的功能，且綁定的 ip 為 127.0.0.1 ，網上有很多文章說，如果安裝 web 控制臺的時候，無法連接 beanstalkd ，就把 127.0.0.1 改成 0.0.0.0 ，這是不對的。 這個 ip 是指 beanstalkd 監聽（允許連接）的客戶端，比如你的客戶端 ip 為 155.22.98.28 ，此時，你設置 -l 為該 ip ， 則，該 ip 可以訪問 beanstalkd 的服務器。 如果改成 0.0.0.0 ，指不限制，那么，你的 beanstalkd 服務器就非常危險，任何 ip 都能訪問進來。 這里，必須要知道一下，為什么改成 0.0.0.0 就可以訪問了。 你可能需要根據你的部署架構來綜合分析，如何設置這個 ip ，并理清你的內外網、物理機、虛擬機，這樣才能設置最合理的 ip 。 另外，在部署環境里，如果非要設置 0.0.0.0 （均衡負載的情況下可能有多個客戶端連接過來），此時，就需要通過網絡環境上的 ip 白名單、端口等方式來過濾。 > 總的來講，beanstalkd 的服務器沒有一個賬號密碼體系，只有監聽 ip 的方式，來鑒別它是否處理你的指令。所以，它非常純潔，如果我們需要最大程度上控制安全，最好讓 beanstalkd server 只允許本機訪問，而外部則訪問位于本機上的 client ，由 client 進行安全校驗和連接 beanstalkd server 。 # 擴展閱讀 [beanstalkd 工具](https://github.com/beanstalkd/beanstalkd/wiki/Tools) [對 windows 的支持](https://github.com/beanstalkd/beanstalkd/wiki/Windows-Support) [客戶端類庫大全](https://github.com/beanstalkd/beanstalkd/wiki/Client-Libraries) [beanstalkd 常見問題](https://github.com/beanstalkd/beanstalkd/wiki/FAQ) [高可用思路](https://blog.csdn.net/qguanri/article/details/50055479) > 為什么把它叫做高可用思路，因為思路指得學習，但具體的實現，建議根據自己的項目需求而定制，盡量不直接使用他人的源碼部署到線上。