消息隊列Java的簡單實現

轉載：http://blog.csdn.net/u012260707/article/details/50476475

今天看到咱們的招聘信息有對消息隊列有要求，而後就思索了一翻，網上一搜一大堆。

我能夠舉個小例子先說明應用場景

假設你的服務器每分鐘的處理量爲200個，但客戶端再峯值的時候可能一分鐘會發1000個消息給你，這時候你就能夠把他作成隊列，而後按正常有序的處理，先進後出(LIFO)，先進先出(FIFO）可根據本身的狀況進行定奪

stack  先進後出(LIFO)--------Java 對應的類 Stack

隊列 先進先出(FIFO）--------java對應的類Queue

這兩種均可用Linkedlist進行封裝和實現，下面是我本身寫的一個棧的例子

 

/**
 * @author 劉伊凡
 * --------->>>>>>隊列的實現--------------
 */
public class MyStack<T> {
    private LinkedList<T> storage = new LinkedList<T>();

    public synchronized void push(T e) {//須要加上同步
        storage.addFirst(e);
    }

    public T peek() {
        return storage.getFirst();
    }

    public void pop() {
        storage.removeFirst();
    }

    public boolean empty() {
        return storage.isEmpty();
    }

    @Override
    public String toString() {
        return storage.toString();
    }

}

下面是一個測試類

 

 

/**
 * @author 劉伊凡
 *
 */
public class StackTest {
    public static void main(String[] args) {
        MyStack<String> stack = new MyStack<String>();
        for(String s : "the prefect code".split(" ")){//LIFO
            stack.push(s);
        }
        while(!stack.empty()){
            System.out.print(stack.peek()+" ");
            stack.pop();
        }

        System.out.println();
        for(char s : "寫了個一句話倒起來講的程序".toCharArray()){//用例：正話反說
            stack.push(String.valueOf(s));
        }
        while(!stack.empty()){
            System.out.print(stack.peek());
            stack.pop();
        }
    }
}

 

挺有意思的，讓我想了，之前在學校的晚會上，主持人互動的時候會讓人上臺去答題拿獎品，其中有一個題目就是主持人說一句話，而後要求選手倒起來講，咱們的這個程序很符合需求嘛，哈哈，咱們能夠用java來做弊，學以至用

 

消息隊列的應用場景，補充（來自互聯網）

 

我的認爲消息隊列的主要特色是異步處理，主要目的是減小請求響應時間和解耦。因此主要的使用場景就是將比較耗時並且不須要即時（同步）返回結果的操做做爲消息放入消息隊列。同時因爲使用了消息隊列，只要保證消息格式不變，消息的發送方和接收方並不須要彼此聯繫，也不須要受對方的影響，即解耦和。

使用場景的話，舉個例子：
假設用戶在你的軟件中註冊，服務端收到用戶的註冊請求後，它會作這些操做：

1. 校驗用戶名等信息，若是沒問題會在數據庫中添加一個用戶記錄
2. 若是是用郵箱註冊會給你發送一封註冊成功的郵件，手機註冊則會發送一條短信
3. 分析用戶的我的信息，以便未來向他推薦一些志同道合的人，或向那些人推薦他
4. 發送給用戶一個包含操做指南的系統通知
5. 等等……

可是對於用戶來講，註冊功能實際只須要第一步，只要服務端將他的帳戶信息存到數據庫中他即可以登陸上去作他想作的事情了。至於其餘的事情，非要在這一次請求中所有完成麼？值得用戶浪費時間等你處理這些對他來講可有可無的事情麼？因此實際當第一步作完後，服務端就能夠把其餘的操做放入對應的消息隊列中而後立刻返回用戶結果，由消息隊列異步的進行這些操做。 或者還有一種狀況，同時有大量用戶註冊你的軟件，再高併發狀況下注冊請求開始出現一些問題，例如郵件接口承受不住，或是分析信息時的大量計算使cpu滿載，這將會出現雖然用戶數據記錄很快的添加到數據庫中了，可是卻卡在發郵件或分析信息時的狀況，致使請求的響應時間大幅增加，甚至出現超時，這就有點不划算了。面對這種狀況通常也是將這些操做放入消息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時能夠很快的完成註冊請求，不會影響用戶使用其餘功能。 因此在軟件的正常功能開發中，並不須要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在能夠異步處理的耗時操做，若是存在的話即可以引入消息隊列來解決。不然盲目的使用消息隊列可能會增長維護和開發的成本卻沒法獲得可觀的性能提高，那就得不償失了。