消息队列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满载，这将会出现虽然用户数据记录很快的添加到数据库中了，可是却卡在发邮件或分析信息时的状况，致使请求的响应时间大幅增加，甚至出现超时，这就有点不划算了。面对这种状况通常也是将这些操做放入消息队列（生产者消费者模型），消息队列慢慢的进行处理，同时能够很快的完成注册请求，不会影响用户使用其余功能。 因此在软件的正常功能开发中，并不须要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在能够异步处理的耗时操做，若是存在的话即可以引入消息队列来解决。不然盲目的使用消息队列可能会增长维护和开发的成本却没法获得可观的性能提高，那就得不偿失了。