算法描述无法连接

PGP协议。。。。。 电子邮件的方便、快速、费用低廉等优点，再加上它不但能传送文字信息，还可以附上图像、声音等功能，这使得电子邮件越来越受人们的欢迎。 1 电子邮件的传输过程 电子邮件通过SMTP和POP协议来进行发送和接受，但由于互联网的开放性，邮件内容是以明文的形式在互联网上进行传递。这使得人们在使用电子邮件时不得不考虑其安全因素，因此如何保证电子邮件的机密性、完整性、真实性和不可抵赖性等方面的问题显得尤为重要。 2 PGP介绍 为了使电子邮件在互联网上能够安全运行，开发出了一些安全电子邮件标准：PGP和S/MIME。其中PGP被广泛运用。 PGP（Pretty Good Privacy）是美国人Phil Zimmermann研究出来的，它是由多种加密算法（IDEA、RSA、MD5、随机数生成算法）组合而成，不但能够实现邮件的保密功能，还可以对邮件进行数字签名，使收信人能够准确判断邮件在传递过程中是否被非法篡改。 3 PGP工作原理 3.1 IDEA算法 IDEA属于对称加密算法，即加密密钥和解密密钥相同，具体的算法规则是，将输入数据以每64为一块，对每块进行分组，分为4组，每组16位，作为第一轮的输入，进行相乘、相加、异或等运行后，形成4个子分组，将中间两间进行交换，作为下一轮的输入，经过8轮运算后，同样得到4个子分组，再将这4组重新连接到一起形成密文共64位。 3.2 RSA算法 RSA属于非对称加密算法，也称公钥算法，即加密密钥和解密密钥不同，并且加密密钥可以完全公开，但由于没有解密密钥，即使非法者窃取到了密文和发送者的加密密钥也无法查看内容，解决了对称加密中对密钥管理困难的问题，RSA的安全性取决于对大数的因式分解，这是数学上的一个难题。 RSA算法描述： 1）随意选择两个大的质数p和q，p不等于q，q和p保密； 2）计算n=pq； 3）欧拉函数，φ（n） = （p-1）（q-1），n公开，φ（n）保密； 4）选择一个小于φ（n）的正整数e，满足gcd（e，φ（n））=1，e是公开的加密密钥； 5）计算d，满足de≡1（modφ（n））， d是保密的解密密钥； 6）加密变换：对明文m∈Zn，密文为C=me mod n； 7）解密变换：对密文C∈Zn，明文为m=Cd mod n； 由于RSA涉及的运算非常复杂，所以在运算速度上很慢，因而RSA算法只适合于对少量数据进行加密，如数字签名，一般情况下，如果要对大量信息进行加密，还是采用对称加密算法，因为对称加密速度比公钥加密速度快得多。 3.3 MD5算法 MD5属于Hash函数，可以将任意长度的输入压缩到固定长度的输出，具有多对一的单向特性。可以用于数字签名、完整性检测等方面。 4 PGP提供的业务 PGP提供的业务包括：认证、加密、压缩、与电子邮件兼容、基数-64变换。 4.1 认证 认证的步骤是：①发信人创建信息M；②发信人使用MD5算法产生128位的消息摘要H；③发信人用自己的私钥，采用RSA算法对H进行加密ER，M‖ER连接后进行压缩得到Z；④将Z通过互联网发送出去；⑤接收者收到信息后首先进行解压Z-1，使用发信人的公开密钥采用RSA算法进行解密得出H，用接收到的M计算消息摘要H，将得出的两个H进行比较，如果相同则接收，否则表示被篡改，拒绝。 4.2 加密 加密的步骤：发信人对信息M进行压缩，采用IDEA算法对其进行加密，用接收者的公钥对密钥进行加密，与M进行连接后发出，接收者采用RSA算法进行解密得到会话密钥，将会话密钥按IDEA算法进行解密，并解压缩，并到原文。 在加密过程中，由于信息相对内容较多，因此对信息的加密采用的是对称加密算法IDEA来实现，而密钥采用的是安全强度为高的非对称加密算法RSA实现，通过IDEA和RSA结合，不但提高了邮件传输的安全性，而且在加解密时间上也缩短了。 4.3 压缩 PGP采用ZIP算法压缩信息，这不但节省了存储空间，而且在传输过程中也节省了时间，另外，在对信息进行加密之前压缩，也相当于进行了一次变换，使其安全性增强。 4.4 与电子邮件兼容 由于电子邮件只允许使用ASCⅡ字符串，而PGP的输出却是8位串，为了与电子邮件进行兼容，PGP采用基数-64变换实现将输出的8位串转换为可以打印的ASCII字符串。 4.5 PGP消息分段和重组 电子邮件中对消息内容的长度有限制的，当大于所限制的长度时要进行分段，分段是在所有处理结束之后才进行，所以会话密钥和签名在第一个段开始位置出现。在接收端，PGP将重新组合成原来的信息。 5 PGP安全性分析 由于PGP是一种混合密码体系，它的安全性在于IDEA、RSA、MD5算法的安全性分析。 5.1 IDEA的安全性 在PGP中采用IDEA的64位CFB模式，很多研究者对IDEA的弱点进行了分析，但也没有找到破译的方法，由此可见，IDEA算法也是比较安全的，它的攻击方法只有“直接攻击”或者是“密钥穷举”攻击。（原作者：钟泽秀）5.2 RSA的安全性 RSA算法是非对称密码体制，它的安全性基于大整数的素分解的难解性，经过长期的研究至今也未找到一个有效的解决方案，在数学上就是一个难题，因此，RSA公钥密码体制就建立在对大数的因式分解这个数学难题上。 假设密码分析者能够通过n分解因子得到p和q，那么他很容易就可以求出欧拉函数φ（n）和解密密钥d，从而破译RSA，因此，破译RSA比对n进行因式分解难度更大。 假设密码分析者能够不对n进行因子分解就求出欧拉函数φ（n），那么他可以根据de≡1（modφ（n）），得到解密密钥d，从而破译RSA，因为p+q=n-φ（n）+1，p-q=sqr（p+q）^2-4n，所以知道φ（n）和n就可以容易地求得p和q，从而成功地分解n，所以不对n进行因子分解而直接计算φ（n）比对n进行因子分解难度更大。 假如密码分析者能够即不对n进行因子分解也不需要求φ（n）而是直接求得解密密钥d，那么他就可以计算ed-1，其中ed-1是欧拉函数φ（n）的倍数，因为利用φ（n）的倍数可以容易的分解出n的因子。所以，直接计算解密密钥d比对n进行因式分解更难。 虽然n越大其安全性越高，但由于涉及到复杂的数学运算，会影响到运行速度，那么我们实际运用中，如果来决定n的大小使其既安全其速度又不能太慢，目前n的长度为1024位至2048位比较合理。 研究人员建议，在运用RSA算法时，除了指定n的长度外，还应对p和q进行限制：①p和q的大小应该相差不多；②p-1和q-1都应该包含大的素因子；③gcd（p-1，q-1）应该很小。 5.3 MD5的安全性 MD5是在MD4的基础上发展起来的，在PGP中被用来单向变换用户口令和对信息签名的单向散列算法。它的安全性体现在能将任意输入长度的消息转化为固定长度的输出。目前对单向散列的直接攻击包括普通直接攻击和“生日攻击”。 在密码学中，有这么一句话：永远不要低估密码分析者的能力。这也将是密码设计者与密码分析者的较量，事实上绝对不可破译的密码体制在理论上是不存在的，因此，在实际应用中，一个密码体制在使用一段时间后，会换一些新的参数，或者是更换一种新的密码体制，当然，密钥也是要经常换的。由此可见，PGP软件虽然给我们的电子邮件带来了安全性保障，但它也不是永恒的，也许在不久的将来，由于它的弱点被攻击而被新的安全电子邮件产品所代替。

公共返回参数 所有请求均返回JSON格式数据，有如下公共字段： 名称 类型 是否必需 描述 code 整型 是 错误码，和HTTP状态码一致（但有扩展）。 2xx 表示成功。 4xx 表示请求有误。 5xx 表示后端有误。 具体请参见公共错误码。 msg 字符串 是 错误的进一步描述。 requestId 字符串 是 唯一标识该请求的ID，可用于定位问题。 data 整型/字符串/JSON对象 否 API（业务）相关的返回数据。出错情况下，该字段可能为空。一般来说，该字段为一个JSON结构体或数组。 公共错误码 错误代码 HTTP 状态码 描述 OK 200 请求成功。 PROCESSING 280 任务正在执行中，建议您等待一段时间（例如5s）后再查询结果。 BAD_REQUEST 400 请求有误，通常由于请求参数不正确导致，请仔细检查请求参数。 NOT_ALLOWED 401 请求失败，通常是由于使用了不安全的图片/视频/语音链接地址。 FORBIDDEN 403 请求访问失败，通常由于您的图片/视频/语音链接无法访问导致，请确认公网是否可访问，并且无防盗链策略。 NOT_FOUND 404 待检测内容未找到，通常是由于您的图片/视频/语音内容无法下载导致，请确认内容可通过公网访问到。 DOWNLOAD_FAILED 480 下载失败，请确认待检测内容的大小、分辨率（如果有）在API的限制范围内。 GENERAL_ERROR 500 一般是服务端临时出错。建议重试，若持续返回该错误码，请通过工单联系我们。 DB_FAILED 580 数据库操作失败。建议重试，若持续返回该错误码，请通过工单联系我们。 TIMEOUT 581 超时。建议重试，若持续返回该错误码，请通过工单联系我们。 CACHE_FAILED 585 缓存出错。建议重试，若持续返回该错误码，请通过工单联系我们。 ALGO_FAILED 586 算法出错。请通过工单联系我们。 MQ_FAILED 587 中间件出错。请通过工单联系我们。 EXCEED_QUOTA 588 请求频率超出配额。默认配额：图片检测50张/秒，视频检测20路/秒，语音检测20路/秒，文本检测100条/秒。如果需要调整配额，请通过工单联系我们。 说明 关于价格说明，请参见内容安全产品定价。 TOO_LARGE 589 待检测内容过大，请确保检测的内容在API的限制范围内。建议重试，若持续返回该错误码，请通过工单联系我们。 BAD_FORMAT 590 待检测内容格式错误，请确保检测的内容在API的限制范围内。 CONNECTION_POOL_FULL 591 连接池满。请通过工单联系我们。 DOWNLOAD_TIMEOUT 592 下载超时，下载时间限制为3s，请确保检测的内容大小在API的限制范围内。 EXPIRED 594 任务过期，如taskId过期。 CATCH_FRAME_FAILED 595 截帧失败，请通过工单联系我们。 PERMISSION_DENY 596 账号未授权，账号欠费，账号未开通，账号被禁，具体可以参考返回的msg。

