openGemini+Nginx：集群访问负载均衡

我们知道，openGemini集群由ts-sql, ts-store和ts-meta三个组件组成，其中ts-sql负责处理客户端请求，在并发量比较大的业务场景中，通常需要部署多个ts-sql，以分担压力，如下图所示：

这种情况下，客户端需要同时管理多个与ts-sql的连接，以及维护多ts-sql之间的负载均衡，稍显复杂。那么有没有更好的办法？

答案是肯定的。如果在客户端和集群之间设置一个反向代理，那么事情就变得简单多了，客户端仅需要维护与反向代理的连接，其余的工作交由反向代理来完成。如下图所示：

什么是反向代理？

简单来说，反向代理是指以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

Nginx反向代理

openGemini搭配Nginx反向代理，非常高效解决了openGemini集群的负载均衡问题，接下来以下图所示部署场景为例，对Nginx的反向代理配置进行详细说明。

环境准备

Nginx安装

https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/

openGemini安装

https://github.com/openGemini/community

Nginx反向代理配置

Nginx的关键配置如下所示：

{
  # 设置Nginx并发处理的worker数量，可以为具体数值，也可以设置为auto
  # 通常建议为节点CPU的核数
  worker_processes auto;
  …
  events {
    # Nginx处理的最大连接数（这里可以进行数据库流控），默认为1024
    # 需根据业务实际运行情况进行调整。
    worker_connections  1024;
  }
  http {
    …
    # 负载均衡默认采用轮询方法
    upstream openGemini {
      server 192.168.0.1:8086;
      server 192.168.0.2:8086;
      server 192.168.0.3:8086;
    }
    server {
      # 可按IP:Port形式指定Nginx监听地址和端口，默认是在所有地址监听
      # 8086是openGemini ts-sql组件默认的服务监听端口，这里可以修改为其他
      listen 8086;
      # location 后面的斜线‘/’不能少
      location / {
        # 这里的openGemini（可修改）与upstream 后面配置的名称（openGemini）
        # 需保持一致，否则无法转发
        proxy_pass http://openGemini；
      }
    }
  }
}

配置修改后，需要重启Nginx才能生效

测试验证

客户端写入数据和查询

总结