重复请求未响应

请求错误 这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。 如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。 400 Bad Request 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。 401 Unauthorized 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。 402 Payment Required 该状态码是为了将来可能的需求而预留的。 403 Forbidden 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。 404 Not Found 请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。出现这个错误的最有可能的原因是服务器端没有这个页面。 405 Method Not Allowed 请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。 406 Not Acceptable 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 除非这是一个 HEAD 请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。 407 Proxy Authentication Required 与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。 408 Request Timeout 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。 409 Conflict 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。 410 Gone 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。 411 Length Required 服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。 412 Precondition Failed 服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。 413 Request Entity Too Large 服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。 414 Request-URI Too Long 请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括： 本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。 重定向URI “黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。 客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。 415 Unsupported Media Type 对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。 416 Requested Range Not Satisfiable 如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。 假如 Range 使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个 Content-Range 实体头，用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。 417 Expectation Failed 在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。 421 too many connections There are too many connections from your internet address 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。 422 Unprocessable Entity 请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV） 423 Locked 当前资源被锁定。（RFC 4918 WebDAV） 424 Failed Dependency 由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV） 425 Unordered Collection 在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。 426 Upgrade Required 客户端应当切换到TLS/1.0。（RFC 2817） 449 Retry With 由微软扩展，代表请求应当在执行完适当的操作后进行重试。 451Unavailable For Legal Reasons 该请求因法律原因不可用。（RFC 7725）

详细解答可以参考官方帮助文档 GetLogs 接口查询指定 Project 下某个 Logstore 中的日志数据。还可以通过指定相关参数仅查询符合指定条件的日志数据。 当日志写入到 Logstore 中，日志服务的查询接口（GetHistograms 和 GetLogs）能够查到该日志的延时因写入日志类型不同而异。日志服务按日志时间戳把日志分为如下两类： 实时数据：日志中时间点为服务器当前时间点 (-180秒，900秒]。例如，日志时间为 UTC 2014-09-25 12:03:00，服务器收到时为 UTC 2014-09-25 12:05:00，则该日志被作为实时数据处理，一般出现在正常场景下。 历史数据：日志中时间点为服务器当前时间点 [-7 x 86400秒, -180秒)。例如，日志时间为 UTC 2014-09-25 12:00:00，服务器收到时为 UTC 2014-09-25 12:05:00，则该日志被作为历史数据处理，一般出现在补数据场景下。 其中，实时数据写入至可查询的最大延时为3秒（99.9%情况下1秒内即可查询）。 请求语法 GET /logstores/<logstorename>?type=histogram&topic=<logtopic>&from=<starttime>&to=<endtime>&query=<querystring>&line=<linenum>&offset=<startindex>&reverse=<ture|false> HTTP/1.1 Authorization: <AuthorizationString> Date: <GMT Date> Host: <Project Endpoint> x-log-bodyrawsize: 0 x-log-apiversion: 0.6.0 x-log-signaturemethod: hmac-sha1 请求参数 名称 类型 必选 描述 logstorename 字符串 是 需要查询日志的 Logstore 名称。 type 字符串 是 查询 Logstore 数据的类型。在 GetLogs 接口中该参数必须为 log。 from 整型 是 查询开始时间点（精度为秒，从 1970-1-1 00:00:00 UTC 计算起的秒数）。 to 整型 是 查询结束时间点（精度为秒，从 1970-1-1 00:00:00 UTC 计算起的秒数）。 topic 字符串 否 查询日志主题。 query 字符串 否 查询表达式。关于查询表达式的详细语法，请参考 查询语法。 line 整型 否 请求返回的最大日志条数。取值范围为 0~100，默认值为 100。 offset 整型 否 请求返回日志的起始点。取值范围为 0 或正整数，默认值为 0。 reverse 布尔型 否 是否按日志时间戳逆序返回日志。true 表示逆序，false 表示顺序，默认值为 false。 请求头 GetLogs接口无特殊请求头。关于 Log Service API 的公共请求头，请参考 公共请求头。 响应头 关于 Log Service API 的公共响应头，请参考 公共响应头。 响应头中有专门成员表示请求返回结果是否完整。具体响应元素格式如下： 名称 类型 描述 x-log-progress 字符串 查询结果的状态。可以有 Incomplete 和 Complete 两个选值，表示本次是否完整。 x-log-count 整型 当前查询结果的日志总数。 响应元素 GetLogs 请求成功，其响应 Body 会包括查询命中的日志数据。当需要查询的日志数据量非常大(T级别)的时候，该接口的响应结果可能并不完整，GetLogs的响应body是一个数组，数组中每个元素是一条日志结果。数组中的每个元素结构如下： 名称 类型 描述 __time__ 整型 日志的时间戳（精度为秒，从 1970-1-1 00:00:00 UTC 计算起的秒数）。 __source__ 字符串 日志的来源，由写入日志时指定。 [content] Key-Value对 日志原始内容，以 Key-value 对的形式组织。 细节描述 该接口中由请求参数 from 和 to 定义的时间区间遵循“左闭右开”原则，即该时间区间包括区间开始时间点，但不包括区间结束时间点。如果 from 和 to 的值相同，则为无效区间，函数直接返回错误。 如上所述，该接口一次调用必须要在限定时间内返回结果，每次查询只能扫描指定条数的日志量。如果一次请求需要处理的数据量非常大的时候，该请求会返回不完整的结果（并在返回header中的 x-log-progress 成员标示是否完整）。如此同时，服务端会缓存 15 分钟内的查询结果。当查询请求的结果有部分被缓存命中，则服务端会在这次请求中继续扫描未被缓存命中的日志数据。为了减少您合并多次查询结果的工作量，服务端会把缓存命中的查询结果与本次查询新命中的结果合并返回给您。因此，日志服务可以让您通过以相同参数反复调用该接口来获取最终完整结果。因为您的查询涉及的日志数据量变化非常大，日志服务 API 无法预测需要调用多少次该接口而获取完整结果。所以需要用户通过检查每次请求的返回结果中的x-log-progress 成员状态值来确定是否需要继续。需要注意的是，每次重复调用该接口都会重新消耗相同数量的查询 CU。 错误码 除了返回 Log Service API 的 通用错误码，还可能返回如下特有错误码： HTTP状态码（Status Code） 错误码（Error Code） 错误消息（Error Message） 描述（Description） 404 LogStoreNotExist logstore {Name} does not exist. 日志库（logstore）不存在。 400 InvalidTimeRange request time range is invalid 请求的时间区间无效。 400 InvalidQueryString query string is invalid 请求的查询字符串无效。 400 InvalidOffset offset is invalid 请求的 offset 参数无效。 400 InvalidLine line is invalid 请求的 line 参数无效。 400 InvalidReverse Reverse value is invalid Reverse 参数的值无效。 400 IndexConfigNotExist logstore without index config 日志库（logstore）未开启索引。 说明 上表错误消息中 {name} 表示该部分会被具体的 LogstoreName 来替换。 示例 以杭州地域内名为 big-game 的 Project 为例，查询该 project 内名为 app_log 的 Logstore 中，主题为 groupA 的日志数据。查询区间为 2014-09-01 00:00:00 到 2014-09-01 22:00:00，查询关键字为 error，且从时间区间头开始查询，最多返回 20 条日志数据。 请求示例： GET /logstores/app_log？type=log&topic=groupA&from=1409529600&to=1409608800&query=error&line=20&offset=0 HTTP/1.1 Authorization: <AuthorizationString> Date: Wed, 3 Sept. 2014 08:33:46 GMT Host: big-game.cn-hangzhou.log.aliyuncs.com x-log-bodyrawsize: 0 x-log-apiversion: 0.4.0 x-log-signaturemethod: hmac-sha1 响应示例： HTTP/1.1 200 OK Content-MD5: 36F9F7F0339BEAF571581AF1B0AAAFB5 Content-Type: application/json Content-Length: 269 Date: Wed, 3 Sept. 2014 08:33:47 GMT x-log-requestid: efag01234-12341-15432f x-log-progress : Complete x-log-count : 10000 x-log-processed-rows: 10000 x-log-elapsed-millisecond:5 { "progress": "Complete", "count": 2, "logs": [ { "__time__": 1409529660, "__source__": "10.237.0.17", "Key1": "error", "Key2": "Value2" }, { "__time__": 1409529680, "__source__": "10.237.0.18", "Key3": "error", "Key4": "Value4" } ] }在这个响应示例中，x-log-progress 成员的状态为 Complete，表明整个日志查询已经完成，返回结果为完整结果。在这次请求中共查询到 2 条符合条件的日志，且日志数据在 logs 成员中。如果响应结果中的 x-log-progress 成员的状态为 Incomplete，则需要重复相同请求以获得完整结果。

HTTP 1xx-信息提示 这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个1xx响应。 100-继续。 101-切换协议。 2xx-成功 这类状态代码表明服务器成功地接受了客户端请求。 200-确定。客户端请求已成功。 201-已创建。 202-已接受。 203-非权威性信息。 204-无内容。 205-重置内容。 206-部分内容。 3xx-重定向 客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。 301-对象已永久移走，即永久重定向。 302-对象已临时移动。 304-未修改。 307-临时重定向。 4xx-客户端错误 发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。400-错误的请求。 401-访问被拒绝。IIS定义了许多不同的401错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在IIS日志中显示： 401.1-登录失败。 401.2-服务器配置导致登录失败。 401.3-由于ACL对资源的限制而未获得授权。 401.4-筛选器授权失败。 401.5-ISAPI/CGI应用程序授权失败。 401.7–访问被Web服务器上的URL授权策略拒绝。这个错误代码为IIS6.0所专用。 403-禁止访问：IIS定义了许多不同的403错误，它们指明更为具体的错误原因： 403.1-执行访问被禁止。 403.2-读访问被禁止。 403.3-写访问被禁止。 403.4-要求SSL。 403.5-要求SSL128。 403.6-IP地址被拒绝。 403.7-要求客户端证书。 403.8-站点访问被拒绝。 403.9-用户数过多。 403.10-配置无效。 403.11-密码更改。 403.12-拒绝访问映射表。 403.13-客户端证书被吊销。 403.14-拒绝目录列表。 403.15-超出客户端访问许可。 403.16-客户端证书不受信任或无效。 403.17-客户端证书已过期或尚未生效。 403.18-在当前的应用程序池中不能执行所请求的URL。这个错误代码为IIS6.0所专用。 403.19-不能为这个应用程序池中的客户端执行CGI。这个错误代码为IIS6.0所专用。 403.20-Passport登录失败。这个错误代码为IIS6.0所专用。 404-未找到。 404.0-（无）–没有找到文件或目录。 404.1-无法在所请求的端口上访问Web站点。 404.2-Web服务扩展锁定策略阻止本请求。 404.3-MIME映射策略阻止本请求。 405-用来访问本页面的HTTP谓词不被允许（方法不被允许） 406-客户端浏览器不接受所请求页面的MIME类型。 407-要求进行代理身份验证。 412-前提条件失败。 413–请求实体太大。 414-请求URI太长。 415–不支持的媒体类型。 416–所请求的范围无法满足。 417–执行失败。 423–锁定的错误。 5xx-服务器错误 服务器由于遇到错误而不能完成该请求。 500-内部服务器错误。 500.12-应用程序正忙于在Web服务器上重新启动。 500.13-Web服务器太忙。 500.15-不允许直接请求Global.asa。 500.16–UNC授权凭据不正确。这个错误代码为IIS6.0所专用。 500.18–URL授权存储不能打开。这个错误代码为IIS6.0所专用。 500.100-内部ASP错误。 501-页眉值指定了未实现的配置。 502-Web服务器用作网关或代理服务器时收到了无效响应。 502.1-CGI应用程序超时。 502.2-CGI应用程序出错。application. 503-服务不可用。这个错误代码为IIS6.0所专用。 504-网关超时。 505-HTTP版本不受支持。 FTP 1xx-肯定的初步答复 这些状态代码指示一项操作已经成功开始，但客户端希望在继续操作新命令前得到另一个答复。 110重新启动标记答复。 120服务已就绪，在nnn分钟后开始。 125数据连接已打开，正在开始传输。 150文件状态正常，准备打开数据连接。 2xx-肯定的完成答复 一项操作已经成功完成。客户端可以执行新命令。200命令确定。 202未执行命令，站点上的命令过多。 211系统状态，或系统帮助答复。 212目录状态。 213文件状态。 214帮助消息。 215NAME系统类型，其中，NAME是AssignedNumbers文档中所列的正式系统名称。 220服务就绪，可以执行新用户的请求。 221服务关闭控制连接。如果适当，请注销。 225数据连接打开，没有进行中的传输。 226关闭数据连接。请求的文件操作已成功（例如，传输文件或放弃文件）。 227进入被动模式(h1,h2,h3,h4,p1,p2)。 230用户已登录，继续进行。 250请求的文件操作正确，已完成。 257已创建“PATHNAME”。 3xx-肯定的中间答复 该命令已成功，但服务器需要更多来自客户端的信息以完成对请求的处理。331用户名正确，需要密码。 332需要登录帐户。 350请求的文件操作正在等待进一步的信息。 4xx-瞬态否定的完成答复 该命令不成功，但错误是暂时的。如果客户端重试命令，可能会执行成功。421服务不可用，正在关闭控制连接。如果服务确定它必须关闭，将向任何命令发送这一应答。 425无法打开数据连接。 426Connectionclosed;transferaborted. 450未执行请求的文件操作。文件不可用（例如，文件繁忙）。 451请求的操作异常终止：正在处理本地错误。 452未执行请求的操作。系统存储空间不够。 5xx-永久性否定的完成答复 该命令不成功，错误是永久性的。如果客户端重试命令，将再次出现同样的错误。500语法错误，命令无法识别。这可能包括诸如命令行太长之类的错误。 501在参数中有语法错误。 502未执行命令。 503错误的命令序列。 504未执行该参数的命令。 530未登录。 532存储文件需要帐户。 550未执行请求的操作。文件不可用（例如，未找到文件，没有访问权限）。 551请求的操作异常终止：未知的页面类型。 552请求的文件操作异常终止：超出存储分配（对于当前目录或数据集）。 553未执行请求的操作。不允许的文件名。 常见的FTP状态代码及其原因 150-FTP使用两个端口：21用于发送命令，20用于发送数据。状态代码150表示服务器准备在端口20上打开新连接，发送一些数据。 226-命令在端口20上打开数据连接以执行操作，如传输文件。该操作成功完成，数据连接已关闭。 230-客户端发送正确的密码后，显示该状态代码。它表示用户已成功登录。 331-客户端发送用户名后，显示该状态代码。无论所提供的用户名是否为系统中的有效帐户，都将显示该状态代码。 426-命令打开数据连接以执行操作，但该操作已被取消，数据连接已关闭。 530-该状态代码表示用户无法登录，因为用户名和密码组合无效。如果使用某个用户帐户登录，可能键入错误的用户名或密码，也可能选择只允许匿名访问。如果使用匿名帐户登录，IIS的配置可能拒绝匿名访问。 550-命令未被执行，因为指定的文件不可用。例如，要GET的文件并不存在，或试图将文件PUT到您没有写入权限的目录。

域名不能正确解析可以更换其它的dns服务器，在百度搜索“公用dns”，选一个就行了 IIS状态代码的含义 概要 当用户试图通过HTTP或文件传输协议(FTP)访问一台正在运行Internet信息服务(IIS)的服务器上的内容时，IIS返回一个表示该请求的状态的数字代码。该状态代码记录在IIS日志中，同时也可能在Web浏览器或FTP客户端显示。状态代码可以指明具体请求是否已成功，还可以揭示请求失败的确切原因。 更多信息 日志文件的位置 在默认状态下，IIS把它的日志文件放在%WINDIR\System32\Logfiles文件夹中。每个万维网(WWW)站点和FTP站点在该目录下都有一个单独的目录。在默认状态下，每天都会在这些目录下创建日志文件，并用日期给日志文件命名（例如，exYYMMDD.log）。 HTTP 1xx-信息提示 这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个1xx响应。 100-继续。 101-切换协议。 2xx-成功 这类状态代码表明服务器成功地接受了客户端请求。 200-确定。客户端请求已成功。 201-已创建。 202-已接受。 203-非权威性信息。 204-无内容。 205-重置内容。 206-部分内容。 3xx-重定向 客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。 301-对象已永久移走，即永久重定向。 302-对象已临时移动。 304-未修改。 307-临时重定向。 4xx-客户端错误 发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。400-错误的请求。 401-访问被拒绝。IIS定义了许多不同的401错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在IIS日志中显示： 401.1-登录失败。 401.2-服务器配置导致登录失败。 401.3-由于ACL对资源的限制而未获得授权。 401.4-筛选器授权失败。 401.5-ISAPI/CGI应用程序授权失败。 401.7–访问被Web服务器上的URL授权策略拒绝。这个错误代码为IIS6.0所专用。 403-禁止访问：IIS定义了许多不同的403错误，它们指明更为具体的错误原因： 403.1-执行访问被禁止。 403.2-读访问被禁止。 403.3-写访问被禁止。 403.4-要求SSL。 403.5-要求SSL128。 403.6-IP地址被拒绝。 403.7-要求客户端证书。 403.8-站点访问被拒绝。 403.9-用户数过多。 403.10-配置无效。 403.11-密码更改。 403.12-拒绝访问映射表。 403.13-客户端证书被吊销。 403.14-拒绝目录列表。 403.15-超出客户端访问许可。 403.16-客户端证书不受信任或无效。 403.17-客户端证书已过期或尚未生效。 403.18-在当前的应用程序池中不能执行所请求的URL。这个错误代码为IIS6.0所专用。 403.19-不能为这个应用程序池中的客户端执行CGI。这个错误代码为IIS6.0所专用。 403.20-Passport登录失败。这个错误代码为IIS6.0所专用。 404-未找到。 404.0-（无）–没有找到文件或目录。 404.1-无法在所请求的端口上访问Web站点。 404.2-Web服务扩展锁定策略阻止本请求。 404.3-MIME映射策略阻止本请求。 405-用来访问本页面的HTTP谓词不被允许（方法不被允许） 406-客户端浏览器不接受所请求页面的MIME类型。 407-要求进行代理身份验证。 412-前提条件失败。 413–请求实体太大。 414-请求URI太长。 415–不支持的媒体类型。 416–所请求的范围无法满足。 417–执行失败。 423–锁定的错误。 5xx-服务器错误 服务器由于遇到错误而不能完成该请求。 500-内部服务器错误。 500.12-应用程序正忙于在Web服务器上重新启动。 500.13-Web服务器太忙。 500.15-不允许直接请求Global.asa。 500.16–UNC授权凭据不正确。这个错误代码为IIS6.0所专用。 500.18–URL授权存储不能打开。这个错误代码为IIS6.0所专用。 500.100-内部ASP错误。 501-页眉值指定了未实现的配置。 502-Web服务器用作网关或代理服务器时收到了无效响应。 502.1-CGI应用程序超时。 502.2-CGI应用程序出错。application. 503-服务不可用。这个错误代码为IIS6.0所专用。 504-网关超时。 505-HTTP版本不受支持。 FTP 1xx-肯定的初步答复 这些状态代码指示一项操作已经成功开始，但客户端希望在继续操作新命令前得到另一个答复。 110重新启动标记答复。 120服务已就绪，在nnn分钟后开始。 125数据连接已打开，正在开始传输。 150文件状态正常，准备打开数据连接。 2xx-肯定的完成答复 一项操作已经成功完成。客户端可以执行新命令。200命令确定。 202未执行命令，站点上的命令过多。 211系统状态，或系统帮助答复。 212目录状态。 213文件状态。 214帮助消息。 215NAME系统类型，其中，NAME是AssignedNumbers文档中所列的正式系统名称。 220服务就绪，可以执行新用户的请求。 221服务关闭控制连接。如果适当，请注销。 225数据连接打开，没有进行中的传输。 226关闭数据连接。请求的文件操作已成功（例如，传输文件或放弃文件）。 227进入被动模式(h1,h2,h3,h4,p1,p2)。 230用户已登录，继续进行。 250请求的文件操作正确，已完成。 257已创建“PATHNAME”。 3xx-肯定的中间答复 该命令已成功，但服务器需要更多来自客户端的信息以完成对请求的处理。331用户名正确，需要密码。 332需要登录帐户。 350请求的文件操作正在等待进一步的信息。 4xx-瞬态否定的完成答复 该命令不成功，但错误是暂时的。如果客户端重试命令，可能会执行成功。421服务不可用，正在关闭控制连接。如果服务确定它必须关闭，将向任何命令发送这一应答。 425无法打开数据连接。 426Connectionclosed;transferaborted. 450未执行请求的文件操作。文件不可用（例如，文件繁忙）。 451请求的操作异常终止：正在处理本地错误。 452未执行请求的操作。系统存储空间不够。 5xx-永久性否定的完成答复 该命令不成功，错误是永久性的。如果客户端重试命令，将再次出现同样的错误。500语法错误，命令无法识别。这可能包括诸如命令行太长之类的错误。 501在参数中有语法错误。 502未执行命令。 503错误的命令序列。 504未执行该参数的命令。 530未登录。 532存储文件需要帐户。 550未执行请求的操作。文件不可用（例如，未找到文件，没有访问权限）。 551请求的操作异常终止：未知的页面类型。 552请求的文件操作异常终止：超出存储分配（对于当前目录或数据集）。 553未执行请求的操作。不允许的文件名。 常见的FTP状态代码及其原因 150-FTP使用两个端口：21用于发送命令，20用于发送数据。状态代码150表示服务器准备在端口20上打开新连接，发送一些数据。 226-命令在端口20上打开数据连接以执行操作，如传输文件。该操作成功完成，数据连接已关闭。 230-客户端发送正确的密码后，显示该状态代码。它表示用户已成功登录。 331-客户端发送用户名后，显示该状态代码。无论所提供的用户名是否为系统中的有效帐户，都将显示该状态代码。 426-命令打开数据连接以执行操作，但该操作已被取消，数据连接已关闭。 530-该状态代码表示用户无法登录，因为用户名和密码组合无效。如果使用某个用户帐户登录，可能键入错误的用户名或密码，也可能选择只允许匿名访问。如果使用匿名帐户登录，IIS的配置可能拒绝匿名访问。 550-命令未被执行，因为指定的文件不可用。例如，要GET的文件并不存在，或试图将文件PUT到您没有写入权限的目录。 答案来源网络，供参考，希望对您有帮助

