• 关于

    有效字节常见问题及解决方法

    的搜索结果

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。

2019-12-01 23:11:57 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。

2019-12-01 23:11:57 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。

2019-12-01 23:11:56 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。

2019-12-01 23:11:56 0 浏览量 回答数 0

回答

本文总结了常见的 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 实例间歇性丢包

KB小秘书 2019-12-02 02:05:57 0 浏览量 回答数 0

回答

HTTPS基本原理 一、http为什么不安全。 http协议没有任何的加密以及身份验证的机制,非常容易遭遇窃听、劫持、篡改,因此会造成个人隐私泄露,恶意的流量劫持等严重的安全问题。 国外很多网站都支持了全站https,国内方面目前百度已经在年初完成了搜索的全站https,其他大型的网站也在跟进中,百度最先完成全站https的最大原因就是百度作为国内最大的流量入口,劫持也必然是首当其冲的,造成的有形的和无形的损失也就越大。关于流量劫持问题,我在另一篇文章中也有提到,基本上是互联网企业的共同难题,https也是目前公认的比较好的解决方法。但是https也会带来很多性能以及访问速度上的牺牲,很多互联网公司在做大的时候都会遇到这个问题:https成本高,速度又慢,规模小的时候在涉及到登录和交易用上就够了,做大以后遇到信息泄露和劫持,想整体换,代价又很高。 2、https如何保证安全 要解决上面的问题,就要引入加密以及身份验证的机制。 这时我们引入了非对称加密的概念,我们知道非对称加密如果是公钥加密的数据私钥才能解密,所以我只要把公钥发给你,你就可以用这个公钥来加密未来我们进行数据交换的秘钥,发给我时,即使中间的人截取了信息,也无法解密,因为私钥在我这里,只有我才能解密,我拿到你的信息后用私钥解密后拿到加密数据用的对称秘钥,通过这个对称密钥来进行后续的数据加密。除此之外,非对称加密可以很好的管理秘钥,保证每次数据加密的对称密钥都是不相同的。 但是这样似乎还不够,如果中间人在收到我的给你公钥后并没有发给你,而是自己伪造了一个公钥发给你,这是你把对称密钥用这个公钥加密发回经过中间人,他可以用私钥解密并拿到对称密钥,此时他在把此对称密钥用我的公钥加密发回给我,这样中间人就拿到了对称密钥,可以解密传输的数据了。为了解决此问题,我们引入了数字证书的概念。我首先生成公私钥,将公钥提供给相关机构(CA),CA将公钥放入数字证书并将数字证书颁布给我,此时我就不是简单的把公钥给你,而是给你一个数字证书,数字证书中加入了一些数字签名的机制,保证了数字证书一定是我给你的。 所以综合以上三点: 非对称加密算法(公钥和私钥)交换秘钥 + 数字证书验证身份(验证公钥是否是伪造的) + 利用秘钥对称加密算法加密数据 = 安全 3、https协议简介 为什么是协议简介呢。因为https涉及的东西实在太多了,尤其是一些加密算法,非常的复杂,对于这些算法面的东西就不去深入研究了,这部分仅仅是梳理一下一些关于https最基本的原理,为后面分解https的连接建立以及https优化等内容打下理论基础。 3.1 对称加密算法 对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通信之前,商定一个密钥。对称算法的安全性依赖于密钥,泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密,所以密钥的保密性对通信至关重要。 对称加密又分为两种模式:流加密和分组加密。 流加密是将消息作为位流对待,并且使用数学函数分别作用在每一个位上,使用流加密时,每加密一次,相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器,它生成的位流与明文位进行异或,从而生成密文。现在常用的就是RC4,不过RC4已经不再安全,微软也建议网络尽量不要使用RC4流加密。 分组加密是将消息划分为若干位分组,这些分组随后会通过数学函数进行处理,每次一个分组。假设需要加密发生给对端的消息,并且使用的是64位的分组密码,此时如果消息长度为640位,就会被划分成10个64位的分组,每个分组都用一系列数学公式公式进行处理,最后得到10个加密文本分组。然后,将这条密文消息发送给对端。对端必须拥有相同的分组密码,以相反的顺序对10个密文分组使用前面的算法解密,最终得到明文的消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法,现在已经被证明不安全。而3DES是一个过渡的加密算法,相当于在DES基础上进行三重运算来提高安全性,但其本质上还是和DES算法一致。而AES是DES算法的替代算法,是现在最安全的对称加密算法之一。分组加密算法除了算法本身外还存在很多种不同的运算方式,比如ECB、CBC、CFB、OFB、CTR等,这些不同的模式可能只针对特定功能的环境中有效,所以要了解各种不同的模式以及每种模式的用途。这个部分后面的文章中会详细讲。 对称加密算法的优、缺点: 优点:算法公开、计算量小、加密速度快、加密效率高。 缺点:(1)交易双方都使用同样钥匙,安全性得不到保证; (2)每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一钥匙,这会使得发收信双方所拥有的钥匙数量呈几何级数增长,密钥管理成为用户的负担。 (3)能提供机密性,但是不能提供验证和不可否认性。 3.2 非对称加密算法 在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。 密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。 常见的密钥交换算法有RSA,ECDHE,DH,DHE等算法。涉及到比较复杂的数学问题,下面就简单介绍下最经典的RSA算法。RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数也就是质数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。我觉得RSA可以算是最经典的非对称加密算法了,虽然算法本身都是数学的东西,但是作为最经典的算法,我自己也花了点时间对算法进行了研究,后面会详细介绍。 非对称加密相比对称加密更加安全,但也存在两个明显缺点: 1,CPU计算资源消耗非常大。一次完全TLS握手,密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%,如果应用层数据也使用非对称加解密,性能开销太大,无法承受。 2,非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是2048位,意味着待加密内容不能超过256个字节。 所以公钥加密(极端消耗CPU资源)目前只能用来作密钥交换或者内容签名,不适合用来做应用层传输内容的加解密。 3.3 身份认证 https协议中身份认证的部分是由数字证书来完成的,证书由公钥、证书主体、数字签名等内容组成,在客户端发起SSL请求后,服务端会将数字证书发给客户端,客户端会对证书进行验证(验证查看这张证书是否是伪造的。也就是公钥是否是伪造的),并获取用于秘钥交换的非对称密钥(获取公钥)。 数字证书有两个作用: 1,身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。 2,分发公钥。每个数字证书都包含了注册者生成的公钥(验证确保是合法的,非伪造的公钥)。在SSL握手时会通过certificate消息传输给客户端。 申请一个受信任的数字证书通常有如下流程: 1,终端实体(可以是一个终端硬件或者网站)生成公私钥和证书请求。 2,RA(证书注册及审核机构)检查实体的合法性。如果个人或者小网站,这一步不是必须的。 3,CA(证书签发机构)签发证书,发送给申请者。 4,证书更新到repository(负责数字证书及CRL内容存储和分发),终端后续从repository更新证书,查询证书状态等。 数字证书验证: 申请者拿到CA的证书并部署在网站服务器端,那浏览器发起握手接收到证书后,如何确认这个证书就是CA签发的呢。怎样避免第三方伪造这个证书。答案就是数字签名(digital signature)。数字签名是证书的防伪标签,目前使用最广泛的SHA-RSA(SHA用于哈希算法,RSA用于非对称加密算法)数字签名的制作和验证过程如下: 1,数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希,生成消息摘要,然后使用CA自己的私钥对消息摘要进行加密。 2,数字签名的校验。使用CA的公钥解密签名,然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较,如果相同就认为校验成功。 需要注意的是: 1)数字签名签发和校验使用的密钥对是CA自己的公私密钥,跟证书申请者提交的公钥没有关系。 2)数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。 3)现在大的CA都会有证书链,证书链的好处一是安全,保持根CA的私钥离线使用。第二个好处是方便部署和撤销,即如果证书出现问题,只需要撤销相应级别的证书,根证书依然安全。 4)根CA证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。 5)怎样获取根CA和多级CA的密钥对。它们是否可信。当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。 3.4 数据完整性验证 数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改,SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。 MAC算法是在密钥参与下的数据摘要算法,能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的参与下,利用MAC算法计算出消息的MAC值,并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值,并与接收到的MAC值比较。如果二者相同,则报文没有改变;否则,报文在传输过程中被修改,接收者将丢弃该报文。 由于MD5在实际应用中存在冲突的可能性比较大,所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1,中国山东大学的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。MAC算法涉及到很多复杂的数学问题,这里就不多讲细节了。 专题二--【实际抓包分析】 抓包结果: fiddler: wireshark: 可以看到,百度和我们公司一样,也采用以下策略: (1)对于高版本浏览器,如果支持 https,且加解密算法在TLS1.0 以上的,都将所有 http请求重定向到 https请求 (2)对于https请求,则不变。 【以下只解读https请求】 1、TCP三次握手 可以看到,我们访问的是 http://www.baidu.com/ , 在初次建立 三次握手的时候, 用户是去 连接 8080端口的(因为公司办公网做了代理,因此,我们实际和代理机做的三次握手,公司代理机再帮我们去连接百度服务器的80端口) 2、CONNECT 建立 由于公司办公网访问非腾讯域名,会做代理,因此,在进行https访问的时候,我们的电脑需要和公司代理机做 " CONNECT " 连接(关于 " CONNECT " 连接, 可以理解为虽然后续的https请求都是公司代理机和百度服务器进行公私钥连接和对称秘钥通信,但是,有了 " CONNECT " 连接之后,可以认为我们也在直接和百度服务器进行公私钥连接和对称秘钥通信。 ) fiddler抓包结果: CONNECT之后, 后面所有的通信过程,可以看做是我们的机器和百度服务器在直接通信 3、 client hello 整个 Secure Socket Layer只包含了: TLS1.2 Record Layer内容 (1)随机数 在客户端问候中,有四个字节以Unix时间格式记录了客户端的协调世界时间(UTC)。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中,0x2516b84b就是协调世界时间。在他后面有28字节的随机数( random_C ),在后面的过程中我们会用到这个随机数。 (2)SID(Session ID) 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 (3) 密文族(Cipher Suites): RFC2246中建议了很多中组合,一般写法是"密钥交换算法-对称加密算法-哈希算法,以“TLS_RSA_WITH_AES_256_CBC_SHA”为例: (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 浏览器支持的加密算法一般会比较多,而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。(比如综合安全性以及速度、性能等因素) (4) Server_name扩展:( 一般浏览器也支持 SNI(Server Name Indication)) 当我们去访问一个站点时,一定是先通过DNS解析出站点对应的ip地址,通过ip地址来访问站点,由于很多时候一个ip地址是给很多的站点公用,因此如果没有server_name这个字段,server是无法给与客户端相应的数字证书的,Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。 还有一个很好的功能: SNI(Server Name Indication)。这个的功能比较好,为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是,在连接到服务器建立SSL连接之前先发送要访问站点的域名(Hostname),这样服务器根据这个域名返回一个合适的CA证书。目前,大多数操作系统和浏览器都已经很好地支持SNI扩展,OpenSSL 0.9.8已经内置这一功能,据说新版的nginx也支持SNI。) 4、 服务器回复(包括 Server Hello, Certificate, Certificate Status) 服务器在收到client hello后,会回复三个数据包,下面分别看一下: 1)Server Hello 1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 (random_S)。 2、Seesion ID,服务端对于session ID一般会有三种选择 (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) : 1)恢复的session ID:我们之前在client hello里面已经提到,如果client hello里面的session ID在服务端有缓存,服务端会尝试恢复这个session; 2)新的session ID:这里又分两种情况,第一种是client hello里面的session ID是空值,此时服务端会给客户端一个新的session ID,第二种是client hello里面的session ID此服务器并没有找到对应的缓存,此时也会回一个新的session ID给客户端; 3)NULL:服务端不希望此session被恢复,因此session ID为空。 3、我们记得在client hello里面,客户端给出了21种加密族,而在我们所提供的21个加密族中,服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”。 (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 这就意味着服务端会使用ECDHE-RSA算法进行密钥交换,通过AES_128_GCM对称加密算法来加密数据,利用SHA256哈希算法来确保数据完整性。这是百度综合了安全、性能、访问速度等多方面后选取的加密组合。 2)Certificate 在前面的https原理研究中,我们知道为了安全的将公钥发给客户端,服务端会把公钥放入数字证书中并发给客户端(数字证书可以自签发,但是一般为了保证安全会有一个专门的CA机构签发),所以这个报文就是数字证书,4097 bytes就是证书的长度。 我们打开这个证书,可以看到证书的具体信息,这个具体信息通过抓包报文的方式不是太直观,可以在浏览器上直接看。 (点击 chrome 浏览器 左上方的 绿色 锁型按钮) 3)Server Hello Done 我们抓的包是将 Server Hello Done 和 server key exchage 合并的包: 4)客户端验证证书真伪性 客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下: 证书链的可信性trusted certificate path,方法如前文所述; 证书是否吊销revocation,有两类方式离线CRL与在线OCSP,不同的客户端行为会不同; 有效期expiry date,证书是否在有效时间范围; 域名domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析; 5)秘钥交换 这个过程非常复杂,大概总结一下: (1)首先,其利用非对称加密实现身份认证和密钥协商,利用非对称加密,协商好加解密数据的 对称秘钥(外加CA认证,防止中间人窃取 对称秘钥) (2)然后,对称加密算法采用协商的密钥对数据加密,客户端和服务器利用 对称秘钥 进行通信; (3)最后,基于散列函数验证信息的完整性,确保通信数据不会被中间人恶意篡改。 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数random_C和random_S与自己计算产生的Pre-master(由客户端和服务器的 pubkey生成的一串随机数),计算得到协商对称密钥; enc_key=Fuc(random_C, random_S, Pre-Master) 6)生成 session ticket 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 后续建立新的https会话,就可以利用 session ID 或者 session Tickets , 对称秘钥可以再次使用,从而免去了 https 公私钥交换、CA认证等等过程,极大地缩短 https 会话连接时间。 7) 利用对称秘钥传输数据 【半分钟后,再次访问百度】: 有这些大的不同: 由于服务器和浏览器缓存了 Session ID 和 Session Tickets,不需要再进行 公钥证书传递,CA认证,生成 对称秘钥等过程,直接利用半分钟前的 对称秘钥 加解密数据进行会话。 1)Client Hello 2)Server Hello

