lesson4:使用锁Lock来解决重复下单的问题

demo源码：https://github.com/mantuliu/javaAdvance 中的类Lesson4IndependentLock

在上一节中，我们分析了Lock的源代码并一起实践了粗粒度锁对于性能的影响，在本节中，我们将用锁机制来解决一个生产环境实际的案例。下面的案例是一个真实的案例。

之前我在一家移动医疗公司做架构师的时候，我司有一个主要的业务是通过网络来完成预约挂号的业务，对于下单操作，之前的版本都是各个jvm独立完成，各个服务之间没有依赖，由于号源是非常珍贵的资源，所以就存在黄牛刷号的情况，最后就出现了，同一个用户在同一个时段上挂到了同一个医生两个以上的号。当时由于前端的负载均衡设备是按照iphash策略来进行负载均衡的，因此我给出了第一版的解决方案，使用细粒度的锁来实现(如果这里我们上了粗粒度的锁，也就是所有的线程都要锁同一个资源才能下单，又因为下单的时间比较慢，大家可以想象一下，所有的线程全部卡在了同一个节点上，直接下单服务完全停止服务)，通过业务分析，我们的锁可以定义为预约人和医生的组合，上一节中我们使用了1.5的Lock来实现的锁，本节中我们才用synchronized机制来实现，demo如下：

package com.mantu.advance;
 
import java.util.HashMap;
 
/**
 * blog http://www.cnblogs.com/mantu/
 * github https://github.com/mantuliu/
 * @author mantu
 *
 */
public class Lesson4IndependentLock implements Runnable{
    String custName;//挂号人姓名
    String doctorId;//医生id
    String other;//其它附属信息
     
    public static HashMap<String,StringBuffer> orderMap = new HashMap<String,StringBuffer>();//此map中存储的是挂号人和医生的组合信息，也就是我们的细粒度的锁
    public static HashMap<String,String> orderYanzhengMap = new HashMap<String,String>();//此map用来存储订单信息
     
    public static void main(String args[]){
        for(int i =0;i<3;i++){//每个用户同时启动3个线程
            Lesson4IndependentLock lock1 =  new Lesson4IndependentLock("王小二", "123456", "test");
            new Thread(lock1).start();
            Lesson4IndependentLock lock2 =  new Lesson4IndependentLock("张小三", "123456", "test");
            new Thread(lock2).start();
        }
    }
     
    public Lesson4IndependentLock(String custName,String doctorId,String other){
        this.custName=custName;
        this.doctorId=doctorId;
        this.other=other;
    }<br>    //添加订单方法
    public void addOrder(String custName,String doctorId,String other){
        StringBuffer lockString = null;
        if(orderMap.containsKey(custName+"&"+other)){
            lockString=orderMap.get(custName+"&"+other);//如果orderMap已经存在后面需要用到的锁信息，则直接取出
        }
        else{
            synchronized(orderMap){//如果没有，则创建一个公用的锁对象，并添加进去，保证所有相关的线程(同一个用户同一个医生)是用同一把锁
                if(!orderMap.containsKey(custName+"&"+other)){
                    lockString = new StringBuffer(custName+"&"+other);
                    orderMap.put(custName+"&"+other, lockString);
                }
                else{
                    lockString=orderMap.get(custName+"&"+other);
                }
            }
        }
        synchronized(lockString){//锁定小粒度的挂号人和医生组合信息的锁
            if(orderYanzhengMap.containsKey(custName+"&"+other)){//验证
                System.out.println(custName+"之前已经下过"+doctorId+"的预约单，不能重复下单");
            }
            else{
                orderYanzhengMap.put(custName+"&"+other, custName+"&"+other);//下单
                System.out.println(custName+"刚刚下了一个"+doctorId+"的预约单");
            }
        }
    }
    @Override
    public void run() {
        addOrder(custName,doctorId,other);//下单
    }
}

上面的实现方式已经很好地解决了重复下单的问题，但是由于后来我们的负载均衡策略改变了，变成了随机的方式，同一个客户下的多笔单可以随机落到各个服务器上。这时，我们只能采用分布式锁的方案来解决重复下单的问题，对问题进行分析：由于我们锁的粒度很小，是对挂号人和医生联合的对象来上锁，正常情况下的用户操作，用户不可能同时下同一个医生的订单，那么我们的分布式锁就可以模拟高并发包中的trylock()机制，而不必采用阻塞等待的lock()机制，如果发现锁已经被其它线程获取到了，马上放弃并返回失败，demo Lesson4DistributedLock：模拟了分布式做下订单的场景，文中主要是采用了redis的setnx操作，此操作是一个原子操作。