登录session改造，缓存redis后，如果redis崩了怎么办？

Question

因为现在自己公司的项目中用的是一致性哈希算法，保证同一个用户的会话能分配到同一台服务器上，所以一直没有仔细考虑过session共享问题。
看完课程中关于登录改造的部分，现在我的疑问是，如果多台服务器的用户登录信息放在一台redis上，那这台redis无法正常工作的情况下，所有服务器就都无法正常登录了，这不是违背了分布式的本意么？
当然我也想到可以做分布式redis，但是举一个具体的例子，假设我现在有8台服务器，他们都把登录信息存在一台redis上，那么这台redis无法正常工作了，这8台服务器就都不能正常登录了。所以为了避免这种情况，我可以加redis（缓存共享就又是另一个头疼的问题了），这里假设redis出异常的概率和服务器一样，那么我redis的台数少于8，都会降低系统的可用性啊。所以生产环境中到底是怎么考虑这个问题的？
因为冲着实战来的，所以除了学习架构知识外，还是想多了解一些实际生产中的解决方案，麻烦老师能指点一下

Answer 1

赵梨花 2018-08-05 14:48:29

建立redis集群就可以了，redis有一套原生的sentinel哨兵机制可以用

Answer 2

还是不会coding 2018-06-22 16:23:06

呃。。。没有完全理解你的意思。要是考虑高可用的话，可以考虑做redis主备，而且redis性能没那么差吧，8台服务器而已，如果redis读写没那么恐怖的话，一个主备就足够支撑了吧（哈哈，没有数据支撑，纯属胡说）。另外真的访问量特别大的话，应该还可以考虑接入mq，坐等Geely大牛权威解答。

• 提问者 生活没有bool型 #1

  嗯，因为访问量不大所以之前也没考虑过redis，只是单就可用性而言，以前session单独存在各自登录的服务器上，保证同一个会话一直访问这台服务器，如果这台服务器崩了，影响的也就是1/8的访问，而且再次登录访问被分配到其他服务器上，业务也是能正常用。只要服务器不是全部崩了，业务至少都能跑。
  但是这样简单统一到redis后，redis崩了，不管多少服务器都不能正常访问业务了吧。

• 还是不会coding 回复 提问者 生活没有bool型 #2

  对的呀，session拿出来之后，所有的服务器都只会去redis上读和写session，redis挂了当然是会出问题，如果现有架构可以支撑当前业务的话，并且暂时没有多余的资源搭建redis集群的话，暂时可以维持现状，将session共享作为一种备用解决方案就好咯，如果服务器日常性挂掉。。。那就影响大了