调用DescribeChanges查询给定环境内所有变更信息或给定变更ID的变更信息。 调试 您可以在OpenAPI Explorer中直接运行该接口，免去您计算签名的困扰。运行成功后，OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求头 该接口使用公共请求头，无特殊请求头。请参见公共请求参数文档。 请求语法 GET /pop/v1/wam/changeInfo HTTP/1.1 请求参数 名称 类型 是否必选 示例值 描述 EnvId String 是 we-5d245f7f1f773f090a0d**** 环境ID，将查询此环境内所有变更信息 ChangeId String 否 wc-5d245f94f314934e2ab1**** 变更ID，将查询此变更ID 返回数据 名称 类型 示例值 描述 Change 变更信息 Code String OK 响应代码，若成功请求为OK Message String success 响应消息，若成功请求为success RequestId String 91AF2647-8A0B-47FE-8AD4-AE49AA79**** 请求ID 示例 请求示例 http://webplus.cn-hangzhou.aliyuncs.com/pop/v1/wam/changeInfo?ChangeId=wc-5d245f94f314934e2ab1****&ServiceCode=webx&<公共请求参数> 正常返回示例 XML 格式 success apply.env Apply false false 1564120665714 apply env we-5d39b8ba6786bd4b1495**** we-5d39b8ba6786bd4b1495**** true 1564120665679 user1 1564120637891 wc-5d3a963d5802611c4ddc**** true false 97CEF6FD-0266-4C15-8745-9325E2AB**** OK JSON 格式 { "Change":{ "ChangeName":"apply.env", "ActionName":"Apply", "ChangeAborted":false, "ChangeTimedout":false, "UpdateTime":1564120665714, "ChangeDescription":"apply env we-5d39b8ba6786bd4b1495****", "EnvId":"we-5d39b8ba6786bd4b1495****", "ChangeSucceed":true, "FinishTime":1564120665679, "CreateUsername":"user1", "CreateTime":1564120637891, "ChangeId":"wc-5d3a963d5802611c4ddc****", "ChangeFinished":true, "ChangeMessage":"", "ChangePaused":false }, "Message":"success", "RequestId":"150EA851-8DD9-4530-A3DF-5940B738****", "Code":"OK" } 错误码 HttpCode 错误码 错误信息 描述 403 ResourceAuthFailed The specified resource does not exist or it does not belong to this Alibaba Cloud account. 相关资源不存在或不属于此阿里云账号。 404 ChangeNotExists The change record could not be found based on the change ID specified, please double confirm the resource is still exists. 无法根据所指定的变更 ID 找到变更记录，该记录可能被删除或传入的参数有误。 访问错误中心查看更多错误码。 调用DescribeChanges查询所有变更信息或给定环境内所有变更信息。 调试 您可以在OpenAPI Explorer中直接运行该接口，免去您计算签名的困扰。运行成功后，OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求头 该接口使用公共请求头，无特殊请求头。请参见公共请求参数文档。 请求语法 GET /pop/v1/wam/change HTTP/1.1 请求参数 名称 类型 是否必选 示例值 描述 EnvId String 是 we-5d245f7f1f773f090a0d**** 环境ID，将查询此环境内所有变更信息 ActionName String 否 Termination 要查询的变更类型 PageNumber Integer 否 1 查询页面数量 PageSize Integer 否 10 查询页面内结果数量 返回数据 名称 类型 示例值 描述 Changes 变更信息列表 Code String OK 响应代码，若成功请求为OK Message String success 响应消息，若成功请求为success PageNumber Integer 1 查询页面数量 PageSize Integer 10 单个查询页面内结果数量 RequestId String 91AF2647-8A0B-47FE-8AD4-AE49AA79**** 请求ID TotalCount Integer 4046 查询结果总数 示例 请求示例 http://webplus.cn-hangzhou.aliyuncs.com/pop/v1/wam/change?PageSize=1&EnvId=we-5d39b8ba6786bd4b1495****&<公共请求参数> 正常返回示例 XML 格式 1 apply.env Apply false false 1564120665714 apply env we-5d39b8ba6786bd4b1495**** we-5d39b8ba6786bd4b1495**** true 1564120665679 user1 1564120637891 wc-5d3a963d5802611c4ddc**** true false 12 success 1 676F2994-039A-46B5-A30A-CABB7FE0**** OK JSON 格式 { "PageNumber":1, "Changes":{ "Change":[ { "ChangeName":"apply.env", "ActionName":"Apply", "ChangeAborted":false, "ChangeTimedout":false, "UpdateTime":1564120665714, "ChangeDescription":"apply env we-5d39b8ba6786bd4b1495****", "EnvId":"we-5d39b8ba6786bd4b1495****", "ChangeSucceed":true, "FinishTime":1564120665679, "CreateUsername":"user1", "CreateTime":1564120637891, "ChangeId":"wc-5d3a963d5802611c4ddc****", "ChangeMessage":"", "ChangeFinished":true, "ChangePaused":false } ] }, "TotalCount":12, "Message":"success", "PageSize":1, "RequestId":"6C25A79D-D46F-4079-B522-7D7CBA46****", "Code":"OK" } 错误码 HttpCode 错误码 错误信息 描述 403 ResourceAuthFailed The specified resource does not exist or it does not belong to this Alibaba Cloud account. 相关资源不存在或不属于此阿里云账号。 访问错误中心查看更多错误码。 调用PauseChange来暂停一个未完成的变更操作。 说明 只能针对处于变更中状态的变更进行暂停变更操作。 调试 您可以在OpenAPI Explorer中直接运行该接口，免去您计算签名的困扰。运行成功后，OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求头 该接口使用公共请求头，无特殊请求头。请参见公共请求参数文档。 请求语法 POST /pop/v1/wam/change/pause HTTP/1.1 请求参数 名称 类型 是否必选 示例值 描述 ChangeId String 是 wc-5d3fabad56fd7c14ac9***** 变更ID，将暂停此变更操作 返回数据 名称 类型 示例值 描述 Code String OK 响应代码，若成功请求为OK EnvChange 环境变更信息 Message String success 响应消息，若成功请求为success RequestId String BF62BC0A-6672-41A2-8EE5-D5034AB***** 请求ID 示例 请求示例 http://webplus.cn-hangzhou.aliyuncs.com/pop/v1/wam/change/pause&<公共请求头> { "ChangeId": "wc-5d3fabad56fd7c14ac9*****" } 正常返回示例 XML 格式 success we-5d39b8ba6786bd4b149***** 1564120637891 wc-5d3fabad56fd7c14ac9***** 97CEF6FD-0266-4C15-8745-9325E2A***** OK JSON 格式 { "Message":"success", "RequestId":"BF62BC0A-6672-41A2-8EE5-D5034AB*****", "EnvChange":{ "EnvId":"we-5d39b8ba6786bd4b149*****", "ChangeId":"wc-5d3fabad56fd7c14ac9*****", "StartTime":1564453805573 }, "Code":"OK" } 错误码 访问错误中心查看更多错误码。 调用ResumeChange来恢复一个被暂停的变更操作。 说明 被恢复的变更必须是处于已停止状态。 调试 您可以在OpenAPI Explorer中直接运行该接口，免去您计算签名的困扰。运行成功后，OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求头 该接口使用公共请求头，无特殊请求头。请参见公共请求参数文档。 请求语法 POST /pop/v1/wam/change/resume HTTP/1.1 请求参数 名称 类型 是否必选 示例值 描述 ChangeId String 是 wc-5d3fabad56fd7c14ac9***** 变更ID，将恢复此变更操作 返回数据 名称 类型 示例值 描述 Code String OK 响应代码，若成功请求为OK EnvChange 环境变更信息 Message String success 响应消息，若成功请求为success RequestId String F38283EF-B83B-47C0-992D-1DC450DE**** 请求ID 示例 请求示例 http://webplus.cn-hangzhou.aliyuncs.com/pop/v1/wam/change/resume&<公共请求头> { "ChangeId": "wc-5d3fabad56fd7c14ac9*****" } 正常返回示例 XML 格式 success we-5d39b8ba6786bd4b149***** 1564453805573 wc-5d3fabad56fd7c14ac9***** 97CEF6FD-0266-4C15-8745-9325E2AB**** OK JSON 格式 { "Message":"success", "RequestId":"F38283EF-B83B-47C0-992D-1DC450DE****", "EnvChange":{ "EnvId":"we-5d39b8ba6786bd4b149*****", "ChangeId":"wc-5d3fabad56fd7c14ac9*****", "StartTime":1564453805573 }, "Code":"OK" } 错误码 访问错误中心查看更多错误码。 使用AbortChange可以中止一次变更。 当此API调用后，Web+会等待正在进行的变更步骤执行完毕后再停止变更。 当环境有变更正在被终止时，不可重复调用此接口。 变更在中止后不可恢复执行。 调试 您可以在OpenAPI Explorer中直接运行该接口，免去您计算签名的困扰。运行成功后，OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求头 该接口使用公共请求头，无特殊请求头。请参见公共请求参数文档。 请求语法 POST /pop/v1/wam/change/abort HTTP/1.1 请求参数 名称 类型 是否必选 示例值 描述 ChangeId String 是 wc-5d3a963d5802611c4ddc**** 变更ID，将中止此变更 返回数据 名称 类型 示例值 描述 Code String OK 响应代码，若成功请求为OK EnvChange 被中止的变更信息 Message String success 响应消息，若成功请求为success RequestId String 14A65FB3-DFD6-4D9A-83EA-9259C2D3**** 请求ID 示例 请求示例 http://webplus.cn-hangzhou.aliyuncs.com&<公共请求参数> { "ChangeId":"wc-5cda75398047880ad2c8****" } 正常返回示例 XML 格式 success wc-5cdbd79a84b53b4bc958**** we-5cdbd64084b53b4bc958**** 1557911450434 BED39BFD-3CBF-42F0-9711-C91E32BF**** OK JSON 格式 { "Message":"success", "RequestId":"3A6ECBAB-4A14-4412-AFE7-6B75D55A****", "EnvChange":{ "EnvId":"we-5cdbd64084b53b4bc958****", "ChangeId":"wc-5cdbd6d884b53b4bc958****", "StartTime":1557911256210 }, "Code":"OK" } 错误码 HttpCode 错误码 错误信息 描述 500 ResourceAuthFailed The specified resource does not exist or it does not belong to this Alibaba Cloud account. 相关资源不存在或不属于此阿里云账号。 400 ChangeOnAborting The change is being canceled. Please do not cancel again. 变更正在被中止，请勿重复操作。 400 ChangeFinished An error occurred while stopping the change. The change is already complete. 放弃变更失败，因为此次变更已经完成。 访问错误中心查看更多错误码。 调用DeleteChange删除一个变更。 调试 您可以在OpenAPI Explorer中直接运行该接口，免去您计算签名的困扰。运行成功后，OpenAPI Explorer可以自动生成SDK代码示例。 调试 请求头 该接口使用公共请求头，无特殊请求头。请参见公共请求参数文档。 请求语法 DELETE /pop/v1/wam/change HTTP/1.1 请求参数 名称 类型 是否必选 示例值 描述 ChangeId String 是 wc-5d3a963d5802611c4dd***** 变更ID，将删除此变更 返回数据 名称 类型 示例值 描述 Code String OK 响应代码，若成功请求为OK Message String success 响应消息，若成功请求为success RequestId String 671FBCF3-D384-4DC4-B6F4-028C28E***** 请求ID 示例 请求示例 http://webplus.cn-hangzhou.aliyuncs.com/pop/v1/wam/change?ServiceCode=webx&Id=wc-5d245f94f314934e2ab1*****&<公共请求参数> 正常返回示例 XML 格式 success 671FBCF3-D384-4DC4-B6F4-028C28***** OK JSON 格式 { "Message":"success", "RequestId":"671FBCF3-D384-4DC4-B6F4-028C28E*****", "Code":"OK" } 错误码 HttpCode 错误码 错误信息 描述 403 ResourceAuthFailed The specified resource does not exist or it does not belong to this Alibaba Cloud account. 相关资源不存在或不属于此阿里云账号。 400 OSSDisabled You have not activated the OSS service and cannot use the WebPlus service. Please go to the OSS console (https://oss.console.aliyun.com) to activate OSS and try again. 您没有开通 OSS 服务，不能使用 WebPlus 服务，请前往 OSS 控制台(https://oss.console.aliyun.com) 开通后重试。 400 OSSApiCallFailed When initializing applications, updating configurations, or destroying applications, WebPlus attempts to communicate with OSS through API communication. An OSS service throw error occurred. The bucket or the file does not exist. 在初始化应用、更新配置、以及销毁应用时，WebPlus 尝试与 OSS 进行 API 通信出现 OSS 服务抛出的异常，如 bucket 不存在、文件不存在等。 访问错误中心查看更多错误码。

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念，不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持，这里可能会有疑惑，前面我们在介绍MongoDB时，说MongoDB是一个NoSQL数据库，不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事，如果你已经非常了解关系型数据库的事务，通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID？ 1）MongoDB对原子性（Atomicity）的支持 原子性在Mongodb中到底是一个什么概念呢？为什么说支持但又说Mongodb的原子性是单行/文档级原子性，这里提供了一个MongoDB更新语句样例，如下图： MongoDB是如何实现事务的ACID？ 更新“username”等于“tj.tang”的文档，更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新，这个概念在MySQL中可能你没有考虑过，但在MongoDB中由于文档可以嵌套子文档可以很复杂，所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的，如下情况： MongoDB是如何实现事务的ACID？ MongoDB更新条件为工资小于50万的人都把工资调整为50万，这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时，出现宕机，服务器重启之后是无法像关系型数据库那样做到数据回滚的，也就是说处理这种多文档关系型数据库事务的支持，但MongoDB不支持。那么怎么解决Mongodb这个问题呢？可以通过建模，MongoDB不是范式而是反范式的设计，通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2）MongoDB对一致性（consistency）的支持 对于数据一致性来说，传统数据库（单机）跟分布式数据库（MongoDB）对于数据一致性是不太一样的，怎么理解呢？如下图： MongoDB是如何实现事务的ACID？ 对于传统型数据库来说，数据一致性主要是在单机上，单机的问题主要是数据进来时的规则检验，数据不能被破坏掉。而在分布式数据库上，因为他们都是多节点分布式的，我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的，MongoDB支持强一致性或最终一致性（弱一致性），MongoDB的数据一致性也叫可调一致性，什么意思呢？如下图： MongoDB是如何实现事务的ACID？ MongoDB的可调一致性，也就是可以自由选择强一致性或最终一致性，如果你的应用场景是前台的方式可以选择强一致性，如果你的应用场景是后台的方式（如报表）可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载，下面我们来看看这样做引发的一个问题：保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难，同步节点可能会故障，甚至会无法恢复，网络可能会有延迟或者丢包，网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中，通常有两个层次的一致性：第一种是强一致性，既集群中的所有机器状态同步保持一致。第二种是最终一致性，既可以允许短暂的数据不一致，但数据最终会保持一致。我们先来讲一下，在分布式集群中，为什么最终一致性通常是更合理的选择，然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢？其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出，称为CAP理论，尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳： 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 分区容忍性（P）：集群中的某些节点在无法联系后，集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 要保证数据强一致性，最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功，也就是同步概念。而这时如果某个结点出现故障，那么写操作就成功不了了，需要一直等到这个节点恢复。也就是说，如果要保证强一致性，那么就无法提供7×24的高可用性。 而要保证可用性的话，就意味着节点在响应请求时，不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功，这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然，事实上还有其它的选择，比如在Yahoo的PNUTS中，采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现，所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证，要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的，但是作为一个整体，当客户端发起对某个key的数据请求时，整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中，一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时，需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系：R＋W>N 下面举个实在的例子。比如我们设定N＝3（数据会备份到A、B、C三个结点）。比如值 employee30:salary 当前的值是20000，我们想将其修改为30000。我们设定W＝2，下面我们会对A、B、C三个节点发起写操作（employee30:salary, 30000），当A、B两个节点返回写成功后，协调器就会返回给客户端说写成功了。至于节点C，我们可以假设它从来没有收到这个写请求，他保存的依然是20000那个值。之后，当一个协调器执行一个对employee30:salary的读操作时，他还是会发三个请求给A、B、C三个节点： 如果设定R＝1，那么当C节点先返回了20000这个值时，那我们客户端实际得到了一个错误的值。 如果设定R＝2，则当协调器收到20000和30000两个值时，它会发现数据不太正确，并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性，在上面的应用场景中，我们需要设定R＝2，W＝2 如果写操作不能收到W个节点的成功返回，或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败，或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定，会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功，既W＝N，那么只要有一个备份节点故障，写操作就失败了。一般设定是R＋W = N+1，这是保证强一致性的最小设定了。一些强一致性的系统设定W＝N，R＝1，这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。为了不至于让写操作太慢，对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后，会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性，或者是W 3）MongoDB对隔离性（isolation）的支持 在关系型数据库中，SQL2定义了四种隔离级别，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准，比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改，哪些在事务内核事务外是可见的，哪些是不可见的。为了尽可能减少事务间的影响，事务隔离级别越高安全性越好但是并发就越差；事务隔离级别越低，事务请求的锁越少，或者保持锁的时间就越短，这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID？ MongoDB在3.2之前使用的是“读未提交”，这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题： READ-UNCOMMITTED（读尚未提交的数据） 在这个级别，一个事务的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为“脏读（dirty read）”。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。 READ-COMMITTED（读已提交的数据） 在这个级别，能满足前面提到的隔离性的简单定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读（non-repeatable read）”，因为两次执行同样的查询，可能会得到不一样的结果。 REPEATABLE-READ（可重复读） 在这个级别，保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC（multiversion concurrency control）解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息，也就是说这些数据数据库当前状态，这在一些对于数据的时效特别敏感的业务中，就很可能会出问题。 SERIALIZABLE（串行化） 在这个级别，它通过强制事务串行执行，避免了前面说的一系列问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别，主要应用在InnoDB存储引擎的分布式事务中。 4）MongoDB对持久性（durability）的支持 对于数据持久性来说，在传统数据库中（单机）的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题，因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID？ 从上图可以看出，MongoDB同样是使用数据进来先写日志（日志刷盘的速度是非常快）然后在写入到数据库中的这种方式来保证数据的持久性，如果出现服务器宕机，当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging（预写日志系统），而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好，MongoDB的复制默认节点就是三节点以上的复制集群，当数据到达主节点之后会马上同步到从节点上去。

