随笔 - 410 文章 - 0 评论 - 519 阅读 - 148万

从单体到分布式，必须解决的四个问题

阅读目录

一，session共享
二，本地缓存
三，文件服务
四，分布式环境下线程同步问题

一般来说，为了应对高并发和高可用，应用服务器都会由单体向分布式演变。而从单体到分布式，通常会遇到四个问题必须要去解决。

回到顶部

一，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

那么，顺利解决了以上四个问题之后，我们的系统架构就演变成以下这个样子。