1、redis 集群

2、mongodb 集群

3、nginx 集群

3.1 高可用策略

3.2 负载策略

(1) 轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

(2) weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

(3) ip_hash

使用该方案可以避免两个问题：

• session问题
• 分片上传问题

当你服务端的一个特定url路径会被同一个用户连续访问时，如果负载均衡策略还是轮询的话，那该用户的多次访问会被打到各台服务器上，这显然并不高效（会建立多次http链接等问题）。甚至考虑一种极端情况，用户需要分片上传文件到服务器下，然后再由服务器将分片合并，这时如果用户的请求到达了不同的服务器，那么分片将存储于不同的服务器目录中，导致无法将分片合并。所以，此类场景可以考虑采用nginx提供的ip_hash策略。既能满足每个用户请求到同一台服务器，又能满足不同用户之间负载均衡

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

缺点：服务器down掉之后，不会像轮询机制一样剔除出问题的服务器

解决：可以通过 nginx_upstream_check_module 插件解决该问题

4、iris session在redis集群模式下登录问题

iris session 存储可以配置redis，但是其所给的库中的redis并没有集群模式，需要重新database.go文件，把redis的实例换为我们的redis集群下的实例

5、集群环境下授权认证问题

将单机授权换为集群授权，生成集群模式下授权码

6、集群环境下的配置分发与命令下发

以CDN服务器为例：

①用户发起修改cdn-2 配置的post request

②请求由于nginx ip_hash 映射到server2上

③server2 更新配置到数据库中

④server2 请求发布cdn-2 的新配置

⑤redis 发布㈡cdn配置更新事件

⑥server3 通过socketio 向 cdn-2 发布最新配置

注意：server1,server2 仍然会收到redis的发布信息，但是不会进行配置的发送

由于redis 发布订阅的不可靠性，可能需要增加配置定期校验功能