1.阻塞与同步2.BIO与NIO对比3.NIO简介4.缓冲区Buffer5.通道Channel6.反应堆7.选择器8.NIO源码分析9.AIO1.阻塞与同步1）阻塞(Block)和非租塞(NonBlock):阻塞和非阻塞是进程在访问数据的时候，数据是否准备就绪的一种处理方式，当数据没有准备的时候阻塞：往往需要等待缞冲区中的数据准备好过后才处理其他的事情，否則一直等待在那里。非阻塞：当我们的进程访问我们的数据缓冲区的时候，如果数据没有准备好则直接返回，不会等待。如果数据已经准备好，也直接返回2）同步(Synchronization)和异步(Async)的方式：同步和异步都是基于应用程序私操作系统处理IO事件所采用的方式，比如同步：是应用程序要直接参与IO读写的操作。异步：所有的IO读写交给搡作系统去处理，应用程序只需要等待通知。同步方式在处理IO事件的时候，必须阻塞在某个方法上靣等待我们的IO事件完成(阻塞IO事件或者通过轮询IO事件的方式）.对于异步来说，所有的IO读写都交给了搡作系统。这个时候，我们可以去做其他的事情，并不拓要去完成真正的IO搡作，当搡作完成IO后.会给我们的应用程序一个通知同步：阻塞到IO事件，阻塞到read成则write。这个时候我们就完全不能做自己的事情，让读写方法加入到线程里面，然后阻塞线程来实现，对线程的性能开销比较大，参考：https://blog.csdn.net/CharJay_Lin/article/details/812598802.BIO与NIO对比block IO与Non-block IO1）区别IO模型 IO NIO方式 从硬盘到内存 从内存到硬盘通信 面向流（乡村公路） 面向缓存（高速公路，多路复用技术）处理 阻塞IO（多线程） 非阻塞IO（反应堆Reactor）触发 无 选择器（轮询机制）2）面向流与面向缓冲Java NIO和IO之间第一个最大的区别是，IO是面向流的.NIO是面向缓冲区的。Java IO面向流意味着毎次从流中读一个成多个字节，直至读取所有字节，它们没有被缓存在任何地方，此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的教据，需要先将它缓存到一个缓冲区。Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，霱要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有您需要处理的数裾。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。3）阻塞与非阻塞Java IO的各种流是阻塞的。这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。 Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。4）选择器（Selector)Java NIO的选择器允许一个单独的线程来监视多个输入通道，你可以注册多个通道使用一个选择器，然后使用一个单独的线程来“选择"通道：这些通里已经有可以处理的褕入，或者选择已准备写入的通道。这选怿机制，使得一个单独的线程很容易来管理多个通道。5）NIO和BIO读取文件BIO读取文件：链接BIO从一个阻塞的流中一行一行的读取数据image | left | 469x426NIO读取文件：链接通道是数据的载体，buffer是存储数据的地方，线程每次从buffer检查数据通知给通道image | left | 559x3946）处理数据的线程数NIO：一个线程管理多个连接BIO：一个线程管理一个连接3.NIO简介在Java1.4之前的I/O系统中，提供的都是面向流的I/O系统，系统一次一个字节地处理数据，一个输入流产生一个字节的数据，一个输出流消费一个字节的数据，面向流的I/O速度非常慢，而在Java 1.4中推出了NIO，这是一个面向块的I/O系统，系统以块的方式处理处理，每一个操作在一步中产生或者消费一个数据库，按块处理要比按字节处理数据快的多。在NIO中有几个核心对象需要掌握：缓冲区（Buffer）、通道（Channel）、选择器（Selector）。参考：链接image2.png | center | 851x3834.缓冲区Buffer缓冲区实际上是一个容器对象，更直接的说，其实就是一个数组，在NIO库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的； 在写入数据时，它也是写入到缓冲区中的；任何时候访问 NIO 中的数据，都是将它放到缓冲区中。而在面向流I/O系统中，所有数据都是直接写入或者直接将数据读取到Stream对象中。在NIO中，所有的缓冲区类型都继承于抽象类Buffer，最常用的就是ByteBuffer，对于Java中的基本类型，基本都有一个具体Buffer类型与之相对应，它们之间的继承关系如下图所示：image3.png | center | 650x3681）其中的四个属性的含义分别如下：容量（Capacity）：缓冲区能够容纳的数据元素的最大数量。这一个容量在缓冲区创建时被设定，并且永远不能改变。上界(Limit)：缓冲区的第一个不能被读或写的元素。或者说,缓冲区中现存元素的计数。位置(Position)：下一个要被读或写的元素的索引。位置会自动由相应的 get( )和 put( )函数更新。标记(Mark)：下一个要被读或写的元素的索引。位置会自动由相应的 get( )和 put( )函数更新。2）Buffer的常见方法如下所示:flip(): 写模式转换成读模式rewind()：将 position 重置为 0 ，一般用于重复读。clear() ：compact(): 将未读取的数据拷贝到 buffer 的头部位。mark(): reset():mark 可以标记一个位置， reset 可以重置到该位置。Buffer 常见类型： ByteBuffer 、 MappedByteBuffer 、 CharBuffer 、 DoubleBuffer 、 FloatBuffer 、 IntBuffer 、 LongBuffer 、 ShortBuffer 。3）基本操作Buffer基础操作： 链接缓冲区分片，缓冲区分配，直接缓存区，缓存区映射，缓存区只读：链接4）缓冲区存取数据流程存数据时position会++，当停止数据读取的时候调用flip()，此时limit=position，position=0读取数据时position++，一直读取到limitclear() 清空 buffer ，准备再次被写入 (position 变成 0 ， limit 变成 capacity) 。5.通道Channel通道是一个对象，通过它可以读取和写入数据，当然了所有数据都通过Buffer对象来处理。我们永远不会将字节直接写入通道中，相反是将数据写入包含一个或者多个字节的缓冲区。同样不会直接从通道中读取字节，而是将数据从通道读入缓冲区，再从缓冲区获取这个字节。image4.png | center | 368x191在NIO中，提供了多种通道对象，而所有的通道对象都实现了Channel接口。它们之间的继承关系如下图所示：image5.png | center | 650x5171）使用NIO读取数据在前面我们说过，任何时候读取数据，都不是直接从通道读取，而是从通道读取到缓冲区。所以使用NIO读取数据可以分为下面三个步骤：从FileInputStream获取Channel 创建Buffer 将数据从Channel读取到Buffer中 例子：链接 2）使用NIO写入数据使用NIO写入数据与读取数据的过程类似，同样数据不是直接写入通道，而是写入缓冲区，可以分为下面三个步骤：从FileInputStream获取Channel 创建Buffer 将数据从Channel写入到Buffer中 例子：链接 6.反应堆1）阻塞IO模型在老的IO包中，serverSocket和socket都是阻塞式的，因此一旦有大规模的并发行为，而每一个访问都会开启一个新线程。这时会有大规模的线程上下文切换操作（因为都在等待，所以资源全都被已有的线程吃掉了），这时无论是等待的线程还是正在处理的线程，响应率都会下降，并且会影响新的线程。image6.png | center | 739x3362）NIOJava NIO是在jdk1.4开始使用的，它既可以说成“新IO”，也可以说成非阻塞式I/O。下面是java NIO的工作原理：1.由一个专门的线程来处理所有的IO事件，并负责分发。2.事件驱动机制：事件到的时候触发，而不是同步的去监视事件。3.线程通讯：线程之间通过wait,notify等方式通讯。保证每次上下文切换都是有意义的。减少无谓的线程切换。image7.png | center | 689x251注：每个线程的处理流程大概都是读取数据，解码，计算处理，编码，发送响应。7.选择器传统的 server / client 模式会基于 TPR ( Thread per Request ) ．服务器会为每个客户端请求建立一个线程．由该线程单独负贵处理一个客户请求。这种模式带未的一个问题就是线程数是的剧增．大量的线程会增大服务器的开销，大多数的实现为了避免这个问题，都采用了线程池模型，并设置线程池线程的最大数量，这又带来了新的问题，如果线程池中有 200 个线程，而有 200 个用户都在进行大文件下载，会导致第 201 个用户的请求无法及时处理，即便第 201 个用户只想请求一个几 KB 大小的页面。传统的 Sorvor / Client 模式如下围所示：image8.png | center | 597x286NIO 中非阻塞IO采用了基于Reactor模式的工作方式，IO调用不会被阻塞，相反是注册感兴趣的特点IO事件，如可读数据到达，新的套接字等等，在发生持定率件时，系统再通知我们。 NlO中实现非阻塞IO的核心设计Selector，Selector就是注册各种IO事件的地方，而且当那些事件发生时，就是这个对象告诉我们所发生的事件。image9.png | center | 462x408当有读或者写等任何注册的事件发生时，可以从Selector中获得相应的SelectionKey，同时从SelectionKey中可以找到发生的事件和该事件所发生的具体的SelectableChannel，以获得客户端发送过来的数据。使用NIO中非阻塞IO编写服务器处理程序，有三个步骤1.向Selector对象注册感兴趣的事件2.从Selector中获取感兴趣的事件3.根据不同事件进行相应的处理8.NIO源码分析Selector是NIO的核心epool模型1）SelectorSelector的open()方法：链接2）ServerSocketChannelServerSocketChannel.open() 链接9.AIOAsynchronous IO异步非阻塞IOBIO ServerSocketNIO ServerSocketChannelAIO AsynchronousServerSocketChannel

134题 其实就是水平扩容了，Zookeeper在这方面不太好。两种方式：全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。逐个重启：这是比较常用的方式。 133题 集群最低3（2N+1）台，保证奇数，主要是为了选举算法。一个由 3 台机器构成的 ZooKeeper 集群，能够在挂掉 1 台机器后依然正常工作，而对于一个由 5 台服务器构成的 ZooKeeper 集群，能够对 2 台机器挂掉的情况进行容灾。注意，如果是一个由6台服务器构成的 ZooKeeper 集群，同样只能够挂掉 2 台机器，因为如果挂掉 3 台，剩下的机器就无法实现过半了。 132题 基于“过半”设计原则，ZooKeeper 在运行期间，集群中至少有过半的机器保存了最新的数据。因此，只要集群中超过半数的机器还能够正常工作，整个集群就能够对外提供服务。 131题 不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。 130题 数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master 选举，分布式锁，分布式队列 129题 客户端 SendThread 线程接收事件通知， 交由 EventThread 线程回调 Watcher。客户端的 Watcher 机制同样是一次性的， 一旦被触发后， 该 Watcher 就失效了。 128题 1、服务端接收 Watcher 并存储； 2、Watcher 触发； 2.1 封装 WatchedEvent； 2.2 查询 Watcher； 2.3 没找到；说明没有客户端在该数据节点上注册过 Watcher； 2.4 找到；提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher； 3、调用 process 方法来触发 Watcher。 127题 1.调用 getData()/getChildren()/exist()三个 API，传入 Watcher 对象 2.标记请求 request，封装 Watcher 到 WatchRegistration 3.封装成 Packet 对象，发服务端发送 request 4.收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理 5.请求返回，完成注册。 126题 Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。工作机制：（1）客户端注册 watcher（2）服务端处理 watcher（3）客户端回调 watcher 125题 服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 LOOKING：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。 FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。 LEADING：领导者状态。表明当前服务器角色是 Leader。 OBSERVING：观察者状态。表明当前服务器角色是 Observer。 124题 Zookeeper 有三种部署模式：单机部署：一台集群上运行；集群部署：多台集群运行；伪集群部署：一台集群启动多个 Zookeeper 实例运行。 123题 Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播），二者有相同的地方，比如都有一个Leader，用来协调N个Follower的运行；Leader要等待超半数的Follower做出正确反馈之后才进行提案；二者都有一个值来代表Leader的周期。不同的地方在于：ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。Paxos算法、ZAB协议要想讲清楚可不是一时半会的事儿，自1990年莱斯利·兰伯特提出Paxos算法以来，因为晦涩难懂并没有受到重视。后续几年，兰伯特通过好几篇论文对其进行更进一步地解释，也直到06年谷歌发表了三篇论文，选择Paxos作为chubby cell的一致性算法，Paxos才真正流行起来。对于普通开发者来说，尤其是学习使用Zookeeper的开发者明确一点就好：分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。 122题 ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议(paxos算法的一种实现)。ZAB协议包括两种基本的模式：崩溃恢复和消息广播。当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。 121题 Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；如果是一个Leader宕机，Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。所以，3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)，2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)。 120题 选完Leader以后，zk就进入状态同步过程。1、Leader等待server连接；2、Follower连接leader，将最大的zxid发送给leader；3、Leader根据follower的zxid确定同步点；4、完成同步后通知follower 已经成为uptodate状态；5、Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。 119题 在zookeeper集群中也是一样，每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了。zookeeper中有三种选举算法，分别是LeaderElection,FastLeaderElection,AuthLeaderElection， FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果，而是不断的统计结果，一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。 118题 zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要自己写插件；但是nginx的吞吐量比zk大很多，应该说按业务选择用哪种方式。 117题 Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 116题 有临时节点和永久节点，分再细一点有临时有序/无序节点，有永久有序/无序节点。当创建临时节点的程序结束后，临时节点会自动消失，临时节点上的数据也会一起消失。 115题 在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，这就是主节点存在的意义。 114题 ZooKeeper 实现分布式事务，类似于两阶段提交，总共分为以下 4 步：客户端先给 ZooKeeper 节点发送写请求；ZooKeeper 节点将写请求转发给 Leader 节点，Leader 广播给集群要求投票，等待确认；Leader 收到确认，统计投票，票数过半则提交事务；事务提交成功后，ZooKeeper 节点告知客户端。 113题 ZooKeeper 实现分布式锁的步骤如下：客户端连接 ZooKeeper，并在 /lock 下创建临时的且有序的子节点，第一个客户端对应的子节点为 /lock/lock-10000000001，第二个为 /lock/lock-10000000002，以此类推。客户端获取 /lock 下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听刚好在自己之前一位的子节点删除消息，获得子节点变更通知后重复此步骤直至获得锁；执行业务代码；完成业务流程后，删除对应的子节点释放锁。 112题 ZooKeeper 特性如下：顺序一致性（Sequential Consistency）：来自相同客户端提交的事务，ZooKeeper 将严格按照其提交顺序依次执行；原子性（Atomicity）：于 ZooKeeper 集群中提交事务，事务将“全部完成”或“全部未完成”，不存在“部分完成”；单一系统镜像（Single System Image）：客户端连接到 ZooKeeper 集群的任意节点，其获得的数据视图都是相同的；可靠性（Reliability）：事务一旦完成，其产生的状态变化将永久保留，直到其他事务进行覆盖；实时性（Timeliness）：事务一旦完成，客户端将于限定的时间段内，获得最新的数据。 111题 ZooKeeper 通常有三种搭建模式：单机模式：zoo.cfg 中只配置一个 server.id 就是单机模式了，此模式一般用在测试环境，如果当前主机宕机，那么所有依赖于当前 ZooKeeper 服务工作的其他服务器都不能进行正常工作；伪分布式模式：在一台机器启动不同端口的 ZooKeeper，配置到 zoo.cfg 中，和单机模式相同，此模式一般用在测试环境；分布式模式：多台机器各自配置 zoo.cfg 文件，将各自互相加入服务器列表，上面搭建的集群就是这种完全分布式。 110题 ZooKeeper 主要提供以下功能：分布式服务注册与订阅：在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，如 Dubbo。分布式配置中心：发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到 ZooKeeper 节点上，供订阅者获取数据，实现配置信息的集中式管理和动态更新。命名服务：在分布式系统中，通过命名服务客户端应用能够根据指定名字来获取资源、服务地址和提供者等信息。分布式锁：这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。 109题 Dubbo是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。 108题 Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。 107题 Dubbo超时时间设置有两种方式： 服务提供者端设置超时时间，在Dubbo的用户文档中，推荐如果能在服务端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。 106题 Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀； RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题； LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求； ConstantHash LoadBalance: 一致性Hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动； 缺省时为Random随机调用。 105题 Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心。 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。 Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。 Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer。 104题 Provider：暴露服务的服务提供方。 Consumer：调用远程服务的服务消费方。 Registry：服务注册与发现的注册中心。 Monitor：统计服务的调用次调和调用时间的监控中心。 Container：服务运行容器。 103题 主要就是如下3个核心功能： Remoting：网络通信框架，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。 Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 102题 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 101题 垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段。水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。 100题 垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。 99题 QPS：每秒查询数。TPS：每秒处理事务数。Uptime：服务器已经运行的时间，单位秒。Questions：已经发送给数据库查询数。Com_select：查询次数，实际操作数据库的。Com_insert：插入次数。Com_delete：删除次数。Com_update：更新次数。Com_commit：事务次数。Com_rollback：回滚次数。 98题 如果需要跨主机进行JOIN，跨应用进行JOIN，或者数据库不能获得较好的执行计划，都可以自己通过程序来实现JOIN。 例如：SELECT a.,b. FROM a,b WHERE a.col1=b.col1 AND a.col2> 10 ORDER BY a.col2; 可以利用程序实现，先SELECT * FROM a WHERE a.col2>10 ORDER BY a.col2;–(1) 利用(1)的结果集，做循环，SELECT * FROM b WHERE b.col1=a.col1; 这样可以避免排序，可以在程序里控制执行的速度，有效降低数据库压力，也可以实现跨主机的JOIN。 97题 搭建复制的必备条件：复制的机器之间网络通畅，Master打开了binlog。 搭建复制步骤：建立用户并设置权限，修改配置文件，查看master状态，配置slave，启动从服务，查看slave状态，主从测试。 96题 Heartbeat方案：利用Heartbeat管理VIP，利用crm管理MySQL，MySQL进行双M复制。（Linux系统下没有分库的标准方案）。 LVS+Keepalived方案：利用Keepalived管理LVS和VIP，LVS分发请求到MySQL，MySQL进行双M复制。（Linux系统下无分库无事务的方案）。 Cobar方案：利用Cobar进行HA和分库，应用程序请求Cobar，Cobar转发请求道数据库。（有分库的标准方案，Unix下唯一方案）。 95题 聚集（clustered）索引，也叫聚簇索引，数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。但是，覆盖索引可以模拟多个聚集索引。存储引擎负责实现索引，因此不是所有的存储索引都支持聚集索引。当前，SolidDB和InnoDB是唯一支持聚集索引的存储引擎。 优点：可以把相关数据保存在一起。数据访问快。 缺点：聚集能最大限度地提升I/O密集负载的性能。聚集能最大限度地提升I/O密集负载的性能。建立在聚集索引上的表在插入新行，或者在行的主键被更新，该行必须被移动的时候会进行分页。聚集表可会比全表扫描慢，尤其在表存储得比较稀疏或因为分页而没有顺序存储的时候。第二（非聚集）索引可能会比预想的大，因为它们的叶子节点包含了被引用行的主键列。 94题 以下原因是导致mysql 表毁坏的常见原因： 服务器突然断电导致数据文件损坏； 强制关机，没有先关闭mysql 服务； mysqld 进程在写表时被杀掉； 使用myisamchk 的同时，mysqld 也在操作表； 磁盘故障；服务器死机；mysql 本身的bug 。 93题 1.定位慢查询 首先先打开慢查询日志设置慢查询时间； 2.分析慢查询（使用explain工具分析sql语句）； 3.优化慢查询 。

