Redis脚本实现分布式锁

原创
2015/01/11 19:19
阅读数 10K

       redis被大量用在分布式的环境中,自然而然分布式环境下的锁如何解决,立马成为一个问题。例如我们当前的手游项目,服务器端是按业务模块划分服务器的,有应用服,战斗服等,但是这两个vm都有可能同时改变玩家的属性,这如果在同一个vm下面,就很容易加锁,但如果在分布式环境下就没那么容易了,当然利用redis现有的功能也有解决办法,比如redis的脚本。

       redis在2.6以后的版本中增加了Lua脚本的功能,可以通过eval命令,直接在RedisServer环境中执行Lua脚本,并且可以在Lua脚本中调用Redis命令。
使用脚本的好处:
1.减少网络开销:可以把一些要批量处理的功能,发在一个脚本里面执行,减少客户端和redis的交互次数
2.原子操作:这主要就是我们在这边主要利用的功能,在分布式环境下保证数据的原子性。
3.复用:客户端发送的脚本会永久的存储在redis中,这就意味着其他客户端可以复用这一脚本而不需要使用代码完成同样的逻辑。

下面先看一段lua脚本:

local food=redis.call('hget',KEYS[1],'food');
food=food+ARGV[1];
redis.call('hset',KEYS[1],'food',food);
local diamond=redis.call('hget',KEYS[1],'diamond');
diamond=diamond+ARGV[2];
redis.call('hset',KEYS[1],'diamond',diamond);

注:redis.call是我们在脚本中调用redis命令,KEYS和ARGV2个数组,分别是键和参数,下标都是从1开始的,不是0。
这段脚本的功能是取出 KEYS指定的玩家food(粮草)和diamond(玉石),然后就行修改,最后保存在redis中,脚本的执行,保证了整个操作的原子性。

下面我们用java代码来看看具体的实现过程

Jedis jedis = new Jedis("192.168.128.128", 6379);
// 1.初始玩家数据到redis中
GamePlayer player = new GamePlayer();
player.setId(1001);
player.setName("ksfzhaohui");
player.setFood(100);
player.setDiamond(100);

Map<String, String> beanMap = BeanUtil.warp(player);// 将对象转换成map
String beanKey = getRedisBeanKey(player.getClass(), player.getId());
System.out.println("key:" + beanKey);
jedis.hmset(beanKey, beanMap);// 将玩家数据保存到redis中

首先模拟了一个玩家将玩家信息保存在redis中,这边的Id随便写了一个,正常的情况下都是通过redis的命令incr生成一个id
结果:
 

String script = "local food=redis.call('hget',KEYS[1],'food');"
				+ "food=food+ARGV[1];"
				+ "redis.call('hset',KEYS[1],'food',food);"
				+ "local diamond=redis.call('hget',KEYS[1],'diamond');"
				+ "diamond=diamond+ARGV[2];"
				+ "redis.call('hset',KEYS[1],'diamond',diamond);";
List<String> keys = new ArrayList<String>();
keys.add(beanKey);
List<String> args = new ArrayList<String>();
args.add("100");
args.add("100");
// 3.执行脚本
jedis.eval(script, keys, args);

指定键和参考,执行脚本,结果:

BeanUtil代码:

public class BeanUtil {
	private static Logger logger = Logger.getLogger(BeanUtil.class);
	private static final String CLASS = "class";

	/**
	 * 将指定的对象数据封装成map
	 * 
	 * @param bean
	 *            对象数据
	 * @return
	 */
	@SuppressWarnings("all")
	public static Map<String, String> warp(Object bean) {
		Map<String, String> propertyMap = new HashMap<String, String>();
		try {
			PropertyDescriptor[] ps = Introspector.getBeanInfo(bean.getClass())
					.getPropertyDescriptors();
			for (PropertyDescriptor propertyDescriptor : ps) {
				String propertyName = propertyDescriptor.getName();
				if (propertyName != null && !propertyName.equals(CLASS)) {
					Method getter = propertyDescriptor.getReadMethod();
					if (getter != null) {
						propertyMap.put(propertyName,
								String.valueOf(getter.invoke(bean, null)));
					}
				}
			}
		} catch (Exception e) {
			logger.error(e);
		}
		return propertyMap;
	}

}

当然网上还有一些其他的方法,如: 用SETNX实现分布式锁
可以参考:http://phl.iteye.com/blog/2029944

个人博客:http://codingo.xyz

展开阅读全文
打赏
14
137 收藏
分享
加载中

引用来自“STG0825”的评论

脚本是原子操作,极端情况下,同参数的两个脚本同时执行时,依旧有风险.
是否可以在脚本执行开始,使用SETNX锁住关键字,脚本结束时释放,避免脚本见的竞争。

引用来自“ksfzhaohui”的评论

SETNX确实可以在代码层面进行处理,但是不太清楚为什么脚本同时执行时,依旧有风险.
理解@STG0825的意思应该是在 diamond=diamond+ARGV 这条语句并发调用时候的问题,例如java在多线程情况下,变量有可能是copy的,例如 100个同时+2的同时调用,其结果远远小于 +200 的情况。
2015/01/15 15:48
回复
举报
ksfzhaohui博主

引用来自“西夏一品堂”的评论

分布式锁
干啥用的?
在不同vm下面保证原子性操作
2015/01/15 13:13
回复
举报
ksfzhaohui博主

引用来自“STG0825”的评论

脚本是原子操作,极端情况下,同参数的两个脚本同时执行时,依旧有风险.
是否可以在脚本执行开始,使用SETNX锁住关键字,脚本结束时释放,避免脚本见的竞争。
SETNX确实可以在代码层面进行处理,但是不太清楚为什么脚本同时执行时,依旧有风险.
2015/01/15 13:12
回复
举报
分布式锁
干啥用的?
2015/01/15 12:58
回复
举报
脚本是原子操作,极端情况下,同参数的两个脚本同时执行时,依旧有风险.
是否可以在脚本执行开始,使用SETNX锁住关键字,脚本结束时释放,避免脚本见的竞争。
2015/01/15 11:30
回复
举报
FYI: http://netkiller.github.io/journal/scheduler.html
2015/01/15 09:49
回复
举报
不明觉厉
2015/01/15 09:42
回复
举报
redis的这个功能有点类似DBMS的数据函数或者存储过程,只是借助Lua脚本实现之。存储过程的形式有利于数据组织的封装,对于分布式锁,可以用multi解决一部分问题,但是锁毕竟是降低效率的行为。最好能从设计上优化之。
2015/01/15 09:18
回复
举报
2015/01/15 08:20
回复
举报
更多评论
打赏
9 评论
137 收藏
14
分享
返回顶部
顶部