一般来说,为了应对高并发和高可用,应用服务器都会由单体向分布式演变。而从单体到分布式,通常会遇到四个问题必须要去解决。
一,session共享
首先第一个要解决的就是sesison共享的问题,如下图。
通常有两种解决方案,第1种是配置nginx的负载集群策略为ip_hash,第2种是将session存储到其它地方,一般推荐放到redis中。
第1种方案适合于临时解决或者是为了兼容历史项目,但是从应用服务器无状态的角度考虑,推荐把用户会话session放到redis,如下图。
二,本地缓存
如果使用本地缓存,当从单体迁移到集群后,就会面临缓存同步的问题,如下图。
最佳实践是上分布式缓存,既解决了缓存同步的问题,也释放了应用服务器的内存资源,如下图。
三,文件服务
应用服务器在上集群之前,文件通常会放在本地,或者单独的文件服务器上,因为文件服务需要占用大量的硬盘空间,以上两种方案都无法很好的解决硬盘扩容的问题,最佳实践是放到云存储上,比如阿里云的OSS,或者腾讯云的COS上,这样可以做到按需扩容,如下图。
四,分布式环境下线程同步问题
在单机环境下,使用lock就可以解决线程同步的问题,一旦上了集群之后,lock就不管用了,这时需要上分布式锁,分布式锁的解决方案也有很多,我这里推荐使用redis的setnx,需要注意的是,如果redis是集群部署的,需要考虑这种情形:假设我们在redis的主节点上添加了一把分布式锁,不幸的是主节点挂掉了,而且主节点上的锁还没有同步到从节点上,如果此时有客户端来请求获得同一把锁,那么它将顺利地获得锁,之前那把锁会被无情地忽视掉,这就是分布式锁在Redis集群中遇到的麻烦。
为了解决这个问题,Redis的作者提出了Redlock的算法来解决这个问题,推荐大家直接使用这个开源项目:https://github.com/samcook/RedLock.net
那么,顺利解决了以上四个问题之后,我们的系统架构就演变成以下这个样子。