问题描述 使用SSH登录Linux实例时，提示如下错误信息，导致无法正常连接Linux实例。 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is ae:6e:68:4c:97:a6:91:81:11:38:8d:64:ff:92:13:50. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:70 RSA host key for x.x.x.x has changed and you have requested strict checking. Host key verification failed. 若客户端为Windows环境，以常见的SSH客户端为例，连接时提示如下错误。 X.X.X.X （端口：XX）的主机密钥与本地主机密钥数据库中保存的不一致。主机密钥已更改或有人试图监听此连接。若无法确定，建议取消此连接。 问题原因 Linux实例进行过重装系统，账户信息变更等使其SSH公钥变更，造成客户端保存的公钥指纹与服务器端不一致，导致SSH认证失败拒绝登录。 解决方案 阿里云提醒您： 如果您对实例或数据有修改、变更等风险操作，务必注意实例的容灾、容错能力，确保数据安全。 如果您对实例（包括但不限于ECS、RDS）等进行配置与数据修改，建议提前创建快照或开启RDS日志备份等功能。 如果您在阿里云平台授权或者提交过登录账号、密码等安全信息，建议您及时修改。 本文相关Linux配置及说明已在CentOS 6.5 64 位操作系统中进行过测试。其它操作系统版本配置可能有所差异，具体情况请参阅相应操作系统官方文档。 客户端为Windows环境 如果客户端是Windows环境，而且使用SSH客户端Putty连接Windows实例，您可以参考以下步骤进行操作。 启动Putty。 在登录页面，单击 Delete，删除登录会话。 Image2.png 重新使用用户名及密码登录实例，确认保存新的公钥指纹后，即可成功登录。 注：您也可以在弹出相关告警信息时，单击 接收并保存，让程序自动更新密钥指纹信息，即可成功登录实例。 客户端为Linux环境 如果客户端是Linux环境，您可以参考以下步骤进行操作。 执行如下命令，进入对应账号的known_hosts文件。 vi ~/.ssh/known_hosts 按 i 键进入编辑模式。 删除Linux实例IP对应的条目，如下图所示。 TB1yJ8YJVXXXXXqXFXXXXXXXXXX.png 输入:wq保存并退出。 重新连接Linux实例，确认保存新的公钥指纹后，即可成功登录。 更多信息 由于公钥一般较长，采用RSA算法时长达1024位，为了简便起见，通过对其MD5计算，生成一个128位的字符串用于信息对比，称为公钥指纹。 相关文档 若还有问题没解决，请参考如下文档，做进一步的排查分析。 云服务器 ECS Linux SSH 无法登录问题排查指引 适用于 云服务器 ECS 如果您的问题仍未解决，您可以在阿里云社区免费咨询，或提交工单联系阿里云技术支持。

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前，您需要： 从实际需要出发，最好有相关数据的支撑，若您的业务没有受到影响不建议调整内核参数。 了解每一个参数的具体作用，并且同类型或版本操作系统下内核参数可能有所不同。 备份 ECS 实例中的重要数据。参阅文档 创建快照。 Linux 常用内核网络参数 参数 描述 net.core.rmem_default 默认的 TCP 数据接收窗口大小（字节）。 net.core.rmem_max 最大的 TCP 数据接收窗口（字节）。 net.core.wmem_default 默认的 TCP 数据发送窗口大小（字节）。 net.core.wmem_max 最大的 TCP 数据发送窗口（字节）。 net.core.netdev_max_backlog 在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。 net.core.somaxconn 定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数。 net.core.optmem_max 表示每个套接字所允许的最大缓冲区的大小。 net.ipv4.tcp_mem 确定 TCP 栈应该如何反映内存使用，每个值的单位都是内存页（通常是 4KB）第一个值是内存使用的下限；第二个值是内存压力模式开始对缓冲区使用应用压力的上限；第三个值是内存使用的上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的 BDP 可以增大这些值（注意：其单位是内存页而不是字节）。 net.ipv4.tcp_rmem 为自动调优定义 socket 使用的内存。第一个值是为 socket 接收缓冲区分配的最少字节数；第二个值是默认值（该值会被 rmem_default 覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是接收缓冲区空间的最大字节数（该值会被 rmem_max 覆盖）。 net.ipv4.tcp_wmem 为自动调优定义 socket 使用的内存。第一个值是为 socket 发送缓冲区分配的最少字节数；第二个值是默认值（该值会被 wmem_default 覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是发送缓冲区空间的最大字节数（该值会被 wmem_max 覆盖）。 net.ipv4.tcp_keepalive_time TCP 发送 keepalive 探测消息的间隔时间（秒），用于确认 TCP 连接是否有效。 net.ipv4.tcp_keepalive_intvl 探测消息未获得响应时，重发该消息的间隔时间（秒）。 net.ipv4.tcp_keepalive_probes 在认定 TCP 连接失效之前，最多发送多少个 keepalive 探测消息。 net.ipv4.tcp_sack 启用有选择的应答（1 表示启用），通过有选择地应答乱序接收到的报文来提高性能，让发送者只发送丢失的报文段，（对于广域网通信来说）这个选项应该启用，但是会增加对 CPU 的占用。 net.ipv4.tcp_fack 启用转发应答，可以进行有选择应答（SACK）从而减少拥塞情况的发生，这个选项也应该启用。 net.ipv4.tcp_timestamps TCP 时间戳（会在 TCP 包头增加 12 B），以一种比重发超时更精确的方法（参考 RFC 1323）来启用对 RTT 的计算，为实现更好的性能应该启用这个选项。 net.ipv4.tcp_window_scaling 启用 RFC 1323 定义的 window scaling，要支持超过 64KB 的 TCP 窗口，必须启用该值（1 表示启用），TCP 窗口最大至 1GB，TCP 连接双方都启用时才生效。 net.ipv4.tcp_syncookies 表示是否打开 TCP 同步标签（syncookie），内核必须打开了 CONFIG_SYN_COOKIES 项进行编译，同步标签可以防止一个套接字在有过多试图连接到达时引起过载。默认值 0 表示关闭。 net.ipv4.tcp_tw_reuse 表示是否允许将处于 TIME-WAIT 状态的 socket （TIME-WAIT 的端口）用于新的 TCP 连接。 net.ipv4.tcp_tw_recycle 能够更快地回收 TIME-WAIT 套接字。 net.ipv4.tcp_fin_timeout 对于本端断开的 socket 连接，TCP 保持在 FIN-WAIT-2 状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。 net.ipv4.ip_local_port_range 表示 TCP/UDP 协议允许使用的本地端口号。 net.ipv4.tcp_max_syn_backlog 对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。默认为 1024。 net.ipv4.tcp_low_latency 允许 TCP/IP 栈适应在高吞吐量情况下低延时的情况，这个选项应该禁用。 net.ipv4.tcp_westwood 启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化，对于 WAN 通信来说应该启用这个选项。 net.ipv4.tcp_bic 为快速长距离网络启用 Binary Increase Congestion，这样可以更好地利用以 GB 速度进行操作的链接，对于 WAN 通信应该启用这个选项。 net.ipv4.tcp_max_tw_buckets 该参数设置系统的 TIME_WAIT 的数量，如果超过默认值则会被立即清除。默认为 180000。 net.ipv4.tcp_synack_retries 指明了处于 SYN_RECV 状态时重传 SYN+ACK 包的次数。 net.ipv4.tcp_abort_on_overflow 设置改参数为 1 时，当系统在短时间内收到了大量的请求，而相关的应用程序未能处理时，就会发送 Reset 包直接终止这些链接。建议通过优化应用程序的效率来提高处理能力，而不是简单地 Reset。默认值： 0 net.ipv4.route.max_size 内核所允许的最大路由数目。 net.ipv4.ip_forward 接口间转发报文。 net.ipv4.ip_default_ttl 报文可以经过的最大跳数。 net.netfilter.nf_conntrack_tcp_timeout_established 让 iptables 对于已建立的连接，在设置时间内若没有活动，那么则清除掉。 net.netfilter.nf_conntrack_max 哈希表项最大值。 查看和修改 Linux 实例内核参数 方法一、通过 /proc/sys/ 目录 /proc/sys/ 目录是 Linux 内核在启动后生成的伪目录，其目录下的 net 文件夹中存放了当前系统中生效的所有内核参数、目录树结构与参数的完整名称相关，如 net.ipv4.tcp_tw_recycle，它对应的文件是 /proc/sys/net/ipv4/tcp_tw_recycle，文件的内容就是参数值。 查看内核参数：使用 cat 查看对应文件的内容，例如执行命令 cat /proc/sys/net/ipv4/tcp_tw_recycle 查看 net.ipv4.tcp_tw_recycle 的值。 修改内核参数：使用 echo 修改内核参数对应的文件，例如执行命令 echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle 将 net.ipv4.tcp_tw_recycle 的值修改为 0。 注意：方法一修改的参数值仅在当次运行中生效，系统重启后会回滚历史值，一般用于临时性的验证修改的效果。若需要永久性的修改，请参阅方法二。 方法二、通过 sysctl.conf 文件 查看内核参数：执行命令 sysctl -a 查看当前系统中生效的所有参数，如下所示： net.ipv4.tcp_app_win = 31 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_frto = 2 net.ipv4.tcp_frto_response = 0 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_tso_win_divisor = 3 net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_abc = 0 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_base_mss = 512 net.ipv4.tcp_workaround_signed_windows = 0 net.ipv4.tcp_challenge_ack_limit = 1000 net.ipv4.tcp_limit_output_bytes = 262144 net.ipv4.tcp_dma_copybreak = 4096 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.cipso_cache_enable = 1 net.ipv4.cipso_cache_bucket_size = 10 net.ipv4.cipso_rbm_optfmt = 0 net.ipv4.cipso_rbm_strictvalid = 1 修改内核参数： 执行命令   /sbin/sysctl -w kernel.domainname="example.com"  来修改指定的参数值，如 sysctl -w net.ipv4.tcp_tw_recycle="0" 执行命令   vi /etc/sysctl.conf  修改   /etc/sysctl.conf  文件中的参数。 执行命令   /sbin/sysctl -p  使配置生效。 Linux 网络相关内核参数引发的常见问题及处理 问题现象 原因分析 解决方案 无法在本地网络环境通过 SSH 连接 ECS Linux 实例，或者访问该 Linux 实例上的 HTTP 业务出现异常。Telnet 测试会被 reset。 如果您的本地网络是 NAT 共享方式上网，该问题可能是由于本地 NAT 环境和目标 Linux 相关内核参数配置不匹配导致。尝试通过修改目标 Linux 实例内核参数来解决问题：1. 远程连接目标 Linux 实例；2. 查看当前配置： cat /proc/sys/net/ipv4/tcp_tw_recyclecat /proc/sys/net/ipv4/tcp_timestamps 查看上述两个配置的值是不是 0，如果为 1的话，NAT 环境下的请求可能会导致上述问题。 通过如下方式将上述参数值修改为 0：1. 执行命令 vi /etc/sysctl.conf。2. 添加如下内容：net.ipv4.tcp_tw_recycle=0net.ipv4.tcp_timestamps=0。3. 输入指令 # sysctl -p 使配置生效。4. 重新 SSH 登录实例或者业务访问测试。 服务端 A 与 客户端 B 建立了 TCP 连接，之后服务端 A 主动断开了连接，但是在客户端 B 上仍然看到连接是建立的。示例见图一，图二。 通常是由于修改了服务端内核参数 net.ipv4.tcp_fin_timeout 默认设置所致。 1. 执行命令 vi /etc/sysctl.conf，修改配置：net.ipv4.tcp_fin_timeout=30。2. 执行命令 # sysctl -p 使配置生效。 通过 netstat 或 ss 可以看到大量处于 TIME_WAIT 状态的连接。 通过 netstat -n | awk ‘/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}’ 查看 TIME_WAIT 数量。 1. 执行命令 vi /etc/sysctl.conf，修改或加入以下内容： net . ipv4 . tcp_syncookies = 1 net . ipv4 . tcp_tw_reuse = 1 net . ipv4 . tcp_tw_recycle = 1 net . ipv4 . tcp_fin_timeout = 30 2. 执行命令 /sbin/sysctl -p  使配置生效。 云服务器上出现大量 CLOSE_WAIT 状态的连接数。 根据实例上的业务量来判断 CLOSE_WAIT 数量是否超出了正常的范围。TCP 连接断开时需要进行四次挥手，TCP 连接的两端都可以发起关闭连接的请求，若对端发起了关闭连接，但本地没有进行后续的关闭连接操作，那么该链接就会处于 CLOSE_WAIT 状态。虽然该链接已经处于半开状态，但是已经无法和对端通信，需要及时的释放该链接。建议从业务层面及时判断某个连接是否已经被对端关闭，即在程序逻辑中对连接及时进行关闭检查。 通过命令 netstat -an|grep CLOSE_WAIT|wc -l 查看当前实例上处于 CLOSE_WAIT 状态的连接数。Java 语言：1. 通过 read 方法来判断 I/O 。当 read 方法返回 -1 时则表示已经到达末尾。2. 通过 close 方法关闭该链接。C 语言：1. 检查 read 的返回值，若是 0 则可以关闭该连接，若小于 0 则查看一下 errno，若不是 AGAIN 则同样可以关闭连接。 ECS Linux FIN_WAIT2 状态的 TCP 链接过多。 HTTP 服务中，SERVER 由于某种原因关闭连接，如 KEEPALIVE 的超时。这样，作为主动关闭的 SERVER 一方就会进入 FIN_WAIT2 状态。但 TCP/IP 协议栈中，FIN_WAIT2 状态是没有超时的（不像 TIME_WAIT 状态），如果 Client 不关闭，FIN_WAIT_2 状态将保持到系统重启，越来越多的 FIN_WAIT_2 状态会致使内核 Crash。 1. 执行命令 vi /etc/sysctl.conf，修改或加入以下内容： net . ipv4 . tcp_syncookies = 1 net . ipv4 . tcp_fin_timeout = 30 net . ipv4 . tcp_max_syn_backlog = 8192 net . ipv4 . tcp_max_tw_buckets = 5000 2. 执行命令 # sysctl -p 使配置生效。 查询服务器 /var/log/message 日志，发现全部是类似如下 kernel: TCP: time wait bucket table overflowt 的报错信息，报错提示 TCP time wait 溢出，见图三。 TCP 连接使用很高，容易超出限制。见图四。 1. 执行命令 netstat -anp |grep tcp |wc -l统计 TCP 连接数。2. 对比 /etc/sysctl.conf 配置文件的 net.ipv4.tcp_max_tw_buckets 最大值，看是否有超出情况。3. 执行命令 vi /etc/sysctl.conf，查询 net.ipv4.tcp_max_tw_buckets 参数。如果确认连接使用很高，容易超出限制。4. 调高参数 net.ipv4.tcp_max_tw_buckets，扩大限制。5. 执行命令 # sysctl -p 使配置生效。 ECS Linux 实例出现间歇性丢包的情况，通过 tracert， mtr 等手段排查，外部网络未见异常。同时，如下图所示，在系统日志中重复出现大量kernel nf_conntrack: table full, dropping packet.错误信息。见图五。 ip_conntrack 是 Linux 系统内 NAT 的一个跟踪连接条目的模块。ip_conntrack 模块会使用一个哈希表记录 TCP 通讯协议的 established connection 记录，当哈希表满了的时候，会导致 nf_conntrack: table full, dropping packet 错误。需要通过修改内核参数来调整 ip_conntrack 限制。 Centos 5.x 系统1. 使用管理终端登录实例。2. 执行命令 # vi /etc/sysctl.conf 编辑系统内核配置。3. 修改哈希表项最大值参数：net.ipv4.netfilter.ip_conntrack_max = 655350。4. 修改超时时间参数：net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1200，默认情况下 timeout 是5天（432000秒）。5. 执行命令 # sysctl -p 使配置生效。Centos 6.x 及以上系统：1. 使用管理终端登录实例。2. 执行命令 # vi /etc/sysctl.conf 编辑系统内核配置。3. 修改哈希表项最大值参数：net.netfilter.nf_conntrack_max = 655350。4. 修改超时时间参数：net.netfilter.nf_conntrack_tcp_timeout_established = 1200，默认情况下 timeout 是5天（432000秒）。5. 执行命令 # sysctl -p 使配置生效。 客户端做了 NAT 后无法访问 ECS、RDS，包括通过 SNAT VPC 访问外网的 ECS 。无法访问连接其他 ECS 或 RDS 等云产品，抓包检测发现远端对客户端发送的 SYN 包没有响应。 若远端服务器同时开启 net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps，即参数取值为 1 时，服务器会检查每一个报文的时间戳（Timestamp），若 Timestamp 不是递增的关系，则不做处理。做了 NAT 后，服务器看到来自不同的客户端的 IP 相似，但 NAT 前每一台客户端的时间可能会有偏差，在服务器上就会看到 Timestamp 不是递增的情况。 - 远端服务器为 ECS：修改参数 net.ipv4.tcp_tw_recycle 为 0。- 远端服务器为 RDS 等 PaaS 服务：RDS 无法直接修改内核参数，需要在客户端上修改参数 net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps 为 0。 参考链接 Linux man-pages kernel/git/torvalds/linux.git_proc kernel/git/torvalds/linux.git_proc_net_tcp kernel/git/torvalds/linux.git_ip-sysctl kernel/git/torvalds/linux.git_netfilter-sysctl kernel/git/torvalds/linux.git_nf_conntrack-sysctl 图一： 客户端 B TCP 连接 图二： 客户端 A TCP 连接 图三： 报错提示 TCP time wait 溢出 图四： 查询 net.ipv4.tcp_max_tw_buckets 参数 图五： ECS Linux 实例间歇性丢包