玄学酱 2019-12-02 01:27:08 0 浏览量 回答数 0

回答

回 2楼(zc_0101) 的帖子 您好,       您的问题非常好,SQL SERVER提供了很多关于I/O压力的性能计数器,请选择性能计算器PhysicalDisk(LogicalDisk),根据我们的经验,如下指标的阈值可以帮助你判断IO是否存在压力: 1.  % Disk Time :这个是磁盘时间百分比,这个平均值应该在85%以下 2.  Current Disk Queue Length:未完成磁盘请求数量,这个每个磁盘平均值应该小于2. 3.  Avg. Disk Queue Length:磁盘请求队列的平均长度,这个每个磁盘平均值也应该小于2 4.  Disk Transfers/sec:每次磁盘传输数量,这个每个磁盘的最大值应该小于100 5.  Disk Bytes/sec:每次磁盘传入字节数,这个在普通的磁盘上应该在10M左右 6.  Avg. Disk Sec/Read:从磁盘读取的平均时间,这个平均值应该小于10ms(毫秒) 7.  Avg. Disk Sec/Write:磁盘写入的平均时间,这个平均值也应该小于10ms(毫秒) 以上,请根据自己的磁盘系统判断,比如传统的机械臂磁盘和SSD有所不同。 一般磁盘的优化方向是: 1. 硬件优化:比如使用更合理的RAID阵列,使用更快的磁盘驱动器,添加更多的内存 2. 数据库设置优化:比如创建多个文件和文件组,表的INDEX和数据放到不同的DISK上,将数据库的日志放到单独的物理驱动器,使用分区表 3. 数据库应用优化:包括应用程序的设计,SQL语句的调整,表的设计的合理性,INDEX创建的合理性,涉及的范围很广 希望对您有所帮助,谢谢! ------------------------- 回 3楼(鹰舞) 的帖子 您好,      根据您的描述,由于查询产生了副本REDO LOG延迟,出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁: 架构锁分成两类: 1. SCH-M:架构更改锁,主要发生在数据库SCHEMA的修改上,从你的描述看,没有更改SCHEMA,那么可以排除这个因素 2. SCH-S:架构稳定锁,主要发生在数据库的查询编译等活动 根据你的情况,应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息,未参数化的SQL语句等等 对于INDEX和SQL语句方面应,我想应该不会有太多问题。 我们重点关注一下统计信息:SQL SERVER 2012 AG副本的统计信息维护有两种: 1. 主体下发到副本 2. 临时统计信息存储在TEMPDB 对于主体下发的,我们可以设置统计信息的更新行为,自动更新时,可以设置为异步的(自动更新统计信息必须首先打开): USE [master] GO ALTER DATABASE [Test_01]     SET AUTO_UPDATE_STATISTICS_ASYNC ON WITH NO_WAIT GO 这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。 对于临时统计信息存储在TEMPDB里面也是很重要的,再加上ALWAYSON的副本数据库默认是快照隔离,优化TEMPDB也是必要的,关于优化TEPDB这个我想大部分都知道,这里只是提醒一下。 除了从统计信息本身来解决,在查询过程中,可以降低查询的时间,以尽量减少LOCK的时间和范围,这需要优化你的SQL语句或者应用程序。 以上,希望对您有所帮助。谢谢! ------------------------- 回 4楼(leamonjxl) 的帖子 这是一个关于死锁的问题,为了能够提供帮助一些。请根据下列建议进行: 1.    跟踪死锁 2.    分析死锁链和原因 3.    一些解决办法 关于跟踪死锁,我们首先需要打开1222标记,例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息: 如果发生了死锁,需要分析死锁发生的根源在哪里?我们不是很清楚你的具体发生死锁的形态是怎么样的。 关于死锁的实例也多,这里不再举例。 这里只是提出一些可以解决的思路: 1.    减少锁的争用 2.    减少资源的访问数 3.    按照相同的时间顺序访问资源 减少锁的争用,可以从几个方面入手 1.    使用锁提示,比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许,大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。 2.    调整隔离级别,使用MVCC,我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别,这样的话可以尽量读写不阻塞,只不过MVCC的ROW VERSION保存到TEMPDB下面,需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED,这些就不必了。 减少资源的访问数,可以从如下几个方面入手: 1.    使用聚集索引,非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此,如果对非聚集INDEX 操作的话,会产生两个锁,一个是基本表,一个是非聚集INDEX。而聚集INDEX就不一样,聚集INDEX的叶子页面和表的数据页面相同,他只需要一个LOCK。 2.    查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX,就不需要访问基本表。如果没有全覆盖,还会通过RID或者CLUSTER INDEX访问基本表,这样产生的LOCK可能会与其他SESSION争用。 按照相同的时间顺序访问资源: 确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问,第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK,但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。 ------------------------- 回 4楼(leamonjxl) 的帖子 两种方式看你的业务怎么应用。这里不仅是分表的问题,还可能存在分库,分服务器的问题。取决与你的架构方案。 物理分表+视图,这是一种典型的冷热数据分离的方案,大致的做法如下: 1.    保留最近3个月的数据为当前表,也即就是我们说的热数据 2.    将其他数据按照某种规则分表,比如按照年或者季度或者月,这部分是相对冷的数据 分表后,涉及到几个问题: 第一问题是,转移数据的过程,一般是晚上业务比较闲来转移,转移按照一定的规则来做,始终保持3个月,这个定时任务本身也很消耗时间 再者,关于查询部分,我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧,主库我觉得压力不会太大,主要是插入或者更新,只读需要做视图来包含全部的数据,但通过UNION ALL所有分表的数据,最后可能还是非常大,在某些情况下,性能不一定好。这个是不是业务上可以解决。比如,对于1年前的历史数据,放在单独的只读上,相对热的数据放在一起,这样压力也会减少。 分区表的话,因为涉及到10亿数据,要有好的分区方案,相对比较简单一点。但对于10亿的大表,始终是个棘手的问题,无论分多少个分区,单个服务器的资源也是有限的。可扩展性方面也存在问题,比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。 现在很多企业都在做分库分表,这些的要解决一些高并发,数据量大的问题。不知是否考虑过类似于中间件的方案,比如阿里巴巴的TDDL类似的方案,如果你有兴趣,可以查询相关资料。 ------------------------- 回 9楼(jiangnii) 的帖子 阿里云数据库不仅提供一个数据库,还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署,还提供了数据库高可用性架构,备份服务,性能诊断服务,监控服务,专家服务等等,保证用户放心、方便、省心地使用数据库,就像水电一样。以前的运维繁琐的事,全部由阿里云接管,用户只需要关注数据库的使用和具体的业务就好。 关于优化和在云数据库上处理大数据量或复杂的数据操作方面,在云数据库上是一样的,没有什么特别的地方,不过我们的云数据库是使用SSD磁盘,这个比普通的磁盘要快很多,IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务,比如索引诊断,连接诊断,容量分析,空间诊断等等,这些工作可能是专业的DBA才能完成的,以后我们会提供自动化的服务来为客户创造价值,希望能帮助到客户。 谢谢! ------------------------- 回 12楼(daniellin17) 的帖子 这个问题我不知道是否是两个问题,一个是并行度,另一个是并发,我更多理解是吞吐量,单就并行度而言。 提高并行度需要考虑的因素有: 1.    可用于SQL SERVER的CPU数量 2.    SQL SERVER的版本(32位/64位) 3.    可用内存 4.    执行的查询类型 5.    给定的流中处理的行数 6.    活动的并发连接数量 7.    sys.configurations参数:affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism 以DOP的参数控制并行度为例,设置如下: SELECT * FROM sys.configurations WITH (NOLOCK) WHERE name = 'max degree of parallelism' EXEC sp_configure 'max degree of parallelism',2 RECONFIGURE WITH OVERRIDE 经过测试,DOP设置为2是一个比较适中的状态,特别是OLTP应用。如果设置高了,会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是:CXPACKET 你可以用下列语句去测试: DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR) SELECT * FROM sys.dm_os_wait_stats WITH (NOLOCK) ORDER BY 2 DESC ,3 DESC 如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话,大多根据业务量来预估,然后考虑以下: 1.    RAID的划分,RAID1适合存放事务日志文件(顺序写),RAID10/RAID5适合做数据盘,RAID10是条带化并镜像,RAID5条带化并奇偶校验 2.    数据库设置,比如并行度,连接数,BUFFER POOL 3.    数据库文件和日志文件的存放规则,数据库文件的多文件设置规则 4.    TEMPDB的优化原则,这个很重要的 5.    表的设计方面根据业务类型而定 6.    CLUSTERED INDEX和NONCLUSTERED INDEX的设计 7.    阻塞分析 8.    锁和死锁分析 9.    执行计划缓冲分析 10.    存储过程重编译 11.    碎片分析 12.    查询性能分析,这个有很多可以优化的方式,比如OR/UNION/类型转换/列上使用函数等等 我这里列举一个高并发的场景: 比如,我们的订单,比如搞活动的时候,订单刷刷刷地增长,单个实例可能每秒达到很高很高,我们分析到最后最常见的问题是HOT PAGE问题,其等待类型是PAGE LATCH竞争。这个过程可以这么来处理,简单列几点,可以参考很多涉及高并发的案例: 1.    数据库文件和日志文件分开,存放在不同的物理驱动器磁盘上 2.    数据库文件需要与CPU个数形成一定的比例 3.    表设计可以使用HASH来作为表分区 4.    表可以设置无序的KEY/INDEX,比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX 5.    我们不能将自增列设计为聚集INDEX 这个场景只是针对高并发的插入。对于查询而言,是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。 ------------------------- 回 13楼(zuijh) 的帖子 ECS上现在有两种磁盘,一种是传统的机械臂磁盘,另一种是SSD,请先诊断你的IO是否出现了问题,本帖中有提到如何判断磁盘出现问题的相关话题,请参考。如果确定IO出现问题,可以尝试使用ECS LOCAL SSD。当然,我们欢迎你使用云数据库的产品,云数据库提供了很多有用的功能,比如高可用性,灵活的备份方案,灵活的弹性方案,实用的监控报警等等。 ------------------------- 回 17楼(豪杰本疯子) 的帖子 我们单个主机或者单个实例的资源总是有限的,因为涉及到很大的数据量,对于存储而言是个瓶颈,我曾使用过SAN和SAS存储,SAN存储的优势确实可以解决数据的灵活扩展,但是SAN也分IPSAN和FIBER SAN,如果IPSAN的话,性能会差一些。即使是FIBER SAN,也不是很好解决性能问题,这不是它的优势,同时,我们所有DB SERVER都连接到SAN上,如果SAN有问题,问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大,是造成性能问题的直接原因,因为我们不管怎么优化,一旦数据量太大,优化的能力总是有限的,所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。 所以现在很多企业在向分布式系统发展,对于数据库而言,其实有很多形式。我们最常见的是读写分离,比如SQL SERVER而言,我们可以通过复制来完成读写分离,SQL SERVER 2012及以后的版本,我们可以使用ALWAYSON来实现读写分离,但这只能解决性能问题,那空间问题怎么解决。我们就涉及到分库分表,这个分库分表跟应用结合得紧密,现在很多公司通过中间件来实现,比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分,那么DB也可以由此拆分开来。举个简单例子,我们一个典型的电子商务系统,有订单,有促销,有仓库,有配送,有财务,有秒杀,有商品等等,很多公司在初期,都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后,就会出现性能和硬件资源问题,这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。 ------------------------- 回 21楼(dt) 的帖子 问: 求大数据量下mysql存储,优化方案 分区好还是分表好,分的过程中需要考虑事项 mysql高并发读写的一些解决办法 答: 分区:对于应用来说比较简单,改造较少 分表: 应用需较多改造,优点是数据量太大的情况下,分表可以拆分到多个实例上,而分区不可以。 高并发优化,有两个建议: 1.    优化事务逻辑 2.    解决mysql高并发热点,这个可以看看阿里的一个热点补丁: http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f ------------------------- 回 23楼(aelven) 的帖子 对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势,比如磁盘是性能超好的SSD,自动转移的高可用性,没有任何单点,自动灵活的备份方案,实用的监控报警,性能监控服务等等,省去DBA很多基础性工作。 你第二个问题,看起来是一个高并发的场景,这种高并发的场景容易出现大量的LOCK甚至死锁,我不是很清楚你的业务,但可以建议一下,首先可以考虑快照隔离级别,实现行多版本控制,让读写不要阻塞。至于写写过程,需要加锁的粒度降低最低,同时这种高并发也容易出现死锁,关于死锁的分析,本帖有提到,请关注。 第三个问题,你用ECS搭建自己的应用也是可以的,RDS数据库提供了很多功能,上面已经讲到了。安全问题一直是我们最看重的问题,肯定有超好的防护的。 ------------------------- 回 26楼(板砖大叔) 的帖子 我曾经整理的关于索引的设计与规范,可以供你参考: ----------------------------------------------------------------------- 索引设计与规范 1.1    使用索引 SQL SERVER没有索引也可以检索数据,只不过检索数据时扫描这个表而异。存储数据的目的,绝大多数都是为了再次使用,而一般数据检索都是带条件的检索,数据查询在数据库操作中会占用较大的比例,提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构,最小优化了定位所需要的键值的访问页面量,包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起,它决定表中数据存储的物理顺序,其叶子节点为数据行。 1.2    聚集索引 1.2.1    关于聚集索引 没聚集索引的表叫堆。堆是一种没有加工的数据,以行标示符作为指向数据存储位置的指针,数据没有顺序。聚集索引的叶子页面和表的数据页面相同,因此表行物理上按照聚集索引列排序,表数据的物理顺序只有一种,所以一个表只有一个聚集索引。 1.2.2    与非聚集索引关系 非聚集索引的一个索引行包含指向表对应行的指针,这个指针称为行定位器,行定位器的值取决于数据页保存为堆还是被聚集。若是堆,行定位器指向的堆中数据行的行号指针,若是聚集索引表,行定位器是聚集索引键值。 1.2.3    设计聚集索引注意事项     首先创建聚集索引     聚集索引上的列需要足够短     一步重建索引,不要使用先DROP再CREATE,可使用DROP_EXISTING     检索一定范围和预先排序数据时使用,因为聚集索引的叶子与数据页面相同,索引顺序也是数据物理顺序,读取数据时,磁头是按照顺序读取,而不是随机定位读取数据。     在频繁更新的列上不要设计聚集索引,他将导致所有的非聚集所有的更新,阻塞非聚集索引的查询     不要使用太长的关键字,因为非聚集索引实际包含了聚集索引值     不要在太多并发度高的顺序插入,这将导致页面分割,设置合理的填充因子是个不错的选择 1.3    非聚集索引 1.3.1    关于非聚集索引 非聚集索引不影响表页面中数据的顺序,其叶子页面和表的数据页面时分离的,需要一个行定位器来导航数据,在将聚集索引时已经有说明,非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型,比如覆盖索引,过滤索引等。 1.3.2    设计非聚集索引     频繁更新的列,不适合做聚集索引,但可以做非聚集索引     宽关键字,例如很宽的一列或者一组列,不适合做聚集索引的列可作非聚集索引列     检索大量的行不宜做非聚集索引,但是可以使用覆盖索引来消除这种影响 1.3.3    优化书签查找 书签会访问索引之外的数据,在堆表,书签查找会根据RID号去访问数据,若是聚集索引表,一般根据聚集索引去查找。在查询数据时,要分两个部分来完成,增加了读取数据的开销,增加了CPU的压力。在大表中,索引页面和数据页面一般不会临近,若数据只存在磁盘,产生直接随机从磁盘读取,这导致更多的消耗。因此,根据实际需要优化书签查找。解决书签查找有如下方法:     使用聚集索引避免书签查找     使用覆盖索引避免书签查找     使用索引连接避免数据查找 1.4    聚集与非聚集之比较 1.4.1    检索的数据行 一般地,检索数据量大的一般使用聚集索引,因为聚集索引的叶子页面与数据页面在相同。相反,检索少量的数据可能非聚集索引更有利,但注意书签查找消耗资源的力度,不过可考虑覆盖索引解决这个问题。 1.4.2    数据是否排序 如果数据需要预先排序,需要使用聚集索引,若不需要预先排序就那就选择聚集索引。 1.4.3    索引键的宽度 索引键如果太宽,不仅会影响数据查询性能,还影响非聚集索引,因此,若索引键比较小,可以作为聚集索引,如果索引键够大,考虑非聚集索引,如果很大的话,可以用INCLUDE创建覆盖索引。 1.4.4    列更新的频度 列更新频率高的话,应该避免考虑所用非聚集索引,否则可考虑聚集索引。 1.4.5    书签查找开销 如果书签查找开销较大,应该考虑聚集索引,否则可使用非聚集索引,更佳是使用覆盖索引,不过得根据具体的查询语句而看。 1.5    覆盖索引 覆盖索引可显著减少查询的逻辑读次数,使用INCLUDE语句添加列的方式更容易实现,他不仅减小索引中索引列的数据,还可以减少索引键的大小,原因是包含列只保存在索引的叶子级别上,而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生,与聚集索引类似,因为聚集索引值发生一次锁,非覆盖索引可能发生两次,一次锁数据,一次锁索引,以确保数据的一致性。覆盖索引相当于数据的一个拷贝,与数据页面隔离,因此也只发生一次锁。 1.6    索引交叉 如果一个表有多个索引,那么可以拥有多个索引来执行一个查询,根据每个索引检索小的结果集,然后就将子结果集做一个交叉,得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。 1.7    索引连接 几乎是跟索引交叉类似,是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询,SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。 1.8    过滤索引 用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效,创建索引时,可以像写T-SQL语句一样加个WHERE条件,以排除某部分数据而检索。 1.9    索引视图 索引视图在OLAP系统上可能有胜算,在OLTP会产生过大的开销和不可操作性,比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构,索引视图要求企业版,这些限制导致不可操作性。 1.10    索引设计建议 1.10.1    检查WHERE字句和连接条件列 检查WHERE条件列的可选择性和数据密度,根据条件创建索引。一般地,连接条件上应当考虑创建索引,这个涉及到连接技术,暂时不说明。 1.10.2    使用窄的索引 窄的索引有可减少IO开销,读取更少量的数据页。并且缓存更少的索引页面,减少内存中索引页面的逻辑读取大小。当然,磁盘空间也会相应地减少。 1.10.3    检查列的唯一性 数据分布比较集中的列,种类比较少的列上创建索引的有效性比较差,如果性别只有男女之分,最多还有个UNKNOWN,单独在上面创建索引可能效果不好,但是他们可以为覆盖索引做出贡献。 1.10.4    检查列的数据类型 索引的数据类型是很重要的,在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型,在数据长度较小的类型上创建又比在长度较长的类型上更有效。 1.10.5    考虑列的顺序 对于包含多个列的索引,列顺序很重要。索引键值在索引上的第一上排序,然后在前一列的每个值的下一列做子排序,符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性,列宽度,列的数据类型来做权衡。 1.10.6    考虑索引的类型 使用索引类型前面已经有较多的介绍,怎么选择已经给出。不再累述。 ------------------------- 回 27楼(板砖大叔) 的帖子 这两种都可以吧。看个人的喜好,不过微软现在的统一风格是下划线,比如表sys.all_columns/sys.tables,然后你再看他的列全是下划线连接,name     /object_id    /principal_id    /schema_id    /parent_object_id      /type    /type_desc    /create_date    /modify_date 我个人的喜好也是喜欢下划线。    