分布式事务的解决方案有如下几种： 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1：全局事务（DTP模型）全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色： AP：Application 应用系统 它就是我们开发的业务系统，在我们开发的过程中，可以使用资源管理器提供的事务接口来实现分布式事务。 TM：Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成，它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器，通过它们提供的XA接口来同一调度这些资源管理器，以实现分布式事务。DTP只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM：Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器，比如：数据库、消息中间件、缓存等。大部分场景下，数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力，它们通过XA接口，将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口，用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范，RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件？DTP模型有啥优缺点？方案2：基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统，分别可以处理任务A和任务B。此时系统A中存在一个业务流程，需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前，首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后，便向系统A返回一个确认应答；系统A收到确认应答后，则可以开始处理任务A；任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失，从而消息中间件并不会向系统B投递这条消息，从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成，下文会介绍。消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行；当任务B执行完成后，系统B向消息中间件返回一个确认应答，告诉消息中间件该消息已经成功消费，此时，这个分布式事务完成。上述过程可以得出如下几个结论： 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后，到任务B执行完成之间，会存在一定的时间差。在这个时间差内，整个系统处于数据不一致的状态，但这短暂的不一致性是可以接受的，因为经过短暂的时间后，系统又可以保持数据一致性，满足BASE理论。 上述过程中，如果任务A处理失败，那么需要进入回滚流程，如下图所示： title 若系统A在处理任务A时失败，那么就会向消息中间件发送Rollback请求。和发送Commit请求一样，系统A发完之后便可以认为回滚已经完成，它便可以去做其他的事情。消息中间件收到回滚请求后，直接将该消息丢弃，而不投递给系统B，从而不会触发系统B的任务B。此时系统又处于一致性状态，因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况，但在实际系统中，Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候，消息中间件是如何保证数据一致性呢？——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时，如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话，就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果： 提交 若获得的状态是“提交”，则将该消息投递给系统B。回滚 若获得的状态是“回滚”，则直接将条消息丢弃。处理中 若获得的状态是“处理中”，则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况，而且能降低上游系统的阻塞时间，上游系统只要发出Commit/Rollback指令后便可以处理其他任务，无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补，这样大大降低上游系统的阻塞时间，提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后，便可以处理其他任务了，此时它可以认为事务已经完成，接下来消息中间件一定会保证消息被下游系统成功消费掉！那么这是怎么做到的呢？这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕！ 如果消息在投递过程中丢失，或消息的确认应答在返回途中丢失，那么消息中间件在等待确认应答超时之后就会重新投递，直到下游消费者返回消费成功响应为止。当然，一般消息中间件可以设置消息重试的次数和时间间隔，比如：当第一次投递失败后，每隔五分钟重试一次，一共重试3次。如果重试3次之后仍然投递失败，那么这条消息就需要人工干预。 title title 有的同学可能要问：消息投递失败后为什么不回滚消息，而是不断尝试重新投递？ 这就涉及到整套分布式事务系统的实现成本问题。 我们知道，当系统A将向消息中间件发送Commit指令后，它便去做别的事情了。如果此时消息投递失败，需要回滚的话，就需要让系统A事先提供回滚接口，这无疑增加了额外的开发成本，业务系统的复杂度也将提高。对于一个业务系统的设计目标是，在保证性能的前提下，最大限度地降低系统复杂度，从而能够降低系统的运维成本。 不知大家是否发现，上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式，也就是当上游系统提交完消息后便可以去做别的事情，接下来提交、回滚就完全交给消息中间件来完成，并且完全信任消息中间件，认为它一定能正确地完成事务的提交或回滚。然而，消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后，它会阻塞等待，等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢？ 首先，上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道，用户体验尤为重要，因此这种异步通信方式能够极大程度地降低用户等待时间。此外，异步通信相对于同步通信而言，没有了长时间的阻塞等待，因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题，这就由消息中间件的超时询问机制来弥补。 那么，消息中间件和下游系统之间为什么要采用同步通信呢？ 异步能提升系统性能，但随之会增加系统复杂度；而同步虽然降低系统并发度，但实现成本较低。因此，在对并发度要求不是很高的情况下，或者服务器资源较为充裕的情况下，我们可以选择同步来降低系统的复杂度。 我们知道，消息中间件是一个独立于业务系统的第三方中间件，它不和任何业务系统产生直接的耦合，它也不和用户产生直接的关联，它一般部署在独立的服务器集群上，具有良好的可扩展性，所以不必太过于担心它的性能，如果处理速度无法满足我们的要求，可以增加机器来解决。而且，即使消息中间件处理速度有一定的延迟那也是可以接受的，因为前面所介绍的BASE理论就告诉我们了，我们追求的是最终一致性，而非实时一致性，因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3：最大努力通知（定期校对）最大努力通知也被称为定期校对，其实在方案二中已经包含，这里再单独介绍，主要是为了知识体系的完整性。这种方案也需要消息中间件的参与，其过程如下： title 上游系统在完成任务后，向消息中间件同步地发送一条消息，确保消息中间件成功持久化这条消息，然后上游系统可以去做别的事情了；消息中间件收到消息后负责将该消息同步投递给相应的下游系统，并触发下游系统的任务执行；当下游系统处理成功后，向消息中间件反馈确认应答，消息中间件便可以将该条消息删除，从而该事务完成。上面是一个理想化的过程，但在实际场景中，往往会出现如下几种意外情况： 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况，消息中间件具有重试机制，我们可以在消息中间件中设置消息的重试次数和重试时间间隔，对于网络不稳定导致的消息投递失败的情况，往往重试几次后消息便可以成功投递，如果超过了重试的上限仍然投递失败，那么消息中间件不再投递该消息，而是记录在失败消息表中，消息中间件需要提供失败消息的查询接口，下游系统会定期查询失败消息，并将其消费，这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题，往往是因为下游系统出现了严重的错误，此时就需要人工干预。 对于第二种情况，需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表，并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败，那么就会触发回滚，之前的任务处理结果就会被取消。如果这量步都执行成功，那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息，如果发送失败它会返回重试。当然，也要给消息发送者设置重试的上限，一般而言，达到重试上限仍然发送失败，那就意味着消息中间件出现严重的问题，此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件，如果要实现分布式事务的话，就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务，但相比于第二种方案，它达到数据一致性的周期较长，而且还需要在上游系统中实现消息重试发布机制，以确保消息成功发布给消息中间件，这无疑增加了业务系统的开发成本，使得业务系统不够纯粹，并且这些额外的业务逻辑无疑会占用业务系统的硬件资源，从而影响性能。 因此，尽量选择支持事务型消息的消息中间件来实现分布式事务，如RocketMQ。 方案4：TCC（两阶段型、补偿型）TCC即为Try Confirm Cancel，它属于补偿型分布式事务。顾名思义，TCC实现分布式事务一共有三个步骤： Try：尝试待执行的业务 这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源Confirm：执行业务 这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。Cancel：取消执行的业务 若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包，并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水，并将流水的状态设为交易中将用户A的账户中扣除100元（预留业务资源）Try成功之后，便进入Confirm阶段Try过程发生任何异常，均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常，均进入Cancel阶段Confirm过程执行成功，则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中，业务逻辑的执行和事务的处理，是在不同的阶段由不同的部件来完成的：业务逻辑部分访问资源实现数据存储，其处理是由业务系统负责；事务处理部分通过协调资源管理器以实现事务管理，其处理由事务管理器来负责。二者没有太多交互的地方，所以，传统事务管理器的事务处理逻辑，仅需要着眼于事务完成（commit/rollback）阶段，而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的， 其Try/Confirm/Cancel业务在执行时，会访问资源管理器（Resource Manager，下文简称RM）来存取数据。这些存取操作，必须要参与RM本地事务，以使其更改的数据要么都commit，要么都rollback。 这一点不难理解，考虑一下如下场景： title 假设图中的服务B没有基于RM本地事务（以RDBS为例，可通过设置auto-commit为true来模拟），那么一旦[B:Try]操作中途执行失败，TCC事务框架后续决定回滚全局事务时，该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB：假设[B:Try]业务有5个写库操作，[B:Cancel]业务则需要逐个判断这5个操作是否生效，并将生效的操作执行反向操作。 不幸的是，由于[B:Cancel]业务也有n（0<=n<=5）个反向的写库操作，此时一旦[B:Cancel]也中途出错，则后续的[B:Cancel]执行任务更加繁重。因为，相比第一次[B:Cancel]操作，后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n（0<=n<=5）个写库中哪几个已经执行、哪几个还没有执行，这就涉及到了幂等性问题。而对幂等性的保障，又很可能还需要涉及额外的写库操作，该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知，如果不基于RM本地事务，TCC事务框架是无法有效的管理TCC全局事务的。 反之，基于RM本地事务的TCC事务，这种情况则会很容易处理：[B:Try]操作中途执行失败，TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时，在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下，根本无需执行[B:Cancel]操作。 换句话说，基于RM本地事务实现TCC事务框架时，一个TCC型服务的cancel业务要么执行，要么不执行，不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为，服务的幂等性，是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求，二者具有相同的副作用。 在TCC事务模型中，Confirm/Cancel业务可能会被重复调用，其原因很多。比如，全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时，可能会出现如网络中断的故障而使得全局事务不能完成。因此，故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务，这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性。 那么，应该由TCC事务框架来提供幂等性保障？还是应该由业务系统自行来保障幂等性呢？ 个人认为，应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话，那么由业务系统来负责也是可以的；然而，这是一类公共问题，毫无疑问，所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决；而且，考虑一下由业务系统来负责幂等性需要考虑的问题，就会发现，这无疑增大了业务系统的复杂度。

新地址 24题 Starters可以理解为启动器，它包含了一系列可以集成到应用里面的依赖包，你可以一站式集成 Spring 及其他技术，而不需要到处找示例代码和依赖包。如你想使用 Spring JPA 访问数据库，只要加入 spring-boot-starter-data-jpa 启动器依赖就能使用了。Starters包含了许多项目中需要用到的依赖，它们能快速持续的运行，都是一系列得到支持的管理传递性依赖。 23题 Spring Boot 的核心配置文件是application(.yml 或者 .properties) 和 bootstrap(.yml 或者 .properties) 配置文件。boostrap 由父 ApplicationContext 加载，比 applicaton 优先加载，boostrap 里面的属性不能被覆盖。application 配置文件主要用于 Spring Boot 项目的自动化配置。bootstrap 配置文件的应用场景：使用 Spring Cloud Config 配置中心时，这时需要在 bootstrap 配置文件中添加连接到配置中心的配置属性来加载外部配置中心的配置信息；一些固定的不能被覆盖的属性；一些加密/解密的场景。 22题 优点：快速构建项目；对主流开发框架的无配置集成；starters自动依赖与版本控制；大量的自动配置，简化开发，也可修改默认值；无需配置XML，无代码生成，开箱即用；项目可独立运行，无须外部依赖Servlet容器；提供运行时的应用监控；与云计算的天然集成。缺点：集成度较高，使用过程中不太容易了解底层。 21题 Spring Boot的初衷就是为了简化spring的配置，使得开发中集成新功能时更快，简化或减少相关的配置文件。Spring Boot其实是一个整合很多可插拔的组件（框架），内嵌了使用工具（比如内嵌了Tomcat、Jetty等），方便开发人员快速搭建和开发的一个框架。 20题 当程序创建对象、数组等引用类型实体时，系统会在堆内存中为之分配一块内存区，对象就保存在内存区中，不需要显式的去释放一个对象的内存，而是由虚拟机自行执行。在JVM 中，有一个垃圾回收线程，它是低优先级的，在正常情况下是不会执行的，只有在虚拟机空闲或者当前堆内存不足时，才会触发执行，标记那些没有被任何引用的对象，并将它们添加到要回收的集合中，进行回收。 19题 HashMap线程不安全，HashTable线程安全。HashMap允许有一个key为null，多个value为null；而HashTable不允许key和vale为null。继承类不一样，HashMap继承的是AbstractMap，HashTable继承的是Dictionary。初始容量不一样。使用的hashcode不一样。内部遍历方式的实现不一样。 18题 作用：内容可见性和禁止指令重排。内存可见性：某线程对 volatile 变量的修改，对其他线程都是可见的，即获取 volatile 变量的值都是最新的；禁止指令重排：重排序在单线程下一定能保证结果的正确性，但是在多线程环境下，可能发生重排序影响结果，若用volatile修饰共享变量，在编译时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。使用：当一个线程需要立刻读取到另外一个线程修改的变量值的时候，我们就可以使用volatile。区别：volatile是变量修饰符，而synchronized则作用于一段代码或者方法；volatile只是在线程内存和main memory(主内存)间同步某个变量的值，而synchronized通过锁定和解锁某个监视器同步所有变量的值。显然synchronized要比volatile消耗更多资源；synchronized 关键字可以保证变量原子性和可见性，volatile 不能保证原子性。 17题 非公平主要表现在获取锁的行为上，并非是按照申请锁的时间前后给等待线程分配锁的 ，每当锁被释放后 ，任何一个线程都有机会竞争到锁，这样做的目的是为了提高执行性能 ，缺点是可能会产生线程饥饿现象 。 16题 如果线程遇到了 IO 阻塞，无能为力，因为IO是操作系统实现的，Java代码并没有办法直接接触到操作系统。如果线程因为调用 wait()、sleep()、或者 join()方法而导致的阻塞，可以中断线程，并且通过抛出 InterruptedException 来唤醒它。 15题 原子操作就是无法被别的线程打断的操作。要么不执行，要么就执行成功。在Java中可以通过锁和循环CAS的方式来实现原子操作。从JDK 1.5开始提供了java.util.concurrent.atomic包，这个包中的原子操作类提供了一种用法简单、性能高效、线程安全地更新一个变量的方式。 14题 wait()是Object类的方法，所以每一个对象能使用wait()方法。sleep()是Thread类中的静态方法。sleep不会释放锁，但会让出cpu，sleep会在指定的休眠时间后自动唤醒。wait则会释放锁，让出系统资源，并且加入wait set中，wait不会自动唤醒，而需要notify()或者notifyAll()唤醒。sleep和wait都可以被中断，使用sleep需要捕获异常。wait与notify、notifyAll只能在同步代码块中使用，而sleep可以在任何地方使用。 13题 Synchronized 是由 JVM 实现的一种实现互斥同步的一种方式，查看编译后的字节码，会发现被 Synchronized 修饰过的程序块，在编译前后被编译器生成了monitorenter 和 monitorexit 两个字节码指令。在虚拟机执行到 monitorenter 指令时，首先要尝试获取对象的锁：如果这个对象没有锁定，或者当前线程已经拥有了这个对象的锁，把锁的计数器+1；当执行 monitorexit 指令时将锁计数器-1；当计数器为0时，锁就被释放了。如果获取对象失败了，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。Java 中 Synchronize 通过在对象头设置标记，达到了获取锁和释放锁的目的。 12题 Mybatis 通过动态代理，为需要拦截的接口生成代理对象以实现接口方法拦截功能，每当执行这 4 种接口对象的方法时，就会进入拦截方法，具体就是InvocationHandler 的 invoke()方法，只会拦截那些你指定需要拦截的方法。 实现方法：1.编写Intercepror接口的实现类；2.设置插件的签名，告诉mybatis拦截哪个对象的哪个方法；3.最后将插件注册到全局配置文件中。 11题 Mybatis可以映射枚举类，不单可以映射枚举类，Mybatis可以映射任何对象到表的一列上。映射方式为自定义一个TypeHandler，实现TypeHandler的setParameter()和getResult()接口方法。TypeHandler 有两个作用，一是完成从 javaType至jdbcType 的转换，二是完成jdbcType至javaType的转换，体现为 setParameter()和getResult()两个方法，分别代表设置sql问号占位符参数和获取列查询结果。 10题 Mybatis使用RowBounds对象进行分页，也可以直接编写sql实现分页，也可以使用Mybatis的分页插件。分页插件的原理：使用Mybatis提供的插件接口，实现自定义插件，在插件的拦截方法内拦截待执行的sql，然后重写sql，根据dialect方言，添加对应的物理分页语句和物理分页参数。举例：select * from student，拦截 sql 后重写为：select t.* from（select * from student）t limit 0，10。 9题 resultType和resultMap都是表示数据库表与pojo之间的映射规则的。类的名字和数据库相同时，可以直接设置resultType 参数为Pojo类。若不同或者有关联查询，需要设置resultMap将结果名字和Pojo名字进行转换。在项目中我们定义的resultMap多了property和column属性，实际也就是分别配置Pojo类的属性和对应的表字段之间的映射关系，多了这个映射关系以后，方便维护。 8题 之所以说Mybatis半自动化，是因为SQL语句需要用户自定义，SQL的解析、执行等工作由Mybatis执行。区别：Hibernate属于全自动 ORM 映射工具，使用Hibernate查询关联对象或者关联集合对象时，可以根据对象关系模型直接获取，所以它是全自动的。而 Mybatis 在查询关联对象或关联集合对象时，需要手动编写 sql 来完成，所以它是半自动ORM映射工具。 7题 MyBatis 的缓存分为一级缓存和二级缓存。一级缓存是SqlSession级别的缓存，默认就有，在操作数据库时需要构造 sqlSession对象，在对象中有一个(内存区域)数据结构（HashMap）用于存储缓存数据，不同的sqlSession之间的缓存数据区域（HashMap）是互相不影响的。二级缓存是mapper级别的缓存，默认是不打开的，多个SqlSession去操作同一个Mapper的sql语句，多个SqlSession去操作数据库得到数据会存在二级缓存区域，多个SqlSession可以共用二级缓存，二级缓存是跨SqlSession的。 6题 RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。用于方法上是为了细化映射，即根据特定的HTTP请求方法（GET、POST 方法等）、HTTP请求中是否携带特定参数等条件，将请求映射到匹配的方法上。 5题 1、前置通知（before advice）：在目标方法调用之前执行； 2、后置通知（after returning advice）：在目标方法调用之后执行，一旦目标方法产生异常不会执行； 3、最终通知（after(finally) advice）：在目标调用方法之后执行，无论目标方法是否产生异常，都会执行； 4、异常通知（after throwing advice）：在目标方法产生异常时执行； 5、环绕通知（around advice）：在目标方法执行之前和执行之后都会执行，可以写一些非核心的业务逻辑，一般用来替代前置通知和后置通知。 4题 1、通过构造器或工厂方法创建Bean实例；2、为Bean的属性设置值和对其他Bean的引用；3、将Bean实例传递给Bean后置处理器的postProcessBeforeInitialization方法；4、调用Bean的初始方法（init-method）;5、将bean实例传递给bean后置处理器的postProcessAfterInitialization方法；6、bean可以使用了；7、当容器关闭时，调用Bean的销毁方法（destroy-method） 3题 在TransactionDefinition接口中定义了五个表示隔离级别的常量： ISOLATION_DEFAULT：使用后端数据库默认的隔离级别，Mysql默认采用的REPEATABLE_READ隔离级别；Oracle默认采用的READ_COMMITTED隔离级别。 ISOLATION_READ_UNCOMMITTED：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。 ISOLATION_READ_COMMITTED：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生 ISOLATION_REPEATABLE_READ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。 ISOLATION_SERIALIZABLE：最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。 2 题 自动装配提供五种不同的模式供Spring容器用来自动装配beans之间的依赖注入: 1.默认的方式是不进行自动装配，通过手工设置ref 属性来进行装配bean。 2.byName:通过参数名自动装配，之后容器试图匹配、装配和该bean的属性具有相同名字的bean。 3.byType:按照参数的数据类型进行自动装配，之后容器试图匹配和装配和该bean的属性类型一样的bean。如果存在多个相同类型的bean对象，会出错。 4.constructor:使用构造方法完成对象注入，其实也是根据构造方法的参数类型进行对象查找，相当于采用byType的方式。 5.autodetect：如果找到默认的构造函数，则通过 constructor的方式自动装配，否则使用 byType的方式自动装配。在Spring3.0以后的版本此模式已被废弃，已经不再合法了。 1 题 循环依赖只会存在在单例实例中，多例循环依赖直接报错。Spring先用构造器实例化Bean对象，然后将实例化结束的对象放到一个Map中，并且Spring提供获取这个未设置属性的实例化对象的引用方法。当Spring实例化了A类、B类后，紧接着会去设置对象的属性，此时发现A类依赖B类，就会去Map中取出已经存在的单例B类对象，以此类推。因为所持有的都是引用，所以A类一改变B类也会跟着改变。从而解决循环依赖问题。

