面试题二 分布式锁和分布式session

一、Zookeeper的作用

1、分布式系统间的协调

A系统发消息到MQ，并在zk的某个节点注册监听器，B系统消费后修改zk那个节点的值，A立马就可以收到通知

2、分布式锁

节点尝试创建临时的znode，创建成功了就获取锁。别的节点尝试获取锁，却获取不到，就对这个锁注册一个监听器，当原来的节点释放锁后，新的节点就会感知到，然后尝试重新获取锁

3、注册中心、配置信息管理

kafka、storm、dubbo选用zk做一些元数据、配置信息的管理

4、HA高可用

重要进程做主备两个机器，主机器挂了就通过ZK切换到备用机器，备用机器就升级到主机器，原来的主机器恢复后就变成备用机器。比如hadoop，hdfs

二、比较下Redis和Zookeeper的分布式锁的区别

1、Redis上锁

方案一：

系统A在redis中设置  set [key] [随机值1] NX PX 30000（NX：键不存在时才创建，PX：键的过期时间30000毫秒），这样系统B、C再设置时，由于已经设置过了，就返回true，所以只能A来运行。运行完后，释放锁（释放锁就是删除key）

如果设置之后，系统A运行时间过长，超过了30秒，那么这个key就会失效。此时系统B、C已经拿到这个锁了，要是这个时候让A直接删除就会有问题。所以要设置一个随机值，当redis发现系统A的随机值和现在的随机值不同，就不会让你删除

问题：

如果redis的主节点挂了，又由于同步是异步的，那么key可能还没复制到从节点，别的系统就可以又拿到锁了

方案二  RedLock算法（官方推荐）：

2、基于临时顺序节点实现Zookeeper的分布式锁

3、两者区别

1）redis上锁很麻烦，RedLock算法还要搭建redis集群

2）redis获取不到锁，会不断尝试，比较消耗性能。zookeeper则是通过监听器，不需要不断重试

三、如何实现分布式Session

1、tomcat + redis

基于Tomcat原生的RedisSessionManager，在context.xml中进行配置。原理就是Tomcat将session存储到redis中，缺点在于依赖Tomcat，如果迁移Web容器比如迁移到jetty就无法使用了

2、Spring Session

通过Spring对session进行管理，从redis中读取、存储session