Redis学习笔记3 Java + Redis模拟秒杀场景

秒杀场景中，客户端对服务器的访问可以抽象为两个：访问静态页面（列出静态商品页面），访问后台接口（抢购）

• 静态页面可以使用DNS实现，压力不大；
• 后台接口是重点要解决的问题。
  • 一定要快
  • 不要直接访问传统数据库，太慢。建议使用内存数据库技术，本例使用Redis进行示例
  • 防止同一账号短时间内的多次请求
  • 防止超发（即本来只有100件商品，却最终成交了101件）
    • 悲观锁：即实际对某个商品的购买api，同时只允许一个用户访问，“查询该商品数量”、“商品数量减1”是在同一个事务中，保证数据的完整性。缺点是性能，通常无法满足抢购的场景。
    • FIFO: 客户端的抢购指令，只是插入一个交易表，由另外一个统一的线程来处理交易表，标记交易的成功或失败（如商品已售完）。缺点是客户端无法立即得到反馈，需要等待统一的线程处理完自己的交易后才知道抢购是否成功。不知道是否有公司采用此种方案实现抢购场景，个人感觉还是可行的。
    • 乐观锁：即每个抢购指令前：step 1. 首先做个特殊标记; step 2. 然后正常执行指令; step 3. 在指令提交时，根据标记判断step 1至step 3之间商品数据是否有变化，如果有，则失败；否则，则抢购成功。

以下采用Java + Redis模拟乐观锁的实现。

• Redis服务器需要事先搭建好，作者将具体ip mask掉
• 本例采用异步方式记录交易log表，之所以要插入此log表，是为了方便统计最终商品交易的成功数、失败数。不是必须的。可以注释掉这些代码。（当然实际业务中应该会记录类似的表）

1. MyJedisPool.java   // Redis客户端pool的实现

package com.cloudboy.redis;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class MyJedisPool {

	private static JedisPool pool;

	static {
		JedisPoolConfig config = new JedisPoolConfig();
		// 设置的逐出策略类名, 默认DefaultEvictionPolicy(当连接超过最大空闲时间,或连接数超过最大空闲连接数)
		config.setE