java中间件 - redis分布式问题

Redis实现分布式锁？
Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接
并不存在竞争关系Redis中可以使用setNx命令实现分布式锁。
当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则 setNx不做任何动作
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
返回值：设置成功，返回 1 。设置失败，返回 0 。
使用setNx完成同步锁的流程及事项如下：
使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功
为了防止获取锁后程序出现异常，导致其他线程/进程调用setNx命令总是返回0而进入死锁状态，
需要为该key设置一个“合理”的过期时间释放锁，使用DEL命令将锁数据删除

如何解决 Redis 的并发竞争 Key 问题
所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺
序和我们期望的顺序不同，这样也就导致了结果的不同！
推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并
发竞争 Key 问题，不要使用分布式锁，这样会影响性能）
基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加锁时，
在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否
获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬
时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流
程后，删除对应的子节点释放锁。
在实践中，当然是从以可靠性为主。所以首推Zookeeper。

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

什么是 RedLock
Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的
单节点的方法更安全。它可以保证以下特性：

1. 安全特性：互斥访问，即永远只有一个 client 能拿到锁
2. 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client
   crash 了或者出现了网络分区
3. 容错性：只要大部分 Redis 节点存活就可以正常提供服务