高可用架构部署方案 高可用架构提供业务分发、弹性扩展、多可用区部署等功能。相较于使用单台ECS实例部署数据库与应用，高可用架构只需简单部署，并且拥有更高的稳定性和可扩展性。 高可用架构特点 高可用架构具有如下特点： 使用多可用区高可用版的负载均衡SLB（Server Load Balancer）对多台云服务器ECS进行流量分发，可扩展应用系统对外服务能力、消除单点故障，提升应用系统的可用性。使用SLB自动跨可用区部署，可加强业务容灾能力。 通过自定义镜像，可以迅速复制出相同应用部署的云服务器ECS实例，之后将实例添加到SLB后端服务器组中，实现业务高可用。SLB可以同时配置四层和七层监听，及轮循、加权轮循、加权最小连接数等多种算法，合理分配后端ECS计算资源。 使用云数据库RDS（Relational Database Service），针对高并发场景进行特殊优化，同时引入线程池、并行复制、隐含主键等功能保证系统持续稳定和高吞吐。云数据库CloudDBA具有完备的性能监控数据，实时监控实例硬件使用指标、慢SQL，并给出各种优化建议，帮您快速定位并解决问题。 部署流程 假设您已拥有一台ECS实例，并且在该实例上部署了数据库与应用，您可以将单实例部署方式转变为单可用区或多可用区高可用架构。本教程指导您如何使用ECS、EIP、SLB和RDS产品来部署多可用区高可用架构。 高可用结构图 使用自定义镜像，部署多台相同配置的ECS实例。详情请参见复制ECS实例。 创建负载均衡SLB实例，将实例添加到SLB后端服务器组中，用于跨可用区挂载ECS实例，实现业务的高可用性。详情请参见配置SLB实例。 使用DTS将ECS实例上的自建数据库迁移至RDS实例，保障业务数据库不中断，自动备份保障数据不丢失。详情请参见迁移自建数据库至RDS实例。 复制ECS实例为了支持跨可用区容灾部署，本教程使用源实例的自定义镜像复制出三台ECS实例。一台与源实例位于同一可用区，两台与源实例位于同一地域下的不同可用区。 前提条件 已注册阿里云账号。如还未注册，请先完成账号注册。 已拥有待复制的源ECS实例。 操作步骤 为ECS实例创建自定义镜像。 登录ECS管理控制台。 在左侧导航栏，单击实例与镜像 > 实例。 在顶部状态栏处，选择地域。 找到目标实例。在操作列中，单击更多 > 磁盘和镜像 > 创建自定义镜像。 输入镜像名称和描述信息。 单击创建。 说明 创建镜像需要一段时间，请您耐心等待。 在左侧导航栏，单击实例与镜像 > 镜像。当目标镜像的进度为100%、状态为可用时，表示镜像创建成功。自定义镜像 使用自定义镜像创建3台ECS实例。 在左侧导航栏，单击实例与镜像 > 镜像。 在自定义镜像页面，找到上一步创建的自定义镜像，在操作列，单击创建实例。 在自定义购买页面，镜像区域已设置为您选择的自定义镜像。根据页面提示，完成其他配置项并购买1台ECS实例。 其中： 地域：选择与源实例相同的地域。 可用区：选择与源实例相同的可用区。 公网带宽：取消勾选分配公网IPv4地址。 更多配置详情，请参见使用向导创建实例。 重复第i步和第ii步。在自定义购买页，镜像区域已设置为您选择的自定义镜像。根据页面提示，完成其他配置项并购买2台实例。 其中： 地域：选择与源实例相同的地域。 可用区：选择与源实例不同的可用区。 实例区域：设置购买实例数量为2。 公网带宽区域：取消勾选分配公网IPv4地址。 更多配置详情，请参见使用向导创建实例。 执行结果 在左侧导航栏，单击实例与镜像 > 实例。在实例列表页面，四台ECS实例的状态均为运行中，可用区两两相同。 ecs_instances 配置SLB实例 ECS实例复制完成后，在支持多可用区的地域创建负载均衡SLB实例，用于跨可用区挂载ECS实例，扩展应用系统对外服务能力、消除单点故障，提升应用系统的可用性。本文介绍SLB实例的部署方法。 前提条件 已复制三台ECS实例，详情请参见复制ECS实例。 四台ECS实例的Web服务均已启动并正常运行。 注意 若Web服务未运行，则SLB实例与ECS实例之间无法正常通信。 操作步骤 创建SLB实例。具体操作，请参见创建负载均衡实例。 本教程使用的配置如下： 地域：必须与ECS实例位于同一地域。 可用区类型：选择多可用区。 实例类型：选择私网。 网络类型：选择专有网络。 主可用区和备可用区：按需配置。 create_slb 将源实例的公网IP转换为弹性公网IP。具体操作，请参见专有网络公网IP转换为弹性公网IP。 说明 为避免影响业务，需保证源实例IP地址不变。因此，需要先将源实例的公网IP转换为弹性公网IP，与源实例解绑后，再将其绑定至高可用版SLB实例上。 ip_eip 解绑源实例与弹性公网IP。 在源实例的IP地址列，单击弹性IP地址链接。 click_eip 在弹性公网IP页面，单击解绑。 unbindEIP 单击确定。更多详情，请参见解绑EIP。 绑定弹性公网IP至SLB实例。 在弹性公网IP页面，找到与源实例解绑后的弹性公网IP。 bindEIP 在操作列，单击绑定。 实例类型选择SLB实例，SLB实例选择刚创建的SLB实例，单击确定。更多详情，请参见绑定SLB实例。 配置SLB实例。具体操作，请参见配置负载均衡实例。 基本配置如下： 在协议&监听页签，完成以下配置。 负载均衡协议：选择TCP。 监听端口：输入80。 调度算法：按需选择。本教程选择轮询。 其他配置使用默认值。 configure_slb 单击下一步。在后端服务器页签，选择默认服务器组，单击继续添加添加ECS实例。 addEcsInstance 勾选源实例和已复制的三台ECS实例，单击下一步：配置权重和端口号。端口配置为80，其他值保持默认，单击下一步。 configure_ports 在健康检查页签，使用默认值，单击下一步。 在配置审核页签，核对信息后，单击提交。 单击确定，返回实例管理页面，单击refresh。 当健康检查状态为正常时，表示后端ECS实例可以正常处理负载均衡转发的请求了。 说明 健康检查需要几分钟时间，请您耐心等待并单击刷新图标查看状态。 health_check 执行结果 为方便测试，本教程分别在四台ECS实例上搭建了静态网页，以标识每台ECS实例。在浏览器中输入负载均衡实例的服务地址，测试负载均衡服务。由于调度算法为轮询，请求会轮流发往每台ECS实例。 slb_test 迁移自建数据库至RDS实例 将源ECS实例上的数据库迁移至高可用版云数据库RDS，可实现数据库服务的高可用性、高可靠性、高安全性和高易用性。本教程以MySQL数据库为例，介绍如何使用DTS将ECS实例上的自建数据库迁移至RDS实例。 前提条件 已配置SLB实例，详情请参见配置SLB实例。 已创建高可用版RDS实例。如未创建，请参见创建RDS for MySQL实例。 已为RDS实例创建账号。如未创建，请参见创建账号和数据库。 已为ECS实例上的自建数据库创建非root账号，用于DTS迁移。 例如，您可以运行以下命令为MySQL数据库创建名为dts、密码为123456的账号。 grant all on . to 'dts'@'%' IDENTIFIED BY '123456'; 背景信息 DTS提供的数据迁移功能能够支持同异构数据源之间的数据迁移，同时提供了库表列三级映射、数据过滤多种ETL特性。您可以使用DTS进行零停机迁移，在迁移过程中，源数据库正常持续提供服务，最大程度降低迁移对业务的影响。DTS支持的数据库类型请参见数据迁移。 操作步骤 登录数据传输DTS控制台。 在左侧导航栏，选择数据迁移。 选择目标RDS实例所在地域，并单击创建迁移任务。 配置迁移任务。 配置任务名称。 您可以使用默认的名称或者自定义名称。 配置源库信息。 DTS支持通过公网、VPN网关、专线及智能网关访问的自建数据库。本教程使用的源数据库为ECS实例上的自建数据库。其他类型数据库的迁移方案，请参见DTS用户手册。 参数名称 描述 实例类型 ECS上的自建数据库。 实例地区 源ECS实例所在地域。 ECS实例ID 源ECS实例的实例ID。DTS支持经典网络及专有网络的ECS实例。 数据库类型 源ECS实例上自建数据库的类型。本示例中，数据库类型为MySQL。 端口 MySQL数据库监听的端口号。 数据库账号 源ECS实例上MySQL数据库的非root账号。 说明 数据库账号必须填写非root账号，否则测试连接时会报错。 数据库密码 非root账号对应的密码。 单击源库信息右下角的测试连接。 当返回的结果为测试通过时，表示源库连接正常。 配置目标库信息。 参数名称 参数值 实例类型 RDS实例。 实例地区 RDS实例所在地域。 RDS实例ID RDS实例的实例ID。 数据库账号 RDS实例的账号。 为RDS实例创建账号，请参见创建账号和数据库。 说明 数据库账号必须填写非root账号，否则测试连接时会报错。 数据库密码 账号对应的密码。 单击目标库信息右下角的测试连接。 当返回的结果为测试通过时，表示目标库连接正常。 单击授权白名单并进入下一步。 配置迁移类型及迁移对象。 配置迁移类型。 业务零停机迁移，请选择：结构迁移＋全量数据迁移＋增量数据迁移。 全量迁移，请选择：结构迁移＋全量数据迁移。 配置迁移对象。 在迁移对象框中单击要迁移的数据库对象，如数据库、表或列，然后单击>添加到已选择对象框中。 说明 默认情况下，数据库对象迁移到ECS自建MySQL实例后，对象名跟本地MySQL实例一致。如果迁移的数据库对象在源实例跟目标实例上名称不同，您需要使用DTS提供的对象名映射功能，详情请参见库表列映射。 单击预检查并启动。 在迁移任务正式启动之前，会预检查连通性、权限及日志格式等。下图表示预检查成功通过。 precheck 预检查通过后，您可以在迁移任务列表中查看迁移任务的迁移状态及进度。 task_result 后续步骤 在应用程序中配置RDS实例的连接地址和账号密码，以连接到RDS实例。您还可以使用数据管理服务DMS（Data Management Service）或客户端管理RDS实例。具体操作，请参见连接MySQL实例。

为保证用户日志数据的安全，日志服务 API 的所有 HTTP 请求都必须经过安全验证。 验证流程 目前，该安全验证基于阿里云的访问密钥，使用对称加密算法完成。 其验证流程如下： 请求端根据 API 请求内容（包括 HTTP Header 和 Body）生成签名字符串。 请求端使用阿里云的访问密钥对（AccessKeyID 和 AccessKeySecret），对第一步生成的签名字符串进行签名，形成该 API 请求的数字签名。 请求端把 API 请求内容和数字签名一同发送给服务端。 服务端在接到请求后会重复如上的步骤1和步骤2的工作，并在服务端计算出该请求期望的数字签名。 说明 服务端会在后台取得该请求使用的用户访问密钥对。 服务端用期望的数字签名和请求端发送过来的数字签名做比对，如果完全一致则认为该请求通过安全验证。否则直接拒绝该请求。 上面的整个流程也可以使用下图描述： 图 1. 安全验证流程 安全验证流程可以达到如下目的： 确认哪位用户在做 API 请求。 因为在发送请求前需要用户指定生成数字签名的密钥对，在服务端即可通过该密钥对确定用户身份，进而可做访问权限管理。 确认用户请求在网络传输过程中有无被篡改。 因为服务端会对接收到的请求内容重新计算数字签名，一旦请求内容在网络上被篡改，则无法通过数字签名比对。 签名 API 请求 为了通过 API 请求的安全验证，用户需要在客户端对其 API 请求进行签名（即生成正确的数字签名），并且使用 HTTP 头 Authorization 在网络上传输该请求的数字签名。Authorization 头的具体格式如下： Authorization:LOG : 如上格式所示，Authorization 头的值包含用户访问密钥对中的 AccessKeyId，且与之对应的 AccessKeySecret 将用于 Signature 值的构造。下面将详细解释如何构造该 Signature 值。 准备阿里云访问密钥。 为 API 请求生成签名，需使用一对访问密钥（AccessKeyId/AccessKeySecret）。您可以使用已经存在的访问密钥对，也可以创建新的访问密钥对，但需要保证使用的密钥对为启用状态。 生成请求的签名字符串。 日志服务 API 的签名字符串由 HTTP 请求中的 Method、Header 和 Body 信息一同生成，具体方式如下： SignString = VERB + "\n" + CONTENT-MD5 + "\n" + CONTENT-TYPE + "\n" + DATE + "\n" + CanonicalizedLOGHeaders + "\n" + CanonicalizedResource 上面公式中的 \n 表示换行转义字符，+（加号）表示字符串连接操作，其他各个部分定义如下所示。 表 1. 签名字符串定义 名称 定义 示例 VERB HTTP 请求的方法名称 PUT、GET、POST 等 CONTENT-MD5 HTTP 请求中 Body 部分的 MD5 值（必须为大写字符串） 875264590688CA6171F6228AF5BBB3D2 CONTENT-TYPE HTTP 请求中 Body 部分的类型 application/x-protobuf DATE HTTP 请求中的标准时间戳头（遵循 RFC 1123 格式，使用 GMT 标准时间） Mon, 3 Jan 2010 08:33:47 GMT CanonicalizedLOGHeaders 由 HTTP 请求中以 x-log 和 x-acs 为前缀的自定义头构造的字符串（具体构造方法见下面详述） x-log-apiversion:0.6.0\nx-log-bodyrawsize:50\nx-log-signaturemethod:hmac-sha1 CanonicalizedResource 由 HTTP 请求资源构造的字符串（具体构造方法见下面详述） /logstores/app_log 对于部分无 Body 的 HTTP 请求，其 CONTENT-MD5 和 CONTENT-TYPE 两个域为空字符串，这时整个签名字符串的生成方式如下： SignString = VERB + "\n" + "\n" + "\n" + DATE + "\n" + CanonicalizedLOGHeaders + "\n" + CanonicalizedResource 如公共请求头中的描述，日志服务 API 中引入了一个自定义请求头 x-log-date。如果您在请求中指定了该请求头，则其值会替代 HTTP 标准请求头 Date 加入签名计算。 CanonicalizedLOGHeaders 的构造方式如下： 将所有以 x-log 和 x-acs 为前缀的 HTTP 请求头的名字转换成小写字母。 将上一步得到的所有 LOG 自定义请求头按照字典顺序进行升序排序。 删除请求头和内容之间分隔符两端出现的任何空格。 将所有的头和内容用 \n 分隔符组合成最后的 CanonicalizedLOGHeader。 CanonicalizedResource 的构造方式如下： 将 CanonicalizedResource 设置为空字符串""。 放入要访问的 LOG 资源，如 /logstores/logstorename（如果没有 logstorename 则可不填写）。 如果请求包含查询字符串QUERY_STRING，则在 CanonicalizedResource 字符串尾部添加 ? 和查询字符串。 QUERY_STRING 是 URL 中请求参数按字典顺序排序后的字符串，其中参数名和值之间用 = 相隔组成字符串，并对参数名-值对按照字典顺序升序排序，然后以 & 符号连接构成字符串。其公式化描述如下： QUERY_STRING = "KEY1=VALUE1" + "&" + "KEY2=VALUE2" 生成请求的数字签名。 目前，日志服务 API 只支持一种数字签名算法，即默认签名算法 hmac-sha1。其完整签名公式如下： Signature = base64(hmac-sha1(UTF8-Encoding-Of(SignString)，AccessKeySecret)) 签名的方法用 RFC 2104 中定义的 HMAC-SHA1 方法。如上公式用的 AccessKeySecret 必须和最终的 Authorization 头中使用的 AccessKeyId 相对应。否则，请求将无法通过服务端验证。 在计算出数字签名后，使用该值按本节最前面描述的 Authorization 头格式构建完整的 Log Service API 请求安全验证头，并填入 HTTP 请求中即可发送。 请求签名过程示例 为了帮助您更好地理解整个请求签名的流程，我们用两个示例来演示整个过程。首先，假设您用做日志服务 API 签名的访问密钥对如下： AccessKeyId = "bq2sjzesjmo86kq*********" AccessKeySecret = "4fdO2fTDDnZPU/L7CHNd********" 示例一 您需要发送如下 GET 请求列出 ali-test-project 项目下的所有 Logstore，其 HTTP 请求如下： GET /logstores HTTP 1.1 Mon, 09 Nov 2015 06:11:16 GMT Host: ali-test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 如上 Log Service API 请求生成的签名字符串为： GET\n\n\nMon, 09 Nov 2015 06:11:16 GMT\nx-log-apiversion:0.6.0\nx-log-signaturemethod:hmac-sha1\n/logstores?logstoreName=&offset=0&size=1000 由于是 GET 请求，该请求无任何 HTTP Body，所以生成的签名字符串中 CONTENT-TYPE 与 CONTENT-MD5 域为空字符串。如果以前面指定的 AccessKeySecret 做签名运算后得到的签名为： jEYOTCJs2e88o+y5F4/S5IsnBJQ= 最后发送经数字签名的 HTTP 请求内容如下： GET /logstores HTTP 1.1 Mon, 09 Nov 2015 06:11:16 GMT Host: ali-test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 Authorization: LOG bq2sjzesjmo86kq35behupbq:jEYOTCJs2e88o+y5F4/S5IsnBJQ= 示例二 您需要给同上例 ali-test-project 项目中名为 test-logstore 的 Logstore 写入下面的日志： topic="" time=1447048976 source="10.10.10.1" "TestKey": "TestContent" 为此，按照 Log Service API 定义需要构建如下 HTTP 请求： POST /logstores/test-logstore HTTP/1.1 Date: Mon, 09 Nov 2015 06:03:03 GMT Host: test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 Content-MD5: 1DD45FA4A70A9300CC9FE7305AF2C494 Content-Length: 52 x-log-apiversion:0.6.0 x-log-bodyrawsize:50 x-log-compresstype:lz4 x-log-signaturemethod:hmac-sha1 <日志内容序列化成 ProtoBuffer 格式的字节流> 在这个 HTTP 请求中，写入的日志内容首先被序列化成 ProtoBuffer 格式（请参见数据编码方式了解该格式的更多细节）后作为请求 Body。所以该请求的 Content-Type 头的值指定为 application/x-protobuf。类似，Content-MD5 头的值是请求 body 对应的 MD5 值。按照上面的签名字符串构造方式，这个请求对应的签名字符串为： POST\n1DD45FA4A70A9300CC9FE7305AF2C494\napplication/x-protobuf\nMon, 09 Nov 2015 06:03:03 GMT\nx-log-apiversion:0.6.0\nx-log-bodyrawsize:50\nx-log-compresstype:lz4\nx-log-signaturemethod:hmac-sha1\n/logstores/test-logstore 同样，以前面示例中的 AccessKeySecret 做签名运算，得到的最终签名为： XWLGYHGg2F2hcfxWxMLiNkGki6g= 最后发送经数字签名的 HTTP 请求内容如下： POST /logstores/test-logstore HTTP/1.1 Date: Mon, 09 Nov 2015 06:03:03 GMT Host: test-project.regionid.example.com x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 Content-MD5: 1DD45FA4A70A9300CC9FE7305AF2C494 Content-Length: 52 x-log-apiversion:0.6.0 x-log-bodyrawsize:50 x-log-compresstype:lz4 x-log-signaturemethod:hmac-sha1 Authorization: LOG bq2sjzesjmo86kq35behupbq:XWLGYHGg2F2hcfxWxMLiNkGki6g= <日志内容序列化成ProtoBuffer格式的字节流>

