22-redis项目实战:在库存服务中实现缓存与数据库双写一致性保障方案(处理时效性要求很高的数据)

上一篇文章我们搭建了一个最基本得springboot+mybatis+redis集群得一个项目。通过这个项目我们来加深理解如何实现缓存与数据库双写一致性。

实现缓存与数据库双写一致性保障方案(一)

大致得思路为:

  • 首先要清楚一般是有两种请求:

1:(主动更新数据,数据发生变化,比如库存因为交易成功发送变化)更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个jvm内部的队列中

2:读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个jvm内部的队列中

  • 大概方法:将读取数据和更新数据得请求,不要直接去执行这些请求,而且分别放到两条队列中,然后在一条一条得执行。

一个队列对应一个工作线程(比如所有得读取数据得请求放在a队列,更新数据得请求放在b队列

每个工作线程串行拿到对应的操作,然后一条一条的执行

这样的话,就保证了一个数据变更的操作顺序是:先执行,删除缓存,然后再去更新数据库。

但是还没完成更新缓存:此时如果一个读请求过来,读到了空的缓存,那么可以先将缓存更新的请求发送到队列中,此时会在队列中积压,然后同步等待缓存更新完成

  • 思路优化点:

这里有优化点:

1:一个队列中,其实多个更新缓存(更新缓存是指先从数据库拿到数据,然后再缓存到redis)请求串在一起是没意义的,因为都是先读数据在缓存到redis中,没必要一直去执行这么多次。因此可以做过滤,如果发现队列中已经有一个更新缓存的请求了,那么就不用再放个更新请求操作进去了,直接等待前面的更新操作请求完成即可

待那个队列对应的工作线程完成了上一个操作的数据库的修改之后,才会去执行下一个操作,也就是缓存更新的操作,此时会从数据库中读取最新的值,然后写入缓存中

2:如果请求还在等待时间范围内,不断轮询发现可以取到值了,那么就直接返回; 如果请求等待的时间超过一定时长,那么这一次直接从数据库中读取当前的旧值

 

实现思路步骤:

1、线程池+内存队列初始化

  • 注册监听器 -- InitListener 实现了线程池和内存队列的初始化
    /**
     * 注册监听器
     * @return
     */
    @SuppressWarnings({ "rawtypes", "unchecked" })
	@Bean
    public ServletListenerRegistrationBean servletListenerRegistrationBean() {
    	ServletListenerRegistrationBean servletListenerRegistrationBean = 
    			new ServletListenerRegistrationBean();
    	servletListenerRegistrationBean.setListener(new InitListener());  
    	return servletListenerRegistrationBean;
    }

项目启动得时候,就初始化两个队列。这两个队列得生命周期应该跟这个系统得生命周期一样得。

一般我们得java web应用,做系统的初始化,一般在哪里做呢?一般是

ServletContextListener里面做,listener,会跟着整个web应用的启动,就初始化,类似于线程池初始化的构建。

spring boot应用配置监听器是在启动类中(Application),搞一个listener的注册。

  • InitListener  --  初始化队列得作用
/**
 * 系统初始化监听器
 * @author Administrator
 *
 * 在 Servlet API 中有一个 ServletContextListener 接口,
 * 它能够监听 ServletContext 对象的生命周期,实际上就是监听 Web 应用的生命周期。
 * 当Servlet 容器启动或终止Web 应用时,会触发ServletContextEvent 事件,该事件由ServletContextListener 来处理。
 * 在 ServletContextListener 接口中定义了处理ServletContextEvent 事件的两个方法contextInitialized、contextDestroyed
 *
 */
public class InitListener implements ServletContextListener {

	/**
	 * 当Servlet 容器启动Web 应用时调用该方法。在调用完该方法之后,容器再对Filter 初始化,
	 * 并且对那些在Web 应用启动时就需要被初始化的Servlet 进行初始化。
	 */
	@Override
	public void contextInitialized(ServletContextEvent sce) {
		// 初始化工作线程池和内存队列
		RequestProcessorThreadPool.init();
	}

	/**
	 * 当Servlet 容器终止Web 应用时调用该方法。在调用该方法之前,容器会先销毁所有的Servlet 和Filter 过滤器。
	 */
	@Override
	public void contextDestroyed(ServletContextEvent sce) {
		
	}

}

自定义监听器实现ServletContextListener接口,在 contextInitialized 初方法中进行始化线程池和内存队列。

  • RequestProcessorThreadPool -- 线程池处理类
/**
 * 请求处理线程池:单例
 * @author Administrator
 *
 */
public class RequestProcessorThreadPool {
	
	// 在实际项目中,你设置线程池大小是多少,每个线程监控的那个内存队列的大小是多少
	// 都可以做到一个外部的配置文件中
	// 我们这了就给简化了,直接写死了
	
	/**
	 * 线程池
	 */
	private ExecutorService threadPool = Executors.newFixedThreadPool(10);
	
	public RequestProcessorThreadPool() {
		RequestQueue requestQueue = RequestQueue.getInstance();
		
		for(int i = 0; i < 10; i++) {
			ArrayBlockingQueue<Request> queue = new ArrayBlockingQueue<Request>(100);
			requestQueue.addQueue(queue);  
			threadPool.submit(new RequestProcessorThread(queue));
		}
	}

	/**
	 * 单例有很多种方式去实现:采取绝对线程安全的一种方式
	 * 静态内部类的方式,去初始化单例
	 * 创建单例线程池
	 * @author Administrator
	 *
	 */
	private static class Singleton {
		private static RequestProcessorThreadPool instance;

		/**
		 * 静态代码块
		 * 特点:随着类的加载而执行,且只执行一次,并优先于主函数。用于给类初始化的。
		 */
		static {
			instance = new RequestProcessorThreadPool();
		}

		public static RequestProcessorThreadPool getInstance() {
			return instance;
		}
		
	}
	
	/**
	 * jvm的机制去保证多线程并发安全
	 * 因为Singleton 是 静态内部类的方式,保证了RequestProcessorThreadPool只会创建一次。
	 * 当第二次之后调用就都是拿之前创建好的对象,保证了多线程并发安全。
	 * 内部类的初始化,一定只会发生一次,不管多少个线程并发去初始化
	 * 
	 * @return
	 */
	public static RequestProcessorThreadPool getInstance() {
		return Singleton.getInstance();
	}
	
	/**
	 * 初始化的便捷方法
	 */
	public static void init() {
		getInstance();
	}
}

线程池的思路处理,主要是内部使用了一个静态内部类,单例模式初始化线程池和内存队列。

设置线程池大小是多少,每个线程监控的那个内存队列的大小是多少,其实都可以设计成配置的形式,不必要写死,(我这里写死了线程池大小为100,每个线程监听的队列大小为10)
  • RequestProcessorThread -- 执行真正请求业务工作的线程类
/**
 * 执行请求的工作线程
 * @author Administrator
 *
 */
public class RequestProcessorThread implements Callable<Boolean> {
	
	/**
	 * 自己监控的内存队列
	 */
	private ArrayBlockingQueue<Request> queue;

	public RequestProcessorThread(ArrayBlockingQueue<Request> queue) {
		this.queue = queue;
	}
	
	@Override
	public Boolean call() throws Exception {
		while(true) {
			//不断消费请求的业务
			break;
		}
		return true;
	}

}
  • RequestQueue -- 请求内存队列
/**
 * 请求内存队列
 * @author Administrator
 *
 */
public class RequestQueue {

	/**
	 * 内存队列
	 */
	private List<ArrayBlockingQueue<Request>> queues = new ArrayList<ArrayBlockingQueue<Request>>();
	
	/**
	 * 单例有很多种方式去实现:我采取绝对线程安全的一种方式
	 * 
	 * 静态内部类的方式,去初始化单例
	 * 
	 * @author Administrator
	 *
	 */
	private static class Singleton {
		
		private static RequestQueue instance;
		
		static {
			instance = new RequestQueue();
		}
		
		public static RequestQueue getInstance() {
			return instance;
		}
		
	}
	
	/**
	 * jvm的机制去保证多线程并发安全
	 * 
	 * 内部类的初始化,一定只会发生一次,不管多少个线程并发去初始化
	 * 
	 * @return
	 */
	public static RequestQueue getInstance() {
		return Singleton.getInstance();
	}
	
	/**
	 * 添加一个内存队列
	 * @param queue
	 */
	public void addQueue(ArrayBlockingQueue<Request> queue) {
		this.queues.add(queue);
	}
	
}

初始化生成的所有的队列都会存在这里面。

  • Request -- 封装的请求接口,所有的请求方式都会继承它
/**
 * 请求接口
 * @author Administrator
 *
 */
public interface Request {
    void process();
}

 

2、两种请求对象封装

首先要清楚一般是有两种请求:

1:比如发生了交易那么需要更新数据,主动来更新数据这是情况一。更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个jvm内部的队列中

2:第二种是读取数据。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个jvm内部的队列中

在第一步骤中,我们已经定义好了一个Request接口,目的就是为了所有的不同类型的请求都去实现该接口。因为我们分析了主要有两种请求的可能性(方式)。

所以我们自定义两个请求实现类。

  • 封装请求1 - 请求1的设计主要是用来主动更新数据库数据的。因此操作顺序就是先把对应的缓存删掉,然后再去更新具体的数据库数据。请求1中实现了定义了process方法,调用了service来进行具体的业务操作。
/**
 * 比如说一个商品发生了交易,那么就要修改这个商品对应的库存
 * 
 * 此时就会发送请求过来,要求修改库存,那么这个可能就是所谓的data update request,数据更新请求
 * 
 * cache aside pattern
 * 
 * (1)删除缓存
 * (2)更新数据库
 * 
 * @author Administrator
 *
 */
public class ProductInventoryDBUpdateRequest implements Request {

	/**
	 * 商品库存
	 */
	private ProductInventory productInventory;
	/**
	 * 商品库存Service
	 */
	private ProductInventoryService productInventoryService;
	
	public ProductInventoryDBUpdateRequest(ProductInventory productInventory,
			ProductInventoryService productInventoryService) {
		this.productInventory = productInventory;
		this.productInventoryService = productInventoryService;
	}
	
	@Override
	public void process() {
		// 删除redis中的缓存
		productInventoryService.removeProductInventoryCache(productInventory); 
		// 修改数据库中的库存
		productInventoryService.updateProductInventory(productInventory);  
	}
	
}
  • 封装请求2 - 请求2的设计主要是用来先去查询库存数据,然后更新到缓存中,所以它 的主要是一个更新缓存的作用的一个请求。请求2中实现了定义了process方法,调用了service来进行具体的业务操作。业务逻辑就是先查数据库数据,再更新到缓存。
/**
 * 重新加载商品库存的缓存
 * @author Administrator
 *
 */
public class ProductInventoryCacheRefreshRequest implements Request {

	/**
	 * 商品id
	 */
	private Integer productId;
	/**
	 * 商品库存Service
	 */
	private ProductInventoryService productInventoryService;
	
	public ProductInventoryCacheRefreshRequest(Integer productId,
			ProductInventoryService productInventoryService) {
		this.productId = productId;
		this.productInventoryService = productInventoryService;
	}
	
	@Override
	public void process() {
		// 从数据库中查询最新的商品库存数量
		ProductInventory productInventory = productInventoryService.findProductInventory(productId);
		// 将最新的商品库存数量,刷新到redis缓存中去
		productInventoryService.setProductInventoryCache(productInventory); 
	}
	
}

在之前封装好的两个请求中,我们已经设计好了service需要的方法,都是设计到具体业务的逻辑。对应的service接口这里就不具体贴出来了,包括mapper也不贴出来看了,因为都是简单的单表操作用来做演示的,相信大家一看就懂怎么取操作哈。现在主要把service接口的实现类贴出来看下,相信大家一看就懂的。四个方法,都是在请求封装类中有用到的。

/**
 * 商品库存Service实现类
 * @author Administrator
 *
 */
@Service("productInventoryService")  
public class ProductInventoryServiceImpl implements ProductInventoryService {

	@Resource
	private ProductInventoryMapper productInventoryMapper;
	@Resource
	private RedisDAO redisDAO;

	/**
	 * 移除redis中商品缓存
	 * @param productInventory 商品库存
	 */
	@Override
	public void removeProductInventoryCache(ProductInventory productInventory) {
		String key = "product:inventory:" + productInventory.getProductId();
		redisDAO.delete(key);
	}
	/**
	 * 更新数据库中库存
	 * @param productInventory 商品库存
	 */
	@Override
	public void updateProductInventory(ProductInventory productInventory) {
		productInventoryMapper.updateProductInventory(productInventory); 
	}



	/**
	 * 根据商品id查询商品库存
	 * @param productId 商品id 
	 * @return 商品库存
	 */
	public ProductInventory findProductInventory(Integer productId) {
		return productInventoryMapper.findProductInventory(productId);
	}
	
	/**
	 * 设置redis中商品库存的缓存
	 * @param productInventory 商品库存
	 */
	public void setProductInventoryCache(ProductInventory productInventory) {
		String key = "product:inventory:" + productInventory.getProductId();
		redisDAO.set(key, String.valueOf(productInventory.getInventoryCnt()));  
	}


    /**
	 * 获取商品库存的缓存
	 * @param productId
	 * @return
	 */
	public ProductInventory getProductInventoryCache(Integer productId) {
		Long inventoryCnt = 0L;
		
		String key = "product:inventory:" + productId;
		String result = redisDAO.get(key);
		
		if(result != null && !"".equals(result)) {
			try {
				inventoryCnt = Long.valueOf(result);
				return new ProductInventory(productId, inventoryCnt);
			} catch (Exception e) {
				e.printStackTrace(); 
			}
		}
		
		return null;
	}
	
}

 

3、请求异步执行Service封装

再对以上的涉及到的具体的业务逻辑封装完之后,我们设计一个同意的入口service,进行路由然后根据reque去执行相对的业务操作。

因为前面我们初始化了线程池,并且使用的单例模式,而且还初始化了一个RequestQueue存放了所有的内存队列,并且线程池的数量和每个内存队列的数量,都可以通过我们的配置去进行改变。线程池中的线程监听的自己的一个内存队列,并且这些队列其实也存在我们初始化时定义的那个RequestQueue中,所以我们可以通过操作RequestQueue中的内存队列,就能影响线程中的内存队列去执行对应的操作线程操作。

/**
 * 请求异步处理的service实现
 * @author Administrator
 *
 */
public interface RequestAsyncProcessService {

    void process(Request request);
}
@Service
public class RequestAsyncProcessServiceImpl implements RequestAsyncProcessService {
    @Override
    public void process(Request request) {
        try {
            // 做请求的路由,根据每个请求的商品id,路由到对应的内存队列中去
            ArrayBlockingQueue<Request> queue = getRoutingQueue(request.getProductId());
            // 将请求放入对应的队列中,完成路由操作,put:当Queue已经满了时,会进入等待,只要不被中断,就会插入数据到队列中。会阻塞,可以响应中断
            queue.put(request);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * 获取路由到的内存队列
     * @param productId 商品id
     * @return 内存队列
     */
    private ArrayBlockingQueue<Request> getRoutingQueue(Integer productId) {
        //通过RequestQueue获取内存队列。
        //因为在初始化线程池的时候,已经调用过一个生成过了,单例模式,所以这里拿到的还是启动时生成的内存队列。
        //并且也是线程池中的内存队列,所以当这里拿到队列并且在队列中设置了参数,线程池中的队列就能做出对应操作,因为线程池一直在阻塞中执行。
        RequestQueue requestQueue = RequestQueue.getInstance();

        // 先获取productId的hash值
        String key = String.valueOf(productId);
        int h;
        int hash = (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);

        // 对hash值取模,将hash值路由到指定的内存队列中,比如内存队列大小 8
        // 用内存队列的数量对hash值取模之后,结果一定是在0~7之间
        // 所以任何一个商品id都会被固定路由到同样的一个内存队列中去的
        int index = (requestQueue.queueSize() - 1) & hash;

        return requestQueue.getQueue(index);
    }
}

 

4、两种请求Controller接口封装

/**
 * 商品库存Controller
 * @author Administrator
 *
 */
@RestController
public class ProductInventoryController {

	@Resource
	private RequestAsyncProcessService requestAsyncProcessService;
	@Resource
	private ProductInventoryService productInventoryService;
	
	/**
	 * 更新商品库存
	 */
	@RequestMapping("/updateProductInventory")
	@ResponseBody
	public Response updateProductInventory(@RequestBody ProductInventory productInventory) {
		Response response = null;
		
		try {
			Request request = new ProductInventoryDBUpdateRequest(
					productInventory, productInventoryService);
			requestAsyncProcessService.process(request);
			response = new Response(Response.SUCCESS);
		} catch (Exception e) {
			e.printStackTrace();
			response = new Response(Response.FAILURE);
		}
		
		return response;
	}
	
	/**
	 * 获取商品库存
	 */
	@RequestMapping("/getProductInventory")
	@ResponseBody
	public ProductInventory getProductInventory(Integer productId) {
		ProductInventory productInventory = null;
		
		try {
			Request request = new ProductInventoryCacheRefreshRequest(
					productId, productInventoryService);
			requestAsyncProcessService.process(request);
			
			// 将请求扔给service异步去处理以后,就需要while(true)一会儿,在这里hang住
			// 去尝试等待前面有商品库存更新的操作,同时缓存刷新的操作,将最新的数据刷新到缓存中
			long startTime = System.currentTimeMillis();
			long endTime = 0L;
			long waitTime = 0L;
			
			// 等待超过200ms没有从缓存中获取到结果
			while(true) {
				if(waitTime > 200) {
					break;
				}
				
				// 尝试去redis中读取一次商品库存的缓存数据
				productInventory = productInventoryService.getProductInventoryCache(productId);
				
				// 如果读取到了结果,那么就返回
				if(productInventory != null) {
					return productInventory;
				}
				
				// 如果没有读取到结果,那么等待一段时间
				else {
					Thread.sleep(20);
					endTime = System.currentTimeMillis();
					waitTime = endTime - startTime;
				}
			}
			
			// 直接尝试从数据库中读取数据
			productInventory = productInventoryService.findProductInventory(productId);
			if(productInventory != null) {
				return productInventory;
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
		
		return new ProductInventory(productId, -1L);  
	}
	
}

到此,就可以进行调用测试了。测试一遍对整个流程可以理解的更清楚。

5、读请求去重优化

情况分析

对一个商品的库存的数据库更新操作已经在内存队列中了,然后对这个商品的库存的读取操作,要求读取数据库的库存数据,然后更新到缓存中,高并发得情况下,此时有多个读请求过来,这多个读,其实只要有一个读请求操作压到队列里就可以了,其他的读操作,全部都wait那个读请求的操作完后,刷新缓存,就可以读到缓存中的最新数据了,就不用在去到数据库读取了。

 

分析完了具体的情况,我们还应该想到一个问题,因为是多线程高并发的环境,所以我们应该避免高并发而产生的问题,所以这里我们就应该清楚,去重的逻辑代码我们应该写在每个线程的实现类了,避免问题的出现。

这里我们就直接贴出代码来看。

@Override
    public Boolean call() throws Exception {
        try {
            while(true) {
                // ArrayBlockingQueue
                // take和put相互对应,如果队列满了,或者是空的,那么都会在执行操作的时候,阻塞住,一直到能够取到数据
                Request request = queue.take();
                // 执行这个request操作
                boolean forceRfresh = request.isForceRefresh();

                // 先做读请求的去重
                if(!forceRfresh) {
                    RequestQueue requestQueue = RequestQueue.getInstance();
                    Map<Integer, Boolean> flagMap = requestQueue.getFlagMap();

                    if(request instanceof ProductInventoryDBUpdateRequest) {
                        // 如果是一个更新数据库的请求,那么就将那个productId对应的标识设置为true
                        flagMap.put(request.getProductId(), true);
                    } else if(request instanceof ProductInventoryCacheRefreshRequest) {
                        Boolean flag = flagMap.get(request.getProductId());

                        // 如果flag是null
                        if(flag == null) {
                            flagMap.put(request.getProductId(), false);
                        }

                        // 如果是缓存刷新的请求,那么就判断,如果标识不为空,而且是true,就说明之前有一个这个商品的数据库更新请求
                        if(flag != null && flag) {
                            flagMap.put(request.getProductId(), false);
                        }

                        // 如果是缓存刷新的请求,而且发现标识不为空,但是标识是false
                        // 说明前面已经有一个数据库更新请求+一个缓存刷新请求了,大家想一想
                        if(flag != null && !flag) {
                            // 对于这种读请求,直接就过滤掉,不要放到后面的内存队列里面去了
                            return true;
                        }
                    }
                }

                System.out.println("===========日志===========: 工作线程处理请求,商品id=" + request.getProductId());
                // 执行这个request操作
                request.process();

                // 假如说,执行完了一个读请求之后,假设数据已经刷新到redis中了
                // 但是后面可能redis中的数据会因为内存满了,被自动清理掉
                // 如果说数据从redis中被自动清理掉了以后
                // 然后后面又来一个读请求,此时如果进来,发现标志位是false,就不会去执行这个刷新的操作了
                // 所以在执行完这个读请求之后,实际上这个标志位是停留在false的
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return true;
    }
  •  在requestQueue中我们定义了唯一的一个map,作为标识符来用。这个标识符,我们在做某一个商品的库存更新的时候,就在这个map中将这个商品标记为true,在缓存刷新的时候,我们就能跟着判断这里面的标识符,来决定是否需要去做缓存刷新。
    /**
     * 标识位map, 做优化操作
     *
     * 我们知道HashMap是线程不安全的,在多线程环境下,使用Hashmap进行put操作会引起死循环,
     * 导致CPU利用率接近100%,所以在并发情况下不能使用HashMap。
     *
     * ConcurrentHashMap:主要就是为了应对hashmap在并发环境下不安全而诞生的,
     * ConcurrentHashMap的设计与实现非常精巧,大量的利用了volatile,final,CAS等lock-free技术来减少锁竞争对于性能的影响。
     */
    private Map<Integer, Boolean> flagMap = new ConcurrentHashMap<Integer, Boolean>();
  •  通过判断从map中得到的flag,可以通过代码分析。如果flag为true,说明之前已经做过一个更新数据库操作,因此这里标记为false,然后代码会继续去做刷新缓存的操作。当flag为false的时候,说明之前已经做过一个更新数据库操作,并且也刷新过一次缓存了,所以这里就直接返回到controller层了,结合controller层可以知道这里稍微等待一会就会去缓冲中获取数据。然后最后如果flag为null,说明前面什么操作也没做过,所以这里把flag设置为false,去执行一次查询刷新缓存操作,有可能查到的数据是空的就是数据库没有数据。

 

还有一些问题:

 1、数据刷入了redis,但是redis LRU算法给清理掉了,标志位还是false
 所以此时下一个读请求是从缓存中拿不到数据的,再放一个读Request进队列,让数据去刷新一下

 2、可能在200ms内,就是读请求在队列中一直积压着,没有等待到它执行(在实际生产环境中,基本是比较坑了)
 所以就直接查一次库,然后给队列里塞进去一个刷新缓存的请求

 3、数据库里本身就没有,缓存穿透,穿透redis,请求到达mysql库

解决办法,,在原来的那个controll中做改变。

/**
	 * 获取商品库存
	 */
	@RequestMapping("/getProductInventory")
	@ResponseBody
	public ProductInventory getProductInventory(Integer productId) {
		ProductInventory productInventory = null;
		
		try {
			Request request = new ProductInventoryCacheRefreshRequest(
					productId, productInventoryService,false);
			requestAsyncProcessService.process(request);
			
			// 将请求扔给service异步去处理以后,就需要while(true)一会儿,在这里hang住
			// 去尝试等待前面有商品库存更新的操作,同时缓存刷新的操作,将最新的数据刷新到缓存中
			long startTime = System.currentTimeMillis();
			long endTime = 0L;
			long waitTime = 0L;
			
			// 等待超过200ms没有从缓存中获取到结果
			while(true) {
				if(waitTime > 200) {
					break;
				}
				
				// 尝试去redis中读取一次商品库存的缓存数据
				productInventory = productInventoryService.getProductInventoryCache(productId);
				
				// 如果读取到了结果,那么就返回
				if(productInventory != null) {
					return productInventory;
				}
				
				// 如果没有读取到结果,那么等待一段时间
				else {
					Thread.sleep(20);
					endTime = System.currentTimeMillis();
					waitTime = endTime - startTime;
				}
			}
			
			// 直接尝试从数据库中读取数据
			productInventory = productInventoryService.findProductInventory(productId);
			if(productInventory != null) {
				// 将缓存刷新一下
				// 这个过程,实际上是一个读操作的过程,但是没有放在队列中串行去处理,还是有数据不一致的问题
				request = new ProductInventoryCacheRefreshRequest(
						productId, productInventoryService, true);
				requestAsyncProcessService.process(request);

				// 代码会运行到这里,只有三种情况:
				// 1、就是说,上一次也是读请求,数据刷入了redis,但是redis LRU算法给清理掉了,标志位还是false
				// 所以此时下一个读请求是从缓存中拿不到数据的,再放一个读Request进队列,让数据去刷新一下
				// 2、可能在200ms内,就是读请求在队列中一直积压着,没有等待到它执行(在实际生产环境中,基本是比较坑了)
				// 所以就直接查一次库,然后给队列里塞进去一个刷新缓存的请求
				// 3、数据库里本身就没有,缓存穿透,穿透redis,请求到达mysql库

				return productInventory;
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
		
		return new ProductInventory(productId, -1L);  
	}

 

评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值