架构师系列-Nginx、OpenResty（三）- 负载均衡配置

Nginx负载均衡

负载均衡用于从“upstream”模块定义的后端服务器列表中选取一台服务器接受用户的请求，一个最基本的upstream模块是这样的，模块内的server是服务器列表：

#动态服务器组
upstream dynamicserver {server 172.16.44.47:9001; #tomcat 1server 172.16.44.47:9002; #tomcat 2server 172.16.44.47:9003; #tomcat 3server 172.16.44.47:9004; #tomcat 4
}

在upstream模块配置完成后，要让指定的访问反向代理到服务器列表

#其他页面反向代理到tomcat容器
location ~.*$ {index index.jsp index.html;proxy_pass http://dynamicserver;
}

这就是最基本的负载均衡实例，但这不足以满足实际需求；目前Nginx服务器的upstream模块支持6种方式的分配。

完整配置文件如下

upstream dynamicserver {server 192.168.64.1:9001; #tomcat 1server 192.168.64.1:9002; #tomcat 2server 192.168.64.1:9003; #tomcat 3server 192.168.64.1:9004; #tomcat 4
}
server {server_name www.itcast.com;default_type text/html;charset   utf-8;location ~ .*$ {index index.jsp index.html;proxy_pass http://dynamicserver;}
}

常用参数

参数描述
server反向服务地址 加端口
weight权重
fail_timeout与max_fails结合使用。
max_fails设置在fail_timeout参数设置的时间内最大失败次数，如果在这个时间内，所有针对该服务器的请求都失败了，那么认为该服务器会被认为是停机了
max_conns允许最大连接数
fail_time服务器会被认为停机的时间长度,默认为10s
backup标记该服务器为备用服务器，当主服务器停止时，请求会被发送到它这里。
down标记服务器永久停机了
slow_start当节点恢复，不立即加入

负载均衡策略 

在这里，只详细说明Nginx自带的负载均衡策略。

负载策略描述
轮询默认方式
weight权重方式
ip_hash依据ip分配方式
least_conn最少连接方式
fair（第三方）响应时间方式
url_hash（第三方）依据URL分配方式

轮询 

最基本的配置方法，上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略，每个请求会按时间顺序逐一分配到不同的后端服务器。

#动态服务器组
upstream dynamicserver {server 192.168.64.1:9001; #tomcat 1server 192.168.64.1:9002; #tomcat 2server 192.168.64.1:9003; #tomcat 3server 192.168.64.1:9004; #tomcat 4
}

 注意

  • 在轮询中，如果服务器down掉了，会自动剔除该服务器。
  • 缺省配置就是轮询策略。
  • 此策略适合服务器配置相当，无状态且短平快的服务使用。

 配置示例

upstream dynamicserver {server 192.168.64.1:9001; #tomcat 1server 192.168.64.1:9002; #tomcat 2server 192.168.64.1:9003; #tomcat 3server 192.168.64.1:9004; #tomcat 4
}server {server_name www.test.com;default_type text/html;charset   utf-8;location ~ .*$ {index index.jsp index.html;proxy_pass http://dynamicserver;}
}

 weight

权重方式，在轮询策略的基础上指定轮询的几率

#动态服务器组
upstream dynamicserver {server 192.168.64.1:9001  weight=2;                   #tomcat 1server 192.168.64.1:9002;                             #tomcat 2server 192.168.64.1:9003;                         #tomcat 3server 192.168.64.1:9004; #tomcat 4
}

weight参数用于指定轮询几率，weight的默认值为1,；weight的数值与访问比率成正比，比如Tomcat 7.0被访问的几率为其他服务器的两倍。

注意

  • 权重越高分配到需要处理的请求越多。
  • 此策略可以与least_conn和ip_hash结合使用。
  • 此策略比较适合服务器的硬件配置差别比较大的情况。

 ip_hash

指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，以保证session会话，这样每个访客都固定访问一个后端服务器，可以解决session不能跨服务器的问题

upstream dynamicserver {ip_hash;  #保证每个访客固定访问一个后端服务器server 192.168.64.1:9001  weight=2;                   #tomcat 1server 192.168.64.1:9002;                             #tomcat 2server 192.168.64.1:9003;                         #tomcat 3server 192.168.64.1:9004; #tomcat 4
}

注意

  • 在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）。
  • ip_hash不能与backup同时使用
  • 此策略适合有状态服务，比如session。
  • 当有服务器需要剔除，必须手动down掉。

least_conn 

把请求转发给连接数较少的后端服务器，轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高，这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

upstream dynamicserver {least_conn;  #把请求转发给连接数较少的后端服务器server 192.168.64.1:9001  weight=2;                   #tomcat 1server 192.168.64.1:9002;                             #tomcat 2server 192.168.64.1:9003;                         #tomcat 3server 192.168.64.1:9004; #tomcat 4
}
  • 此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。

 重试策略

现在对外服务的网站，很少只使用一个服务节点，而是部署多台服务器，上层通过一定机制保证容错和负载均衡。

基础失败重试 

为了方便理解，使用了以下配置进行分析（proxy_next_upstream 没有特殊配置）

upstream dynamicserver {server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #Server Aserver 192.168.64.1:9002 fail_timeout=60s max_fails=3; #Server B
}

配置说明

max_fails=3 fail_timeout=60s代表在60秒内请求某一应用失败3次，认为该应用宕机，后等待60秒，这期间内不会再把新请求发送到宕机应用，而是直接发到正常的那一台，时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次，如果还是失败，则继续等待60秒...以此循环，直到恢复

模拟异常

模拟后端异常的方式是直接将对应服务关闭，造成 connect refused 的情况，对应 error 错误。

在最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个 Server 处理。假设这时 A 节点服务崩溃，端口不通，则会出现这种情况：

  1. 请求 1 转到 A 异常，再重试到 B 正常处理，A fails +1
  2. 请求 2 转到 B 正常处理
  3. 请求 3 转到 A 异常，再重试到 B 正常处理，A fails +1 达到 max_fails 将被屏蔽 60s
  4. 屏蔽 A 的期间请求都只转给 B 处理，直到屏蔽到期后将 A 恢复重新加入存活列表，再按照这个逻辑执行

如果在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现：

  1. 请求 1 转到 B 异常，此时所有线上节点异常，会出现：

    • AB 节点一次性恢复，都重新加入存活列表
    • 请求转到 A 处理异常，再转到 B 处理异常
    • 触发 no live upstreams 报错，返回 502 错误
    • 所有节点再次一次性恢复，加入存活列表

  2. 请求 2 依次经过 AB 均无法正常处理， 触发 no live upstreams 报错，返回 502 错误

 错误重试

有时候我们系统出现500等异常的情况下，希望nginx能够到其他的服务器进行重试，我们可以配置那些错误码才进行重试。在nginx的配置文件中，proxy_next_upstream项定义了什么情况下进行重试，官网文档中给出的说明如下

Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ...;
Default:    proxy_next_upstream error timeout;
Context:    http, server, location

默认情况下，当请求服务器发生错误或超时时，会尝试到下一台服务器，还有一些其他的配置项如下：

错误状态描述
error与服务器建立连接，向其传递请求或读取响应头时发生错误;
timeout在与服务器建立连接，向其传递请求或读取响应头时发生超时;
invalid_header服务器返回空的或无效的响应;
http_500服务器返回代码为500的响应;
http_502服务器返回代码为502的响应;
http_503服务器返回代码为503的响应;
http_504服务器返回代码504的响应;
http_403服务器返回代码为403的响应;
http_404服务器返回代码为404的响应;
http_429服务器返回代码为429的响应（1.11.13）;
non_idempotent通常，请求与 非幂等 方法（POST，LOCK，PATCH）不传递到请求是否已被发送到上游服务器（1.9.13）的下一个服务器; 启用此选项显式允许重试此类请求;
off禁用将请求传递给下一个服务器。

配置说明 

这里面我们配置了500等错误的时候会进行重试

upstream dynamicserver {server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #tomcat 1server 192.168.64.1:9002 fail_timeout=60s max_fails=3; #tomcat 2
}server {server_name www.itcast.com;default_type text/html;charset   utf-8;location ~ .*$ {index index.jsp index.html;proxy_pass http://dynamicserver;#下一节点重试的错误状态proxy_next_upstream error timeout http_500 http_502 http_503 http_504;}
}

模拟异常

在正常的情况下如果500错误会直接出现异常页面，现在我们加入了以上500重试策略，重试错误的流程和上面流程是一样的

 backup 服务器

Nginx 支持设置备用节点，当所有线上节点都异常时启用备用节点，同时备用节点也会影响到失败重试的逻辑，因此单独列出来介绍。

backup 处理逻辑

upstream 的配置中，可以通过 backup 指令来定义备用服务器，其含义如下

  1. 正常情况下，请求不会转到到 backup 服务器，包括失败重试的场景
  2. 当所有正常节点全部不可用时，backup 服务器生效，开始处理请求
  3. 一旦有正常节点恢复，就使用已经恢复的正常节点
  4. backup 服务器生效期间，不会存在所有正常节点一次性恢复的逻辑
  5. 如果全部 backup 服务器也异常，则会将所有节点一次性恢复，加入存活列表
  6. 如果全部节点（包括 backup）都异常了，则 Nginx 返回 502 错误

配置说明 

upstream dynamicserver {server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #Service Aserver 192.168.64.1:9002 fail_timeout=60s max_fails=3; #Server Bserver 192.168.64.1:9003 backup; #backup
}server {server_name www.itcast.com;default_type text/html;charset   utf-8;location ~ .*$ {index index.jsp index.html;proxy_pass http://dynamicserver;#下一节点重试的错误状态proxy_next_upstream error timeout http_500 http_502 http_503 http_504;}
}

在最初始阶段，所有服务器都正常，请求会按照轮询方式依次转发给 AB 两个节点处理。当只有 A 异常的情况下，与上文没有 backup 服务器场景处理方式一致，这里就不重复介绍了。

假设在 A 的屏蔽期还没结束时，B 节点的服务也崩溃，端口不通，则会出现：

  1. 请求 1 转到 B 处理，异常，此时所有线上节点异常，会出现：

    • AB 节点一次性恢复，都重新加入存活列表
    • 请求转到 A 处理异常，再重试到 B 处理异常，两者 fails 都 +1
    • 因 AB 都异常，启用 backup 节点正常处理，并且 AB 节点一次性恢复，加入存活列表

  2. 请求 2 再依次经过 A、B 节点异常，转到 backup 处理，两者 fails 都达到 max_fails：

    • AB 节点都将会被屏蔽 60s，并且不会一次性恢复
    • backup 节点正式生效，接下来所有请求直接转到 backup 处理
    • 直到 AB 节点的屏蔽到期后，重新加入存活列表

假设 AB 的屏蔽期都还没结束时，C 节点的服务也崩溃，端口不通，则会出现

  1. 请求 1 转到 C 异常，此时所有节点（包括 backup）都异常，会出现：

    • ABC 三个节点一次性恢复，加入存活列表
    • 请求转到 A 处理异常，重试到 B 处理异常，最后重试到 C 处理异常
    • 触发 no live upstreams 报错，返回 502 错误
    • 所有节点再次一次性恢复，加入存活列表

  2. 请求 2 依次经过 AB 节点异常，重试到 C 异常，最终结果如上个步骤，返回 502 错误

 限制重试方式

默认配置是没有做重试机制进行限制的，也就是会尽可能去重试直至失败，Nginx 提供了以下两个参数来控制重试次数以及重试超时时间

  • proxy_next_upstream_tries：设置重试次数，默认 0 表示无限制，该参数包含所有请求 upstream server 的次数，包括第一次后之后所有重试之和；
  • proxy_next_upstream_timeout：设置重试最大超时时间，默认 0 表示不限制，该参数指的是第一次连接时间加上后续重试连接时间，不包含连接上节点之后的处理时间
upstream dynamicserver {server 192.168.64.1:9001 fail_timeout=60s max_fails=3; #Server Aserver 192.168.64.1:9002 fail_timeout=60s max_fails=3; #Server B
}server {server_name www.itcast.com;default_type text/html;charset   utf-8;location ~ .*$ {index index.jsp index.html;proxy_pass http://dynamicserver;# 表示重试超时时间是3sproxy_connect_timeout 3s;#表示在 6 秒内允许重试 3 次，只要超过其中任意一个设置，Nginx 会结束重试并返回客户端响应proxy_next_upstream_timeout 6s;proxy_next_upstream_tries 3;}
}

常用案例

代理静态文件

server {listen       10086;server_name  www.test.com;location / {proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header Host $http_host;proxy_set_header X-NginX-Proxy true;proxy_redirect off;}location /data/ {alias '/usr/local/data/'; #这里是重点，就是代理这个文件夹 expires    7d;}
}

访问 http://localhost:10086/data/下面的资源就是访问/usr/local/data文件夹的资源

反向代理 

server {listen       80;server_name  www.itcast.com;;location / {proxy_pass http://127.0.0.1:8080;index  index.html index.htm .jsp;}
}

跨域配置

server {listen       80;server_name  www.itcast.com;if ( $host ~ (.*).itcast.com){set $domain $1;##记录二级域名值}#是否允许请求带有验证信息add_header Access-Control-Allow-Credentials true;#允许跨域访问的域名,可以是一个域的列表，也可以是通配符*add_header Access-Control-Allow-Origin  *;#允许脚本访问的返回头add_header Access-Control-Allow-Headers 'x-requested-with,content-type,Cache-Control,Pragma,Date,x-timestamp';#允许使用的请求方法，以逗号隔开add_header Access-Control-Allow-Methods 'POST,GET,OPTIONS,PUT,DELETE';#允许自定义的头部，以逗号隔开,大小写不敏感add_header Access-Control-Expose-Headers 'WWW-Authenticate,Server-Authorization';#P3P支持跨域cookie操作add_header P3P 'policyref="/w3c/p3p.xml", CP="NOI DSP PSAa OUR BUS IND ONL UNI COM NAV INT LOC"';if ($request_method = 'OPTIONS') {##OPTIONS类的请求，是跨域先验请求return 204;##204代表ok}
}

防盗链

通过Referer实现防盗链比较基础，仅可以简单实现方式资源被盗用，构造Referer的请求很容易实现

场景：由于图片链接可以跨域访问，所以图片链接往往被其他网站盗用，从而增加服务器负担；

解决方案：nginx可以通过valid_referers配置进行防盗链配置

valid_referers 指令

指定合法的来源'referer', 他决定了内置变量$invalid_referer的值，如果referer头部包含在这个合法网址里面，这个变量被设置为0，否则设置为1. 需要注意的是：这里并不区分大小写的.

  • 语法: valid_referers none | blocked | server_names | string …;
  • 配置段: server, location

配置说明

  • none : 允许没有http_refer的请求访问资源；
  • blocked : 允许不是http://开头的，不带协议的请求访问资源；
  • 192.168.0.1 : 只允许指定ip来的请求访问资源；
  • *.google.com：允许*.google.com的域名请求访问资源

 配置代码

# 需要防盗的后缀
location ~* \.(jpg|jpeg|png|gif|bmp|swf|rar|zip|doc|xls|pdf|gz|bz2|mp3|mp4|flv)$#设置过期时间expires     30d;# valid_referers 就是白名单的意思# 支持域名或ip# 允许ip 192.168.0.1 的请求# 允许域名 *.google.com 所有子域名valid_referers none blocked 192.168.0.1 *.google.com;if ($invalid_referer) {# return 403;# 盗链返回的图片，替换盗链网站所有盗链的图片rewrite ^/ https://site.com/403.jpg;}root  /usr/share/nginx/img;
}

 

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/pingmian/2849.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

绿色便携方式安装apache+mysql+tomcat+php集成环境并提供控制面板

绿色便携方式安装apache+mysql+tomcat+php集成环境并提供控制面板

绿色便携方式安装带控制面板的ApacheMariaDBTomcatPHP集成环境 目录 绿色便携方式安装带控制面板的ApacheMariaDBTomcatPHP集成环境[TOC](目录) 前言一、XAMPP二、安装和使用1.安装2.使用 三、可能的错误1、检查端口占用2、修改端口 前言 安装集成环境往往配置复杂&#xff0c…
阅读更多...
无人机飞行特点

无人机飞行特点

你知道吗？无人机飞行竟然有这么多的神奇特点！ 🤩想象一下，它们如同天空中的自由精灵，不受束缚地穿梭在云端。 🚁 首先，无人机的飞行高度和角度都可以随心所欲地调整，无论是俯瞰美景…
阅读更多...
自动化立体库安全使用管理制度

自动化立体库安全使用管理制度

导语 大家好，我是智能仓储物流技术研习社的社长，老K。专注分享智能仓储物流技术、智能制造等内容。 新书《智能物流系统构成与技术实践》 完整版文件和更多学习资料，请球友到知识星球 【智能仓储物流技术研习社】自行下载 关于自动化立体库安…
阅读更多...
四、Flask进阶

四、Flask进阶

Flask-Cache pip install flask-caching安装flask_cache初始化 # ext.py from flask_sqlalchemy import SQLAlchemy from flask_migrate import Migrate from flask_caching import Cachedb SQLAlchemy() migrate Migrate() cache Cache(config{CACHE_TYPE: simple # 缓存…
阅读更多...
webpack、rollup、vite、esbuild 前端构建工具到底有什么关系和区别？

webpack、rollup、vite、esbuild 前端构建工具到底有什么关系和区别？

一、为什么需要构建工具，前端构建工具具体干了些什么？ 前端最开始的开发模式为HTMLJSCSS，写起来痛不欲生，要直面js操作dom、浏览器兼容js / css、代码压缩、开发中要不断手动刷新等问题。直到nodeJS后，出现了angular、…
阅读更多...
MybatisPlus（简单CURD，MP的实体类注解，MP条件查询，MP分页查询，MP批量操作，乐观锁，代码生成器）

MybatisPlus（简单CURD，MP的实体类注解，MP条件查询，MP分页查询，MP批量操作，乐观锁，代码生成器）

目录 一、MP入门 1. MP是什么 2. MP使用入门 1 说明 2 准备MP项目环境 1) 添加依赖 2) 创建配置文件 3) 创建引导类 3 MP使用入门 1 创建实体类 2 创建Mapper 3 使用测试 3. 小结 二、MP简单CURD【重点】 1. 说明 2. 示例 3. 小结 三、MP的实体类注解[重点] …
阅读更多...
字符串漏洞注入深入学习

字符串漏洞注入深入学习

字符串型漏洞注入，特别是针对Web应用程序的SQL注入，是一种常见的网络安全威胁。它涉及攻击者在不受控制的情况下，通过构造特定的字符串输入，干扰或改变应用程序中原有的SQL查询语句，从而执行恶意的SQL代码。 要深入学…
阅读更多...
常用vim命令

常用vim命令

vim 是一种文本编辑器，常用于命令行界面下。它具有强大的功能和灵活的配置选项，适用于编辑各种类型的文本文件，包括代码文件、配置文件等。使用 vim 可以进行文本的编辑、查找、替换、复制、粘贴等操作。 1、编辑文件 - vim filename&#x…
阅读更多...
微软Phi-3，3.8亿参数能与Mixtral 8x7B和GPT-3.5相媲美，量化后还可直接在IPhone中运行

微软Phi-3，3.8亿参数能与Mixtral 8x7B和GPT-3.5相媲美，量化后还可直接在IPhone中运行

Phi-3系列 Phi-3是一系列先进的语言模型，专注于在保持足够紧凑以便在移动设备上部署的同时，实现高性能。Phi-3系列包括不同大小的模型： Phi-3-mini（38亿参数） - 该模型在3.3万亿个令牌上进行训练，设计得足…
阅读更多...
go学习知识点

go学习知识点

学习 Go 语言涉及许多不同的概念和知识点。以下是一些关键的学习领域： 基础概念 变量和类型：了解 Go 的基本数据类型，如整型、浮点型、布尔型、字符串等，以及如何声明和使用变量。包管理：学习如何导入和使用其他包&a…
阅读更多...
【Stable Diffusion系列】（一）：AI绘画本地部署教程

【Stable Diffusion系列】（一）：AI绘画本地部署教程

目录 一、总览 二、本地部署 1、安装cuda 2、安装python 3、安装git 4、方法一 1）获取安装包 2）update 3）run 5、方法二 1）git clone 2）双击webui-user.bat 3）更新 6、设置启动参数 7、…
阅读更多...
指针（5）

指针（5）

前言 本节是有关指针内容的最后一节，本节的内容以讲解指针习题为主，那么就让我们一起来开启本节的学习吧！ sizeof和strlen的对比 1.sizeof 我们在学习操作符的时候，学习了sizeof。sizeof存在的意义是用来计算变量所占用的内存空…
阅读更多...
AI大模型日报#0424：全球首个AI基因编辑器、出门问问上市、微软开源Phi-3 Mini、昆仑万维年收49亿

AI大模型日报#0424：全球首个AI基因编辑器、出门问问上市、微软开源Phi-3 Mini、昆仑万维年收49亿

导读： 欢迎阅读《AI大模型日报》，内容基于Python爬虫和LLM自动生成。目前采用“文心一言”生成了每条资讯的摘要。标题: 爱诗科技完成A2轮超亿元融资，蚂蚁集团领投摘要: 爱诗科技完成A2轮超亿元融资，成为视频大模型领域融资规模最…
阅读更多...
STM32学习和实践笔记（20）：定时器

STM32学习和实践笔记（20）：定时器

1.定时器介绍 STM32F1的定时器一共有8个，由2个基本定时器（TIM6、TIM7）、4个通用定时器（TIM2-TIM5）和2个高级定时器（TIM1、TIM8）组成。 基本定时器的功能最为简单，类似于51单片机内定…
阅读更多...
前置路由守卫、后置路由守卫，前置请求守卫、后置请求守卫

前置路由守卫、后置路由守卫，前置请求守卫、后置请求守卫

前置路由守卫、后置路由守卫，前置请求守卫、后置请求守卫 在Vue 3和Axios中，路由守卫和请求守卫是用于控制路由跳转和HTTP请求的关键机制。 下面是这些守卫的介绍和使用方式： 前置路由守卫（Before Route Guards） 前置…
阅读更多...
【行为型模式】中介者模式

【行为型模式】中介者模式

一、中介者模式概述 中介者模式定义：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式。(对象行为型模式) 中介者模式…
阅读更多...
python+django校园社交高校交友网站2x7r5.

python+django校园社交高校交友网站2x7r5.

本课题使用Python语言进行开发。代码层面的操作主要在PyCharm中进行，将系统所使用到的表以及数据存储到MySQL数据库中，方便对数据进行操作本课题基于WEB的开发平台，设计的基本思路是： 前端：vue.jselementui 框架&#…
阅读更多...
Node.JS安装及配置教程（Windows）【安装】

Node.JS安装及配置教程（Windows）【安装】

文章目录 一、 Node.JS 下载1. 官网下载（1）国内地址（2）国外地址 2. 其它渠道 二、 Node.JS 安装三、 Node.JS验证四、 Node.JS 配置（可选）1. 配置全局模块安装路径方法一方法二2. 配置国内镜像 五、 yarn 安…
阅读更多...
企业数智化：为什么选择梧桐数据库？

企业数智化：为什么选择梧桐数据库？

个人介绍：艺名司镜233，是中国移动梧桐数据库研发团队成员，从事相关的技术开发近5年了。最让我觉得自豪的不是在研发这款数据库，而是我们用代码，切实地帮助企业解决数据的困扰，切实地解决社会的问题。 本篇文…
阅读更多...
大模型自动优化 Prompt 的可行性分析

大模型自动优化 Prompt 的可行性分析

随着自然语言处理领域的快速发展，大模型（Large Language Models）已经成为了当前研究的热点。大模型通过在海量语料上进行预训练，能够学习到丰富的语言知识和通用表示，在各种自然语言处理任务上取得了突破性的进展。然而…
阅读更多...
最新文章

Copyright @ 2022~2023