如果Linux系统的ECS实例CPU持续保持高使用率，则会对系统稳定性和业务运行造成影响。可以按如下步骤进行处理。 定位问题。找到影响CPU使用率过高的具体进程。 分析处理。查看影响CPU使用率过高的进程是否正常，并分类进行处理。 对于正常进程：您需要对程序进行优化或者升级服务器配置。 对于异常进程：您可以手动对进程进行查杀，也可以使用第三方安全工具去查杀。 CPU负载的查询分析 在Linux系统中，查看进程的常用命令如下所示。本文主要介绍vmstat和top。 vmstat top ps -aux ps -ef 使用vmstat命令查看 通过vmstat命令，从系统维度查看CPU资源的使用情况。命令格式类似如下，表示结果一秒刷新一次。 vmstat -n 1 示例如下。 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 2684984 310452 2364304 0 0 5 17 19 35 4 2 94 0 0 0 0 0 2687504 310452 2362268 0 0 0 252 1942 4326 5 2 93 0 0 0 0 0 2687356 310460 2362252 0 0 0 68 1891 4449 3 2 95 0 0 0 0 0 2687252 310460 2362256 0 0 0 0 1906 4616 4 1 95 0 0 注：返回结果中的主要数据列说明如下。 r：表示系统中CPU等待处理的线程。一个CPU每次只能处理一个线程，所以该数值越大，通常表示系统运行越慢。 us：用户模式消耗的CPU时间百分比。该值较高时，说明用户进程消耗的CPU时间比较多。如果该值长期超过50%，则需要对程序算法或代码等进行优化。 sy：内核模式消耗的CPU时间百分比。 wa：IO等待消耗的CPU时间百分比。该值较高时，说明IO等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。 id：处于空闲状态的CPU时间百分比。如果该值持续为0，同时sy是us的两倍，则通常说明系统面临CPU资源短缺。 使用top命令查看 登录Linux实例，关于如何登录Linux实例，请参考使用管理终端连接Linux实例。 执行如下命令，从进程纬度来查看CPU、内存等资源的使用情况。命令格式类似如下。 top 系统显示类似如下。 top - 17:27:13 up 27 days, 3:13, 1 user, load average: 0.02, 0.03, 0.05 Tasks: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.3 us, 0.1 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.1 st KiB Mem: 1016656 total, 946628 used, 70028 free, 169536 buffers KiB Swap: 0 total, 0 used, 0 free. 448644 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 41412 3824 2308 S 0.0 0.4 0:19.01 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd 针对负载问题，您只需关注回显的第一行和第三行信息，详细说明如下。 top命令的第一行显示的内容17:27:13 up 27 days, 3:13, 1 user, load average: 0.02, 0.03, 0.05，依次为系统当前时间、系统到目前为止已运行的时间、当前登录系统的用户数量、系统负载，这与直接执行uptime命令查询结果一致。 top命令的第三行会显示当前CPU资源的总体使用情况，下方会显示各个进程的资源占用情况。 通过 P 键，可以对CPU使用率进行倒序排列，进而定位系统中占用CPU较高的进程。 提示：通过 M 键，您可以对系统内存使用情况进行排序。如果有多核CPU，数字键1可以显示每核CPU的负载状况。 执行如下命令，可以查看每个进程ID对应的程序文件。 ll /proc/PID/exe 操作案例 案例一：使用top命令终止CPU消耗较大的进程 通过top命令查看系统的负载问题，并定位耗用较多CPU资源的进程，在运行界面快速终止相应的异常进程。 想要终止某个进程，先键入小写字母 k。 输入想要终止的进程PID，默认为输出结果的第一个PID。如下图所示，假如想要终止PID为23的进程，输入23后回车。 操作成功后，界面会出现类似Send pid 23 signal [15/sigterm]的提示信息让用户进行确认。按回车确认即可。 案例二：CPU使用率较低但负载较高 问题描述 当前Linux系统没有业务程序运行。通过top命令观察，发现CPU很空闲，但是load average却非常高，如下图所示。 处理办法 load average是对CPU负载进行评估的，其值越高说明其任务队列越长，处于等待执行的任务越多。出现此种情况时，可能是由于僵死进程导致的。可以通过ps -axjf命令查看是否存在 D+ 状态进程，该状态是指不可中断的睡眠状态。处于该状态的进程无法终止，也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。 案例三：kswapd0进程占用CPU较高 操作系统使用分页机制来管理物理内存。操作系统将磁盘的一部分划出来作为虚拟内存，由于内存的速度要比磁盘快得多，所以操作系统要按照某种换页机制将不需要的页面换到磁盘中，将需要的页面调到内存中。由于内存持续不足，这个换页动作持续进行。kswapd0是虚拟内存管理中负责换页的进程，当服务器内存不足的时候kswapd0会执行换页操作，这个换页操作是十分消耗主机CPU资源的。如果通过top命令发现该进程持续处于非睡眠状态，且运行时间较长，可以初步判定系统在持续的进行换页操作，可以将问题转向内存不足的原因来排查。 问题描述 kswapd0进程占用了系统大量CPU资源。 处理办法 执行如下命令，查看kswapd0进程。 top 系统显示类似如下，发现kswapd0进程持续处于非睡眠状态，且运行时间较长并持续占用较高CPU资源，则通常是由于系统在持续的进行换页操作所致。 通过free 、ps等指令进一步查询系统及系统内进程的内存占用情况，做进一步排查分析。 针对系统当前内存不足的问题，您可以重启一些服务，释放内存。 提示：从长远的角度来看，您需要对内存大小进行升级。

