商品预约抢购实践及redis性能测试

类似于小米手机预约抢购，但这里预约是需要资格的，难点是高并发的处理。

 1.后台管理系统添加商品，字段包括sku、库存，抢购开始时间、抢购所需白条订单数，同时写入redis缓存

 2.前端系统直接从缓存查询展示商品及预约抢购信息

 3.订单累计系统接收消息累计用户订单数和金额，预约资格要用

 4.用户在前端系统预约商品，数据库记下预约记录，同时写入redis集群，按用户分片，写入成功后扣减预约资格

 5.开抢前一个小时给用户发送抢购提醒通知

 6.抢购开始，前端系统从redis集群(或本地缓存如BitSet)检查用户是否有预约，有则调用抢购系统的抢购服务，并进行防刷和已抢购检查。

 7.抢购服务从redis检查商品库存b，若b<=0，提示已抢光，否则执行b--，判断和减库存作为原子操作一次性提交给redis。redis成功返回后，发送MQ(可降级为RPC调用)，由抢购结果系统进行后续处理，若发送MQ成功，则提示抢购成功或已抢光，若失败，则回滚之前的redis操作，提示抢购失败请重试。

 8.抢购结果系统记录抢购结果，领优惠券

注：redis回滚失败表示少卖，是允许的。

考虑问题：单个商品的库存用一个redis?在这种应用场景下，系统必须限流。抢购做成服务便于水平扩展， 便于需求变化。

 

lua:

local b = redis.call(‘get’, KEYS[1]);

if b <= 0 then

  return 0

else

  redis.call(‘INCRBY’, KEYS[1], -1);

 

  return 1

 

java:

String script = "...";

String key = "..."; // 商品库存缓存key

String sha = jedis.scriptLoad(script);

int result = (Integer) jedis.evalsha(sha, 1, key);

 

 

redis发布版本中自带了redis-benchmark性能测试工具;

示例：

使用50个并发连接，发出100000个请求，每个请求的数据为2kb，

测试host为127.0.0.1 端口为6379的redis服务器性能：

./redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -d 2

...

====== SADD ======
  100000 requests completed in 2.27 seconds
  500 parallel clients
  3 bytes payload
  keep alive: 1

4.66% <= 1 milliseconds
14.15% <= 2 milliseconds
23.87% <= 3 milliseconds
33.59% <= 4 milliseconds
43.13% <= 5 milliseconds
52.69% <= 6 milliseconds
62.08% <= 7 milliseconds
71.43% <= 8 milliseconds
80.66% <= 9 milliseconds
89.10% <= 10 milliseconds
95.23% <= 11 milliseconds
98.76% <= 12 milliseconds
99.59% <= 13 milliseconds
99.78% <= 14 milliseconds
99.87% <= 15 milliseconds
99.95% <= 16 milliseconds
99.99% <= 17 milliseconds
100.00% <= 17 milliseconds
44150.11 requests per second

我们关注结果最后一行：每秒44150.11个请求，既QPS4.4万；但这里的数据都只是测试数据，测出来的QPS不能代表实际生产的处理能力；

测算redis处理实际生产请求的QPS/TPS

在实际生产中，我们需要关心这个指标，在我们的应用场景中，redis能够处理的最大的(QPS/TPS)是多少？

测量redis QPS的方式有两种：

1. 估计生产的报文大小，使用benchmark工具指定-d数据块大小来模拟；

2. 使用redis-cli中info统计信息计算差值；redis-cli的info命令中有一项total_commands_processed表示：从启动到现在处理的所有命令总数，可以通过统计两次info指令间的差值来计算QPS：

//返回redis-cli info中total_commands_processed的结果 
long getCmdProcessNum(redisContext *c)
{
	string strVal;
	getInfo(c,strVal);
	map<string,string> mpVal;
	parserInfo(strVal,mpVal);
	map<string,string>::iterator  iter = mpVal.find("total_commands_processed");
	if(iter != mpVal.end())
	{
		return atol(iter->second.c_str());
	}
	cout << "[err] not found total_commands_processed" << endl;
	return 0;
}

程序实现很简单，就不全贴在这里了，完整代码详见github：

https://github.com/me115/cppset/tree/master/redisTPS

在实际生产中，运行这个程序来统计实际的QPS。运行示例：

/opt/app/redisTPS#./redisTPS 
Time:  1  Process:40962  TPS:40839.48
Time:  1  Process:43741  TPS:43610.17
Time:  1  Process:38935  TPS:38779.88
Time:  1  Process:31724  TPS:31597.61
Time:  1  Process:32169  TPS:32008.96
Time:  1  Process:31634  TPS:31476.62
Time:  1  Process:46007  TPS:45823.71
Time:  1  Process:50460  TPS:50258.96
Time:  1  Process:47309  TPS:47167.50
Time:  1  Process:50511  TPS:50359.92
...

原文链接:[http://wely.iteye.com/blog/2361500]