本文转载自微信公众号,孤独烟
本文故事绝对真实,如有雷同,绝对不是巧合!
话说前几天有一次,某大厂的二面。然后呢,烟哥那天刚好有事,所以去不了。于是就约了一场视频面试了!
于是呢,烟哥提前十分钟在公司里头找了一个厕所的坑位,然后进去随手一锁门….(以下省略10000字)…
唉…
我竟然…
我竟然…
我竟然又带薪上厕所了,而且上了一小时!我有罪!
额,是这样的,大厂的厕所是有雅间的。所以环境还马马虎虎,鼻子还是正常的!
OK,交待完背景,然后开始我们的主题!
全局session
当时的情形是这样的,先介绍一下自己的项目。然后介绍完项目背景以后,因为有一个登陆模块。于是乎有了如下问题
面试官:“先说说全局Session干嘛用的,你们那边全局session是怎么做的?”
这个问题还是很容易的。因为一个应用通常有多台服务器,在登陆成功后,Session只会在其中某一台存储。需要想办法让多台服务器都识别到这个Session,因此才有了这个全局Session的概念。我们用的是后端统一存储的策略,有专门的用户管理系统,上面存储着用户信息以及Session状态。
烟哥注:目前业内在解决全局Sesssion上无外乎四种方法
- (1)服务端自己进行同步,例如早期的项目,大概是07年那会的(我司老古董项目啊),那会Tomcat的集群能力不行。用的是Weblogic服务器,使用的就是Weblogic的Session复制功能。
- (2)客户端存储法,将session存储到浏览器cookie中,每次http请求都带session。这里摸着良心坦白说,该方案从没用过,安全性太差。
- (3)反向代理hash一致性,不需要修改应用代码。修改nginx的配置,保证同一个ip的请求落在同一个web-server上即可。
- (4)后端统一存储,后端统一找一个中间件将Session存起来即可,这个中间件是数据库或者缓存。
面试官:“那你知道这个平台里Session怎么管理的么?”
必须不知道啊!对我们来说该平台只是一个黑盒,会调接口即可。
于是乎,一个让我头疼的问题出现了!
面试官:“如果让你设计这样一个平台,管理这些Session,你会怎么设计?”
用redis来存储Session,用sessionId作为key,用session当value进行存储。
OK,这时我头脑浮现的架构是这样的
面试官:"如果redis挂了呢?"
咦,这个时候,我突然懵了。面试官到底想问我什么?难道挂了,不是redis从服务器顶上么?这个问题莫非有什么玄机?
然后我是这样答的。
一般情况,主redis挂了,由从redis顶上。如果redis某个slot的主从节点全挂了,
那么我们在rediscluster中有一个配置叫
cluster-require-full-coverage
当cluster-require-full-coverage为no时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群仍然可用。但是该槽的相关命令不可用。
当cluster-require-full-coverage为yes时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群不可用。
该值默认值为yes,也就是集群处于不可用的状态。
这个时候,可能出现了网络中断!
面试官:"你的意思是,redis挂了,整个集群数据就不可用了?"
我回答嗯嗯,是的!
这个时候,面试官
面试官:"你不知道一致性哈希算法么?回去了解一下!"
然后我突然懵了。原来是我想太多,他这样问完,我才get到他问的点。
烟哥注:所以我才说这个面试我有点失败,和面试官不在一个频道上。如果是现场面,可以现场画图,则不会出现这种问题!
面试官想到的架构应该是这样的