reprint
From http://blog.5ibc.net/p/28883.html
Business scene
The so-called seckill, from a business point of view, is a short period of time when multiple users "compete" for resources. The resources here are commodities in most seckill scenarios; abstracting the business, from a technical point of view, seckill is the operation of resources by multiple threads , so to achieve a spike, it is necessary to control the contention of threads for resources, not only to ensure efficient concurrency, but also to ensure the correct operation.
some possible implementations
As mentioned just now, the key point to realize the spike is to control the thread's competition for resources. According to the basic thread knowledge, you can think of the following methods without thinking:
1. The technical abstraction of spikes should be a method. The possible operations in this method are to add the product inventory to -1, add the product to the user's shopping cart, etc., and the database should be operated without considering the cache. Then the simplest and most direct implementation is to add synchronizedkeywords to this method. In layman's terms, it is to lock the entire method;
2. The strategy of locking the entire method is simple and convenient, but it seems a bit rude. It can be optimized a little, and only lock the code block of the spike, such as the part of writing the database;
3. Since there is a concurrency problem, then I will let it "not concurrent", and manage all threads with a queue to make it become Serial operation, naturally there will be no concurrency problems.
The methods described above are all valid, but none of them are bad. Why? The first and second methods are essentially "locking", but the lock granularity is still relatively high. What's the meaning? Just imagine, if two threads execute the seckill method at the same time, the two threads operate on different commodities. From a business point of view, they should be able to do it at the same time, but if the first and second methods are used, these two threads will also go to Fight for the same lock, which is actually unnecessary. The third method does not solve the problem mentioned above either.
So how to control locks at a finer granularity? Consider setting a mutual exclusion lock for each commodity, with the string related to the commodity ID as the unique identifier, so that only the threads competing for the same commodity are mutually exclusive, and all threads are not mutually exclusive. Distributed locks just help us solve this problem.
What is a distributed lock
Distributed locks are a way to control synchronized access to shared resources between distributed systems. In distributed systems, it is often necessary to coordinate their actions. If different systems or different hosts of the same system share one or a set of resources, mutual exclusion is often required to prevent mutual interference to ensure consistency when accessing these resources. In this case, it is necessary to Use distributed locks.
Let's assume the simplest seckill scenario: there is a table in the database, the columns are the product ID and the inventory corresponding to the product ID. If the seckill is successful, the inventory of this product will be -1. Now suppose there are 1000 threads to kill two items, 500 threads to kill the first item, and 500 threads to kill the second item. Let's explain distributed locks based on this simple business scenario.
Usually, business systems with spike scenarios are complex, carry a huge amount of business, and have high concurrency. Such systems often use a distributed architecture to balance the load. Then these 1,000 concurrency will come from different places. The commodity inventory is a shared resource, and it is also the resource that these 1,000 concurrently compete for. At this time, we need to manage the concurrent mutual exclusion. This is the application of distributed locks.
And key-value storage systems, such as redis , are important tools for implementing distributed locks because of some of their characteristics.
concrete implementation
Let's first take a look at some basic commands of redis: SETNX key value
if the key does not exist, set the key corresponding to the string value. In this case, the command is the same as SET. When the key already exists, do nothing. SETNX is "SET if Not eXists". expire KEY seconds
Set the expiration time of the key. If the key has expired, it will be automatically deleted. del KEY
Delete key
Since the author's implementation only uses these three commands, only these three commands are introduced. For more commands and the characteristics and use of redis, you can refer to the redis official website .
issues to consider
1、用什么操作redis？幸亏redis已经提供了jedis客户端用于java应用程序，直接调用jedis API即可。
2、怎么实现加锁？“锁”其实是一个抽象的概念，将这个抽象概念变为具体的东西，就是一个存储在redis里的key-value对，key是于商品ID相关的字符串来唯一标识，value其实并不重要，因为只要这个唯一的key-value存在，就表示这个商品已经上锁。
3、如何释放锁？既然key-value对存在就表示上锁，那么释放锁就自然是在redis里删除key-value对。
4、阻塞还是非阻塞？笔者采用了阻塞式的实现，若线程发现已经上锁，会在特定时间内轮询锁。
5、如何处理异常情况？比如一个线程把一个商品上了锁，但是由于各种原因，没有完成操作（在上面的业务场景里就是没有将库存-1写入数据库），自然没有释放锁，这个情况笔者加入了锁超时机制，利用redis的expire命令为key设置超时时长，过了超时时间redis就会将这个key自动删除，即强制释放锁（可以认为超时释放锁是一个异步操作，由redis完成，应用程序只需要根据系统特点设置超时时间即可）。
talk is cheap,show me the code
在代码实现层面，注解有并发的方法和参数，通过动态代理获取注解的方法和参数，在代理中加锁，执行完被代理的方法后释放锁。
几个注解定义：
cachelock是方法级的注解，用于注解会产生并发问题的方法:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface CacheLock {
String lockedPrefix() default "";//redis 锁key的前缀
long timeOut() default 2000;//轮询锁的时间
int expireTime() default 1000;//key在redis里存在的时间，1000S
}lockedObject是参数级的注解，用于注解商品ID等基本类型的参数：
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface LockedObject {
//不需要值
}LockedComplexObject也是参数级的注解，用于注解自定义类型的参数：
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface LockedComplexObject {
String field() default "";//含有成员变量的复杂对象中需要加锁的成员变量，如一个商品对象的商品ID
}CacheLockInterceptor实现InvocationHandler接口，在invoke方法中获取注解的方法和参数，在执行注解的方法前加锁，执行被注解的方法后释放锁：
public class CacheLockInterceptor implements InvocationHandler{
public static int ERROR_COUNT = 0;
private Object proxied;
public CacheLockInterceptor(Object proxied) {
this.proxied = proxied;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
CacheLock cacheLock = method.getAnnotation(CacheLock.class);
//没有cacheLock注解，pass
if(null == cacheLock){
System.out.println("no cacheLock annotation");
return method.invoke(proxied, args);
}
//获得方法中参数的注解
Annotation[][] annotations = method.getParameterAnnotations();
//根据获取到的参数注解和参数列表获得加锁的参数
Object lockedObject = getLockedObject(annotations,args);
String objectValue = lockedObject.toString();
//新建一个锁
RedisLock lock = new RedisLock(cacheLock.lockedPrefix(), objectValue);
//加锁
boolean result = lock.lock(cacheLock.timeOut(), cacheLock.expireTime());
if(!result){//取锁失败
ERROR_COUNT += 1;
throw new CacheLockException("get lock fail");
}
try{
//加锁成功，执行方法
return method.invoke(proxied, args);
}finally{
lock.unlock();//释放锁
}
}
/**
*
* @param annotations
* @param args
* @return
* @throws CacheLockException
*/
private Object getLockedObject(Annotation[][] annotations,Object[] args) throws CacheLockException{
if(null == args || args.length == 0){
throw new CacheLockException("方法参数为空，没有被锁定的对象");
}
if(null == annotations || annotations.length == 0){
throw new CacheLockException("没有被注解的参数");
}
//不支持多个参数加锁，只支持第一个注解为lockedObject或者lockedComplexObject的参数
int index = -1;//标记参数的位置指针
for(int i = 0;i < annotations.length;i++){
for(int j = 0;j < annotations[i].length;j++){
if(annotations[i][j] instanceof LockedComplexObject){//注解为LockedComplexObject
index = i;
try {
return args[i].getClass().getField(((LockedComplexObject)annotations[i][j]).field());
} catch (NoSuchFieldException | SecurityException e) {
throw new CacheLockException("注解对象中没有该属性" + ((LockedComplexObject)annotations[i][j]).field());
}
}
if(annotations[i][j] instanceof LockedObject){
index = i;
break;
}
}
//找到第一个后直接break，不支持多参数加锁
if(index != -1){
break;
}
}
if(index == -1){
throw new CacheLockException("请指定被锁定参数");
}
return args[index];
}
}最关键的RedisLock类中的lock方法和unlock方法：
/**
* 加锁
* 使用方式为：
* lock();
* try{
* executeMethod();
* }finally{
* unlock();
* }
* @param timeout timeout的时间范围内轮询锁
* @param expire 设置锁超时时间
* @return 成功 or 失败
*/
public boolean lock(long timeout,int expire){
long nanoTime = System.nanoTime();
timeout *= MILLI_NANO_TIME;
try {
//在timeout的时间范围内不断轮询锁
while (System.nanoTime() - nanoTime < timeout) {
//锁不存在的话，设置锁并设置锁过期时间，即加锁
if (this.redisClient.setnx(this.key, LOCKED) == 1) {
this.redisClient.expire(key, expire);//设置锁过期时间是为了在没有释放
//锁的情况下锁过期后消失，不会造成永久阻塞
this.lock = true;
return this.lock;
}
System.out.println("出现锁等待");
//短暂休眠，避免可能的活锁
Thread.sleep(3, RANDOM.nextInt(30));
}
} catch (Exception e) {
throw new RuntimeException("locking error",e);
}
return false;
}
public void unlock() {
try {
if(this.lock){
redisClient.delKey(key);//直接删除
}
} catch (Throwable e) {
}
}上述的代码是框架性的代码，现在来讲解如何使用上面的简单框架来写一个秒杀函数。
先定义一个接口，接口里定义了一个秒杀方法：
public interface SeckillInterface {
/**
*现在暂时只支持在接口方法上注解
*/
//cacheLock注解可能产生并发的方法
@CacheLock(lockedPrefix="TEST_PREFIX")
public void secKill(String userID,@LockedObject Long commidityID);//最简单的秒杀方法，参数是用户ID和商品ID。可能有多个线程争抢一个商品，所以商品ID加上LockedObject注解
}上述SeckillInterface接口的实现类，即秒杀的具体实现：
public class SecKillImpl implements SeckillInterface{
static Map<Long, Long> inventory ;
static{
inventory = new HashMap<>();
inventory.put(10000001L, 10000l);
inventory.put(10000002L, 10000l);
}
@Override
public void secKill(String arg1, Long arg2) {
//最简单的秒杀，这里仅作为demo示例
reduceInventory(arg2);
}
//模拟秒杀操作，姑且认为一个秒杀就是将库存减一，实际情景要复杂的多
public Long reduceInventory(Long commodityId){
inventory.put(commodityId,inventory.get(commodityId) - 1);
return inventory.get(commodityId);
}
}模拟秒杀场景，1000个线程来争抢两个商品：
@Test
public void testSecKill(){
int threadCount = 1000;
int splitPoint = 500;
CountDownLatch endCount = new CountDownLatch(threadCount);
CountDownLatch beginCount = new CountDownLatch(1);
SecKillImpl testClass = new SecKillImpl();
Thread[] threads = new Thread[threadCount];
//起500个线程，秒杀第一个商品
for(int i= 0;i < splitPoint;i++){
threads[i] = new Thread(new Runnable() {
public void run() {
try {
//等待在一个信号量上，挂起
beginCount.await();
//用动态代理的方式调用secKill方法
SeckillInterface proxy = (SeckillInterface) Proxy.newProxyInstance(SeckillInterface.class.getClassLoader(),
new Class[]{SeckillInterface.class}, new CacheLockInterceptor(testClass));
proxy.secKill("test", commidityId1);
endCount.countDown();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
threads[i].start();
}
//再起500个线程，秒杀第二件商品
for(int i= splitPoint;i < threadCount;i++){
threads[i] = new Thread(new Runnable() {
public void run() {
try {
//等待在一个信号量上，挂起
beginCount.await();
//用动态代理的方式调用secKill方法
SeckillInterface proxy = (SeckillInterface) Proxy.newProxyInstance(SeckillInterface.class.getClassLoader(),
new Class[]{SeckillInterface.class}, new CacheLockInterceptor(testClass));
proxy.secKill("test", commidityId2);
//testClass.testFunc("test", 10000001L);
endCount.countDown();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
threads[i].start();
}
long startTime = System.currentTimeMillis();
//主线程释放开始信号量，并等待结束信号量，这样做保证1000个线程做到完全同时执行，保证测试的正确性
beginCount.countDown();
try {
//主线程等待结束信号量
endCount.await();
//观察秒杀结果是否正确
System.out.println(SecKillImpl.inventory.get(commidityId1));
System.out.println(SecKillImpl.inventory.get(commidityId2));
System.out.println("error count" + CacheLockInterceptor.ERROR_COUNT);
System.out.println("total cost " + (System.currentTimeMillis() - startTime));
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}在正确的预想下，应该每个商品的库存都减少了500，在多次试验后，实际情况符合预想。如果不采用锁机制，会出现库存减少499，498的情况。
这里采用了动态代理的方法，利用注解和反射机制得到分布式锁ID，进行加锁和释放锁操作。当然也可以直接在方法进行这些操作，采用动态代理也是为了能够将锁操作代码集中在代理中，便于维护。
通常秒杀场景发生在web项目中，可以考虑利用spring的AOP特性将锁操作代码置于切面中，当然AOP本质上也是动态代理。