今天看到我們的招聘信息有對消息隊列有要求，然后就思索了一翻，網上一搜一大堆。
我可以舉個小例子先說明應用場景
假設你的服務器每分鐘的處理量為200個，但客戶端再峰值的時候可能一分鐘會發1000個消息給你，這時候你就可以把他做成隊列，然后按正常有序的處理，先進后出(LIFO)，先進先出(FIFO）可根據自己的情況進行定奪
stack 先進后出(LIFO)--------Java 對應的類 Stack
隊列 先進先出(FIFO）--------java對應的類Queue
這兩種都可用Linkedlist進行封裝和實現，下面是我自己寫的一個棧的例子
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
/** * @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(); } } |
下面是一個測試類
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
/** * @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來作弊，學以致用
消息隊列的應用場景，補充（來自互聯網）
個人認為消息隊列的主要特點是異步處理，主要目的是減少請求響應時間和解耦。所以主要的使用場景就是將比較耗時而且不需要即時（同步）返回結果的操作作為消息放入消息隊列。同時由于使用了消息隊列，只要保證消息格式不變，消息的發送方和接收方并不需要彼此聯系，也不需要受對方的影響，即解耦和。
使用場景的話，舉個例子：
假設用戶在你的軟件中注冊，服務端收到用戶的注冊請求后，它會做這些操作：
校驗用戶名等信息，如果沒問題會在數據庫中添加一個用戶記錄
如果是用郵箱注冊會給你發送一封注冊成功的郵件，手機注冊則會發送一條短信
分析用戶的個人信息，以便將來向他推薦一些志同道合的人，或向那些人推薦他
發送給用戶一個包含操作指南的系統通知
等等……
但是對于用戶來說，注冊功能實際只需要第一步，只要服務端將他的賬戶信息存到數據庫中他便可以登錄上去做他想做的事情了。至于其他的事情，非要在這一次請求中全部完成么？值得用戶浪費時間等你處理這些對他來說無關緊要的事情么？所以實際當第一步做完后，服務端就可以把其他的操作放入對應的消息隊列中然后馬上返回用戶結果，由消息隊列異步的進行這些操作。
或者還有一種情況，同時有大量用戶注冊你的軟件，再高并發情況下注冊請求開始出現一些問題，例如郵件接口承受不住，或是分析信息時的大量計算使cpu滿載，這將會出現雖然用戶數據記錄很快的添加到數據庫中了，但是卻卡在發郵件或分析信息時的情況，導致請求的響應時間大幅增長，甚至出現超時，這就有點不劃算了。面對這種情況一般也是將這些操作放入消息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時可以很快的完成注冊請求，不會影響用戶使用其他功能。
所以在軟件的正常功能開發中，并不需要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在可以異步處理的耗時操作，如果存在的話便可以引入消息隊列來解決。否則盲目的使用消息隊列可能會增加維護和開發的成本卻無法得到可觀的性能提升，那就得不償失了。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：http://blog.csdn.net/u012260707/article/details/50476475