详细解答可以参考官方帮助文档 阿里云任何版本的企业邮箱服务禁止发送营销邮件，营销邮件标准及相关规范，参见中国互联网协会反垃圾信息中心的管理规范。中国互联网协会电子邮件营销规范(V1.2)来源：反垃圾信息中心一、总则1.1 为规范电子邮件形式的市场营销行为，统一电子邮件营销[注1]的基本要求，为接收和发送营销内容的电子邮件提供依据，保护电子邮件用户的合法权益，根据我国相关法律法规的规定，制定本规范。1.2 本规范适用于电子邮件营销活动的开展和评价。1.3 本规范基于《互联网电子邮件服务管理办法》（中华人民共和国信息产业部令第38号）制定，从事电子邮件营销除应执行本规范外，还应符合《互联网电子邮件服务管理办法》及其他国家现行的有关标准的规定。二、基本规定2.1 中国互联网协会对电子邮件营销服务提供者[注2]实行登记备案管理。电子邮件营销服务提供者应当在开展电子邮件营销活动前将电子邮件发送服务器所使用的IP地址[注11]及相关信息向中国互联网协会反垃圾信息中心登记备案，并遵守以下规定：2.1.1需报备的 IP 地址及相关信息（1）备案单位基本情况，包括备案单位名称、备案单位地址、备案单位性质、备案单位组织机构代码、备案单位营业执照注册号、备案单位经营范围、备案单位注册资金、备案单位网站域名、备案单位法人代表姓名、备案单位联系人姓名、联系人电话、 联系人电子邮件、联系人即时通信方式等。（2）备案单位电子邮件发送服务器IP地址分配使用信息，包括备案单位用于发送电子邮件的IP地址数量、IP地址、IP地址段、IP地址所属单位名称、IP地址对应域名、IP地址对应发送营销电子邮件[注3]性质/类型（事务性邮件和商业性邮件等）；（3）备案单位可自愿报备每次电子邮件营销活动的信息，包括本次营销活动使用IP地址、域名、发件人邮箱地址、电子邮件HELO[注19]信息、收件人数量、发送周期、平均发送速率[注10]、单IP最大发送速率、发送营销电子邮件性质/类型（事务性邮件和商业性邮件等）、营销电子邮件的原信/样信等。（4）其他需要备案的信息。2.1.2 电子邮件营销服务提供者拟变更电子邮件营销服务信息的，应当提前办理变更登记手续。2.1.3 电子邮件营销服务提供者提交的备案信息必须完整、真实、有效且符合我国相关法律法规规定。2.1.4 中国互联网协会反垃圾信息中心负责审核电子邮件营销服务提供者提交的备案资料，对符合要求的备案单位发放电子邮件营销备案资质证书。2.2 电子邮件营销服务提供者应当确保所有与电子邮件服务有关的域名和IP地址注册信息正确、完整和及时更新，并遵守以下规定：2.2.1 发送电子邮件的服务器IP地址必须使用静态IP[注12]地址，并已采取IP反向解析[注13]措施。2.2.2 发送电子邮件的邮箱域名建议与发送电子邮件的服务器IP反向解析的域名信息一致，并已采取SPF解析[注14]。2.2.3 建议使用DKIM[注15]、DMARC[注16]等反垃圾邮件技术，提高与电子邮件发送相关的域名和IP的信誉。2.2.4 关注知名的RBL[注17]组织列表，如果发现与电子邮件发送相关的域名、IP或邮箱地址出现在知名的RBL[注17]组织列表上，应及时采取措施进行申诉和解封。2.2.5 建议发送事务性邮件和商业性邮件的服务器分配不同的IP地址和发送邮箱地址。2.2.6 具有特殊功能的账户，如postmaster@账户（邮件管理员账户）或abuse@账户（投诉账户），必须保证其有效，并由专人负责管理维护。2.3 电子邮件营销服务提供者应当建立可靠有效的订阅[注5]及退订[注9]机制，并遵守以下规定：2.3.1未经电子邮件接收者明确许可，不得向其发送营销电子邮件。获取接收者许可的过程和内容应清楚、明确，且不违背我国的相关法律规定。电子邮件营销服务提供者应公布获取接收者许可的策略，保存接收者同意接收营销邮件的许可记录，以便在需要时向接收者提供相关信息。2.3.2营销电子邮件必须提供给接收者至少包含一种退订的途径和具体操作方法，退订信息应醒目、清晰，退订操作方法应简单，有效。2.3.3确保退订请求可以正常发送并能够被及时自动响应处理。不得强制要求用户提交退订原因或设置退订条件，退订请求发出后应在3个工作日内生效。2.4 电子邮件营销服务提供者应规范的使用和维护其营销用户[注4]的电子邮件地址列表[注6]，并遵守以下规定：2.4.1 电子邮件营销服务提供者对营销用户的个人信息和电子邮件地址负有保密的义务。未经用户同意，不得泄露用户的个人信息和电子邮件地址，法律、行政法规另有规定的除外。2.4.2 电子邮件营销服务提供者应制定安全合理的隐私策略[注8]。营销用户的个人信息资料和电子邮件地址的使用应与收集目的一致，未经用户同意，不得用于收集目的以外的其它用途。2.4.3 必须保证每个电子邮件地址的取得都经过了用户的许可。尽量确保每个电子邮件地址都是真实有效的。2.4.4 应合理处理邮件投递过程中接收电子邮件的服务器返回的错误代码[注7]。对于返回代码表示不存在的电子邮件地址，应及时从发送列表中删除；对于连续出现投递错误的电子邮件地址，建议及时调整投递策略，减少可能导致错误发生的情况。2.5 电子邮件营销服务提供者应使用规范的电子邮件格式与内容，并遵守以下规定：2.5.1 营销电子邮件的内容不得违反我国相关法律法规规定。2.5.2 营销电子邮件格式应符合国际通用规范标准（参见RFC 2822）。邮件中如果包含HTML格式，应遵循由万维网联盟（W3C）公布的w3.org[注18]设计规范。2.5.3 营销电子邮件应标明邮件发送方的身份和真实的可返回的邮件发送地址。邮件的标题和信体要能准确的反映出邮件的内容、真实来源和通信目的。邮件正文应包含发送方的名称、地址、联系电话和电子邮件地址等详细信息。2.5.4 营销电子邮件的主题与内容必须相匹配。邮件内容应与营销用户的订阅内容一致。2.5.5 应采取有效的措施保护未成年人，尽可能的识别未成年的邮件订阅者。营销电子邮件含有不适合未成年人阅读的内容时，应提前核实接收者的年龄，确保接收者达到合法接收和阅读的年龄。发送给未成年人的营销邮件应征得其监护人的许可，内容符合此年龄段人群的知识水准、阅历和心里成熟程度。2.6 电子邮件营销服务提供者应与邮件接收方建立良好的沟通渠道，并参考以下规定：2.6.1 中国互联网协会反垃圾信息中心负责协助电子邮件营销服务提供者与邮件接收组织之间的沟通协调，在邮件传送过程中出现问题时，及时有效的进行沟通，确保尽快使问题得到解决。2.6.2 中国互联网协会反垃圾信息中心应协助电子邮件营销服务提供者与邮件接收组织之间建立信息反馈机制，改进电子邮件营销服务提供者的服务水平。2.6.3 中国互联网协会反垃圾信息中心应对电子邮件营销活动进行监督，对电子邮件营销服务提供者的信誉进行评价。2.6.4 电子邮件营销服务提供者应建立公平、高效、安全、易于使用的邮件投诉系统，在营销电子邮件中为营销用户提供便捷的投诉方式，受理营销用户对营销电子邮件的投诉。对被投诉的营销电子邮件，应立即开展调查，采取合理有效的防范或处理措施，并将有关情况和调查结果及时向各省通信管理局等国家有关机关或者12321网络不良和垃圾信息举报受理中心报告。2.6.5 电子邮件营销服务提供者应按照邮件接收方的要求限制营销电子邮件的发送速率。邮件接收方应将未投递成功的电子邮件服务器错误信息反馈邮件发送方。对信誉良好，行为规范的电子邮件营销服务提供者，邮件接收方可适当放宽营销电子邮件的发送速率。2.7 电子邮件营销服务提供者应积极配合各省通信管理局等国家有关机关和12321网络不良和垃圾信息举报受理中心开展调查工作。2.8 中国互联网协会拥有本规范的解释权和修改权。2.9 本规范自发布之日起施行。 附注:1. 电子邮件营销：指通过电子邮件开展的营销活动。2. 电子邮件营销服务提供者：也是营销电子邮件的发送方，指提供电子邮件营销服务的单位或个人，包括直接开展电子邮件营销活动的单位或个人以及接受委托开展电子邮件营销活动的单位或个人。3. 营销电子邮件：指具有营销功能的电子邮件。根据电子邮件的发送目的，分为事务性邮件和商业性邮件两种类型。3.1 事务性邮件，是指由收件人触发并已允许发件人发送的，以推动、完成或确认相关联流程为主要目的而发送的电子邮件。常见分类包括：（1）账号相关：账号激活、信息验证、账号绑定、密码修改、密码取回等。（2）交易信息：订单通知、付款通知、退款通知、物流通知、交易投诉等。（3）账单信息：对帐单、流水账单、催款通知、账户变更等。（4）其他类型。3.2 商业性邮件，是指任何以推销或者推广某种商品或服务（包括商业性网站的内容）为主要目的而发送的电子邮件。常见分类包括：（1）期刊资讯：更新通知、各类期刊、各类报表等。（2）产品促销：新品推广、季末促销、优惠套餐、折扣优惠、积分优惠等。（3）成员营销：好友邀请、成员关怀、主题活动、用户调研等。（4）其他类型。3.3 事务性邮件如果附带商业性内容，则视为商业性邮件。4. 营销用户：指电子邮件营销活动的对象，即接收营销电子邮件的电子邮箱使用者。5. 订阅：指营销用户预先订制，同意接收订制的营销电子邮件的行为。6. 邮件列表：指已经订阅了某一类营销电子邮件的用户电子邮箱地址列表，该列表是此类营销电子邮件的发送对象。7. 错误代码/硬退回/软退回：指在邮件的SMTP发送过程中，收信方服务器每处理完一条SMTP命令，都会向发信方服务器回传一个返回信息，用于表明对这条SMTP命令的执行结果。如返回信息以4XX（如450等）开头，指接收方临时性拒收该邮件，称软退回；如返回信息以5XX（如550等）开头，指接收方永久性拒收该邮件，称硬退回。以上列举的两类代码，习惯称为错误代码。8. 隐私策略：指电子邮件营销活动所收集的营销用户信息类型，收集方式和收集技术，以及信息的提供对象和使用用途。隐私策略中还应包括用户信息保护的安全措施、责任和实施过程。9. 退订：指营销用户取消订阅营销电子邮件的行为。10. 发送速率：指单位时间内的发送电子邮件的总数量。 常见的时间间隔单位包括：分钟、15分钟、小时、天、周、月等。11. IP地址/IP段IP地址是被用于定位互联网上的电脑一个唯一编号，地址的格式如159.226.1.1。多个IP地址的组合，即称为IP段。邮件发送过程中会?谰軮P地址，来确定邮件发送者和邮件接收者的位置。12. 静态IP地址指长期固定分配给一台计算机使用的IP地址，一般是由网络运营商分配。13. IP反向解析IP反向解析是一项常用的反垃圾邮件技术。常用的DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”。正向查找区域是指域名解析，反向查找区域即是IP反向解析，简称PTR记录，其作用是通过查询IP地址的PTR记录来得到该IP地址指向的域名。PTR记录需要由提供IP地址的网络运营商（ISP）进行配置。14. SPFSPF（Sender Policy Framework）是一种通过IP地址来认证电子邮件发件人身份的技术，是一项非常高效的反垃圾邮件技术。它通过在DNS中发布一条TXT类型的记录，用于登记某个域名所有拥有的合法的发送邮件的所有IP地址。15. DKIMDKIM（DomainKeys Identified Mail）是一种防诈骗邮件的反垃圾邮件技术。DKIM要求邮件发送方在电子邮件的信头插入DKIM-Signature及电子签名信息，而邮件接收方则通过DNS查询得到其公钥然后进行合法性验证。16. DMARCDMARC（Domain-based Message Authentication, Reporting and Conformance）是一种防诈骗邮件的反垃圾邮件技术。DMARC结合SPF和DKIM两项技术，通过检查电子邮件信头的发件人的合法性，将诈骗邮件识别出来。17. RBLRBL（Real-time Blackhole List），即实时黑名单列表，是一些由国际知名的反垃圾邮件组织所提供的恶意发送垃圾邮件的发件人邮箱地址，IP地址，URL地址等黑名单列表的服务。若已被RBL收录，需到相应RBL官方网站上去核实并申请移除。常见的知名RBL组织，如中国互联网协会反垃圾信息中心、spamhaus，Maps，sorbs，uribl，surbl等。18. w3.org规范由万维网联盟(W3C)共同开发与公布的各种web设计规范。当邮件正文以网页的形式组织时，应当参考这些规范。19．HELO电子邮件头中邮件发送者用来标识自己的身份的命令字段。 附录:电子邮件营销常用指标1. 发送量发送的营销电子邮件数量2. 到达量发送的营销电子邮件数量-退回的营销电子邮件数量3. 到达率到达接收方邮箱的营销电子邮件数量/发送的营销电子邮件数量×100%4. 退信率退回的营销电子邮件数量/发送的营销电子邮件数量×100%5. 硬退信率硬退回的营销电子邮件数量/发送的营销电子邮件数量×100%6. 软退信率软退回的营销电子邮件数量/发送的营销电子邮件数量×100%7. 打开率打开营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复打开邮件的情况。8. 点击率点击了营销电子邮件内容中链接的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复点击的情况。9. 点击打开率点击了营销电子邮件内容中链接的接收方数量/打开营销电子邮件的接收方数量×100%，不计算重复点击和重复打开的情况。10. 退订率退订营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%11. 投诉率被投诉的营销电子邮件数量/到达接收方邮箱的营销电子邮件数量×100%12. 信誉度邮件接收方或者第三方机构对营销电子邮件服务信誉和质量的评定结果 参考中华人民共和国信息产业部令第38号 互联网电子邮件服务管理办法中国互联网协会 电子邮件服务指南（V1.1）中国互联网协会 中国互联网协会互联网公共电子邮件服务规范YD-T 1310-2004 互联网广告电子邮件格式要求YD-T 1311-2004 防范互联网垃圾电子邮件技术要求