常见错误处理 错误码 处理方式 1000 一般为语法或者超时引起，如果多次刷新不再出现，则是超时引起，如果仍出现，则语法有问题，请对照文档仔细检查，如分隔符、函数字段类型等 2112 排序表达式中的text_relevance(field)、fieldterm_proximity(field)等文本feature中的field必须在查询的索引包含的源字段中，否则会报错，但不影响搜索结果。 3007 对于API推送系统是有频率限制，请控制好频率重试 4003 可以先按照文档样例，试下签名结果是否一致，判断是否是签名算法问题。如果不是，请检查下参数按照字典序排序后应该是公共参数（大写字母）在前，请求参数（小写字母）在后。另外还有空格等一些编码规则，具体参考授权文档介绍 4007 一般Json字段内容中包含双引号或者不可见字符会导致格式解析失败，请转义或者过滤后重试 4010 TimeStamp参数是有过期时间的，请按照要求格式取当前时间来计算 5001 没有找到对应的用户，一般为ACCESSKEY信息不正确，或者使用区域域名错误（API域名请以应用管理-》基本信息-》API入口为准），请检查修改后重试 5008 服务内部是通过Accesskey来进行用户身份校验的，请确保AccessKey已经开启，您可以通过控制台AccessKey管理入口来创建和删除 6013 start+hit不能超过5000，否则会报错无结果。需要超过5000的请求，请查看下API文档中的SCROLL接口，看是否满足需求 6015 请及时到控制台配额管理处进行QPS峰值的调整，否则超过的请求会被丢弃 6127 除了query子句，其他子句出现的字段都必须配置为属性字段才能使用。请修改应用结构后重试 系统级别（1000-1999） 错误码 错误说明 1000 系统内部错误 1001 没有找到模版 1003 不支持的索引类型 1004 服务暂时不可用，请稍后再试 应用相关（2000-2999） 错误码 错误说明 2001 待查应用不存在 2002 应用已经存在 2003 到达创建应用总限制 2004 应用名不可用。应用名由数字、26个英文字母或下划线组成，长度不超过30位 2005 应用名称没有设定 2006 新应用名称没有设定 2007 备注不超300字 2008 摘要配置参数错误 2009 更新状态失败 2010 应用暂停中 2011 应用冻结中 2012 应用未开启 2013 删除失败，没有此应用 2014 文件上传失败 2016 区域信息没有 2017 此应用并不属于当前区域 2099 当前接口暂时不提供服务。 2101 表达式不存在 2102 表达式名称被占用 2103 到达该应用表达式总数限制 2104 表达式名不可用。表达式名由数字、26个英文字母或下划线组成，长度不超过30位 2105 表达式名称没有设定 2106 新表达式名称没有设定 2107 表达式备注不超过300字 2108 表达式备注格式错误 2109 表达式格式错误 2110 表达式长度超过限制 2111 表达式id未指定 2112 表达式错误 2113 表达式不能为空 2114 操作错误 2201 粗排配置名没有设定 2202 粗排配置名已经存在 2203 粗排配置个数超出限制 2204 粗排配置名错误。只能由数字、26个英文字母或下划线组成 2205 粗排配置名长度超出限制 2206 粗排字段必须是数值型 2207 粗排配置不存在 2208 粗排配置错误，必须包含字段 2209 粗排配置权重错误,必须是-100000到100000之间的非0数值，浮点数精度支持6位 2210 与系统默认粗排配置重名 2211 timeliness()的参数必须是INT类型 2112 排序表达式错误 2551 查询指定的下拉提示规则不存在 文档相关（3000-3999） 错误码 错误说明 3001 文档不能为空 3002 文档大小超过限制 3003 已经到最大文档数 3004 保存文档失败 3005 doc格式错误 3006 文档操作cmd不合法 3007 请求过于频繁 3008 文档总长度太长 3009 没有文档id 3011 在配置RDS或MYSQL数据源后，不支持API推送文档 3012 未找到指定资源 3013 文档推送速率超过应用配额 3014 文档推送速率触发系统限制 3015 单次推送文档个数超过系统限制 3016 文档总数超过应用配额 授权相关（4000-4999） 错误码 错误说明 4001 认证失败 4002 需要设置签名 4003 签名验证失败 4004 需要设置SignatureNonce 4005 SignatureNonce不能重复使用 4006 SignatureNonce验证失败 4007 解析JSON格式失败 4008 用户名称不能为空，请检查域名正确性 4009 需要指定用户标识 4010 时间过期 4011 demo帐号禁止执行的操作 4012 数据表不存在 4013 Timestamp格式错误 4014 需要设置Timestamp 4020 RAM子账户鉴权失败 用户相关（5000-5999） 错误码 错误说明 5001 用户不存在 5002 用户名不正确 5003 需要用户登录 5005 用户未开通OpenSearch服务，请前往阿里云官网开通 5008 用户没有启用ACCESSKEY 5100 用户没有此区域的操作权限 5004 用户未缴费 5005 用户未开通OpenSearch服务，请前往阿里云官网开通 5006 欠费冻结中 5008 用户没有启用ACCESSKEY 5009 用户已经删除 5010 ACCESSKEY 已经禁用 5011 通过邮箱获取到多个用户 5012 CODE_USER_ALIYUN_USER_ID_INVALID，错误信息为空 5013 CODE_USER_ALIYUN_BID_INVALID，错误信息为空 5014 CODE_USER_CLIENT_ID_INVALID，错误信息为空 5015 CODE_USER_ID_INVALID，错误信息为空 5100 用户没有此区域的操作权限 搜索相关（6000-6999） 错误码 错误说明 6001 查询query为空 6002 并不被支持的搜索key关键字 6003 并不被支持的搜索field关键字 6004 复杂查询为空 6005 field无效 6006 请求包含太多应用名 6007 超出多索引查询每个模板中索引总数 6008 请求串语法错误，解析失败 6009 查询子句过长 6010 无效的rerank size 6011 SignatureNonce格式错误 6013 start+hit超过系统限制 6014 因系统繁忙，请求被丢弃 6015 因流量超出配额，请求被丢弃 6016 查询hit数超过系统限制 6017 目前scroll只支持search_type为scan，也就是说设置了参数scroll，就必须设置参数search_type=scan 6018 设置了scroll参数，但没有search_type参数 6019 传入的scroll_id参数解析失败 6020 无效的scroll参数值 6021 scroll请求不支持Aggregate/Sort/Distinct，当传入这些clause时，会报错 6022 scroll_id已经过期失效了 6100 查询词为空 6101 查询的索引字段不存在 6102 Query中的数值范围错误 6103 Filter中的表达式返回值必须为bool类型 6104 Sort中的表达式返回值不能为bool类型 6105 Sort中存在相同的表达式 6106 查询query语句非法 6107 统计函数表达式的返回值不能为bool或者string类型 6108 统计中的范围必须为升序 6109 统计中的范围表达式返回值类型错误 6110 统计函数不存在 6111 不支持的统计函数 6112 Query 子句错误 6113 Filter子句错误 6114 Aggregate子句错误 6115 Sort子句错误 6116 Distinct子句错误 6117 查询中包含未知的子句 6118 语法错误 6119 Distinct子句中的dist_count值错误，应该为大于0的整数 6120 Distinct子句中的dist_times值错误，应该为大于0的整数 6121 Distinct子句中的reserved值错误，应为true/false 6122 Distinct子句缺少distinct_key 6123 Distinct子句中的grade值错误，例如为空，或非数值 6124 Distinct子句中包含distinct个数不对,个数应在(0,2] 6125 Distinct子句中的max_item_count值错误，应该为大于0的整数 6126 Distinct子句中的update_total_hit值错误，应为true/false 6127 请求中包含了未定义的attribute字段 6128 表达式中的二元操作符的两边的表达式结果类型不匹配 6129 表达式中的二元操作符的两边表达式不能同时为常量 6130 二元逻辑运算表达式类型错误，应为bool类型 6131 二元表达式中不支持string类型 6132 二元表达式中不支持数组类型 6133 位操作中的类型错误 6134 常量表达式的返回值类型错误 6300 常量表达式类型应是整数或浮点数 6301 位取反操作数类型必须为整数 6302 取负数操作数必须为数值 6303 逻辑非操作数必须为数值 6304 二元运算操作数类型错误 6305 非法的二元运算符 6306 函数参数类型错误 6307 函数未定义 6308 函数参数个数错误 6309 非法的数组操作 6310 可过滤字段不存在 6311 数组字段被错当作单值使用 6312 单值字段被错当作数组使用 6313 数组字段下标越界(小于0) 6314 不支持的字段类型 6315 索引字段参数不存在 6316 Query中没有指定索引 6317 Filter子句中只能使用一次公式 6318 公式语法解析出错 6500 搜索语法中包含不存在的字段 6501 在线系统没有索引数据 6502 用户query语法错误 6601 一个索引字段只能包含在一个规则中 6602 没有查询词，如default:’’的情况 6603 查询中的索引字段没有在查询分析规则中指定 6604 关键词没有使用引号括起来，如default:xxx，正确为default:’xxx’ 6605 双引号查询不能配置查询分析规则 6607 disable参数格式错误 6608 disable指定关闭的索引字段不存在 6609 disable指定关闭的功能列表不存在 6610 查询分析后的query为空（原query为空，或者全部是stopword） 6611 查询中没有指定索引字段 数据处理相关（7000-7999） 错误码 错误说明 7100 没有错误发生 7101 单个文档过长 7102 文档所属应用的元信息错误（clientid 或 accesskey、应用名或表名等不正确） 7103 HA3 文档格式错误: 字段解析失败 7104 JSON文档格式错误：字段解析失败 7105 JSON 文档格式错误: json非法 7106 JSON 文档格式错误: json非法 7107 不支持的编码 7108 编码转换失败 7109 fields中没有id字段 7110 fields中id定义不合法 7111 fields中包含保留字段 7201 HA3 文档格式错误: cmd 非法(cmd 非 ADD/UPDATE/DELETE) 7202 JSON 文档格式错误: cmd 非法(cmd 非 ADD/UPDATE/DELETE) 7301 主键字段不存在 7302 字段数据类型错误 7303 数组字段相关错误 7401 文档总数超出配额 7402 每日更新文档数超出配额 7403 单次导入的数据大小超出配额 7500 系统内部错误 7501 云梯Hive待同步字段的列号超出了当前数据的列数范围 7502 从Mysql中读取到的主键字段为空,请联系数据库管理员 7503 JsonKeyValueExtractor内容转换错误: Json格式非法 7504 JsonKeyValueExtractor内容转换错误: key不存在 7505 TairLDBExtractor内容转换错误: namespace非法（应为int32类型） 7506 TairLDBExtractor内容转换错误: 从Tair中读取数据失败 7507 MySql实时同步过滤条件格式错误 7508 系统内部错误: 内容转换插件初始化失败 7509 TairLDBExtractor内容转换配置错误：Tair连接失败，请检查configId 或 namespace 是否有效 7510 KVExtractor内容解析错误：KV格式无法解析 7511 OSS 数据读取失败 7512 OSS 内容长度超过限度 7513 OSS 内容解析错误 7514 系统内部错误: OSS LOG 格式不兼容 7515 过滤条件执行错误 7516 字段映射过程中源表字段缺失 7517 StringCatenateExtractor内容转换错误: 源字段不存在 7518 StringCatenateExtractor内容转换错误: 不支持多值字段 7601 任务执行错误 7602 更新app失败 7701 数据清理任务错误：指定过滤字段不存在 7801 文档格式错误 文档错误内部通知（8000-8999） 错误码 错误说明 8001 保存错误信息失败 8002 必要参数缺失 8003 应用不存在 8004 参数错误 模板相关（9000-9999） 错误码 错误说明 9001 用户名为空 9002 应用名为空 9003 模板名不可用。模板名只能由数字、26个英文字母或下划线组成 9004 模板名长度不可超过30位 9005 查询模板信息出错 9006 模板名字已存在 9007 插入模板信息出错 9008 无效的数据 9009 定义的字段数目超过系统允许的最大字段数 9010 此字段保留字段名 9011 字段已存在 9012 索引名称必须以字母开头，由数字、26个英文字母或下划线组成，长度不超过30位，多值字段类型不能为SWS_TEXT或TEXT 9013 不支持数组 9014 不支持主键 9015 未设定主键 9016 主键不唯一 9017 更新信息失败 9018 删除信息失败 9019 包含多个索引字段的搜索字段最多4个 9020 同一个STRING/TEXT类型的索引字段不能进入多个只包含一个字段的搜索字段中 9021 索引名称必须以字母开头，由数字、26个英文字母或下划线组成，长度不超过30个 9022 该表已经关联 9023 索引名不能包含多类型的字段 9100 系统内部错误 9101 该字段超过数量限制 9102 该数据源未被用到 9103 无效的外表连接 9104 最多2级关联 9105 待查模板不存在 9501 用户名为空 9502 应用名为空 9519 未指定模板 9600 系统内部错误 9902 插件字段类型错误 9999 此域名不提供本服务 数据同步相关（10000-） 错误码 错误说明 10001 没有指定的tddl group key，tddl信息获取失败 10002 获取字段失败或者表不存在 10011 连接agg失败 10012 应用里存在doc 10013 应用不是自定义结构 10110 该任务已结束 10010 部分数据源有问题，已经忽略有错误的数据 10014 数据源类型错误 10100 创建任务失败，未结束的任务已经存在 10101 没有指定应用ID 10106 没有指定应用ID 10107 没有指定应用ID 10102 ACTION无效 10112 文档数量超过限制 10201 获取配额列表失败 10202 更新配额失败 10301 参数错误：参数未提供或者格式不正确 10302 时间参数错误 10303 数据源未配置 10304 该表配额超限 10305 OSS参数错误 10306 OSS BUCKET名称无效 10307 OSS 记录类型无效 10308 OSS BUCKET日志功能未开启 10309 存在未完成的任务 10310 不是运行中的应用，无法创建任务 10311 时间范围不合法 10312 应用描述长度超过限制，最多600字 10313 OSS 内容格式不合法 10314 OSS BUCKET所在区域ACL网络不通 10315 OSS BUCKET的地址信息不合法 10330 数据源参数不合法 10350 连接ODPS服务失败 10351 ODPS 返回错误 10400 OSS前缀不合法 10450 字段不存在

