Redis的解决

Redis实现分布式锁
Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则SETNX不做任何动作
SETNX是[SETif Not eXists] (如果不存在，则SET)的简写

返回值:设置成功，返回 1。设置失败，返回 0
     127..日.1:6379> setnx lock-key value1integer)1
      12?.日.0.1:6379> setnx lock-key value2integer>日127.日.日.1:6379> get lock-key"value1"

使用SETNX完成同步锁的流程及事项如下(mg:使用SETNX命令获取锁若返回0key已存在，锁已存在则获取失败，反之获取成功为了防止获取后程序出现异常，导致其他线程/进程调用SETNX命令总是返回
0而进入死锁状态，需要为该key设置一个“合理”的过期时间释放锁，使用DEL命令将锁数据删除
如何解决 Redis 的并发竞争 Key 问题
所谓Redis 的并发竞争Key 的问题也就是多个系统同时对一个key 进行操作，但是 后执行的质序和我们期望的序不同，这样也就导致了结果的不同!

推荐一种方案:分布式锁(zokeeper和 redis 都可以实现分布式锁)。(如果不存在 Redis 的并发竞争 ey问题，不要使用分布式锁，这样会影响性能)基于2o0keeper临有序节点可以实现的分布式锁，大致思想为:每个客户端对某个方法加锁时，在zo0keeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点，判断是否获取锁的式很简单，只需要判断有序节点中号 小的一个，当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。
在实践中，当然是从以可靠性为主，所以首推Zookeeper.

分布式Redis是前期做还是后期规模上来了再做好?为什么?
既然Redis是如此的轻量单实例只使用1M内存)，为防止以后的广容，好的办法就是一开始就启动较多实例。即便你只有一合服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。
开始就多设置几个Redis实例，例3或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺性是值得的，
这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已《而不用考虑重新分区的问题)。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。