详细解答可以参考官方帮助文档 阿里云任何版本的企业邮箱服务禁止发送营销邮件，营销邮件标准及相关规范，参见中国互联网协会反垃圾信息中心的管理规范。中国互联网协会电子邮件营销规范(V1.2)来源：反垃圾信息中心一、总则1.1 为规范电子邮件形式的市场营销行为，统一电子邮件营销[注1]的基本要求，为接收和发送营销内容的电子邮件提供依据，保护电子邮件用户的合法权益，根据我国相关法律法规的规定，制定本规范。1.2 本规范适用于电子邮件营销活动的开展和评价。1.3 本规范基于《互联网电子邮件服务管理办法》（中华人民共和国信息产业部令第38号）制定，从事电子邮件营销除应执行本规范外，还应符合《互联网电子邮件服务管理办法》及其他国家现行的有关标准的规定。二、基本规定2.1 中国互联网协会对电子邮件营销服务提供者[注2]实行登记备案管理。电子邮件营销服务提供者应当在开展电子邮件营销活动前将电子邮件发送服务器所使用的IP地址[注11]及相关信息向中国互联网协会反垃圾信息中心登记备案，并遵守以下规定：2.1.1需报备的 IP 地址及相关信息（1）备案单位基本情况，包括备案单位名称、备案单位地址、备案单位性质、备案单位组织机构代码、备案单位营业执照注册号、备案单位经营范围、备案单位注册资金、备案单位网站域名、备案单位法人代表姓名、备案单位联系人姓名、联系人电话、 联系人电子邮件、联系人即时通信方式等。（2）备案单位电子邮件发送服务器IP地址分配使用信息，包括备案单位用于发送电子邮件的IP地址数量、IP地址、IP地址段、IP地址所属单位名称、IP地址对应域名、IP地址对应发送营销电子邮件[注3]性质/类型（事务性邮件和商业性邮件等）；（3）备案单位可自愿报备每次电子邮件营销活动的信息，包括本次营销活动使用IP地址、域名、发件人邮箱地址、电子邮件HELO[注19]信息、收件人数量、发送周期、平均发送速率[注10]、单IP最大发送速率、发送营销电子邮件性质/类型（事务性邮件和商业性邮件等）、营销电子邮件的原信/样信等。（4）其他需要备案的信息。2.1.2 电子邮件营销服务提供者拟变更电子邮件营销服务信息的，应当提前办理变更登记手续。2.1.3 电子邮件营销服务提供者提交的备案信息必须完整、真实、有效且符合我国相关法律法规规定。2.1.4 中国互联网协会反垃圾信息中心负责审核电子邮件营销服务提供者提交的备案资料，对符合要求的备案单位发放电子邮件营销备案资质证书。2.2 电子邮件营销服务提供者应当确保所有与电子邮件服务有关的域名和IP地址注册信息正确、完整和及时更新，并遵守以下规定：2.2.1 发送电子邮件的服务器IP地址必须使用静态IP[注12]地址，并已采取IP反向解析[注13]措施。2.2.2 发送电子邮件的邮箱域名建议与发送电子邮件的服务器IP反向解析的域名信息一致，并已采取SPF解析[注14]。2.2.3 建议使用DKIM[注15]、DMARC[注16]等反垃圾邮件技术，提高与电子邮件发送相关的域名和IP的信誉。2.2.4 关注知名的RBL[注17]组织列表，如果发现与电子邮件发送相关的域名、IP或邮箱地址出现在知名的RBL[注17]组织列表上，应及时采取措施进行申诉和解封。2.2.5 建议发送事务性邮件和商业性邮件的服务器分配不同的IP地址和发送邮箱地址。2.2.6 具有特殊功能的账户，如postmaster@账户（邮件管理员账户）或abuse@账户（投诉账户），必须保证其有效，并由专人负责管理维护。2.3 电子邮件营销服务提供者应当建立可靠有效的订阅[注5]及退订[注9]机制，并遵守以下规定：2.3.1未经电子邮件接收者明确许可，不得向其发送营销电子邮件。获取接收者许可的过程和内容应清楚、明确，且不违背我国的相关法律规定。电子邮件营销服务提供者应公布获取接收者许可的策略，保存接收者同意接收营销邮件的许可记录，以便在需要时向接收者提供相关信息。2.3.2营销电子邮件必须提供给接收者至少包含一种退订的途径和具体操作方法，退订信息应醒目、清晰，退订操作方法应简单，有效。2.3.3确保退订请求可以正常发送并能够被及时自动响应处理。不得强制要求用户提交退订原因或设置退订条件，退订请求发出后应在3个工作日内生效。2.4 电子邮件营销服务提供者应规范的使用和维护其营销用户[注4]的电子邮件地址列表[注6]，并遵守以下规定：2.4.1 电子邮件营销服务提供者对营销用户的个人信息和电子邮件地址负有保密的义务。未经用户同意，不得泄露用户的个人信息和电子邮件地址，法律、行政法规另有规定的除外。2.4.2 电子邮件营销服务提供者应制定安全合理的隐私策略[注8]。营销用户的个人信息资料和电子邮件地址的使用应与收集目的一致，未经用户同意，不得用于收集目的以外的其它用途。2.4.3 必须保证每个电子邮件地址的取得都经过了用户的许可。尽量确保每个电子邮件地址都是真实有效的。2.4.4 应合理处理邮件投递过程中接收电子邮件的服务器返回的错误代码[注7]。对于返回代码表示不存在的电子邮件地址，应及时从发送列表中删除；对于连续出现投递错误的电子邮件地址，建议及时调整投递策略，减少可能导致错误发生的情况。2.5 电子邮件营销服务提供者应使用规范的电子邮件格式与内容，并遵守以下规定：2.5.1 营销电子邮件的内容不得违反我国相关法律法规规定。2.5.2 营销电子邮件格式应符合国际通用规范标准（参见RFC 2822）。邮件中如果包含HTML格式，应遵循由万维网联盟（W3C）公布的w3.org[注18]设计规范。2.5.3 营销电子邮件应标明邮件发送方的身份和真实的可返回的邮件发送地址。邮件的标题和信体要能准确的反映出邮件的内容、真实来源和通信目的。邮件正文应包含发送方的名称、地址、联系电话和电子邮件地址等详细信息。2.5.4 营销电子邮件的主题与内容必须相匹配。邮件内容应与营销用户的订阅内容一致。2.5.5 应采取有效的措施保护未成年人，尽可能的识别未成年的邮件订阅者。营销电子邮件含有不适合未成年人阅读的内容时，应提前核实接收者的年龄，确保接收者达到合法接收和阅读的年龄。发送给未成年人的营销邮件应征得其监护人的许可，内容符合此年龄段人群的知识水准、阅历和心里成熟程度。2.6 电子邮件营销服务提供者应与邮件接收方建立良好的沟通渠道，并参考以下规定：2.6.1 中国互联网协会反垃圾信息中心负责协助电子邮件营销服务提供者与邮件接收组织之间的沟通协调，在邮件传送过程中出现问题时，及时有效的进行沟通，确保尽快使问题得到解决。2.6.2 中国互联网协会反垃圾信息中心应协助电子邮件营销服务提供者与邮件接收组织之间建立信息反馈机制，改进电子邮件营销服务提供者的服务水平。2.6.3 中国互联网协会反垃圾信息中心应对电子邮件营销活动进行监督，对电子邮件营销服务提供者的信誉进行评价。2.6.4 电子邮件营销服务提供者应建立公平、高效、安全、易于使用的邮件投诉系统，在营销电子邮件中为营销用户提供便捷的投诉方式，受理营销用户对营销电子邮件的投诉。对被投诉的营销电子邮件，应立即开展调查，采取合理有效的防范或处理措施，并将有关情况和调查结果及时向各省通信管理局等国家有关机关或者12321网络不良和垃圾信息举报受理中心报告。2.6.5 电子邮件营销服务提供者应按照邮件接收方的要求限制营销电子邮件的发送速率。邮件接收方应将未投递成功的电子邮件服务器错误信息反馈邮件发送方。对信誉良好，行为规范的电子邮件营销服务提供者，邮件接收方可适当放宽营销电子邮件的发送速率。2.7 电子邮件营销服务提供者应积极配合各省通信管理局等国家有关机关和12321网络不良和垃圾信息举报受理中心开展调查工作。2.8 中国互联网协会拥有本规范的解释权和修改权。2.9 本规范自发布之日起施行。 附注:1. 电子邮件营销：指通过电子邮件开展的营销活动。2. 电子邮件营销服务提供者：也是营销电子邮件的发送方，指提供电子邮件营销服务的单位或个人，包括直接开展电子邮件营销活动的单位或个人以及接受委托开展电子邮件营销活动的单位或个人。3. 营销电子邮件：指具有营销功能的电子邮件。根据电子邮件的发送目的，分为事务性邮件和商业性邮件两种类型。3.1 事务性邮件，是指由收件人触发并已允许发件人发送的，以推动、完成或确认相关联流程为主要目的而发送的电子邮件。常见分类包括：（1）账号相关：账号激活、信息验证、账号绑定、密码修改、密码取回等。（2）交易信息：订单通知、付款通知、退款通知、物流通知、交易投诉等。（3）账单信息：对帐单、流水账单、催款通知、账户变更等。（4）其他类型。3.2 商业性邮件，是指任何以推销或者推广某种商品或服务（包括商业性网站的内容）为主要目的而发送的电子邮件。常见分类包括：（1）期刊资讯：更新通知、各类期刊、各类报表等。（2）产品促销：新品推广、季末促销、优惠套餐、折扣优惠、积分优惠等。（3）成员营销：好友邀请、成员关怀、主题活动、用户调研等。（4）其他类型。3.3 事务性邮件如果附带商业性内容，则视为商业性邮件。4. 营销用户：指电子邮件营销活动的对象，即接收营销电子邮件的电子邮箱使用者。5. 订阅：指营销用户预先订制，同意接收订制的营销电子邮件的行为。6. 邮件列表：指已经订阅了某一类营销电子邮件的用户电子邮箱地址列表，该列表是此类营销电子邮件的发送对象。7. 错误代码/硬退回/软退回：指在邮件的SMTP发送过程中，收信方服务器每处理完一条SMTP命令，都会向发信方服务器回传一个返回信息，用于表明对这条SMTP命令的执行结果。如返回信息以4XX（如450等）开头，指接收方临时性拒收该邮件，称软退回；如返回信息以5XX（如550等）开头，指接收方永久性拒收该邮件，称硬退回。以上列举的两类代码，习惯称为错误代码。8. 隐私策略：指电子邮件营销活动所收集的营销用户信息类型，收集方式和收集技术，以及信息的提供对象和使用用途。隐私策略中还应包括用户信息保护的安全措施、责任和实施过程。9. 退订：指营销用户取消订阅营销电子邮件的行为。10. 发送速率：指单位时间内的发送电子邮件的总数量。 常见的时间间隔单位包括：分钟、15分钟、小时、天、周、月等。11. IP地址/IP段IP地址是被用于定位互联网上的电脑一个唯一编号，地址的格式如159.226.1.1。多个IP地址的组合，即称为IP段。邮件发送过程中会?谰軮P地址，来确定邮件发送者和邮件接收者的位置。12. 静态IP地址指长期固定分配给一台计算机使用的IP地址，一般是由网络运营商分配。13. IP反向解析IP反向解析是一项常用的反垃圾邮件技术。常用的DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”。正向查找区域是指域名解析，反向查找区域即是IP反向解析，简称PTR记录，其作用是通过查询IP地址的PTR记录来得到该IP地址指向的域名。PTR记录需要由提供IP地址的网络运营商（ISP）进行配置。14. SPFSPF（Sender Policy Framework）是一种通过IP地址来认证电子邮件发件人身份的技术，是一项非常高效的反垃圾邮件技术。它通过在DNS中发布一条TXT类型的记录，用于登记某个域名所有拥有的合法的发送邮件的所有IP地址。15. DKIMDKIM（DomainKeys Identified Mail）是一种防诈骗邮件的反垃圾邮件技术。DKIM要求邮件发送方在电子邮件的信头插入DKIM-Signature及电子签名信息，而邮件接收方则通过DNS查询得到其公钥然后进行合法性验证。16. DMARCDMARC（Domain-based Message Authentication, Reporting and Conformance）是一种防诈骗邮件的反垃圾邮件技术。DMARC结合SPF和DKIM两项技术，通过检查电子邮件信头的发件人的合法性，将诈骗邮件识别出来。17. RBLRBL（Real-time Blackhole List），即实时黑名单列表，是一些由国际知名的反垃圾邮件组织所提供的恶意发送垃圾邮件的发件人邮箱地址，IP地址，URL地址等黑名单列表的服务。若已被RBL收录，需到相应RBL官方网站上去核实并申请移除。常见的知名RBL组织，如中国互联网协会反垃圾信息中心、spamhaus，Maps，sorbs，uribl，surbl等。18. w3.org规范由万维网联盟(W3C)共同开发与公布的各种web设计规范。当邮件正文以网页的形式组织时，应当参考这些规范。19．HELO电子邮件头中邮件发送者用来标识自己的身份的命令字段。 附录:电子邮件营销常用指标1. 发送量发送的营销电子邮件数量2. 到达量发送的营销电子邮件数量-退回的营销电子邮件数量3. 到达率到达接收方邮箱的营销电子邮件数量/发送的营销电子邮件数量×100%4. 退信率退回的营销电子邮件数量/发送的营销电子邮件数量×100%5. 硬退信率硬退回的营销电子邮件数量/发送的营销电子邮件数量×100%6. 软退信率软退回的营销电子邮件数量/发送的营销电子邮件数量×100%7. 打开率打开营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复打开邮件的情况。8. 点击率点击了营销电子邮件内容中链接的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复点击的情况。9. 点击打开率点击了营销电子邮件内容中链接的接收方数量/打开营销电子邮件的接收方数量×100%，不计算重复点击和重复打开的情况。10. 退订率退订营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%11. 投诉率被投诉的营销电子邮件数量/到达接收方邮箱的营销电子邮件数量×100%12. 信誉度邮件接收方或者第三方机构对营销电子邮件服务信誉和质量的评定结果 参考中华人民共和国信息产业部令第38号 互联网电子邮件服务管理办法中国互联网协会 电子邮件服务指南（V1.1）中国互联网协会 中国互联网协会互联网公共电子邮件服务规范YD-T 1310-2004 互联网广告电子邮件格式要求YD-T 1311-2004 防范互联网垃圾电子邮件技术要求