石沫 2019-12-02 01:34:30 0 浏览量 回答数 0

问题

性能测试:软件测试的重中之重

云效平台 2019-12-01 21:45:09 5839 浏览量 回答数 1

回答

92题 一般来说,建立INDEX有以下益处:提高查询效率;建立唯一索引以保证数据的唯一性;设计INDEX避免排序。 缺点,INDEX的维护有以下开销:叶节点的‘分裂’消耗;INSERT、DELETE和UPDATE操作在INDEX上的维护开销;有存储要求;其他日常维护的消耗:对恢复的影响,重组的影响。 需要建立索引的情况:为了建立分区数据库的PATITION INDEX必须建立; 为了保证数据约束性需要而建立的INDEX必须建立; 为了提高查询效率,则考虑建立(是否建立要考虑相关性能及维护开销); 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用:加快查询速度。原则:(1) 如果某属性或属性组经常出现在查询条件中,考虑为该属性或属性组建立索引;(2) 如果某个属性常作为最大值和最小值等聚集函数的参数,考虑为该属性建立索引;(3) 如果某属性经常出现在连接操作的连接条件中,考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像,对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言,快照能保证系统的完整性。 89题 游标用于定位结果集的行,通过判断全局变量@@FETCH_STATUS可以判断是否到了最后,通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前,而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行,而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引,叫做联合索引。在联合索引中,如果想要命中索引,需要按照建立索引时的字段顺序挨个使用,否则无法命中索引。具体原因为:MySQL使用索引时需要索引有序,假设现在建立了"name,age,school"的联合索引,那么索引的排序为: 先按照name排序,如果name相同,则按照age排序,如果age的值也相等,则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句,在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句,所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程,不由用户直接调用。创建触发器时会对其进行定义,以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合,涉及特定表或其它对象的任务,用户可以调用存储过程,而函数通常是数据库已定义的方法,它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接,减少复杂 SQL,拆分成简单SQL。减少排序:非必要不排序,利用索引排序,减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or,使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤:选择更优的索引,先分页再Join…。避免类型转换:索引失效。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL。从全局出发优化,而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or,即使其中有条件带索引也不会使用(要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引)。对于多列索引,不是使用的第一部分,则不会使用索引。like查询是以%开头。如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不使用索引。如果mysql估计使用全表扫描要比使用索引快,则不使用索引。例如,使用<>、not in 、not exist,对于这三种情况大多数情况下认为结果集很大,MySQL就有可能不使用索引。 81题 主键不能重复,不能为空,唯一键不能重复,可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键,但可以有很多唯一键。 80题 空值('')是不占用空间的,判断空字符用=''或者<>''来进行处理。NULL值是未知的,且占用空间,不走索引;判断 NULL 用 IS NULL 或者 is not null ,SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0;它们是不等价的。无法使用比较运算符来测试 NULL 值,比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较,该符号与等号作用相似,但对NULL有意义。进行 count ()统计某列的记录数的时候,如果采用的 NULL 值,会被系统自动忽略掉,但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表,他使用保存在内存中的散列索引。一旦服务器重启,所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=,<,>,=>,= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字,可以输入带有单引号的十六进制数字和前缀(X),或者只用(Ox)前缀输入十六进制数字。如果表达式上下文是字符串,则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问,权限表存放在mysql数据库里,由mysql_install_db脚本初始化。这些权限表分别user,db,table_priv,columns_priv和host。 76题 在缺省模式下,MYSQL是autocommit模式的,所有的数据库更新操作都会即时提交,所以在缺省情况下,mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话,你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式,在非autocommit模式下,你必须使用COMMIT来提交你的更改,或者用ROLLBACK来回滚你的更改。 75题 它会停止递增,任何进一步的插入都将产生错误,因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引,由于使用b+tree做为索引,以innodb为例,一个树节点的大小由“innodb_page_size”,为了减少树的高度,同时让一个节点能存放更多的值,索引列尽量在整数类型上创建,如果必须使用字符类型,也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读。垂直分区: 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException,那么我们就针对这块考虑一下重试,自定义一个注解,用于做切面。针对注解进行切面,设置最大重试次数n,然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞,是通过innodb的行多版本实现的,行多版本并不是实际存储多个版本记录而是通过undo实现(undo日志用来记录数据修改前的版本,回滚时会用到,用来保证事务的原子性)。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎:尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);哈希索引也不支持多列联合索引的最左匹配规则;B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单,一般优先考虑,但float存储的数据范围大,所以范围大的数据就只能用它了,但要注意一些处理细节,因为不精确可能会与自己想的不一致,也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒,datetime与时区无关,存储的范围广(1001-9999),timestamp与时区有关,存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储,char(4)存储4个字符,根据编码方式的不同占用不同的字节,gbk编码方式,不论是中文还是英文,每个字符占用2个字节的空间,utf8编码方式,每个字符占用3个字节的空间。Varchar保存可变长度的字符串,使用额外的一个或两个字节存储字符串长度,varchar(10),除了需要存储10个字符,还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格,char会自动去掉空格后存储,varchar虽然不会去掉空格,但在进行字符串比较时,会去掉空格进行比较。Varbinary保存变长的字符串,后面不会补\0。 65题 首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行分析以及重写。分析语句的执行计划,然后获得其使用索引的情况,之后修改语句或者修改索引,使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行,可以考虑表中的数据量是否太大,如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解:存储过程可以说是一个记录集,它是由一些T-SQL语句组成的代码块,这些T-SQL语句代码像一个方法一样实现一些功能(对单表或多表的增删改查),然后再给这个代码块取一个名字,在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块,执行效率比较高,一个存储过程替代大量T_SQL语句 ,可以降低网络通信量,提高通信速率,可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID,不要使用UUID。因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段,假如申请了char(10)的空间,那么无论实际存储多少内容。该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间。在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted(读取未提交数据) 即便是事务没有commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种。 二. read committed(可以读取其他事务提交的数据)---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据,未提交的数据读不到。 三. repeatable read(可重读)---MySQL默认的隔离级别 当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。 四. serializable(串行化) 其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层,所以查找记录时最多只需要2-4次IO,相对二叉平衡树已经大大降低了。范围查找时,能通过叶子节点的指针获取数据。例如查找大于等于3的数据,当在叶子节点中查到3时,通过3的尾指针便能获取所有数据,而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。 Redo(里面包括 undo 的修改) 一定要比数据页先持久化到磁盘。 当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎,MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统,也就是 redo log 来实现 crash-safe 能力。 55题 重做日志(redo log)      作用:确保事务的持久性,防止在发生故障,脏页未写入磁盘。重启数据库会进行redo log执行重做,达到事务一致性。 回滚日志(undo log)  作用:保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。 二进 制日志(binlog)    作用:用于主从复制,实现主从同步;用于数据库的基于时间点的还原。 错误日志(errorlog) 作用:Mysql本身启动,停止,运行期间发生的错误信息。 慢查询日志(slow query log)  作用:记录执行时间过长的sql,时间阈值可以配置,只记录执行成功。 一般查询日志(general log)    作用:记录数据库的操作明细,默认关闭,开启后会降低数据库性能 。 中继日志(relay log) 作用:用于数据库主从同步,将主库发来的bin log保存在本地,然后从库进行回放。 54题 MySQL有三种锁的级别:页级、表级、行级。 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是:让不同的session加锁有次序。死锁的解决办法:1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性(脏读,不可重复读,幻读等),可能产生死锁。 乐观锁:乐观锁不是数据库自带的,需要我们自己去实现。 悲观锁:在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁:加了共享锁的数据对象可以被其他事务读取,但不能修改。 排他锁:当数据对象被加上排它锁时,一个事务必须得到锁才能对该数据对象进行访问,一直到事务结束锁才被释放。 行锁:就是给某一条记录加上锁。 52题 Mysql是关系型数据库,MongoDB是非关系型数据库,数据存储结构的不同。 51题 关系型数据库优点:1.保持数据的一致性(事务处理)。 2.由于以标准化为前提,数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点:1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点:1、无需经过sql层的解析,读写性能很高。 2、基于键值对,数据没有耦合性,容易扩展。 3、存储数据的格式:nosql的存储格式是key,value形式、文档形式、图片形式等等,文档形式、图片形式等等,而关系型数据库则只支持基础类型。 缺点:1、不提供sql支持,学习和使用成本较高。 2、无事务处理,附加功能bi和报表等支持也不好。 redis与mongoDB的区别: 性能:TPS方面redis要大于mongodb。 可操作性:mongodb支持丰富的数据表达,索引,redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用,使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用,必须使用固定的keys-to-nodes映射关系,节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况),必须使用可以在运行时进行数据再平衡的一套系统,而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存。如果没有分区,你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外(Redis默认的有6种策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种: 1.定时去清理过期的缓存; 2.当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪种方案,可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列,一旦消息到达,消费者马上消费,谁先抢到算谁的,如果队列里没有消息,则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道,只要发布者发布消息,所有订阅者都能收到消息,订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列,可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop,blpop/brpop阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列,消息作为value,时间作为score。Zrem 命令用于移除有序集中的一个或多个成员,不存在的成员将被忽略。当 key 存在但不是有序集类型时,返回一个错误。 45题 1.热点数据缓存:因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务:expire 命令设置 key 的生存时间,到时间后自动删除 key。 3.计数器:incrby 命令可以实现原子性的递增。 4.排行榜:借助 SortedSet 进行热点数据的排序。 5.分布式锁:利用 Redis 的 setnx 命令进行。 6.队列机制:有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后,哈希表槽位数(大小)的改变平均只需要对 K/n 个关键字重新映射,其中K是关键字的数量, n是槽位数量。然而在传统的哈希表中,添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点:适合做冷备份;读写服务影响小,reids可以保持高性能;重启和恢复redis进程,更加快速。RDB的缺点:宕机会丢失最近5分钟的数据;文件特别大时可能会暂停数毫秒,或者甚至数秒。 AOF的优点:每个一秒执行fsync操作,最多丢失1秒钟的数据;以append-only模式写入,没有任何磁盘寻址的开销;文件过大时,不会影响客户端读写;适合做灾难性的误删除的紧急恢复。AOF的缺点:AOF日志文件比RDB数据快照文件更大,支持写QPS比RDB支持的写QPS低;比RDB脆弱,容易有bug。 42题 对于Redis而言,命令的原子性指的是:一个操作的不可以再分,操作要么执行,要么不执行。Redis的操作之所以是原子性的,是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的,这也和普通数据库的表现是一样的,可以用incr或者使用Redis的事务,或者使用Redis+Lua的方式实现。对Redis来说,执行get、set以及eval等API,都是一个一个的任务,这些任务都会由Redis的线程去负责执行,任务要么执行成功,要么执行失败,这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单(相对redis只需修改连接端口),对旧项目扩展的首选。(2)codis,目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数改变情况下,旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。(4)在业务代码层实现,起几个毫无关联的redis实例,在代码层,对key进行hash计算,然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的代替算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。 40题 (1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件 (2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。 39题 比如订单管理,热数据:3个月内的订单数据,查询实时性较高;温数据:3个月 ~ 12个月前的订单数据,查询频率不高;冷数据:1年前的订单数据,几乎不会查询,只有偶尔的查询需求。热数据使用mysql进行存储,需要分库分表;温数据可以存储在ES中,利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说,一般情况冷数据存储在磁带、光盘,热数据一般存放在SSD中,存取速度快,而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。 37题 分层架构设计,有一条准则:站点层、服务层要做到无数据无状态,这样才能任意的加节点水平扩展,数据和状态尽量存储到后端的数据存储服务,例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。 35题 redis分布式锁加锁过程:通过setnx向特定的key写入一个随机值,并同时设置失效时间,写值成功既加锁成功;redis分布式锁解锁过程:匹配随机值,删除redis上的特点key数据,要保证获取数据、判断一致以及删除数据三个操作是原子的,为保证原子性一般使用lua脚本实现;在此基础上进一步优化的话,考虑使用心跳检测对锁的有效期进行续期,同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random:当内存不足以容纳写入数据时,从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru:当内存不足以容纳写入数据时,从数据集中挑选最近最少使用的数据淘汰。 allkeys-random:当内存不足以容纳写入数据时,从数据集中任意选择数据淘汰。 noeviction:禁止驱逐数据,当内存使用达到阈值的时候,所有引起申请内存的命令会报错。 33题 定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。 惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。 定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿,一个存在的key,在缓存过期的一刻,同时有大量的请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。如何避免:在访问key之前,采用SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问,访问结束再删除该短期key。 31题 缓存雪崩,是指在某一个时间段,缓存集中过期失效。大量的key设置了相同的过期时间,导致在缓存在同一时刻全部失效,造成瞬时DB请求量大、压力骤增,引起雪崩。而缓存服务器某个节点宕机或断网,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。如何避免:1.redis高可用,搭建redis集群。2.限流降级,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热,在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间。 30题 缓存穿透,是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并把查询到的对象,放进缓存。如果数据库查询对象为空,则不放进缓存。一些恶意的请求会故意查询不存在的 key,请求量很大,对数据库造成压力,甚至压垮数据库。 如何避免:1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存。2:对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份,即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小:redis最大可以达到1GB,而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置,但是 Spring Boot 中也可以使用 XML 配置,通过spring提供的@ImportResource来加载xml配置。例如:@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族,有众多衍生产品例如Spring Boot,Spring Security等等,但他们的基础都是Spring的IOC和AOP,IOC提供了依赖注入的容器,而AOP解决了面向切面的编程,然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架,主要解决WEB开发的问题,因为 Spring的配置非常复杂,各种xml,properties处理起来比较繁琐。Spring Boot遵循约定优于配置,极大降低了Spring使用门槛,又有着Spring原本灵活强大的功能。总结:Spring MVC和Spring Boot都属于Spring,Spring MVC是基于Spring的一个MVC框架,而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"(YAML 不是一种标记语言)的递归缩写。YAML 的配置文件后缀为 .yml,是一种人类可读的数据序列化语言,可以简单表达清单、散列表,标量等数据形态。它通常用于配置文件,与属性文件相比,YAML文件就更加结构化,而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式: 1.使用springloaded配置pom.xml文件,使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动,配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包,操作简单,但是每次需要重新部署。 用

游客ih62co2qqq5ww 2020-03-27 23:56:48 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站