本文适用基于API URL发起HTTP/HTTPS GET请求的用户，如果您使用的是SDK可以跳过此环节。 发起API请求的URL由不同参数拼凑而成，有固定的请求结构。URL中包含公共参数、您的签名机制和某个API的具体参数。每篇API文档均给出了URL请求示例供您参考，但是为了方便显示，我们并没有编码这些URL示例，您需要在发起请求前自行编码。我们根据您的签名验证了请求后，会返回结果。接口调用成功会显示返回参数，调用失败则显示相应报错，您可以根据公共错误码和具体API错误码分析排查。 公共参数分为公共请求参数和公共返回参数。 公共请求参数 名称 类型 是否必需 描述 Action String 是 API的名称。取值参见API概览。 AccessKeyId String 是 访问密钥ID。AccessKey用于调用API，而用户密码用于登录OOS 管理控制台 Signature String 是 您的签名。取值参见签名机制。 SignatureMethod String 是 签名方式。取值范围：HMAC-SHA1。 SignatureVersion String 是 签名算法版本。取值范围：1.0。 SignatureNonce String 是 签名唯一随机数。用于防止网络重放攻击，建议您每一次请求都使用不同的随机数。 Timestamp String 是 请求的时间戳。按照时间格式标准表示，并需要使用UTC时间，格式为yyyy-MM-ddTHH:mm:ssZ。示例：2019-06-01T12:00:00Z表示北京时间2019年06月01日12点00分00秒。 Version String 是 API 的版本号，格式为 YYYY-MM-DD。取值范围：2019-06-01。 Format String 是 返回参数的语言类型。取值范围：json。 请求示例 https://oos.cn-hangzhou.aliyuncs.com/?Action=XXXXXX &Format=json &Version=2019-06-01 &Signature=cWgxtKc9dQWgSMB7OEhtOkq%2B9AM%3D &SignatureMethod=HMAC-SHA1 &SignatureNonce=479a2bf5-8045-11e9-8d42-6c96cfdd1fa1 &SignatureVersion=1.0 &AccessKeyId=key-test &Timestamp=2019-05-27T06%3A04%3A25Z … 公共返回参数 名称 类型 描述 RequestId String 请求ID。无论调用接口成功与否，我们都会返回请求ID。 阿里云OOS API支持基于URL发起HTTP/HTTPS GET请求。请求参数需要包含在URL中。本文列举了GET请求中的结构解释，并提供了OOS的服务接入地址（Endpoint）。 结构示例 以下为CreateTemplate一条未编码的URL请求示例： https://oos.cn-hangzhou.aliyuncs.com/?Action=CreateTemplate &TemplateName=YourTemplateName &<公共请求参数> https指定了请求通信协议。 oos.cn-hangzhou.aliyuncs.com指定了OOS的服务接入地址（Endpoint）。 Action=CreateTemplate指定了要调用的API，TemplateName=YourTemplateName是CreateTemplate规定的参数。 <公共请求参数>是系统规定的公共参数。 通信协议 支持HTTP或HTTPS协议请求通信。为了获得更高的安全性，推荐您使用HTTPS协议发送请求。 涉及敏感数据时，如用户密码和SSH密钥对，推荐使用HTTPS协议。例如，在StartExecution中指定敏感参数时。 接入地址 OOS API的服务接入地址，参见以下表格。为较少网络延时，建议您根据业务调用来源配置接入地址。 华东1（杭州） oos.cn-hangzhou.aliyuncs.com 华北2（北京） oos.cn-beijing.aliyuncs.com 华北5（呼和浩特） oos.cn-huhehaote.aliyuncs.com 华北3（张家口) oos.cn-zhangjiakou.aliyuncs.com 中国香港 oos.cn-hongkong.aliyuncs.com 华东2（上海） oos.cn-shanghai.aliyuncs.com 华南1（深圳） oos.cn-shenzhen.aliyuncs.com 印度（孟买） oos.ap-south-1.aliyuncs.com 美国（弗吉尼亚） oos.us-east-1.aliyuncs.com 德国(法兰克福) oos.eu-central-1.aliyuncs.com 英国(伦敦) oos.eu-west-1.aliyuncs.com 请求参数 您需要通过Action参数指定目标操作，例如Action=CreateTemplate。还需要指定接口的其他参数以及公共请求参数。 字符编码 请求及返回结果都使用UTF-8字符集编码。 对于每一次HTTP或者HTTPS协议请求，我们会根据访问中的签名信息验证访问请求者身份。具体由使用AccessKeyID和AccessKeySecret对称加密验证实现。 AccessKey相当于用户密码，AccessKey用于调用API，而用户密码用于登录OOS控制台。其中AccessKeyID是访问者身份，AccessKeySecret是加密签名字符串和服务器端验证签名字符串的密钥，必须严格保密谨防泄露。 说明 我们提供了多种编程语言的SDK及第三方SDK，可以免去您签名的烦恼。更多详情，请下载SDK。 构造规范化请求字符串 排序参数。排序规则以首字母顺序排序，排序参数包括公共请求参数和接口自定义参数，不包括公共请求参数中的Signature参数。 说明 当使用GET方法提交请求时，这些参数就是请求URL中的参数部分，即URL中?之后由&连接的部分。 编码参数。使用UTF-8字符集按照RFC3986规则编码请求参数和参数取值，编码规则如下： 字符A~Z、a~z、0~9以及字符 -、_、.、~不编码。 其它字符编码成%XY的格式，其中XY是字符对应ASCII码的16进制。示例：半角双引号（"）对应%22。 扩展的UTF-8字符，编码成%XY%ZA…的格式。 空格（ ）编码成%20，而不是加号（+）。该编码方式与application/x-www-form-urlencoded MIME格式编码算法相似，但又有所不同。如果您使用的是Java标准库中的java.net.URLEncoder，可以先用标准库中percentEncode编码，随后将编码后的字符中加号（+）替换为%20、星号（）替换为%2A、%7E替换为波浪号（~），即可得到上述规则描述的编码字符串。 private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("", "%2A").replace("%7E", "~") : null; } 使用等号（=）连接编码后的请求参数和参数取值。 使用与号（&）连接编码后的请求参数，注意参数排序与步骤一：构造规范化请求字符串一致。 现在，您得到了规范化请求字符串（CanonicalizedQueryString），其结构遵循请求结构。 构造签名字符串 构造待签名字符串StringToSign。您可以同样使用percentEncode处理上一步构造的规范化请求字符串，规则如下： StringToSign= HTTPMethod + "&" + //HTTPMethod：发送请求的 HTTP 方法，例如 GET。 percentEncode("/") + "&" + //percentEncode("/")：字符（/）UTF-8 编码得到的值，即 %2F。 percentEncode(CanonicalizedQueryString) //您的规范化请求字符串。 按照RFC2104的定义，计算待签名字符串StringToSign的HMAC-SHA1值。示例使用的是Java Base64编码方法。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of(StringToSign) ) ) 添加根据RFC3986规则编码后的参数Signature到规范化请求字符串URL中。 说明 计算签名时，RFC2104规定的Key值是您的AccessKeySecret并加上与号（&)，其ASCII值为38。 示例 1. 参数拼接法 以调用ListTemplates查询模板为例。假设您获得了AccessKeyID=testid以及AccessKeySecret=testsecret，签名流程如下所示： 构造规范化请求字符串。 AccessKeyId=testid&Action=ListTemplates&Format=json&SignatureMethod=HMAC-SHA1&SignatureNonce=9a3fdf30-8049-11e9-8875-6c96cfdd1fa1&SignatureVersion=1.0&Timestamp=2019-05-27T06%3A35%3A22Z&Version=2019-06-01 构造待签名字符串StringToSign，详情请参见步骤二：构造签名字符串。 GET&%2F&AccessKeyId%3Dtestid&Action%3DListTemplates&Format%3Djson&SignatureMethod%3DHMAC-SHA1&SignatureNonce%3D9a3fdf30-8049-11e9-8875-6c96cfdd1fa1&SignatureVersion%3D1.0&Timestamp%3D2019-05-27T06%253A35%253A22Z&Version%3D2019-06-01 计算签名值。因为AccessKeySecret=testsecret，用于计算的Key为testsecret&，计算得到的签名值为 1FcsD6/AvH2KugeowoCJSi8lBd8=。示例使用的是Java Base64编码方法。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of(StringToSign) ) ) 添加RFC3986规则编码后的Signature=1FcsD6%2FAvH2KugeowoCJSi8lBd8%3D到步骤一：构造规范化请求字符串的URL中。 http://oos.cn-hangzhou.aliyuncs.com/?SignatureVersion=1.0&Format=json&Timestamp=2019-05-27T06%3A35%3A22Z&AccessKeyId=testid&SignatureMethod=HMAC-SHA1&Version=2019-06-01&Signature=1FcsD6%2FAvH2KugeowoCJSi8lBd8%3D&Action=ListTemplates&SignatureNonce=9a3fdf30-8049-11e9-8875-6c96cfdd1fa1 通过以上URL，您可以使用浏览器、curl或者wget等工具发起HTTP请求调用ListTemplates，查询您的模板。 示例 2. 编程语言法 依然以调用ListTemplates查询模板为例。假设您获得了AccessKeyID=testid以及AccessKeySecret=testsecret，并且假定所有请求参数放在一个Java Map<String, String>对象里。 预定义编码方法。 private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 预定义编码时间格式Timestamp。参数Timestamp必须符合时间格式规范，并需要使用UTC时间，时区为+0。 private static final String ISO8601_DATE_FORMAT = "yyyy-MM-dd'T'HH:mm:ss'Z'"; private static String formatIso8601Date(Date date) { SimpleDateFormat df = new SimpleDateFormat(ISO8601_DATE_FORMAT); df.setTimeZone(new SimpleTimeZone(0, "GMT")); return df.format(date); } 构造请求字符串。 final String HTTP_METHOD = "GET"; Map parameters = new HashMap(); // 输入请求参数 parameters.put("Action", "ListTemplates"); parameters.put("Version", "2019-06-01"); parameters.put("AccessKeyId", "testid"); parameters.put("Timestamp", formatIso8601Date(new Date())); parameters.put("SignatureMethod", "HMAC-SHA1"); parameters.put("SignatureVersion", "1.0"); parameters.put("SignatureNonce", UUID.randomUUID().toString()); parameters.put("Format", "JSON"); // 排序请求参数 String[] sortedKeys = parameters.keySet().toArray(new String[]{}); Arrays.sort(sortedKeys); final String SEPARATOR = "&"; // 构造 stringToSign 字符串 StringBuilder stringToSign = new StringBuilder(); stringToSign.append(HTTP_METHOD).append(SEPARATOR); stringToSign.append(percentEncode("/")).append(SEPARATOR); StringBuilder canonicalizedQueryString = new StringBuilder(); for(String key : sortedKeys) { // 这里注意编码 key 和 value canonicalizedQueryString.append("&") .append(percentEncode(key)).append("=") .append(percentEncode(parameters.get(key))); } // 这里注意编码 canonicalizedQueryString stringToSign.append(percentEncode( canonicalizedQueryString.toString().substring(1))); 签名。因为 AccessKeySecret=testsecret，所以用于计算HMAC的Key为testsecret&，计算得到的签名值为1FcsD6/AvH2KugeowoCJSi8lBd8=。 // 以下是一段计算签名的示例代码 final String ALGORITHM = "HmacSHA1"; final String ENCODING = "UTF-8"; key = "testsecret&"; Mac mac = Mac.getInstance(ALGORITHM); mac.init(new SecretKeySpec(key.getBytes(ENCODING), ALGORITHM)); byte[] signData = mac.doFinal(stringToSign.getBytes(ENCODING)); String signature = new String(Base64.encodeBase64(signData)); 增加签名参数后，按照RFC3986规则编码后的URL如下所示： http://oos.cn-hangzhou.aliyuncs.com/?SignatureVersion=1.0&Format=json&Timestamp=2019-05-27T06%3A35%3A22Z&AccessKeyId=testid&SignatureMethod=HMAC-SHA1&Version=2019-06-01&Signature=1FcsD6%2FAvH2KugeowoCJSi8lBd8%3D&Action=ListTemplates&SignatureNonce=9a3fdf30-8049-11e9-8875-6c96cfdd1fa1 使用浏览器、curl或者wget等工具发送HTTP请求。 { "Templates": [ { "Hash": "9ea05673ea6c7d03fe8707ddd3d347d74f9e47963538097d120583c0b5385edf", "Description": "", "TemplateName": "demo", "ShareType": "Private", "Tags": [], "TemplateFormat": "JSON", "CreatedBy": "1000008528360000", "CreatedDate": "2019-06-01T12:00:00Z", "TemplateVersion": "v1", "TotalExecutionCount": 1 },...], "NextToken": "gAAAAABc5pnvl_meBuZkGEbZNmzTOA1RotEjFs4q8q2fICes_oGk4qenxGB5UeyXYWa5eF4TeZLQMpnVc6rmhr2BC0Kahyx1P5brt_fQvLFTLBEcXQzzqsWwxDS-Y1xL7pkhOOgU_K3Z0-dMQHOkIQwWhodp4qutzKNO7gQ-EPWQvM1ugrGkonFDe_bV3TckHyHqgJDTLwk8Swfm1NvnZTXg9AH8YLvhu0fTK8sgXI6nBkvqTkozedWFhq8jmH1SFbs1yVZoKoKpFaYV6-vuTFcUO9G9-5W0YVdfliTuEOf42QHtkWLZ8jj1Xhmk9rTBYjb7P4KmRm7b7UhQ6FamvpVv9vXlCQvWAafnPgT98ViFlr6z7ByNHrI=", "RequestId": "8B813042-7F00-45CE-AF8C-85CCEEFC6BA2", "MaxResults": 50 } 返回结果列举了模板信息。 返回结果为JSON格式。为了便于查看和美观，API文档返回示例均有换行和缩进等处理，实际返回结果无换行和缩进处理。 正常返回示例 接口调用成功后会返回接口返回参数和请求ID，我们称这样的返回为正常返回。HTTP状态码为2xx。 JSON示例 { "RequestId": "AC467B38-3910-447D-87BC-AC049166F216" /* 返回结果数据 */ } 异常返回示例 接口调用出错后，会返回错误码、错误信息和请求ID，我们称这样的返回为异常返回。HTTP状态码为4xx或者5xx。 您可以根据接口错误码，参考公共错误码以及API错误中心排查错误。当您无法排查错误时，可以提交工单联系我们，并在工单中注明服务节点HostId和RequestId。 JSON示例 { "RequestId": "A40CFF28-407A-40B5-B6A5-AC049166F216", /* 请求 ID / "HostId": "oos.cn-hangzhou.aliyuncs.com", / 服务节点 / "Code": "InvalidNextToken", / 错误码 / "Message": "NextToken is invalid" / 错误信息 / } 公共错误码 错误代码 HTTP状态码 错误信息 描述 InvalidVersion 400 Specified parameter Version is not valid. 给定的Version非法。请检查URL中指定的Version的正确性。 InvalidAction.NotFound 400 Specified api is not found, please check your url and method. 给定的API不存在。请检查URL中指定的Action的正确性。 Throttling.User 400 Request was denied due to user flow control. 访问频率太高导致流控。 InvalidParameter 400 内容随校验场景不同而不同，如 TemplateName can not contain “” 参数非法。请根据错误信息来检查指定参数的正确性。 User.NoPermission 400 User has no permission to do the action: ({api_name}) 用户没有调用某个API的权限。请检查是否在RAM中给当前用户赋予了OOS的API的权限。 InvalidStsToken 400 Invalid STS token to do the action: ({api_name}) 给定的STS Token非法。 ExpiredStsToken 400 Expired STS token to do the action: ({api_name}) 给定的STS Token过期。 MissingParameter 400 The Parameter ({name}) was not provided. 缺少必填参数。 QuotaExceed 400 The Quota ({key}) exceeded ({value}). 特定属性（如模板数量、正在运行的执行数等）超过上限。 InvalidAccountType 400 The account type ({account_type}) was not supported. 不支持给定的账号类型。 TemplateValidationError 400 {reason} 模板约束，如参数类型、数值等，校验不通过。 InvalidFunctionParameters 400 The specified function {fn_name}’s parameters are incorrect. 模板中使用函数时给定的参数校验错误。请检查参数的数量和值。 InvalidTemplateReference 400 The specified reference {resource} (in {key}) is incorrect. 模板内参数引用不正确。 UnknownUserParameter 400 The parameter ({key}) was not defined in engine. 模板中给定的参数未定义或不被支持。 InvalidTimerTriggerParameter 400 The parameter ({key}) is invalid TimerTrigger动作的给定参数非法。 InvalidTemplateParameter 400 The parameter ({key}) has no attributes. 模板中的Parameters类型非法，必须为字典。