详细解答可以参考官方帮助文档 阿里云任何版本的企业邮箱服务禁止发送营销邮件，营销邮件标准及相关规范，参见中国互联网协会反垃圾信息中心的管理规范。中国互联网协会电子邮件营销规范(V1.2)来源：反垃圾信息中心一、总则1.1 为规范电子邮件形式的市场营销行为，统一电子邮件营销[注1]的基本要求，为接收和发送营销内容的电子邮件提供依据，保护电子邮件用户的合法权益，根据我国相关法律法规的规定，制定本规范。1.2 本规范适用于电子邮件营销活动的开展和评价。1.3 本规范基于《互联网电子邮件服务管理办法》（中华人民共和国信息产业部令第38号）制定，从事电子邮件营销除应执行本规范外，还应符合《互联网电子邮件服务管理办法》及其他国家现行的有关标准的规定。二、基本规定2.1 中国互联网协会对电子邮件营销服务提供者[注2]实行登记备案管理。电子邮件营销服务提供者应当在开展电子邮件营销活动前将电子邮件发送服务器所使用的IP地址[注11]及相关信息向中国互联网协会反垃圾信息中心登记备案，并遵守以下规定：2.1.1需报备的 IP 地址及相关信息（1）备案单位基本情况，包括备案单位名称、备案单位地址、备案单位性质、备案单位组织机构代码、备案单位营业执照注册号、备案单位经营范围、备案单位注册资金、备案单位网站域名、备案单位法人代表姓名、备案单位联系人姓名、联系人电话、 联系人电子邮件、联系人即时通信方式等。（2）备案单位电子邮件发送服务器IP地址分配使用信息，包括备案单位用于发送电子邮件的IP地址数量、IP地址、IP地址段、IP地址所属单位名称、IP地址对应域名、IP地址对应发送营销电子邮件[注3]性质/类型（事务性邮件和商业性邮件等）；（3）备案单位可自愿报备每次电子邮件营销活动的信息，包括本次营销活动使用IP地址、域名、发件人邮箱地址、电子邮件HELO[注19]信息、收件人数量、发送周期、平均发送速率[注10]、单IP最大发送速率、发送营销电子邮件性质/类型（事务性邮件和商业性邮件等）、营销电子邮件的原信/样信等。（4）其他需要备案的信息。2.1.2 电子邮件营销服务提供者拟变更电子邮件营销服务信息的，应当提前办理变更登记手续。2.1.3 电子邮件营销服务提供者提交的备案信息必须完整、真实、有效且符合我国相关法律法规规定。2.1.4 中国互联网协会反垃圾信息中心负责审核电子邮件营销服务提供者提交的备案资料，对符合要求的备案单位发放电子邮件营销备案资质证书。2.2 电子邮件营销服务提供者应当确保所有与电子邮件服务有关的域名和IP地址注册信息正确、完整和及时更新，并遵守以下规定：2.2.1 发送电子邮件的服务器IP地址必须使用静态IP[注12]地址，并已采取IP反向解析[注13]措施。2.2.2 发送电子邮件的邮箱域名建议与发送电子邮件的服务器IP反向解析的域名信息一致，并已采取SPF解析[注14]。2.2.3 建议使用DKIM[注15]、DMARC[注16]等反垃圾邮件技术，提高与电子邮件发送相关的域名和IP的信誉。2.2.4 关注知名的RBL[注17]组织列表，如果发现与电子邮件发送相关的域名、IP或邮箱地址出现在知名的RBL[注17]组织列表上，应及时采取措施进行申诉和解封。2.2.5 建议发送事务性邮件和商业性邮件的服务器分配不同的IP地址和发送邮箱地址。2.2.6 具有特殊功能的账户，如postmaster@账户（邮件管理员账户）或abuse@账户（投诉账户），必须保证其有效，并由专人负责管理维护。2.3 电子邮件营销服务提供者应当建立可靠有效的订阅[注5]及退订[注9]机制，并遵守以下规定：2.3.1未经电子邮件接收者明确许可，不得向其发送营销电子邮件。获取接收者许可的过程和内容应清楚、明确，且不违背我国的相关法律规定。电子邮件营销服务提供者应公布获取接收者许可的策略，保存接收者同意接收营销邮件的许可记录，以便在需要时向接收者提供相关信息。2.3.2营销电子邮件必须提供给接收者至少包含一种退订的途径和具体操作方法，退订信息应醒目、清晰，退订操作方法应简单，有效。2.3.3确保退订请求可以正常发送并能够被及时自动响应处理。不得强制要求用户提交退订原因或设置退订条件，退订请求发出后应在3个工作日内生效。2.4 电子邮件营销服务提供者应规范的使用和维护其营销用户[注4]的电子邮件地址列表[注6]，并遵守以下规定：2.4.1 电子邮件营销服务提供者对营销用户的个人信息和电子邮件地址负有保密的义务。未经用户同意，不得泄露用户的个人信息和电子邮件地址，法律、行政法规另有规定的除外。2.4.2 电子邮件营销服务提供者应制定安全合理的隐私策略[注8]。营销用户的个人信息资料和电子邮件地址的使用应与收集目的一致，未经用户同意，不得用于收集目的以外的其它用途。2.4.3 必须保证每个电子邮件地址的取得都经过了用户的许可。尽量确保每个电子邮件地址都是真实有效的。2.4.4 应合理处理邮件投递过程中接收电子邮件的服务器返回的错误代码[注7]。对于返回代码表示不存在的电子邮件地址，应及时从发送列表中删除；对于连续出现投递错误的电子邮件地址，建议及时调整投递策略，减少可能导致错误发生的情况。2.5 电子邮件营销服务提供者应使用规范的电子邮件格式与内容，并遵守以下规定：2.5.1 营销电子邮件的内容不得违反我国相关法律法规规定。2.5.2 营销电子邮件格式应符合国际通用规范标准（参见RFC 2822）。邮件中如果包含HTML格式，应遵循由万维网联盟（W3C）公布的w3.org[注18]设计规范。2.5.3 营销电子邮件应标明邮件发送方的身份和真实的可返回的邮件发送地址。邮件的标题和信体要能准确的反映出邮件的内容、真实来源和通信目的。邮件正文应包含发送方的名称、地址、联系电话和电子邮件地址等详细信息。2.5.4 营销电子邮件的主题与内容必须相匹配。邮件内容应与营销用户的订阅内容一致。2.5.5 应采取有效的措施保护未成年人，尽可能的识别未成年的邮件订阅者。营销电子邮件含有不适合未成年人阅读的内容时，应提前核实接收者的年龄，确保接收者达到合法接收和阅读的年龄。发送给未成年人的营销邮件应征得其监护人的许可，内容符合此年龄段人群的知识水准、阅历和心里成熟程度。2.6 电子邮件营销服务提供者应与邮件接收方建立良好的沟通渠道，并参考以下规定：2.6.1 中国互联网协会反垃圾信息中心负责协助电子邮件营销服务提供者与邮件接收组织之间的沟通协调，在邮件传送过程中出现问题时，及时有效的进行沟通，确保尽快使问题得到解决。2.6.2 中国互联网协会反垃圾信息中心应协助电子邮件营销服务提供者与邮件接收组织之间建立信息反馈机制，改进电子邮件营销服务提供者的服务水平。2.6.3 中国互联网协会反垃圾信息中心应对电子邮件营销活动进行监督，对电子邮件营销服务提供者的信誉进行评价。2.6.4 电子邮件营销服务提供者应建立公平、高效、安全、易于使用的邮件投诉系统，在营销电子邮件中为营销用户提供便捷的投诉方式，受理营销用户对营销电子邮件的投诉。对被投诉的营销电子邮件，应立即开展调查，采取合理有效的防范或处理措施，并将有关情况和调查结果及时向各省通信管理局等国家有关机关或者12321网络不良和垃圾信息举报受理中心报告。2.6.5 电子邮件营销服务提供者应按照邮件接收方的要求限制营销电子邮件的发送速率。邮件接收方应将未投递成功的电子邮件服务器错误信息反馈邮件发送方。对信誉良好，行为规范的电子邮件营销服务提供者，邮件接收方可适当放宽营销电子邮件的发送速率。2.7 电子邮件营销服务提供者应积极配合各省通信管理局等国家有关机关和12321网络不良和垃圾信息举报受理中心开展调查工作。2.8 中国互联网协会拥有本规范的解释权和修改权。2.9 本规范自发布之日起施行。 附注:1. 电子邮件营销：指通过电子邮件开展的营销活动。2. 电子邮件营销服务提供者：也是营销电子邮件的发送方，指提供电子邮件营销服务的单位或个人，包括直接开展电子邮件营销活动的单位或个人以及接受委托开展电子邮件营销活动的单位或个人。3. 营销电子邮件：指具有营销功能的电子邮件。根据电子邮件的发送目的，分为事务性邮件和商业性邮件两种类型。3.1 事务性邮件，是指由收件人触发并已允许发件人发送的，以推动、完成或确认相关联流程为主要目的而发送的电子邮件。常见分类包括：（1）账号相关：账号激活、信息验证、账号绑定、密码修改、密码取回等。（2）交易信息：订单通知、付款通知、退款通知、物流通知、交易投诉等。（3）账单信息：对帐单、流水账单、催款通知、账户变更等。（4）其他类型。3.2 商业性邮件，是指任何以推销或者推广某种商品或服务（包括商业性网站的内容）为主要目的而发送的电子邮件。常见分类包括：（1）期刊资讯：更新通知、各类期刊、各类报表等。（2）产品促销：新品推广、季末促销、优惠套餐、折扣优惠、积分优惠等。（3）成员营销：好友邀请、成员关怀、主题活动、用户调研等。（4）其他类型。3.3 事务性邮件如果附带商业性内容，则视为商业性邮件。4. 营销用户：指电子邮件营销活动的对象，即接收营销电子邮件的电子邮箱使用者。5. 订阅：指营销用户预先订制，同意接收订制的营销电子邮件的行为。6. 邮件列表：指已经订阅了某一类营销电子邮件的用户电子邮箱地址列表，该列表是此类营销电子邮件的发送对象。7. 错误代码/硬退回/软退回：指在邮件的SMTP发送过程中，收信方服务器每处理完一条SMTP命令，都会向发信方服务器回传一个返回信息，用于表明对这条SMTP命令的执行结果。如返回信息以4XX（如450等）开头，指接收方临时性拒收该邮件，称软退回；如返回信息以5XX（如550等）开头，指接收方永久性拒收该邮件，称硬退回。以上列举的两类代码，习惯称为错误代码。8. 隐私策略：指电子邮件营销活动所收集的营销用户信息类型，收集方式和收集技术，以及信息的提供对象和使用用途。隐私策略中还应包括用户信息保护的安全措施、责任和实施过程。9. 退订：指营销用户取消订阅营销电子邮件的行为。10. 发送速率：指单位时间内的发送电子邮件的总数量。 常见的时间间隔单位包括：分钟、15分钟、小时、天、周、月等。11. IP地址/IP段IP地址是被用于定位互联网上的电脑一个唯一编号，地址的格式如159.226.1.1。多个IP地址的组合，即称为IP段。邮件发送过程中会?谰軮P地址，来确定邮件发送者和邮件接收者的位置。12. 静态IP地址指长期固定分配给一台计算机使用的IP地址，一般是由网络运营商分配。13. IP反向解析IP反向解析是一项常用的反垃圾邮件技术。常用的DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”。正向查找区域是指域名解析，反向查找区域即是IP反向解析，简称PTR记录，其作用是通过查询IP地址的PTR记录来得到该IP地址指向的域名。PTR记录需要由提供IP地址的网络运营商（ISP）进行配置。14. SPFSPF（Sender Policy Framework）是一种通过IP地址来认证电子邮件发件人身份的技术，是一项非常高效的反垃圾邮件技术。它通过在DNS中发布一条TXT类型的记录，用于登记某个域名所有拥有的合法的发送邮件的所有IP地址。15. DKIMDKIM（DomainKeys Identified Mail）是一种防诈骗邮件的反垃圾邮件技术。DKIM要求邮件发送方在电子邮件的信头插入DKIM-Signature及电子签名信息，而邮件接收方则通过DNS查询得到其公钥然后进行合法性验证。16. DMARCDMARC（Domain-based Message Authentication, Reporting and Conformance）是一种防诈骗邮件的反垃圾邮件技术。DMARC结合SPF和DKIM两项技术，通过检查电子邮件信头的发件人的合法性，将诈骗邮件识别出来。17. RBLRBL（Real-time Blackhole List），即实时黑名单列表，是一些由国际知名的反垃圾邮件组织所提供的恶意发送垃圾邮件的发件人邮箱地址，IP地址，URL地址等黑名单列表的服务。若已被RBL收录，需到相应RBL官方网站上去核实并申请移除。常见的知名RBL组织，如中国互联网协会反垃圾信息中心、spamhaus，Maps，sorbs，uribl，surbl等。18. w3.org规范由万维网联盟(W3C)共同开发与公布的各种web设计规范。当邮件正文以网页的形式组织时，应当参考这些规范。19．HELO电子邮件头中邮件发送者用来标识自己的身份的命令字段。 附录:电子邮件营销常用指标1. 发送量发送的营销电子邮件数量2. 到达量发送的营销电子邮件数量-退回的营销电子邮件数量3. 到达率到达接收方邮箱的营销电子邮件数量/发送的营销电子邮件数量×100%4. 退信率退回的营销电子邮件数量/发送的营销电子邮件数量×100%5. 硬退信率硬退回的营销电子邮件数量/发送的营销电子邮件数量×100%6. 软退信率软退回的营销电子邮件数量/发送的营销电子邮件数量×100%7. 打开率打开营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复打开邮件的情况。8. 点击率点击了营销电子邮件内容中链接的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复点击的情况。9. 点击打开率点击了营销电子邮件内容中链接的接收方数量/打开营销电子邮件的接收方数量×100%，不计算重复点击和重复打开的情况。10. 退订率退订营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%11. 投诉率被投诉的营销电子邮件数量/到达接收方邮箱的营销电子邮件数量×100%12. 信誉度邮件接收方或者第三方机构对营销电子邮件服务信誉和质量的评定结果 参考中华人民共和国信息产业部令第38号 互联网电子邮件服务管理办法中国互联网协会 电子邮件服务指南（V1.1）中国互联网协会 中国互联网协会互联网公共电子邮件服务规范YD-T 1310-2004 互联网广告电子邮件格式要求YD-T 1311-2004 防范互联网垃圾电子邮件技术要求

详细解答可以参考官方帮助文档 阿里云任何版本的企业邮箱服务禁止发送营销邮件，营销邮件标准及相关规范，参见中国互联网协会反垃圾信息中心的管理规范。中国互联网协会电子邮件营销规范(V1.2)来源：反垃圾信息中心一、总则1.1 为规范电子邮件形式的市场营销行为，统一电子邮件营销[注1]的基本要求，为接收和发送营销内容的电子邮件提供依据，保护电子邮件用户的合法权益，根据我国相关法律法规的规定，制定本规范。1.2 本规范适用于电子邮件营销活动的开展和评价。1.3 本规范基于《互联网电子邮件服务管理办法》（中华人民共和国信息产业部令第38号）制定，从事电子邮件营销除应执行本规范外，还应符合《互联网电子邮件服务管理办法》及其他国家现行的有关标准的规定。二、基本规定2.1 中国互联网协会对电子邮件营销服务提供者[注2]实行登记备案管理。电子邮件营销服务提供者应当在开展电子邮件营销活动前将电子邮件发送服务器所使用的IP地址[注11]及相关信息向中国互联网协会反垃圾信息中心登记备案，并遵守以下规定：2.1.1需报备的 IP 地址及相关信息（1）备案单位基本情况，包括备案单位名称、备案单位地址、备案单位性质、备案单位组织机构代码、备案单位营业执照注册号、备案单位经营范围、备案单位注册资金、备案单位网站域名、备案单位法人代表姓名、备案单位联系人姓名、联系人电话、 联系人电子邮件、联系人即时通信方式等。（2）备案单位电子邮件发送服务器IP地址分配使用信息，包括备案单位用于发送电子邮件的IP地址数量、IP地址、IP地址段、IP地址所属单位名称、IP地址对应域名、IP地址对应发送营销电子邮件[注3]性质/类型（事务性邮件和商业性邮件等）；（3）备案单位可自愿报备每次电子邮件营销活动的信息，包括本次营销活动使用IP地址、域名、发件人邮箱地址、电子邮件HELO[注19]信息、收件人数量、发送周期、平均发送速率[注10]、单IP最大发送速率、发送营销电子邮件性质/类型（事务性邮件和商业性邮件等）、营销电子邮件的原信/样信等。（4）其他需要备案的信息。2.1.2 电子邮件营销服务提供者拟变更电子邮件营销服务信息的，应当提前办理变更登记手续。2.1.3 电子邮件营销服务提供者提交的备案信息必须完整、真实、有效且符合我国相关法律法规规定。2.1.4 中国互联网协会反垃圾信息中心负责审核电子邮件营销服务提供者提交的备案资料，对符合要求的备案单位发放电子邮件营销备案资质证书。2.2 电子邮件营销服务提供者应当确保所有与电子邮件服务有关的域名和IP地址注册信息正确、完整和及时更新，并遵守以下规定：2.2.1 发送电子邮件的服务器IP地址必须使用静态IP[注12]地址，并已采取IP反向解析[注13]措施。2.2.2 发送电子邮件的邮箱域名建议与发送电子邮件的服务器IP反向解析的域名信息一致，并已采取SPF解析[注14]。2.2.3 建议使用DKIM[注15]、DMARC[注16]等反垃圾邮件技术，提高与电子邮件发送相关的域名和IP的信誉。2.2.4 关注知名的RBL[注17]组织列表，如果发现与电子邮件发送相关的域名、IP或邮箱地址出现在知名的RBL[注17]组织列表上，应及时采取措施进行申诉和解封。2.2.5 建议发送事务性邮件和商业性邮件的服务器分配不同的IP地址和发送邮箱地址。2.2.6 具有特殊功能的账户，如postmaster@账户（邮件管理员账户）或abuse@账户（投诉账户），必须保证其有效，并由专人负责管理维护。2.3 电子邮件营销服务提供者应当建立可靠有效的订阅[注5]及退订[注9]机制，并遵守以下规定：2.3.1未经电子邮件接收者明确许可，不得向其发送营销电子邮件。获取接收者许可的过程和内容应清楚、明确，且不违背我国的相关法律规定。电子邮件营销服务提供者应公布获取接收者许可的策略，保存接收者同意接收营销邮件的许可记录，以便在需要时向接收者提供相关信息。2.3.2营销电子邮件必须提供给接收者至少包含一种退订的途径和具体操作方法，退订信息应醒目、清晰，退订操作方法应简单，有效。2.3.3确保退订请求可以正常发送并能够被及时自动响应处理。不得强制要求用户提交退订原因或设置退订条件，退订请求发出后应在3个工作日内生效。2.4 电子邮件营销服务提供者应规范的使用和维护其营销用户[注4]的电子邮件地址列表[注6]，并遵守以下规定：2.4.1 电子邮件营销服务提供者对营销用户的个人信息和电子邮件地址负有保密的义务。未经用户同意，不得泄露用户的个人信息和电子邮件地址，法律、行政法规另有规定的除外。2.4.2 电子邮件营销服务提供者应制定安全合理的隐私策略[注8]。营销用户的个人信息资料和电子邮件地址的使用应与收集目的一致，未经用户同意，不得用于收集目的以外的其它用途。2.4.3 必须保证每个电子邮件地址的取得都经过了用户的许可。尽量确保每个电子邮件地址都是真实有效的。2.4.4 应合理处理邮件投递过程中接收电子邮件的服务器返回的错误代码[注7]。对于返回代码表示不存在的电子邮件地址，应及时从发送列表中删除；对于连续出现投递错误的电子邮件地址，建议及时调整投递策略，减少可能导致错误发生的情况。2.5 电子邮件营销服务提供者应使用规范的电子邮件格式与内容，并遵守以下规定：2.5.1 营销电子邮件的内容不得违反我国相关法律法规规定。2.5.2 营销电子邮件格式应符合国际通用规范标准（参见RFC 2822）。邮件中如果包含HTML格式，应遵循由万维网联盟（W3C）公布的w3.org[注18]设计规范。2.5.3 营销电子邮件应标明邮件发送方的身份和真实的可返回的邮件发送地址。邮件的标题和信体要能准确的反映出邮件的内容、真实来源和通信目的。邮件正文应包含发送方的名称、地址、联系电话和电子邮件地址等详细信息。2.5.4 营销电子邮件的主题与内容必须相匹配。邮件内容应与营销用户的订阅内容一致。2.5.5 应采取有效的措施保护未成年人，尽可能的识别未成年的邮件订阅者。营销电子邮件含有不适合未成年人阅读的内容时，应提前核实接收者的年龄，确保接收者达到合法接收和阅读的年龄。发送给未成年人的营销邮件应征得其监护人的许可，内容符合此年龄段人群的知识水准、阅历和心里成熟程度。2.6 电子邮件营销服务提供者应与邮件接收方建立良好的沟通渠道，并参考以下规定：2.6.1 中国互联网协会反垃圾信息中心负责协助电子邮件营销服务提供者与邮件接收组织之间的沟通协调，在邮件传送过程中出现问题时，及时有效的进行沟通，确保尽快使问题得到解决。2.6.2 中国互联网协会反垃圾信息中心应协助电子邮件营销服务提供者与邮件接收组织之间建立信息反馈机制，改进电子邮件营销服务提供者的服务水平。2.6.3 中国互联网协会反垃圾信息中心应对电子邮件营销活动进行监督，对电子邮件营销服务提供者的信誉进行评价。2.6.4 电子邮件营销服务提供者应建立公平、高效、安全、易于使用的邮件投诉系统，在营销电子邮件中为营销用户提供便捷的投诉方式，受理营销用户对营销电子邮件的投诉。对被投诉的营销电子邮件，应立即开展调查，采取合理有效的防范或处理措施，并将有关情况和调查结果及时向各省通信管理局等国家有关机关或者12321网络不良和垃圾信息举报受理中心报告。2.6.5 电子邮件营销服务提供者应按照邮件接收方的要求限制营销电子邮件的发送速率。邮件接收方应将未投递成功的电子邮件服务器错误信息反馈邮件发送方。对信誉良好，行为规范的电子邮件营销服务提供者，邮件接收方可适当放宽营销电子邮件的发送速率。2.7 电子邮件营销服务提供者应积极配合各省通信管理局等国家有关机关和12321网络不良和垃圾信息举报受理中心开展调查工作。2.8 中国互联网协会拥有本规范的解释权和修改权。2.9 本规范自发布之日起施行。 附注:1. 电子邮件营销：指通过电子邮件开展的营销活动。2. 电子邮件营销服务提供者：也是营销电子邮件的发送方，指提供电子邮件营销服务的单位或个人，包括直接开展电子邮件营销活动的单位或个人以及接受委托开展电子邮件营销活动的单位或个人。3. 营销电子邮件：指具有营销功能的电子邮件。根据电子邮件的发送目的，分为事务性邮件和商业性邮件两种类型。3.1 事务性邮件，是指由收件人触发并已允许发件人发送的，以推动、完成或确认相关联流程为主要目的而发送的电子邮件。常见分类包括：（1）账号相关：账号激活、信息验证、账号绑定、密码修改、密码取回等。（2）交易信息：订单通知、付款通知、退款通知、物流通知、交易投诉等。（3）账单信息：对帐单、流水账单、催款通知、账户变更等。（4）其他类型。3.2 商业性邮件，是指任何以推销或者推广某种商品或服务（包括商业性网站的内容）为主要目的而发送的电子邮件。常见分类包括：（1）期刊资讯：更新通知、各类期刊、各类报表等。（2）产品促销：新品推广、季末促销、优惠套餐、折扣优惠、积分优惠等。（3）成员营销：好友邀请、成员关怀、主题活动、用户调研等。（4）其他类型。3.3 事务性邮件如果附带商业性内容，则视为商业性邮件。4. 营销用户：指电子邮件营销活动的对象，即接收营销电子邮件的电子邮箱使用者。5. 订阅：指营销用户预先订制，同意接收订制的营销电子邮件的行为。6. 邮件列表：指已经订阅了某一类营销电子邮件的用户电子邮箱地址列表，该列表是此类营销电子邮件的发送对象。7. 错误代码/硬退回/软退回：指在邮件的SMTP发送过程中，收信方服务器每处理完一条SMTP命令，都会向发信方服务器回传一个返回信息，用于表明对这条SMTP命令的执行结果。如返回信息以4XX（如450等）开头，指接收方临时性拒收该邮件，称软退回；如返回信息以5XX（如550等）开头，指接收方永久性拒收该邮件，称硬退回。以上列举的两类代码，习惯称为错误代码。8. 隐私策略：指电子邮件营销活动所收集的营销用户信息类型，收集方式和收集技术，以及信息的提供对象和使用用途。隐私策略中还应包括用户信息保护的安全措施、责任和实施过程。9. 退订：指营销用户取消订阅营销电子邮件的行为。10. 发送速率：指单位时间内的发送电子邮件的总数量。 常见的时间间隔单位包括：分钟、15分钟、小时、天、周、月等。11. IP地址/IP段IP地址是被用于定位互联网上的电脑一个唯一编号，地址的格式如159.226.1.1。多个IP地址的组合，即称为IP段。邮件发送过程中会?谰軮P地址，来确定邮件发送者和邮件接收者的位置。12. 静态IP地址指长期固定分配给一台计算机使用的IP地址，一般是由网络运营商分配。13. IP反向解析IP反向解析是一项常用的反垃圾邮件技术。常用的DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”。正向查找区域是指域名解析，反向查找区域即是IP反向解析，简称PTR记录，其作用是通过查询IP地址的PTR记录来得到该IP地址指向的域名。PTR记录需要由提供IP地址的网络运营商（ISP）进行配置。14. SPFSPF（Sender Policy Framework）是一种通过IP地址来认证电子邮件发件人身份的技术，是一项非常高效的反垃圾邮件技术。它通过在DNS中发布一条TXT类型的记录，用于登记某个域名所有拥有的合法的发送邮件的所有IP地址。15. DKIMDKIM（DomainKeys Identified Mail）是一种防诈骗邮件的反垃圾邮件技术。DKIM要求邮件发送方在电子邮件的信头插入DKIM-Signature及电子签名信息，而邮件接收方则通过DNS查询得到其公钥然后进行合法性验证。16. DMARCDMARC（Domain-based Message Authentication, Reporting and Conformance）是一种防诈骗邮件的反垃圾邮件技术。DMARC结合SPF和DKIM两项技术，通过检查电子邮件信头的发件人的合法性，将诈骗邮件识别出来。17. RBLRBL（Real-time Blackhole List），即实时黑名单列表，是一些由国际知名的反垃圾邮件组织所提供的恶意发送垃圾邮件的发件人邮箱地址，IP地址，URL地址等黑名单列表的服务。若已被RBL收录，需到相应RBL官方网站上去核实并申请移除。常见的知名RBL组织，如中国互联网协会反垃圾信息中心、spamhaus，Maps，sorbs，uribl，surbl等。18. w3.org规范由万维网联盟(W3C)共同开发与公布的各种web设计规范。当邮件正文以网页的形式组织时，应当参考这些规范。19．HELO电子邮件头中邮件发送者用来标识自己的身份的命令字段。 附录:电子邮件营销常用指标1. 发送量发送的营销电子邮件数量2. 到达量发送的营销电子邮件数量-退回的营销电子邮件数量3. 到达率到达接收方邮箱的营销电子邮件数量/发送的营销电子邮件数量×100%4. 退信率退回的营销电子邮件数量/发送的营销电子邮件数量×100%5. 硬退信率硬退回的营销电子邮件数量/发送的营销电子邮件数量×100%6. 软退信率软退回的营销电子邮件数量/发送的营销电子邮件数量×100%7. 打开率打开营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复打开邮件的情况。8. 点击率点击了营销电子邮件内容中链接的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复点击的情况。9. 点击打开率点击了营销电子邮件内容中链接的接收方数量/打开营销电子邮件的接收方数量×100%，不计算重复点击和重复打开的情况。10. 退订率退订营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%11. 投诉率被投诉的营销电子邮件数量/到达接收方邮箱的营销电子邮件数量×100%12. 信誉度邮件接收方或者第三方机构对营销电子邮件服务信誉和质量的评定结果 参考中华人民共和国信息产业部令第38号 互联网电子邮件服务管理办法中国互联网协会 电子邮件服务指南（V1.1）中国互联网协会 中国互联网协会互联网公共电子邮件服务规范YD-T 1310-2004 互联网广告电子邮件格式要求YD-T 1311-2004 防范互联网垃圾电子邮件技术要求

