今天看到我們的招聘信息有對(duì)消息隊(duì)列有要求，然后就思索了一翻，網(wǎng)上一搜一大堆。

我可以舉個(gè)小例子先說明應(yīng)用場(chǎng)景

假設(shè)你的服務(wù)器每分鐘的處理量為200個(gè)，但客戶端再峰值的時(shí)候可能一分鐘會(huì)發(fā)1000個(gè)消息給你，這時(shí)候你就可以把他做成隊(duì)列，然后按正常有序的處理，先進(jìn)后出(LIFO)，先進(jìn)先出(FIFO）可根據(jù)自己的情況進(jìn)行定奪

stack  先進(jìn)后出(LIFO)--------Java 對(duì)應(yīng)的類 Stack

隊(duì)列 先進(jìn)先出(FIFO）--------java對(duì)應(yīng)的類Queue

這兩種都可用Linkedlist進(jìn)行封裝和實(shí)現(xiàn)，下面是我自己寫的一個(gè)棧的例子

/** 
 * @author 劉伊凡 
 * --------->>>>>>隊(duì)列的實(shí)現(xiàn)-------------- 
 */ 
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(); 
  } 
 
} 

下面是一個(gè)測(cè)試類

/** 
 * @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 : "寫了個(gè)一句話倒起來說的程序".toCharArray()){//用例：正話反說 
      stack.push(String.valueOf(s)); 
    } 
    while(!stack.empty()){ 
      System.out.print(stack.peek()); 
      stack.pop(); 
    } 
  } 
} 

挺有意思的，讓我想了，以前在學(xué)校的晚會(huì)上，主持人互動(dòng)的時(shí)候會(huì)讓人上臺(tái)去答題拿獎(jiǎng)品，其中有一個(gè)題目就是主持人說一句話，然后要求選手倒起來說，我們的這個(gè)程序很符合需求嘛，哈哈，我們可以用java來作弊，學(xué)以致用

消息隊(duì)列的應(yīng)用場(chǎng)景，補(bǔ)充（來自互聯(lián)網(wǎng)）

個(gè)人認(rèn)為消息隊(duì)列的主要特點(diǎn)是異步處理，主要目的是減少請(qǐng)求響應(yīng)時(shí)間和解耦。所以主要的使用場(chǎng)景就是將比較耗時(shí)而且不需要即時(shí)（同步）返回結(jié)果的操作作為消息放入消息隊(duì)列。同時(shí)由于使用了消息隊(duì)列，只要保證消息格式不變，消息的發(fā)送方和接收方并不需要彼此聯(lián)系，也不需要受對(duì)方的影響，即解耦和。

使用場(chǎng)景的話，舉個(gè)例子：

假設(shè)用戶在你的軟件中注冊(cè)，服務(wù)端收到用戶的注冊(cè)請(qǐng)求后，它會(huì)做這些操作：

校驗(yàn)用戶名等信息，如果沒問題會(huì)在數(shù)據(jù)庫中添加一個(gè)用戶記錄

如果是用郵箱注冊(cè)會(huì)給你發(fā)送一封注冊(cè)成功的郵件，手機(jī)注冊(cè)則會(huì)發(fā)送一條短信

分析用戶的個(gè)人信息，以便將來向他推薦一些志同道合的人，或向那些人推薦他

發(fā)送給用戶一個(gè)包含操作指南的系統(tǒng)通知

等等……

但是對(duì)于用戶來說，注冊(cè)功能實(shí)際只需要第一步，只要服務(wù)端將他的賬戶信息存到數(shù)據(jù)庫中他便可以登錄上去做他想做的事情了。至于其他的事情，非要在這一次請(qǐng)求中全部完成么？值得用戶浪費(fèi)時(shí)間等你處理這些對(duì)他來說無關(guān)緊要的事情么？所以實(shí)際當(dāng)?shù)谝徊阶鐾旰?，服?wù)端就可以把其他的操作放入對(duì)應(yīng)的消息隊(duì)列中然后馬上返回用戶結(jié)果，由消息隊(duì)列異步的進(jìn)行這些操作。

或者還有一種情況，同時(shí)有大量用戶注冊(cè)你的軟件，再高并發(fā)情況下注冊(cè)請(qǐng)求開始出現(xiàn)一些問題，例如郵件接口承受不住，或是分析信息時(shí)的大量計(jì)算使cpu滿載，這將會(huì)出現(xiàn)雖然用戶數(shù)據(jù)記錄很快的添加到數(shù)據(jù)庫中了，但是卻卡在發(fā)郵件或分析信息時(shí)的情況，導(dǎo)致請(qǐng)求的響應(yīng)時(shí)間大幅增長(zhǎng)，甚至出現(xiàn)超時(shí)，這就有點(diǎn)不劃算了。面對(duì)這種情況一般也是將這些操作放入消息隊(duì)列（生產(chǎn)者消費(fèi)者模型），消息隊(duì)列慢慢的進(jìn)行處理，同時(shí)可以很快的完成注冊(cè)請(qǐng)求，不會(huì)影響用戶使用其他功能。

所以在軟件的正常功能開發(fā)中，并不需要去刻意的尋找消息隊(duì)列的使用場(chǎng)景，而是當(dāng)出現(xiàn)性能瓶頸時(shí)，去查看業(yè)務(wù)邏輯是否存在可以異步處理的耗時(shí)操作，如果存在的話便可以引入消息隊(duì)列來解決。否則盲目的使用消息隊(duì)列可能會(huì)增加維護(hù)和開發(fā)的成本卻無法得到可觀的性能提升，那就得不償失了。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論