共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE 锁的类别有两种分法： 1. 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁 MS-SQL Server 使用以下资源锁模式。 锁模式 描述 共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。 更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。 排它 (X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。 意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。 架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。 大容量更新 (BU) 向表中大容量复制数据并指定了 TABLOCK 提示时使用。 共享锁 共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁。 更新锁 更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。 若要避免这种潜在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。 排它锁 排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。 意向锁 意向锁表示 SQL Server 需要在层次结构中的某些底层资源上获取共享 (S) 锁或排它 (X) 锁。例如，放置在表级的共享意向锁表示事务打算在表中的页或行上放置共享 (S) 锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它 (X) 锁。意向锁可以提高性能，因为 SQL Server 仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁。而无须检查表中的每行或每页上的锁以确定事务是否可以锁定整个表。 意向锁包括意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。 锁模式 描述 意向共享 (IS) 通过在各资源上放置 S 锁，表明事务的意向是读取层次结构中的部分（而不是全部）底层资源。 意向排它 (IX) 通过在各资源上放置 X 锁，表明事务的意向是修改层次结构中的部分（而不是全部）底层资源。IX 是 IS 的超集。 与意向排它共享 (SIX) 通过在各资源上放置 IX 锁，表明事务的意向是读取层次结构中的全部底层资源并修改部分（而不是全部）底层资源。允许顶层资源上的并发 IS 锁。例如，表的 SIX 锁在表上放置一个 SIX 锁（允许并发 IS 锁），在当前所修改页上放置 IX 锁（在已修改行上放置 X 锁）。虽然每个资源在一段时间内只能有一个 SIX 锁，以防止其它事务对资源进行更新，但是其它事务可以通过获取表级的 IS 锁来读取层次结构中的底层资源。 独占锁：只允许进行锁定操作的程序使用，其他任何对他的操作均不会被接受。执行数据更新命令时，SQL Server会自动使用独占锁。当对象上有其他锁存在时，无法对其加独占锁。 共享锁：共享锁锁定的资源可以被其他用户读取，但其他用户无法修改它，在执行Select时，SQL Server会对对象加共享锁。 更新锁：当SQL Server准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server确定要进行更新数据操作时，他会自动将更新锁换为独占锁，当对象上有其他锁存在时，无法对其加更新锁。 数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。MySQL各存储引擎使用了三种类型（级别）的锁定机制：表级锁定，行级锁定和页级锁定。 1.表级锁定（table-level） 表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。 当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。 使用表级锁定的主要是MyISAM，MEMORY，CSV等一些非事务性存储引擎。 2.行级锁定（row-level） 行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。 虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定也最容易发生死锁。 使用行级锁定的主要是InnoDB存储引擎。 3.页级锁定（page-level） 页级锁定是MySQL中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。 在数据库实现资源锁定的过程中，随着锁定资源颗粒度的减小，锁定相同数据量的数据所需要消耗的内存数量是越来越多的，实现算法也会越来越复杂。不过，随着锁定资源颗粒度的减小，应用程序的访问请求遇到锁等待的可能性也会随之降低，系统整体并发度也随之提升。 使用页级锁定的主要是BerkeleyDB存储引擎。 总的来说，MySQL这3种锁的特性可大致归纳如下： 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低； 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高； 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 适用：从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。 -------------MYSQL处理------------------ 表级锁定 由于MyISAM存储引擎使用的锁定机制完全是由MySQL提供的表级锁定实现，所以下面我们将以MyISAM存储引擎作为示例存储引擎。 1.MySQL表级锁的锁模式 MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。锁模式的兼容性： 对MyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求； 对MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作； MyISAM表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。 2.如何加表锁 MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。 3.MyISAM表锁优化建议 对于MyISAM存储引擎，虽然使用表级锁定在锁定实现的过程中比实现行级锁定或者页级锁所带来的附加成本都要小，锁定本身所消耗的资源也是最少。但是由于锁定的颗粒度比较到，所以造成锁定资源的争用情况也会比其他的锁定级别都要多，从而在较大程度上会降低并发处理能力。所以，在优化MyISAM存储引擎锁定问题的时候，最关键的就是如何让其提高并发度。由于锁定级别是不可能改变的了，所以我们首先需要尽可能让锁定的时间变短，然后就是让可能并发进行的操作尽可能的并发。 （1）查询表级锁争用情况 MySQL内部有两组专门的状态变量记录系统内部锁资源争用情况： mysql> show status like 'table%'; +----------------------------+---------+ | Variable_name | Value | +----------------------------+---------+ | Table_locks_immediate | 100 | | Table_locks_waited | 10 | +----------------------------+---------+ 这里有两个状态变量记录MySQL内部表级锁定的情况，两个变量说明如下： Table_locks_immediate：产生表级锁定的次数； Table_locks_waited：出现表级锁定争用而发生等待的次数； 两个状态值都是从系统启动后开始记录，出现一次对应的事件则数量加1。如果这里的Table_locks_waited状态值比较高，那么说明系统中表级锁定争用现象比较严重，就需要进一步分析为什么会有较多的锁定资源争用了。 （2）缩短锁定时间 如何让锁定时间尽可能的短呢？唯一的办法就是让我们的Query执行时间尽可能的短。 a)尽两减少大的复杂Query，将复杂Query分拆成几个小的Query分布进行； b)尽可能的建立足够高效的索引，让数据检索更迅速； c)尽量让MyISAM存储引擎的表只存放必要的信息，控制字段类型； d)利用合适的机会优化MyISAM表数据文件。 （3）分离能并行的操作 说到MyISAM的表锁，而且是读写互相阻塞的表锁，可能有些人会认为在MyISAM存储引擎的表上就只能是完全的串行化，没办法再并行了。大家不要忘记了，MyISAM的存储引擎还有一个非常有用的特性，那就是ConcurrentInsert（并发插入）的特性。 MyISAM存储引擎有一个控制是否打开Concurrent Insert功能的参数选项：concurrent_insert，可以设置为0，1或者2。三个值的具体说明如下： concurrent_insert=2，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录； concurrent_insert=1，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置； concurrent_insert=0，不允许并发插入。 可以利用MyISAM存储引擎的并发插入特性，来解决应用中对同一表查询和插入的锁争用。例如，将concurrent_insert系统变量设为2，总是允许并发插入；同时，通过定期在系统空闲时段执行OPTIMIZE TABLE语句来整理空间碎片，收回因删除记录而产生的中间空洞。 （4）合理利用读写优先级 MyISAM存储引擎的是读写互相阻塞的，那么，一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？ 答案是写进程先获得锁。不仅如此，即使读请求先到锁等待队列，写请求后到，写锁也会插到读锁请求之前。 这是因为MySQL的表级锁定对于读和写是有不同优先级设定的，默认情况下是写优先级要大于读优先级。 所以，如果我们可以根据各自系统环境的差异决定读与写的优先级： 通过执行命令SET LOW_PRIORITY_UPDATES=1，使该连接读比写的优先级高。如果我们的系统是一个以读为主，可以设置此参数，如果以写为主，则不用设置； 通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。 虽然上面方法都是要么更新优先，要么查询优先的方法，但还是可以用其来解决查询相对重要的应用（如用户登录系统）中，读锁等待严重的问题。 另外，MySQL也提供了一种折中的办法来调节读写冲突，即给系统参数max_write_lock_count设置一个合适的值，当一个表的读锁达到这个值后，MySQL就暂时将写请求的优先级降低，给读进程一定获得锁的机会。 这里还要强调一点：一些需要长时间运行的查询操作，也会使写进程“饿死”，因此，应用中应尽量避免出现长时间运行的查询操作，不要总想用一条SELECT语句来解决问题，因为这种看似巧妙的SQL语句，往往比较复杂，执行时间较长，在可能的情况下可以通过使用中间表等措施对SQL语句做一定的“分解”，使每一步查询都能在较短时间完成，从而减少锁冲突。如果复杂查询不可避免，应尽量安排在数据库空闲时段执行，比如一些定期统计可以安排在夜间执行 三、行级锁定 行级锁定不是MySQL自己实现的锁定方式，而是由其他存储引擎自己所实现的，如广为大家所知的InnoDB存储引擎，以及MySQL的分布式存储引擎NDBCluster等都是实现了行级锁定。考虑到行级锁定君由各个存储引擎自行实现，而且具体实现也各有差别，而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎，所以这里我们就主要分析一下InnoDB的锁定特性。 1.InnoDB锁定模式及实现机制 考虑到行级锁定君由各个存储引擎自行实现，而且具体实现也各有差别，而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎，所以这里我们就主要分析一下InnoDB的锁定特性。 总的来说，InnoDB的锁定机制和Oracle数据库有不少相似之处。InnoDB的行级锁定同样分为两种类型，共享锁和排他锁，而在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。 当一个事务需要给自己需要的某个资源加锁的时候，如果遇到一个共享锁正锁定着自己需要的资源的时候，自己可以再加一个共享锁，不过不能加排他锁。但是，如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。而如果自己需要的是某行（或者某些行）上面添加一个排他锁的话，则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个，但是意向排他锁同时只能有一个存在。所以，可以说InnoDB的锁定模式实际上可以分为四种：共享锁（S），排他锁（X），意向共享锁（IS）和意向排他锁（IX），我们可以通过以下表格来总结上面这四种所的共存逻辑关系 如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。 意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。 共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE 用SELECT ... IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。 但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT... FOR UPDATE方式获得排他锁。 2.InnoDB行锁实现方式 InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁 在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。 （1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。 （2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。 （3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。 （4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。 3.间隙锁（Next-Key锁） 当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁； 对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。 例： 假如emp表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL： mysql> select * from emp where empid > 100 for update; 是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。 InnoDB使用间隙锁的目的： （1）防止幻读，以满足相关隔离级别的要求。对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读； （2）为了满足其恢复和复制的需要。 很显然，在使用范围条件检索并锁定记录时，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。 除了间隙锁给InnoDB带来性能的负面影响之外，通过索引实现锁定的方式还存在其他几个较大的性能隐患： （1）当Query无法利用索引的时候，InnoDB会放弃使用行级别锁定而改用表级别的锁定，造成并发性能的降低； （2）当Query使用的索引并不包含所有过滤条件的时候，数据检索使用到的索引键所只想的数据可能有部分并不属于该Query的结果集的行列，但是也会被锁定，因为间隙锁锁定的是一个范围，而不是具体的索引键； （3）当Query在使用索引定位数据的时候，如果使用的索引键一样但访问的数据行不同的时候（索引只是过滤条件的一部分），一样会被锁定。 因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。 还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁。 4.死锁 MyISAM表锁是deadlock free的，这是因为MyISAM总是一次获得所需的全部锁，要么全部满足，要么等待，因此不会出现死锁。但在InnoDB中，除单个SQL组成的事务外，锁是逐步获得的，当两个事务都需要获得对方持有的排他锁才能继续完成事务，这种循环锁等待就是典型的死锁。 在InnoDB的事务管理和锁定机制中，有专门检测死锁的机制，会在系统中产生死锁之后的很短时间内就检测到该死锁的存在。当InnoDB检测到系统中产生了死锁之后，InnoDB会通过相应的判断来选这产生死锁的两个事务中较小的事务来回滚，而让另外一个较大的事务成功完成。 那InnoDB是以什么来为标准判定事务的大小的呢？MySQL官方手册中也提到了这个问题，实际上在InnoDB发现死锁之后，会计算出两个事务各自插入、更新或者删除的数据量来判定两个事务的大小。也就是说哪个事务所改变的记录条数越多，在死锁中就越不会被回滚掉。 但是有一点需要注意的就是，当产生死锁的场景中涉及到不止InnoDB存储引擎的时候，InnoDB是没办法检测到该死锁的，这时候就只能通过锁定超时限制参数InnoDB_lock_wait_timeout来解决。 需要说明的是，这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。 通常来说，死锁都是应用设计的问题，通过调整业务流程、数据库对象设计、事务大小，以及访问数据库的SQL语句，绝大部分死锁都可以避免。下面就通过实例来介绍几种避免死锁的常用方法： （1）在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。 （2）在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。 （3）在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。 （4）在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED，就可避免问题。 （5）当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT...FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第1个线程提交后，第2个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁。这时如果有第3个线程又来申请排他锁，也会出现死锁。对于这种情况，可以直接做插入操作，然后再捕获主键重异常，或者在遇到主键重错误时，总是执行ROLLBACK释放获得的排他锁。 5.什么时候使用表锁 对于InnoDB表，在绝大部分情况下都应该使用行级锁，因为事务和行锁往往是我们之所以选择InnoDB表的理由。但在个别特殊事务中，也可以考虑使用表级锁： （1）事务需要更新大部分或全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高该事务的执行速度。 （2）事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。这种情况也可以考虑一次性锁定事务涉及的表，从而避免死锁、减少数据库因事务回滚带来的开销。 应用中这两种事务不能太多，否则，就应该考虑使用MyISAM表了。 在InnoDB下，使用表锁要注意以下两点。 （1）使用LOCK TABLES虽然可以给InnoDB加表级锁，但必须说明的是，表锁不是由InnoDB存储引擎层管理的，而是由其上一层──MySQL Server负责的，仅当autocommit=0、InnoDB_table_locks=1（默认设置）时，InnoDB层才能知道MySQL加的表锁，MySQL Server也才能感知InnoDB加的行锁，这种情况下，InnoDB才能自动识别涉及表级锁的死锁，否则，InnoDB将无法自动检测并处理这种死锁。 （2）在用 LOCK TABLES对InnoDB表加锁时要注意，要将AUTOCOMMIT设为0，否则MySQL不会给表加锁；事务结束前，不要用UNLOCK TABLES释放表锁，因为UNLOCK TABLES会隐含地提交事务；COMMIT或ROLLBACK并不能释放用LOCK TABLES加的表级锁，必须用UNLOCK TABLES释放表锁。

