Beanstalkd 一個高性能分布式內存隊列系統

fmms 13年前發布 | 12K 次閱讀隊列系統

之前在微博上調查過大家正在使用的分布式內存隊列系統，反饋有Memcacheq,Fqueue, RabbitMQ , Beanstalkd以及linkedin的kafka。RabbitMQ使用比較廣泛，Beanstalkd是后起之秀。Beanstalkd之于RabbitMQ，就好比Nginx之于Apache，Varnish之于Squid。后面在項目中使用Beanstalkd的過程中，更發現其簡單、輕量級、高性能、易使用等特點，以及優先級、多隊列、持久化、分布式容錯、超時控制等特性。下面就簡單介紹一下Beanstalkd，不足之處請大家指正。

———————————————–正文分割線————————————————-

設計思想

高性能離不開異步，異步離不開隊列，而其內部都是Producer-Comsumer模式的原理。

Beanstalkd 一個高性能分布式內存隊列系統

圖1 Producer-Comsumer模式

應用

Beanstalkd，一個高性能、輕量級的分布式內存隊列系統，最初設計的目的是想通過后臺異步執行耗時的任務來降低高容量Web應用系統的頁面訪問延遲，支持過有9.5 million用戶的非死book Causes應用。后來開源，現在有PostRank大規模部署和使用，每天處理百萬級任務。Beanstalkd是典型的類Memcached設計，協議和使用方式都是同樣的風格，所以使用過memcached的用戶會覺得Beanstalkd似曾相識。

核心概念

Beanstalkd設計里面的核心概念：

一個需要異步處理的任務，是Beanstalkd中的基本單元，需要放在一個tube中。

tube

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

producer

Job的生產者，通過put命令來將一個job放到一個tube中。

consumer

Job的消費者，通過reserve/release/bury/delete命令來獲取job或改變job的狀態。

Beanstalkd中一個job的生命周期如圖2所示。一個job有READY, RESERVED, DELAYED, BURIED四種狀態。當producer直接put一個job時，job就處于READY狀態，等待consumer來處理，如果選擇延遲put，job就先到DELAYED狀態，等待時間過后才遷移到READY狀態。consumer獲取了當前READY的job后，該job的狀態就遷移到RESERVED，這樣其他的consumer就不能再操作該job。當consumer完成該job后，可以選擇delete, release或者bury操作；delete之后，job從系統消亡，之后不能再獲取；release操作可以重新把該job狀態遷移回READY（也可以延遲該狀態遷移操作），使其他的consumer可以繼續獲取和執行該job；有意思的是bury操作，可以把該job休眠，等到需要的時候，再將休眠的job kick回READY狀態，也可以delete BURIED狀態的job。正是有這些有趣的操作和狀態，才可以基于此做出很多意思的應用，比如要實現一個循環隊列，就可以將RESERVED狀態的job休眠掉，等沒有READY狀態的job時再將BURIED狀態的job一次性kick回READY狀態。

Beanstalkd 一個高性能分布式內存隊列系統