详细解答可以参考官方帮助文档 阿里云任何版本的企业邮箱服务禁止发送营销邮件，营销邮件标准及相关规范，参见中国互联网协会反垃圾信息中心的管理规范。中国互联网协会电子邮件营销规范(V1.2)来源：反垃圾信息中心一、总则1.1 为规范电子邮件形式的市场营销行为，统一电子邮件营销[注1]的基本要求，为接收和发送营销内容的电子邮件提供依据，保护电子邮件用户的合法权益，根据我国相关法律法规的规定，制定本规范。1.2 本规范适用于电子邮件营销活动的开展和评价。1.3 本规范基于《互联网电子邮件服务管理办法》（中华人民共和国信息产业部令第38号）制定，从事电子邮件营销除应执行本规范外，还应符合《互联网电子邮件服务管理办法》及其他国家现行的有关标准的规定。二、基本规定2.1 中国互联网协会对电子邮件营销服务提供者[注2]实行登记备案管理。电子邮件营销服务提供者应当在开展电子邮件营销活动前将电子邮件发送服务器所使用的IP地址[注11]及相关信息向中国互联网协会反垃圾信息中心登记备案，并遵守以下规定：2.1.1需报备的 IP 地址及相关信息（1）备案单位基本情况，包括备案单位名称、备案单位地址、备案单位性质、备案单位组织机构代码、备案单位营业执照注册号、备案单位经营范围、备案单位注册资金、备案单位网站域名、备案单位法人代表姓名、备案单位联系人姓名、联系人电话、 联系人电子邮件、联系人即时通信方式等。（2）备案单位电子邮件发送服务器IP地址分配使用信息，包括备案单位用于发送电子邮件的IP地址数量、IP地址、IP地址段、IP地址所属单位名称、IP地址对应域名、IP地址对应发送营销电子邮件[注3]性质/类型（事务性邮件和商业性邮件等）；（3）备案单位可自愿报备每次电子邮件营销活动的信息，包括本次营销活动使用IP地址、域名、发件人邮箱地址、电子邮件HELO[注19]信息、收件人数量、发送周期、平均发送速率[注10]、单IP最大发送速率、发送营销电子邮件性质/类型（事务性邮件和商业性邮件等）、营销电子邮件的原信/样信等。（4）其他需要备案的信息。2.1.2 电子邮件营销服务提供者拟变更电子邮件营销服务信息的，应当提前办理变更登记手续。2.1.3 电子邮件营销服务提供者提交的备案信息必须完整、真实、有效且符合我国相关法律法规规定。2.1.4 中国互联网协会反垃圾信息中心负责审核电子邮件营销服务提供者提交的备案资料，对符合要求的备案单位发放电子邮件营销备案资质证书。2.2 电子邮件营销服务提供者应当确保所有与电子邮件服务有关的域名和IP地址注册信息正确、完整和及时更新，并遵守以下规定：2.2.1 发送电子邮件的服务器IP地址必须使用静态IP[注12]地址，并已采取IP反向解析[注13]措施。2.2.2 发送电子邮件的邮箱域名建议与发送电子邮件的服务器IP反向解析的域名信息一致，并已采取SPF解析[注14]。2.2.3 建议使用DKIM[注15]、DMARC[注16]等反垃圾邮件技术，提高与电子邮件发送相关的域名和IP的信誉。2.2.4 关注知名的RBL[注17]组织列表，如果发现与电子邮件发送相关的域名、IP或邮箱地址出现在知名的RBL[注17]组织列表上，应及时采取措施进行申诉和解封。2.2.5 建议发送事务性邮件和商业性邮件的服务器分配不同的IP地址和发送邮箱地址。2.2.6 具有特殊功能的账户，如postmaster@账户（邮件管理员账户）或abuse@账户（投诉账户），必须保证其有效，并由专人负责管理维护。2.3 电子邮件营销服务提供者应当建立可靠有效的订阅[注5]及退订[注9]机制，并遵守以下规定：2.3.1未经电子邮件接收者明确许可，不得向其发送营销电子邮件。获取接收者许可的过程和内容应清楚、明确，且不违背我国的相关法律规定。电子邮件营销服务提供者应公布获取接收者许可的策略，保存接收者同意接收营销邮件的许可记录，以便在需要时向接收者提供相关信息。2.3.2营销电子邮件必须提供给接收者至少包含一种退订的途径和具体操作方法，退订信息应醒目、清晰，退订操作方法应简单，有效。2.3.3确保退订请求可以正常发送并能够被及时自动响应处理。不得强制要求用户提交退订原因或设置退订条件，退订请求发出后应在3个工作日内生效。2.4 电子邮件营销服务提供者应规范的使用和维护其营销用户[注4]的电子邮件地址列表[注6]，并遵守以下规定：2.4.1 电子邮件营销服务提供者对营销用户的个人信息和电子邮件地址负有保密的义务。未经用户同意，不得泄露用户的个人信息和电子邮件地址，法律、行政法规另有规定的除外。2.4.2 电子邮件营销服务提供者应制定安全合理的隐私策略[注8]。营销用户的个人信息资料和电子邮件地址的使用应与收集目的一致，未经用户同意，不得用于收集目的以外的其它用途。2.4.3 必须保证每个电子邮件地址的取得都经过了用户的许可。尽量确保每个电子邮件地址都是真实有效的。2.4.4 应合理处理邮件投递过程中接收电子邮件的服务器返回的错误代码[注7]。对于返回代码表示不存在的电子邮件地址，应及时从发送列表中删除；对于连续出现投递错误的电子邮件地址，建议及时调整投递策略，减少可能导致错误发生的情况。2.5 电子邮件营销服务提供者应使用规范的电子邮件格式与内容，并遵守以下规定：2.5.1 营销电子邮件的内容不得违反我国相关法律法规规定。2.5.2 营销电子邮件格式应符合国际通用规范标准（参见RFC 2822）。邮件中如果包含HTML格式，应遵循由万维网联盟（W3C）公布的w3.org[注18]设计规范。2.5.3 营销电子邮件应标明邮件发送方的身份和真实的可返回的邮件发送地址。邮件的标题和信体要能准确的反映出邮件的内容、真实来源和通信目的。邮件正文应包含发送方的名称、地址、联系电话和电子邮件地址等详细信息。2.5.4 营销电子邮件的主题与内容必须相匹配。邮件内容应与营销用户的订阅内容一致。2.5.5 应采取有效的措施保护未成年人，尽可能的识别未成年的邮件订阅者。营销电子邮件含有不适合未成年人阅读的内容时，应提前核实接收者的年龄，确保接收者达到合法接收和阅读的年龄。发送给未成年人的营销邮件应征得其监护人的许可，内容符合此年龄段人群的知识水准、阅历和心里成熟程度。2.6 电子邮件营销服务提供者应与邮件接收方建立良好的沟通渠道，并参考以下规定：2.6.1 中国互联网协会反垃圾信息中心负责协助电子邮件营销服务提供者与邮件接收组织之间的沟通协调，在邮件传送过程中出现问题时，及时有效的进行沟通，确保尽快使问题得到解决。2.6.2 中国互联网协会反垃圾信息中心应协助电子邮件营销服务提供者与邮件接收组织之间建立信息反馈机制，改进电子邮件营销服务提供者的服务水平。2.6.3 中国互联网协会反垃圾信息中心应对电子邮件营销活动进行监督，对电子邮件营销服务提供者的信誉进行评价。2.6.4 电子邮件营销服务提供者应建立公平、高效、安全、易于使用的邮件投诉系统，在营销电子邮件中为营销用户提供便捷的投诉方式，受理营销用户对营销电子邮件的投诉。对被投诉的营销电子邮件，应立即开展调查，采取合理有效的防范或处理措施，并将有关情况和调查结果及时向各省通信管理局等国家有关机关或者12321网络不良和垃圾信息举报受理中心报告。2.6.5 电子邮件营销服务提供者应按照邮件接收方的要求限制营销电子邮件的发送速率。邮件接收方应将未投递成功的电子邮件服务器错误信息反馈邮件发送方。对信誉良好，行为规范的电子邮件营销服务提供者，邮件接收方可适当放宽营销电子邮件的发送速率。2.7 电子邮件营销服务提供者应积极配合各省通信管理局等国家有关机关和12321网络不良和垃圾信息举报受理中心开展调查工作。2.8 中国互联网协会拥有本规范的解释权和修改权。2.9 本规范自发布之日起施行。 附注:1. 电子邮件营销：指通过电子邮件开展的营销活动。2. 电子邮件营销服务提供者：也是营销电子邮件的发送方，指提供电子邮件营销服务的单位或个人，包括直接开展电子邮件营销活动的单位或个人以及接受委托开展电子邮件营销活动的单位或个人。3. 营销电子邮件：指具有营销功能的电子邮件。根据电子邮件的发送目的，分为事务性邮件和商业性邮件两种类型。3.1 事务性邮件，是指由收件人触发并已允许发件人发送的，以推动、完成或确认相关联流程为主要目的而发送的电子邮件。常见分类包括：（1）账号相关：账号激活、信息验证、账号绑定、密码修改、密码取回等。（2）交易信息：订单通知、付款通知、退款通知、物流通知、交易投诉等。（3）账单信息：对帐单、流水账单、催款通知、账户变更等。（4）其他类型。3.2 商业性邮件，是指任何以推销或者推广某种商品或服务（包括商业性网站的内容）为主要目的而发送的电子邮件。常见分类包括：（1）期刊资讯：更新通知、各类期刊、各类报表等。（2）产品促销：新品推广、季末促销、优惠套餐、折扣优惠、积分优惠等。（3）成员营销：好友邀请、成员关怀、主题活动、用户调研等。（4）其他类型。3.3 事务性邮件如果附带商业性内容，则视为商业性邮件。4. 营销用户：指电子邮件营销活动的对象，即接收营销电子邮件的电子邮箱使用者。5. 订阅：指营销用户预先订制，同意接收订制的营销电子邮件的行为。6. 邮件列表：指已经订阅了某一类营销电子邮件的用户电子邮箱地址列表，该列表是此类营销电子邮件的发送对象。7. 错误代码/硬退回/软退回：指在邮件的SMTP发送过程中，收信方服务器每处理完一条SMTP命令，都会向发信方服务器回传一个返回信息，用于表明对这条SMTP命令的执行结果。如返回信息以4XX（如450等）开头，指接收方临时性拒收该邮件，称软退回；如返回信息以5XX（如550等）开头，指接收方永久性拒收该邮件，称硬退回。以上列举的两类代码，习惯称为错误代码。8. 隐私策略：指电子邮件营销活动所收集的营销用户信息类型，收集方式和收集技术，以及信息的提供对象和使用用途。隐私策略中还应包括用户信息保护的安全措施、责任和实施过程。9. 退订：指营销用户取消订阅营销电子邮件的行为。10. 发送速率：指单位时间内的发送电子邮件的总数量。 常见的时间间隔单位包括：分钟、15分钟、小时、天、周、月等。11. IP地址/IP段IP地址是被用于定位互联网上的电脑一个唯一编号，地址的格式如159.226.1.1。多个IP地址的组合，即称为IP段。邮件发送过程中会?谰軮P地址，来确定邮件发送者和邮件接收者的位置。12. 静态IP地址指长期固定分配给一台计算机使用的IP地址，一般是由网络运营商分配。13. IP反向解析IP反向解析是一项常用的反垃圾邮件技术。常用的DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”。正向查找区域是指域名解析，反向查找区域即是IP反向解析，简称PTR记录，其作用是通过查询IP地址的PTR记录来得到该IP地址指向的域名。PTR记录需要由提供IP地址的网络运营商（ISP）进行配置。14. SPFSPF（Sender Policy Framework）是一种通过IP地址来认证电子邮件发件人身份的技术，是一项非常高效的反垃圾邮件技术。它通过在DNS中发布一条TXT类型的记录，用于登记某个域名所有拥有的合法的发送邮件的所有IP地址。15. DKIMDKIM（DomainKeys Identified Mail）是一种防诈骗邮件的反垃圾邮件技术。DKIM要求邮件发送方在电子邮件的信头插入DKIM-Signature及电子签名信息，而邮件接收方则通过DNS查询得到其公钥然后进行合法性验证。16. DMARCDMARC（Domain-based Message Authentication, Reporting and Conformance）是一种防诈骗邮件的反垃圾邮件技术。DMARC结合SPF和DKIM两项技术，通过检查电子邮件信头的发件人的合法性，将诈骗邮件识别出来。17. RBLRBL（Real-time Blackhole List），即实时黑名单列表，是一些由国际知名的反垃圾邮件组织所提供的恶意发送垃圾邮件的发件人邮箱地址，IP地址，URL地址等黑名单列表的服务。若已被RBL收录，需到相应RBL官方网站上去核实并申请移除。常见的知名RBL组织，如中国互联网协会反垃圾信息中心、spamhaus，Maps，sorbs，uribl，surbl等。18. w3.org规范由万维网联盟(W3C)共同开发与公布的各种web设计规范。当邮件正文以网页的形式组织时，应当参考这些规范。19．HELO电子邮件头中邮件发送者用来标识自己的身份的命令字段。 附录:电子邮件营销常用指标1. 发送量发送的营销电子邮件数量2. 到达量发送的营销电子邮件数量-退回的营销电子邮件数量3. 到达率到达接收方邮箱的营销电子邮件数量/发送的营销电子邮件数量×100%4. 退信率退回的营销电子邮件数量/发送的营销电子邮件数量×100%5. 硬退信率硬退回的营销电子邮件数量/发送的营销电子邮件数量×100%6. 软退信率软退回的营销电子邮件数量/发送的营销电子邮件数量×100%7. 打开率打开营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复打开邮件的情况。8. 点击率点击了营销电子邮件内容中链接的接收方数量/收到营销电子邮件的接收方数量×100%，不计算重复点击的情况。9. 点击打开率点击了营销电子邮件内容中链接的接收方数量/打开营销电子邮件的接收方数量×100%，不计算重复点击和重复打开的情况。10. 退订率退订营销电子邮件的接收方数量/收到营销电子邮件的接收方数量×100%11. 投诉率被投诉的营销电子邮件数量/到达接收方邮箱的营销电子邮件数量×100%12. 信誉度邮件接收方或者第三方机构对营销电子邮件服务信誉和质量的评定结果 参考中华人民共和国信息产业部令第38号 互联网电子邮件服务管理办法中国互联网协会 电子邮件服务指南（V1.1）中国互联网协会 中国互联网协会互联网公共电子邮件服务规范YD-T 1310-2004 互联网广告电子邮件格式要求YD-T 1311-2004 防范互联网垃圾电子邮件技术要求