您可以使用阿里云负载均衡来访问服务。 背景信息 如果您的集群的cloud-controller-manager版本大于等于v1.9.3，对于指定已有SLB，系统默认不再为该SLB处理监听，用户可以通过设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"参数来显示启用监听配置，或者手动配置该SLB的监听规则。 执行以下命令，可查看cloud-controller-manager的版本。 root@master # kubectl get pod -n kube-system -o yaml|grep image:|grep cloud-con|uniq image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/cloud-controller-manager-amd64:v1.9.3 注意事项 Cloud Controller Manager（简称CCM）会为Type=LoadBalancer类型的Service创建或配置阿里云负载均衡（SLB），包含SLB、监听、虚拟服务器组等资源。 对于非LoadBalancer类型的Service则不会为其配置负载均衡，这包含如下场景：当用户将Type=LoadBalancer的Service变更为Type!=LoadBalancer时，CCM也会删除其原先为该Service创建的SLB（用户通过service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id指定的已有SLB除外）。 自动刷新配置 CCM使用声明式API，会在一定条件下自动根据Service的配置刷新阿里云负载均衡配置，所有用户自行在SLB控制台上修改的配置均存在被覆盖的风险（使用已有SLB同时不覆盖监听的场景除外），因此不能在SLB控制台手动修改Kubernetes创建并维护的SLB的任何配置，否则有配置丢失的风险。 同时支持为serivce指定一个已有的负载均衡，或者让CCM自行创建新的负载均衡。但两种方式在SLB的管理方面存在一些差异： 指定已有SLB 仅支持复用负载均衡控制台创建的SLB，不支持复用CCM创建的SLB。 如果您需要在Kubernetes集群中复用私网类型的SLB，则该SLB需要和Kubernetes集群在同一VPC下。 需要为Service设置annotation：service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id 。 SLB配置 此时CCM会使用该SLB做为Service的SLB，并根据其他annotation配置SLB，并且自动的为SLB创建多个虚拟服务器组（当集群节点变化的时候，也会同步更新虚拟服务器组里面的节点）。 监听配置 是否配置监听取决于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: 是否设置为true。如果设置为false，CCM不会为SLB管理任何监听配置；如果设置为true，CCM会根据service配置管理监听，如果监听已经存在，则CCM会覆盖已有监听。 SLB的删除 当Service删除时CCM不会删除用户通过id指定的已有SLB。 CCM管理的SLB CCM会根据Service的配置自动的创建配置SLB、监听、虚拟服务器组等资源，所有资源归CCM管理，因此用户不得手动在SLB控制台更改以上资源的配置，否则CCM在下次Reconcile的时候将配置刷回Service所声明的配置，造成非用户预期的结果。 SLB的删除 当Service删除时CCM会删除该SLB。 后端服务器更新 CCM会自动的为该Service对应的SLB刷新后端虚拟服务器组。当Service对应的后端Endpoint发生变化的时候或者集群节点变化的时候都会自动的更新SLB的后端Server。 spec.externalTrafficPolicy = Cluster模式的Service，CCM默认会将所有节点挂载到SLB的后端（使用BackendLabel标签配置后端的除外）。由于SLB限制了每个ECS上能够attach的SLB的个数（quota），因此这种方式会快速的消耗该quota，当quota耗尽后，会造成Service Reconcile失败。解决的办法，可以使用Local模式的Service。 spec.externalTrafficPolicy = Local模式的Service，CCM默认只会将Service对应的Pod所在的节点加入到SLB后端。这会明显降低quota的消耗速度。同时支持四层源IP保留。 任何情况下CCM不会将Master节点作为SLB的后端。 CCM默认不会从SLB后端移除被kubectl drain/cordon的节点。如需移除节点，请设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend为on。 说明 如果是v1.9.3.164-g2105d2e-aliyun之前的版本，CCM默认会从SLB后端移除被kubectl drain/cordon的节点。 VPC路由 集群中一个节点对应一条路由表项，VPC默认情况下仅支持48条路由表项，如果集群节点数目多于48个，请提工单给VPC产品。 说明 您可以在提交工单时，说明需要修改vpc_quota_route_entrys_num参数，用于提升单个路由表可创建的自定义路由条目的数量。 更多VPC使用限制请参见使用限制。 专有网络VPC配额查询请参见专有网络VPC配额管理。 SLB使用限制 CCM会为Type=LoadBalancer类型的Service创建SLB。默认情况下一个用户可以保留60个SLB实例，如果需要创建的SLB数量大于60，请提交工单给SLB产品。 说明 您可以在提交工单时，说明需要修改slb_quota_instances_num参数，用于提高用户可保有的slb实例个数。 CCM会根据Service将ECS挂载到SLB后端服务器组中。 默认情况下一个ECS实例可挂载的后端服务器组的数量为50个，如果一台ECS需要挂载到更多的后端服务器组中，请提交工单给SLB产品。 说明 您可以在提交工单时，说明需要修改slb_quota_backendservers_num参数，用于提高同一台服务器可以重复添加为SLB后端服务器的次数。 默认情况下一个SLB实例可以挂载200个后端服务器，如果需要挂载更多的后端服务器，请提交工单给SLB产品。 说明 您可以在提交工单时，说明需要修改slb_quota_backendservers_num参数，提高每个SLB实例可以挂载的服务器数量。 CCM会根据Service中定义的端口创建SLB监听。默认情况下一个SLB实例可以添加50个监听，如需添加更多监听，请提交工单给SLB产品。 说明 您可以在提交工单时，说明需要修改slb_quota_listeners_num参数，用于提高每个实例可以保有的监听数量。 更多SLB使用限制请参见使用限制。 负载均衡SLB配额查询请参见负载均衡SLB配额管理。 通过命令行操作 方法一： 通过命令行工具创建一个Nginx应用。 root@master # kubectl run nginx --image=registry.aliyuncs.com/acs/netdia:latest root@master # kubectl get po NAME READY STATUS RESTARTS AGE nginx-2721357637-dvwq3 1/1 Running 1 6s 为Nginx应用创建阿里云负载均衡服务，指定 type=LoadBalancer 来向外网用户暴露Nginx服务。 root@master # kubectl expose deployment nginx --port=80 --target-port=80 --type=LoadBalancer root@master # kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx 172.19.XX.XX 101.37.XX.XX 80:31891/TCP 4s 在浏览器中访问 http://101.37.XX.XX，来访问您的Nginx服务。 方法二： 将下面的yml code保存到 nginx-svc.yml文件中。 apiVersion: v1 kind: Service metadata: labels: run: nignx name: nginx-01 namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 执行如下命令，创建一个Nginx应用。 kubectl apply -f nginx-svc.yml 执行如下命令，向外网用户暴露Nginx服务。 root@master # kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE9d ngi-01nx LoadBalancer 172.19.XX.XX 101.37.XX.XX 80:32325/TCP 3h 在浏览器中访问 http://101.37.XX.XX，来访问您的Nginx服务。 通过 Kubernetes Dashboard 操作 将下面的yml code保存到 nginx-svc.yml文件中。 apiVersion: v1 kind: Service metadata: labels: run: nginx name: http-svc namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 登录容器服务管理控制台，单击目标集群右侧的控制台，进入Kubernetes Dashboard页面。 单击创建，开始创建应用。 创建应用 单击使用文件创建。选择刚才保存的nginx-svc.yml 文件。 单击上传。 此时，会创建一个阿里云负载均衡实例指向创建的Nginx应用，服务的名称为 http-svc。 在Kubernetes Dashboard上定位到default命名空间，选择服务。 可以看到刚刚创建的 http-svc 的Nginx服务和机器的负载均衡地址 http://114.55.XX.XX:80。 访问服务 将该地址拷贝到浏览器中即可访问该服务。 通过控制台操作 登录容器服务管理控制台。 在 Kubernetes 菜单下，单击左侧导航栏中的应用 > 无状态，进入无状态（Deployment）页面。 选择目标集群和命名空间，单击右上角使用模板创建。 创建应用 示例模板选为自定义，将以下内容复制到模板中。 apiVersion: v1 kind: Service metadata: labels: run: nginx name: ngnix namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 单击创建。 创建成功，单击Kubernetes 控制台前往控制台查看创建进度。 Kubernetes 控制台 或单击左侧导航栏路由与负载均衡 > 服务，选择目标集群和命名空间，查看已部署的服务。 部署服务 更多信息 阿里云负载均衡还支持丰富的配置参数，包含健康检查、收费类型、负载均衡类型等参数。 注释 阿里云可以通过注释annotations的形式支持丰富的负载均衡功能。 创建一个公网类型的负载均衡 apiVersion: v1 kind: Service metadata: name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建一个私网类型的负载均衡 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建HTTP类型的负载均衡 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建HTTPS类型的负载均衡 需要先在阿里云控制台上创建一个证书并记录cert-id，然后使用如下annotation创建一个 HTTPS 类型的SLB。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 限制负载均衡的带宽 只限制负载均衡实例下的总带宽，所有监听共享实例的总带宽，参见共享实例带宽。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: "paybybandwidth" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: "100" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 指定负载均衡规格 负载均衡规格可参见CreateLoadBalancer。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s1.small" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用已有的负载均衡 默认情况下，使用已有的负载均衡实例，不会覆盖监听，如要强制覆盖已有监听，请配置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners为true。 说明 复用已有的负载均衡默认不覆盖已有监听，因为以下两点原因： 如果已有负载均衡的监听上绑定了业务，强制覆盖可能会引发业务中断。 由于CCM目前支持的后端配置有限，无法处理一些复杂配置。如果有复杂的后端配置需求，可以在不覆盖监听的情况下，通过控制台自行配置监听。 如存在以上两种情况不建议强制覆盖监听，如果已有负载均衡的监听端口不再使用，则可以强制覆盖。 使用已有的负载均衡暂不支持添加额外标签（annotation: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags） apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALACER_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用已有的负载均衡，并强制覆盖已有监听 强制覆盖已有监听，如果监听端口冲突，则会删除已有监听。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALACER_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用指定Label的worker节点作为后端服务器 多个Label以逗号分隔。例如"k1=v1,k2=v2"。多个label之间是and的关系。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-backend-label: "failure-domain.beta.kubernetes.io/zone=ap-southeast-5a" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为TCP类型的负载均衡配置会话保持时间 参数service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-time仅对TCP协议的监听生效。 如果负载均衡实例配置了多个TCP协议的监听端口，则默认将该配置应用到所有TCP协议的监听端口。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-timeout: "1800" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为HTTP&HTTPS协议的负载均衡配置会话保持（insert cookie） 仅支持HTTP及HTTPS协议的负载均衡实例。 如果配置了多个HTTP或者HTTPS的监听端口，该会话保持默认应用到所有HTTP和HTTPS监听端口。 配置insert cookie，以下四项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type: "insert" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie-timeout: "1800" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为HTTP&HTTPS协议的负载均衡配置会话保持（server cookie） 仅支持HTTP及HTTPS协议的负载均衡实例。 如果配置了多个HTTP或者HTTPS的监听端口，该会话保持默认应用到所有HTTP和HTTPS监听端口。 配置server cookie，以下四项annotation必选。 cookie名称（service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie）只能包含字母、数字、‘_’和‘-’。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type: "server" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie: "${YOUR_COOKIE}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建负载均衡时，指定主备可用区 某些region的负载均衡不支持主备可用区，例如ap-southeast-5。 一旦创建，主备可用区不支持修改。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "ap-southeast-5a" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "ap-southeast-5a" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 使用Pod所在的节点作为后端服务器 默认externalTrafficPolicy为Cluster模式，会将集群中所有节点挂载到后端服务器。Local模式仅将Pod所在节点作为后端服务器。 Local模式需要设置调度策略为加权轮询wrr。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler: "wrr" name: nginx namespace: default spec: externalTrafficPolicy: Local ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建私有网络类型（VPC）的负载均衡 创建私有网络类型的负载均衡，以下两个annotation必选。 私网负载均衡支持专有网络（VPC）和经典网络（Classic），两者区别参见实例概述。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-network-type: "vpc" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 创建按流量付费的负载均衡 仅支持公网类型的负载均衡实例 以下两项annotation必选 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: "45" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: "paybybandwidth" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 创建带健康检查的负载均衡 设置TCP类型的健康检查 TCP端口默认开启健康检查，且不支持修改，即service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag annotation无效。 设置TCP类型的健康检查，以下所有annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "tcp" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout: "8" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 设置HTTP类型的健康检查 设置HTTP类型的健康检查，以下所有的annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "http" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri: "/test/index.html" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout: "10" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为负载均衡设置调度算法 rr（默认值）：轮询，按照访问顺序依次将外部请求依序分发到后端服务器。 wrr：加权轮询，权重值越高的后端服务器，被轮询到的次数（概率）也越高。 wlc：加权最小连接数，除了根据每台后端服务器设定的权重值来进行轮询，同时还考虑后端服务器的实际负载（即连接数）。当权重值相同时，当前连接数越小的后端服务器被轮询到的次数（概率）也越高。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler: "wlc" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡配置访问控制策略组 需要先在阿里云负载均衡控制台上创建一个负载均衡访问控制策略组，然后记录该访问控制策略组ID（acl-id），然后使用如下annotation创建一个带有访问控制的负载均衡实例。 白名单适合只允许特定IP访问的场景，black黑名单适用于只限制某些特定IP访问的场景。 使用该功能前，请确保CloudControllerManage组件是最新版本。请登录容器服务管理控制台，在左侧导航栏选择集群 > 集群，在集群列表中对需要升级的集群单击更多 > 系统组件升级，在组件列表中找到Cloud Controller Manager，单击升级。系统组建升级 创建带有访问控制的负载均衡，以下三项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-status: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-id: "${YOUR_ACL_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-type: "white" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡指定虚拟交换机 通过阿里云专有网络控制台查询交换机ID，然后使用如下的annotation为负载均衡实例指定虚拟交换机。 为负载均衡指定虚拟交换机，以下两项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vswitch-id: "${YOUR_VSWITCH_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡指定转发端口 端口转发是指将http端口的请求转发到https端口上。 设置端口转发需要先在阿里云控制台上创建一个证书并记录cert-id。 如需设置端口转发，以下三项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443,http:80" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-forward-port: "80:443" name: nginx namespace: default spec: ports: - name: https port: 443 protocol: TCP targetPort: 443 - name: http port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为负载均衡添加额外标签 多个tag以逗号分隔，例如"k1=v1,k2=v2"。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags: "Key1=Value1,Key2=Value2" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 移除SLB后端unscheduleable状态的节点 kubectl cordon与kubectl drain命令会将节点置为unscheduleable状态，默认service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend的取值为off，此时不会将处于unscheduleable状态的节点从SLB的后端服务器组移除。若需要从SLB的后端服务器组移除unscheduleable状态的节点，请将service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend的的取值设置为on。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend: "on" name: nginx spec: externalTrafficPolicy: Local ports: - name: http port: 30080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 直接将Pod ENI挂载到SLB后端 支持在Terway 网络模式下，通过annotation：service.beta.kubernetes.io/backend-type："eni" 将Pod直接挂载到SLB后端，提升网络转发性能。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/backend-type: "eni" name: nginx spec: ports: - name: http port: 30080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 创建IPv6类型的负载均衡 集群的kube-proxy代理模式需要是IPVS。 生成的IPv6地址仅可在支持IPv6的环境中访问。 创建后IP类型不可更改。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-ip-version: "ipv6" name: nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 说明 注释的内容是区分大小写的。 自2019年9月11日起，annotation字段alicloud更新为alibaba-cloud。 例如： 更新前：service.beta.kubernetes.io/alicloud-loadbalancer-id 更新后：service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id 系统将继续兼容alicloud的写法，用户无需做任何修改，敬请注意。 注释 类型 描述 默认值 支持的版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port string 多个值之间由逗号分隔，例如：https:443,http:80 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type string 取值可以是internet或者intranet internet v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slb-network-type string 负载均衡的网络类型，取值可以是classic或者vpc 取值为vpc时，需设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type为intranet。 classic v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type string 取值可以是paybytraffic或者paybybandwidth paybytraffic v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id string 负载均衡实例的 ID。通过 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id指定您已有的SLB，默认情况下，使用已有的负载均衡实例，不会覆盖监听，如要强制覆盖已有监听，请配置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners为true。 无 v1.9.3.81-gca19cd4-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-backend-label string 通过 label 指定 SLB 后端挂载哪些worker节点。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec string 负载均衡实例的规格。可参见：CreateLoadBalancer 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-timeout string 会话保持时间。 仅针对TCP协议的监听，取值：0-3600（秒） 默认情况下，取值为0，会话保持关闭。 可参见：CreateLoadBalancerTCPListener 0 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session string 是否开启会话保持。取值：on | off 说明 仅对HTTP和HTTPS协议的监听生效。 可参见：CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener off v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type string cookie的处理方式。取值： insert：植入Cookie。 server：重写Cookie。 说明 仅对HTTP和HTTPS协议的监听生效。 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session取值为on时，该参数必选。 可参见：CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie-timeout string Cookie超时时间。取值：1-86400（秒） 说明 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session为on且service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type为insert时，该参数必选。 可参见：CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie string 服务器上配置的Cookie名称。 长度为1-200个字符，只能包含ASCII英文字母和数字字符，不能包含逗号、分号或空格，也不能以$开头。 说明 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session为on且service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type为server时，该参数必选。 可参见：CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid string 主后端服务器的可用区ID。 无 v1.9.3.10-gfb99107-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid string 备后端服务器的可用区ID。 无 v1.9.3.10-gfb99107-aliyun及以上版本 externalTrafficPolicy string 哪些节点可以作为后端服务器，取值： Cluster：使用所有后端节点作为后端服务器。 Local：使用Pod所在节点作为后端服务器。 Cluster v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners string 绑定已有负载均衡时，是否强制覆盖该SLB的监听。 false：不覆盖 v1.9.3.81-gca19cd4-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth string 负载均衡的带宽，仅适用于公网类型的负载均衡。 50 v1.9.3.10-gfb99107-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id string 阿里云上的证书ID。您需要先上传证书 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag string 取值是on | off TCP监听默认为on且不可更改。 HTTP监听默认为off。 默认为off。TCP 不需要改参数。因为 TCP 默认打开健康检查，用户不可设置。 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type string 健康检查类型，取值：tcp | http。 可参见：CreateLoadBalancerTCPListener tcp v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri string 用于健康检查的URI。 说明 当健康检查类型为TCP模式时，无需配置该参数。 可参见：CreateLoadBalancerTCPListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-port string 健康检查使用的端口。取值： -520：默认使用监听配置的后端端口。 1-65535：健康检查的后端服务器的端口。 可参见：CreateLoadBalancerTCPListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold string 健康检查连续成功多少次后，将后端服务器的健康检查状态由fail判定为success。 取值：2-10 可参见：CreateLoadBalancerTCPListener 3 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold string 健康检查连续失败多少次后，将后端服务器的健康检查状态由success判定为fail。取值： 2-10 可参见：CreateLoadBalancerTCPListener 3 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval string 健康检查的时间间隔。 取值：1-50（秒） 可参见：CreateLoadBalancerTCPListener 2 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout string 接收来自运行状况检查的响应需要等待的时间，适用于TCP模式。如果后端ECS在指定的时间内没有正确响应，则判定为健康检查失败。 取值：1-300（秒） 说明 如果service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout的值小于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值，则service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout无效，超时时间为service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值。 可参见：CreateLoadBalancerTCPListener 5 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout string 接收来自运行状况检查的响应需要等待的时间，适用于HTTP模式。如果后端ECS在指定的时间内没有正确响应，则判定为健康检查失败。 取值：1-300（秒） 说明 如果 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout的值小于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值，则 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout无效，超时时间为 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值。 可参见：CreateLoadBalancerTCPListener 5 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-domain string 用于健康检查的域名。 $_ip：后端服务器的私网IP。当指定了IP或该参数未指定时，负载均衡会使用各后端服务器的私网IP当做健康检查使用的域名。 domain：域名长度为1-80，只能包含字母、数字、点号（.）和连字符（-）。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-httpcode string 健康检查正常的HTTP状态码，多个状态码用逗号（,）分割。取值： http_2xx http_3xx http_4xx http_5xx 默认值为http_2xx。 http_2xx v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler string 调度算法。取值wrr | wlc| rr。 wrr：权重值越高的后端服务器，被轮询到的次数（概率）也越高。 wlc：除了根据每台后端服务器设定的权重值来进行轮询，同时还考虑后端服务器的实际负载（即连接数）。当权重值相同时，当前连接数越小的后端服务器被轮询到的次数（概率）也越高。 rr：默认取值，按照访问顺序依次将外部请求依序分发到后端服务器。 rr v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-status string 是否开启访问控制功能。取值： on | off off v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-id string 监听绑定的访问策略组ID。当AclStatus参数的值为on时，该参数必选。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-type string 访问控制类型。 取值：white | black。 white：仅转发来自所选访问控制策略组中设置的IP地址或地址段的请求，白名单适用于应用只允许特定IP访问的场景。设置白名单存在一定业务风险。一旦设名单，就只有白名单中的IP可以访问负载均衡监听。如果开启了白名单访问，但访问策略组中没有添加任何IP，则负载均衡监听会转发全部请求。 black： 来自所选访问控制策略组中设置的IP地址或地址段的所有请求都不会转发，黑名单适用于应用只限制某些特定IP访问的场景。如果开启了黑名单访问，但访问策略组中没有添加任何IP，则负载均衡监听会转发全部请求。当AclStatus参数的值为on时，该参数必选。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vswitch-id string 负载均衡实例所属的VSwitch ID。设置该参数时需同时设置addresstype为intranet。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-forward-port string 将HTTP请求转发至HTTPS指定端口。取值如80:443 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags string 需要添加的Tag列表，多个标签用逗号分隔。例如："k1=v1,k2=v2" 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend string 从slb后端移除SchedulingDisabled Node。取值on | off off v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/backend-type string 支持在Terway eni网络模式下，通过设定改参数为"eni"，可将Pod直接挂载到SLB后端，提升网络转发性能。取值：eni。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-ip-version string 负载均衡实例的IP版本，取值：ipv4或ipv6 ipv4 v1.9.3.220-g24b1885-aliyun及以上版本