当前处理机状态是什么

TCP 提供⼀种⾯向连接的、可靠的字节流服务在⼀个 TCP 连接中，仅有两⽅进⾏彼此通信。⼴播和多播不能⽤于 TCPTCP 使⽤校验和，确认和重传机制来保证可靠传输TCP 给数据分节进⾏排序，并使⽤累积确认保证数据的顺序不变和⾮重复TCP 使⽤滑动窗⼝机制来实现流量控制，通过动态改变窗⼝的⼤⼩进⾏拥塞控制 扩展： 头部 从这个图上我们就可以发现 TCP 头部比 UDP 头部复杂的多。 对于 TCP 头部来说，以下几个字段是很重要的 Sequence number，这个序号保证了 TCP 传输的报文都是有序的，对端可以通过序号顺序的拼接报文Acknowledgement Number，这个序号表示数据接收端期望接收的下一个字节的编号是多少，同时也表示上一个序号的数据已经收到Window Size，窗口大小，表示还能接收多少字节的数据，用于流量控制标识符 URG=1：该字段为一表示本数据报的数据部分包含紧急信息，是一个高优先级数据报文，此时紧急指针有效。紧急数据一定位于当前数据包数据部分的最前面，紧急指针标明了紧急数据的尾部。ACK=1：该字段为一表示确认号字段有效。此外，TCP 还规定在连接建立后传送的所有报文段都必须把 ACK 置为一。PSH=1：该字段为一表示接收端应该立即将数据 push 给应用层，而不是等到缓冲区满后再提交。RST=1：该字段为一表示当前 TCP 连接出现严重问题，可能需要重新建立 TCP 连接，也可以用于拒绝非法的报文段和拒绝连接请求。SYN=1：当SYN=1，ACK=0时，表示当前报文段是一个连接请求报文。当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文。FIN=1：该字段为一表示此报文段是一个释放连接的请求报文。 状态机 TCP 的状态机是很复杂的，并且与建立断开连接时的握手息息相关，接下来就来详细描述下两种握手。 在这之前需要了解一个重要的性能指标 RTT。该指标表示发送端发送数据到接收到对端数据所需的往返时间。 建立连接三次握手 首先假设主动发起请求的一端称为客户端，被动连接的一端称为服务端。不管是客户端还是服务端，TCP 连接建立完后都能发送和接收数据，所以 TCP 是一个全双工的协议。 起初，两端都为 CLOSED 状态。在通信开始前，双方都会创建 TCB。 服务器创建完 TCB 后便进入 LISTEN 状态，此时开始等待客户端发送数据。 第一次握手 客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。 第二次握手 服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。 第三次握手 当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。 PS：第三次握手中可以包含数据，通过快速打开（TFO）技术就可以实现这一功能。其实只要涉及到握手的协议，都可以使用类似 TFO 的方式，客户端和服务端存储相同的 cookie，下次握手时发出 cookie 达到减少 RTT 的目的。 为什么 TCP 建立连接需要三次握手，明明两次就可以建立起连接 因为这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。 可以想象如下场景。客户端发送了一个连接请求 A，但是因为网络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送一个连接请求 B。此时请求顺利到达服务端，服务端应答完就建立了请求，然后接收数据后释放了连接。 假设这时候连接请求 A 在两端关闭后终于抵达了服务端，那么此时服务端会认为客户端又需要建立 TCP 连接，从而应答了该请求并进入 ESTABLISHED 状态。但是客户端其实是 CLOSED 的状态，那么就会导致服务端一直等待，造成资源的浪费。 PS：在建立连接中，任意一端掉线，TCP 都会重发 SYN 包，一般会重试五次，在建立连接中可能会遇到 SYN Flood 攻击。遇到这种情况你可以选择调低重试次数或者干脆在不能处理的情况下拒绝请求。 断开链接四次握手 TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK。 第一次握手 若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。 第二次握手 B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。 第三次握手 B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。 PS：通过延迟确认的技术（通常有时间限制，否则对方会误认为需要重传），可以将第二次和第三次握手合并，延迟 ACK 包的发送。 第四次握手 A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。 为什么 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态？ 为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。 ...... 总结 建立连接需要三次握手，断开连接需要四次握手滑动窗口解决了数据的丢包、顺序不对和流量控制问题拥塞窗口实现了对流量的控制，保证在全天候环境下最优的传递数据

什么是Kubernetes? Kubernetes是一种轻便的可伸展的开源平台，用来管理容器化的工作或者服务，拥有声明化配置和自动化等优点。它现在拥有一个快速扩大与成长的生态系统，其服务，工具和技术支持可被广泛用于各个方面。 为什么我需要Kubernetes，它用来做些什么？ Kubernetes拥有大量的特性，比如： 容器平台 微服务平台 轻量化云服务平台 等等 Kubernetes提供了一个以容器为中心的管理环境，它根据用户的工作负载来协调计算，网络和储存基础架构。它既有PaaS的简化性，又具有IaaS的灵活性，并支持跨基础架构的可移植性 为什么Kubernetes是一个平台? 尽管Kubernetes提供了大量的功能性，总会有新的场景需要新的功能。一些特性的应用程序工作流程可以被简化来加快开发速度。最初的部署通常需要大规模的应用自动化。这就是为什么Kubernetes被设计成一个平台服务，用来创建一个包含工具和其他组成部分的系统环境，来使部署，测量和管理应用更加容易。 Label可以授权用户按照他们的想法来组织他们的资源。Annotation允许用户布置含有自定义信息的资源，来使工作流更加顺畅，并为管理工具提供到checkpoint状态的一种更简单的方式。 此外，Kubernetes控制平面基于开发人员和用户可用的相同API构建。用户可以编写他们自己的 controller，比如schedulers，这些API可以通过通用命令行工具进行定位。 这种设计使得许多其他系统能够在Kubernetes上面构建 Kubernetes不是什么 Kubernetes不是一个传统的，包罗万象的PaaS（平台即服务）系统。由于Kubernetes在容器级而不是在硬件级运行，因此它能提供一些PaaS产品常用的通用功能，比如部署，扩展，负载均衡，日志记录和监控。但是，Kubernetes并不是一个整体，这些默认解决方案都是可选和可插拔的。Kubernetes提供了构建人员平台的构建模块，但是在一些重要的地方保留了用户选择和灵活性。 Kubernetes： 不限制支持的应用程序类型。Kubernetes旨在支持各种各样的工作负载，包括无状态，有状态和数据处理工作负载。 如果一个应用程序可以在一个容器中运行，它应该在Kubernetes上运行得很好。 不部署源代码并且不构建您的应用程序。持续集成，交付和部署（CI / CD）工作流程由组织和偏好以及技术要求决定。 不提供应用程序级服务，例如中间件（例如，消息总线），数据处理框架（例如，Spark），数据库（例如，mysql），高速缓存，也不提供集群存储系统（例如，Ceph）。 在服务中。 这些组件可以在Kubernetes上运行，和/或可以通过便携式机制（例如Open Service Broker）在Kubernetes上运行的应用程序访问。 不指示日志，监视或警报解决方案。 它提供了一些集成作为概念证明，以及收集和导出指标的机制。 不提供或授权配置语言/系统（例如，jsonnet）。 它提供了一个声明性API，可以通过任意形式的声明性规范来实现。 不提供或采用任何全面的机器配置，维护，管理或自我修复系统。 此外，Kubernetes不仅仅是一个编排系统。 实际上，它消除了编排的需要。 业务流程的技术定义是执行定义的工作流程：首先执行A，然后运行B，然后运行C.相反，Kubernetes由一组独立的，可组合的控制流程组成，这些流程将当前状态持续推向所提供的所需状态。 如何从A到C无关紧要。也不需要集中控制。 这使得系统更易于使用且功能更强大，更具弹性且可扩展 为什么使用容器 过去部署应用的方式，是将应用安装在一个使用操作系统软件包管理器的主机上。这样做的缺点是应用程序的可执行文件、配置、库和生命周期互相影响，也会和操作系统纠缠不清。你也可以构建一个不可被修改的虚拟机镜像来实现可预测的部署和回滚，但是这样显然不够轻量化而且不可被移植 新的方式是在虚拟化的操作系统层来部署容器，而不是在虚拟化的硬件层。这些容器之间彼此独立，相对主机也保持独立。它们有自己单独的文件系统，也不能看到其他容器的进程，而且它们对于计算资源的使用量可以被限制。它们比虚拟机更容易被构建，因为它们从底层基础架构和主机文件系统中解耦出来，也可以跨单机与云之间移植。 因为容器小巧且轻快，一个应用程序可以被打包放到每个容器镜像中。这种一对一的应用对镜像的关系可以使容器发挥出最大功效。有了容器，不可变的容器镜像可以在构建时被创建，而不是在部署时，因为每个应用都不需要依赖于程序的其它应用部分，也不依赖于基础生产环境。同样，容器比VM更加透明，这有利于监控和管理。当容器的生命周期由基础架构管理而不是隐藏在流程管理器之后时，尤其如此。最后，当一个应用被部署在每个容器时，管理容器就变得和管理程序部署一样了。 阿里云导入自建K8S集群 更多阿里云帮助文档 https://help.aliyun.com 希望对您有帮助！

本文介绍了创建及配置集群的基本配置流程和查看配置清单的方法，并详细说明了各高级配置项的用法。 基本配置流程 开通并创建NAS 首次创建E-HPC集群之前，需要先登录文件存储产品页面 开通NAS服务，NAS服务开通后，登录到NAS控制台开始 创建NAS文件系统，并为文件系统 添加挂载点，操作完成之后，就可以登录到EHPC控制台创建集群了。 创建集群 1.. 登录E-HPC管理控制台。如果尚未注册，请先单击 免费注册 完成注册流程（按照最新国家规定，需要实名制注册）。登录后定位到 弹性高性能计算，会直接显示如下的集群界面： ClusterView 2.. 在该 集群 界面，先选择地域（如华东1），单击右上角开始 创建集群。 注意1：请先了解地域和可用区。 注意2： 在创建、管理或使用E-HPC集群时，非特殊情况请勿使用云服务器ECS管理控制台调整单个集群节点。建议通过E-HPC集群管控平台操作。详情见 为什么不能使用ECS管理控制台对E-HPC集群节点进行操作？ 第一步：硬件配置 硬件配置项包括：可用区、付费类型、部署方式和节点配置，如下图所示：HardwareConfig 选择可用区。 ZoneSelect 说明：为了保证E-HPC节点间的网络通讯效率，所有开通的节点均位于同一地域同一可用区，请参见地域和可用区。如果在开通E-HPC集群时发现想用的区域不可选，请参见为什么某些地域无法开通E-HPC集群 选择付费类型 付费类型是指集群节点ECS实例的计费方式，其中不包括弹性IP、NAS存储的费用。共有三种付费类型供您选择：包年包月、按量付费和竞价实例。ChargeMode 选择部署方式 DeployMode 说明： 标准：登录节点、管控节点和计算节点分离部署，管控节点可以选2台或4台（HA）。 简易：登录、管控服务混合部署在一台节点上，计算节点分离。 One-box: 所有类型的服务都部署在一台计算节点上，整个集群只有一个节点，可选择使用本地存储或NAS存储。使用NAS存储时可支持集群扩容。 4. 节点配置 NodeSelect 如上图，系统中默认分配2个管控节点实例，还可以自己选择1个或者4（HA）。计算节点的数量指定为3台。登录节点默认分配1台。点击节点的打开下拉菜单可进一步选择所需机型。 说明： E-HPC集群主要由以下3种节点构成 计算节点：用于执行高性能计算作业的节点 管控节点：用于进行作业角度和域账户管理的节点，包括相互独立的2种节点： 作业调度节点：部署作业调度器 域帐户管理节点：部署集群的域账号管理软件 登录节点：具备公网IP，用户可远程登录该节点，通过命令行操作HPC集群 一般来说，作业调度节点只处理作业调度，域帐户管理节点只处理帐户信息，都不参与作业运算，因此原则上管控节点选用较低配置的企业级实例（如小于4CPU核的sn1ne实例）保证高可用性即可。计算节点的硬件配置选择是影响集群性能的关键点。登录节点通常会被配置为开发环境，需要为集群所有用户提供软件开发调试所需的资源及测试环境，因此推荐登录节点选择与计算节点配置一致或内存配比更大的实例。各种机型的详细信息可参考推荐配置。 完成硬件配置后，点击下一步进入软件配置界面。 第二步：软件配置 软件配置项包括：镜像类型、操作系统、调度器和软件包，如下图所示：SoftwareConfig 说明： 选择不同的镜像类型，操作系统的可选项也会变化。操作系统指部署在集群所有节点上的操作系统。“镜像类型”说明： 若用户选择镜像为"自定义镜像类型"，则不能使用基于已有E-HPC集群节点创建产生的自定义镜像，否则，创建集群计算节点将会产生异常。 调度器是指HPC集群上部署的作业调度软件。选择不同的作业调度软件，向集群提交作业时作业脚本和参数也会有相应的不同。 软件包是指HPC集群上部署的HPC软件，HPC提供多种类型的典型配置软件包如GROMACS、OpenFOAM和LAMMPS等，包含相应的软件和运行依赖，集群创建完毕之后，所选的软件将会预装到集群上。 第三步：基础配置 基础配置项包括：基本信息和登录设置，如下图所示：BaseConfig 说明： 基本信息中的名称是指集群名称，该名称将会在集群列表中显示，便于用户查找。 登录设置填写的是登录该集群的密码，该密码用于远程SSH访问集群登录节点时使用，对应的用户名为root。 完成基本配置后，勾选《E-HPC服务条款》,点击确认即可创建集群。 查看配置清单 您可以在创建集群界面的右侧查看当前配置清单。默认情况下，配置清单仅显示基础配置，您可以勾选高级配置选项查看更多配置项。 ConfigList 查看配置拓扑图 在创建完集群之后，点击右上角查看详情，我们可以查看到集群的在拓扑图。TopoButton 可以看到当前配置拓扑图中，包括VPC名称、交换机名称、NAS实例名、登录节点、管控节点、计算节点的配置及数量等。ClusterTopo 查询创建状态 大约20分钟后，您可以回到E-HPC集群页面，查看新集群状态。若新集群所有节点皆处于 运行中 的状态，则集群已创建完毕。下一步用户可登录到集群进行操作，请参见指引使用集群。 高级配置 按照基本配置流程可创建通用E-HPC集群，如果用户需要更灵活的配置，可以在高级配置选项下进行选择。创建集群的三个步骤中前两个步骤都有高级配置可供用户选择。 硬件高级配置 依次打开创建集群 > 硬件配置 > 高级配置，可以看到如下配置选项（本例在创建集群前已事先创建了网络、存储等基础服务）： HardwareAdvConfig 网络配置 上图中的网络配置部分，用户可自行在阿里云专有网络控制台创建VPC、交换机，在阿里云云服务器控制台创建安全组，创建完成后即可在这里可以选择所需的VPC、交换机、安全组等网络配置。如果不想跳转到其他服务的控制台，也可点击此处的“创建VPC”、“创建子网（交换机）”链接，在右侧的滑动窗口中创建相应的组件。 说明：如果用户事先没有创建VPC和交换机，创建集群的流程将会自动创建默认一个默认的VPC和交换机，VPC网段为192.168.0.0/16，交换机网段为192.168.0.0/20。用户如果自行创建了VPC，需要在所需的可用区下自行创建交换机才可继续创建集群。如果用户自行创建了VPC和交换机，使用基础配置流程创建集群时将会自动选择第一个VPC和交换机，请确保交换机下的IP地址空间足够（可用IP数大于集群所有节点的数量），用户也可以在高级配置下的VPC和交换机配置中自行选择任何已创建的VPC和交换机。 共享存储配置 上图中的共享存储部分，E-HPC所有用户数据、用户管理、作业共享数据等信息都会存储在共享存储上以供集群各节点访问。目前共享存储是由文件存储NAS提供。而要使用NAS还要配套挂载点和远程目录。 说明：如果用户事先没有在当前可用区创建NAS实例和挂载点，创建集群的流程将会在可用区下自动创建默认一个默认的NAS实例与挂载点。如果用户在当前可用区自行创建了NAS实例和挂载点，使用基础配置流程创建集群时将会自动选择第一个NAS实例和挂载点。如果在该NAS实例在可用区下没有可用的挂载点，创建集群的流程会自动创建一个挂载点。请确保该NAS实例还有可用的挂载点余量。 系统盘大小配置 用户可以根据自己实际需求，在这里指定创建集群计算节点的系统盘大小，默认值是40，范围在40-500（G）之间。 该值与集群扩容时系统盘大小的默认值保持一致，用户也可以在集群扩容时为新扩容的节点重新设置系统盘大小。 软件高级配置 依次打开创建集群 > 软件配置 > 高级配置，进行高级选项配置。 队列配置 用户可在此处为创建的集群指定队列，当不指定时集群会加入到默认的队列，如，PBS集群的默认队列为workq，slurm集群的默认队列为comp. queueconfig 安装后执行脚本 集群部署完毕后，用户可以在此处执行脚本。PostScript 说明： 下载地址是指脚本文件所在的地址，一般将脚本上传到OSS服务，这里填写OSS文件的url。 执行参数是指执行脚本时需要传入的命令行参数。 软件版本 用户可以在此处选择域账号服务软件类型和具体的软件清单：VersionConfig 注意：在选择预装高性能计算应用软件时，必须选择所依赖的软件包（如mpich或openmpi，参见软件包名后缀）。如选择”-gpu”后缀的软件，必须确保计算节点使用GPU系列机型。否则会有集群创建失败或软件无法正常运行的风险。

首先，百度搜索oracle VM VirtualBox 点开第一个Oracle vm的官网，可以直接点击download下载，当然因为oracle的服务器在国外，如果访问速度很慢的话，我们可以选择国内的资源，比如百度软件中的资源，我们点击普通下载。点击download后，根据当前系统环境选择对应的版本，如果是win10，可以选择windows hosts，总共有109MB，我们等它下载完。下载好之后就可以安装了，然后就是一路点击“下一步”，然后安装就ok了。 然后是操作系统的下载百度搜索ubantu 17.10，出现以下界面，点击第一个可以Ubantu官网（这里为了方便找到Ubantu官网，我搜索了17.04，大家可以根据左下角的绿色网址确定网站来源），同样，如果大家喜欢支持中文的系统，可以选择下面的Ubantu Kylin（优麒麟），这是中国团队基于Ubantu开发的中文的操作系统。同样，Ubantu也有很多不同的发行版。我们在ubantu的官网选择download，然后选择desktop；或者直接访问网站https://www.ubuntu.com/download/desktop，其中上面的Ubantu 16.04.3 LTS（Long Term Support）是Ubantu的长时间支持的稳定版本，下面的Ubantu 17.10是最新发行的。直接点选continue to the download，将自动下载，约1.4GB。 准备好之后，我们开始配置虚拟机首先，打开oracle VM VirtualBox，依次点击控制->新建，给虚拟机取个名字后，将后面的类型设为linux，版本选择Ubantu（64-bit），注意，如果是32位的系统请选择（32-bit）。内存大小分配2G以上，虚拟硬盘选择“现在创建虚拟硬盘文件”，点击创建。 将文件位置选择在合适的（有足够空间的）硬盘分区后，分配文件大小（推荐15G以上） 虚拟硬盘文件类型选择“VDI”，选择“动态分配”，点击创建。选中刚建立好的虚拟机，点击设置（ctrl+s），按照以下图片更改设置 然后点击存储选项点击存储树中的光盘图标，点击右侧属性栏分配光驱属性后面的光盘图标，添加光盘镜像，选择添加一个虚拟光盘文件，然后找到我们刚才下载的Ubantu的镜像，点击打开，点击OK完成配置。 点击启动运行虚拟机，等待引导；选择语言后，点击安装ubantu，选择安装时更新并继续，点击现在安装、继续，选择所属位置用于分配服务器，一路点击继续，填写用户信息设置密码后，点击继续开始安装Ubantu系统。（该过程需保持联网，会下载一些配置文件），如果选择跳过则会跳过下载过程，进入系统后重新下载。 安装完毕后，选择现在重启，更新系统。 这样，我们就安装好了Ubantu 17.10，现在我们就可以使用linux系统进行学习与开发了！ 可以通过图形界面进行操作，召唤右上角的菜单可以查看状态或关机。 打开电脑的时候如果没有正常的Windows桌面，而只出现了一个“Windows资源管理器 已停止工作”的对话框，下面只有两个选项：①联机检查解决方案并关闭该程序；②关闭程序。 处理方法： 首先点击对话框中的“关闭程序”，不用Windows自动地联机检查解决方案，因为它压根什么都解决不了。 同时按住“Ctrl”+"Alt"+"Del"键，这时候电脑上的Windows资源管理器会出现，点击五个选项中的最后一个“启动任务管理器（T）”，这时候会蹦出来一个Windows资源管理器的对话框。 在“进程”选项卡中找到“explorer.exe”应用程序进程，，在右下方找到“结束进程”，点击“确定”。 在“资源管理器”的左上角有一个“文件”菜单，里面有“新建任务（运行...）（N）”，点击进去。在“创建新任务”的对话框中，点击浏览选项，这时候会出现一个文件搜索框，找到系统盘C盘下的Windows文件夹，在里面搜索explorer，这时候会出现文件路径为C:Windowsexplorer.exe的文件夹 双击“explorer.exe”退出文件搜索对话框，进入资源管理器。这时会看到打开后面会出现我们刚才搜索到的文件路径。点击确定，这时候就算大功告成了。

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的复制默认节点就是三节点以上的复制集群，当数据到达主节点之后会马上同步到从节点上去。

9.1 iOS的定位支持 iOS设备支持的定位方式有多种，最早期的iPhone只支持通过运营商的基站信号进行定位，后来iOS系统开始引入WiFi支持，从而允许iOS设备通过周围的WiFi信号进行定位。 从iPhone 3g开始，iPhone手机提供了内置的GPS模块处理芯片，从而允许通过GPS卫星系统进行定位。从iPhone 4开始，iPhone手机更换了精确度更高、耗电量更少、灵敏度更高的芯片，因此可以使用GPS进行精确定位。 下面先简单介绍iOS定位支持的3种模式。 9.1.1 GPS卫星定位 GPS是英文Global Positioning System（全球定位系统）的简称，GPS是20世纪70年代由美国陆海空三军联合研制的新一代空间卫星导航定位系统。从这个介绍不难发现，GPS的作用就是为全球的物体提供定位功能。 GPS定位系统由3部分组成，即由GPS卫星组成的空间部分、若干地面站组成的控制部分和普通用户手中的接收机这3个部分。对于手机用户来说，手机就是GPS定位系统的接收机，也就是说，GPS定位需要手机的硬件支持GPS功能。 GPS定位需要能收到卫星信号才行，卫星信号可能会被建筑物（比如高楼）遮挡，因此一般需要在室外进行接收、定位。虽然iPhone 4采用了高灵敏度的GPS芯片，但仍然需要在窗户旁或者户外才能进行接收、定位，因为只有这些地方才能确保卫星信号的强度和稳定性。 与基站定位、WiFi定位相比，GPS定位耗电量最大，速度最慢，但是精度最高。 需要说明的是，iOS的GPS定位与单纯的GPS定位不同，它是一种所谓辅助GPS（简称A-GPS）。A-GPS首先通过基站定位或WiFi定位获得该设备的大概位置，然后通过将设备的大致位置发到远程服务器，由服务器负责进行查询和计算，从而获取当前位置的卫星信息，并通过网络将这些卫星信息反馈给iOS设备，这样就避免了iOS设备直接通过GPS扫描、分析天上的卫星信息，如哪些卫星可见、具体在什么位置、时钟是多少等。因此，通常来说A-GPS比单纯的GPS更快。当然，这只是一般而论，对于专业级的GPS定位设备，其GPS芯片的灵敏度可能更好，因此这种GPS定位设备肯定更快。 A-GPS的优点是定位快，缺点是需要网络，但也只是在初次定位时需要网络，一旦卫星信息返回，在一段时间和范围内，这些卫星信息无须改变，接下来的GPS定位就无须联网，直接使用已有的卫星参数即可。 在iOS设备上，iOS系统会综合使用上述定位方式。一般来说，iOS系统可能先按照最快的“无网基站定位”返回一个位置，当有网络连接时，再使用“有网基站定位”来更新位置，然后利用A-GPS查询卫星星图，最后在能收到GPS信号的情况下，转为使用GPS定位。 根据当前卫星信号情况和网络环境，iOS系统可能在上述方式之间反复迭代，不一定按照特定步骤或方式，而且随着iOS系统升级，定位顺序和规则可能改变。 9.1.2 基站定位 每个手机基站都有一个标识符，iOS设备可以搜集周围所有收到信号的基站和它们的标识符，通过联网发送到苹果云端服务器，再由服务器根据这些基站的位置信息查询并计算出当前位置，然后把该定位信息返回给手机。因为基站信号的辐射范围大，所以相对来说误差是比较大的，通常在500米到几公里范围内。 基于基站定位的方式具有速度快，耗电量比较少，但误差较大的特征。 在没有网络的情况下，iOS 4对其进行了优化，可以在没有网络连接时采用无网定位，因为Apple已经预先将一些重要基站（几十公里选一个）提前存储在iOS系统中，因此即使不联网，iOS系统也可通过这些本地基站信息定位到设备的位置。这种定位方式的误差更大，通常在10公里到50公里范围内。 无网基站定位的前提是：iOS设备能接收到内置在手机中的那些“重要基站”的信号，不一定是你的手机所属运营商，只要能收到信号就可以了，所以室内、室外一样都可以进行基站定位。 9.1.3 WiFi定位 WiFi定位和基站定位的原理大致相似，iOS设备通过无线网卡搜集周围所有的WiFi热点，获得它们的MAC地址，然后通过Apple的云端服务器查询该WiFi热点是否已经登记，如果已经登记，即可获取该WiFi热点的位置，最后通过对多个WiFi热点折中计算得到当前位置并返回给iOS设备。 只要能收到手机信号的地方都可通过WiFi定位，室内、室外的效果相同。 WiFi定位速度、耗电量和精度都介于基站和GPS之间，精度大概在几十米范围内。 传统的WiFi定位是需要网络的，但是iOS系统对其进行了优化，可以实现无网WiFi定位。无网WiFi定位的原理是：iOS设备在联网状态下，会大致定位出设备的位置，并自动将设备所在地周围所有的WiFi热点信息保存在手机系统中。在接下来的时间内，即使当前iOS设备没有联网，iOS系统也可以利用之前保存的本地的WiFi热点信息定位出设备的位置。 根据无网WiFi定位的原理不难看出，无网WiFi定位的前提是：该iOS设备之前在该区域附近曾经接入过网络，如果初次到一个陌生的地方，无网WiFi是无法定位的。 iOS系统在进行定位时已将底层具体的定位细节进行了屏蔽——也就是说，这些定位细节对开发者而言是透明的，iOS系统会智能地根据设备的情况和周围的环境，采用一套最佳的解决方案。例如能够接收GPS信号，那么优先使用GPS定位；否则采用WiFi或基站定位，在WiFi和基站之间优先使用WiFi，如果无法连接WiFi才使用基站定位。

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.优化慢查询 。

很多人电脑是不是会出现各种蓝屏故障问题啊，出现问题又不知道怎么样解决。 1.故障检查信息 *STOP 0x0000001E(0xC0000005,0xFDE38AF9,0x0000001,0x7E8B0EB4)KMODE_EXCEPTION_NOT_HANDLED * 其中错误的第一部分是停机码(Stop Code)也就是STOP 0x0000001E, 用于识别已发生错误的类型, 错误第二部分是被括号括起来的四个数字集, 表示随机的开发人员定义的参数(这个参数对于普通用户根本无法理解, 只有驱动程序编写者或者操作系统的开发人员才懂). 第三部分是错误名. 信息第一行通常用来识别生产错误的驱动程序或者设备. 2.推荐操作蓝屏第二部分是推荐用户进行的操作信息. 有时, 推荐的操作仅仅是一般性的建议; 有时, 也就是显示一条与当前问题相关的提示. 一般来说, 惟一的建议就是重启. 3.调试端口告诉用户内存转储映像是否写到磁盘商了, 使用内存转储映像可以确定发生问题的性质, 还会告诉用户调试信息是否被传到另一台电脑商, 以及使用了什么端口完成这次通讯. 蓝屏时的处理办法：1.重启有时只是某个程序或驱动程序一时犯错, 重启后有可能就会正常。 2.新硬件首先, 应该检查新硬件是否插牢, 这个被许多人忽视的问题往往会引发许多莫名其妙的故障. 如果确认没有问题, 将其拔下, 然后换个插槽试试, 并安装最新的驱动程序. 同时还应对照微软网站的硬件兼容类别检查一下硬件是否与操作系统兼容. 3.新驱动和新服务如果刚安装完某个硬件的新驱动, 或安装了某个软件, 而它又在系统服务中添加了相应项目， 在重启或使用中出现了蓝屏故障, 请到安全模式来卸载或禁用它们. 4.检查病毒比如冲击波和振荡波等病毒有时会导致Windows蓝屏死机, 因此查杀病毒必不可少. 同时一些木马间谍软件也会引发蓝屏, 所以最好再用相关工具进行扫描检查. 5.检查BIOS和硬件兼容性对于新装的电脑经常出现蓝屏问题, 应该检查并升级BIOS到最新版本, 同时关闭其中的内存相关项, 比如:缓存和映射. 另外, 还应该对照微软的硬件兼容列表检查自己的硬件. 还有就是, 如果主板BIOS无法支持大容量硬盘也会导致蓝屏, 需要对其进行升级. 6.检查系统曰志在开始-->菜单中输入:EventVwr.msc, 回车出现"事件查看器", 注意检查其中的"系统曰志"和"应用程序曰志"中表明"错误"的项. 7.最后一次正确配置 最后一次正确配置界面 一般情况下, 蓝屏都出现于更新了硬件驱动或新加硬件并安装其驱动后, 这时Windows 2K/XP提供的"最后一次正确配置"就是解决蓝屏的快捷方式. 重启系统, 在出现启动菜单时按下F8键就会出现高级启动选项菜单, 接着选择"最后一次正确配置". 常见的蓝屏代码 0X0000000操作完成 0X0000001不正确的函数 0X0000002系统找不到指定的文件 0X0000003系统找不到指定的路径 0X0000004系统无法打开文件 0X0000005拒绝存取 0X0000006无效的代码 0X0000007内存控制模块已损坏 0X0000008内存空间不足，无法处理这个指令 0X0000009内存控制模块位址无效 0X000000A环境不正确 0X000000B尝试载入一个格式错误的程序 0X000000C存取码错误 0X000000D资料错误 0X000000E内存空间不够，无法完成这项操作 0X000000F系统找不到指定的硬盘 0X0000010无法移除目录 0X0000011系统无法将文件移到其他的硬盘 0X0000012没有任何文件 0X0000019找不到指定扇区或磁道 0X000001A指定的磁盘或磁片无法存取 0X000001B磁盘找不到要求的装置 0X000001C打印机没有纸 0X000001D系统无法将资料写入指定的磁盘 0X000001E系统无法读取指定的装置 0X000001F连接到系统的某个装置没有作用 0X0000021文件的一部分被锁定，现在无法存取 0X0000024开启的分享文件数量太多 0X0000026到达文件结尾 0X0000027磁盘已满 0X0000036网络繁忙 0X000003B网络发生意外的错误 0X0000043网络名称找不到 0X0000050文件已经存在 0X0000052无法建立目录或文件 0X0000053 INT24失败 0X000006B因为代用的磁盘尚未插入，所以程序已经停止 0X000006C磁盘正在使用中或被锁定 0X000006F文件名太长 0X0000070硬盘空间不足 0X000007F找不到指定的程序 0X000045B系统正在关机 0X000045C无法中止系统关机，因为没有关机的动作在进行中 0X000046A可用服务器储存空间不足 0X0000475系统 BIOS无法变更系统电源状态 0X000047E指定的程序需要新的windows版本 0X000047F指定的程序不是windwos或ms-dos程序 0X0000480指定的程序已经启动，无法再启动一次 0X0000481指定的程序是为旧版的windows所写的 0X0000482执行此应用程序所需的程序库文件之一被损 0X0000483没有应用程序与此项操作的指定文件建立关联 0X0000484传送指令到应用程序无效 0X00005A2指定的装置名称无效 0X00005AA系统资源不足，无法完成所要求的服务 0X00005AB系统资源不足，无法完成所要求的服务 0X00005AC系统资源不足，无法完成所要求的服务 110 0x006E系统无法开启指定的装置或档案。 111 0x006F档名太长。 112 0x0070磁碟空间不足。 113 0x0071没有可用的内部档案识别字。 114 0x0072目标内部档案识别字不正确。 117 0x0075由应用程式所执行的IOCTL 呼叫不正确。 118 0x0076写入验证参数值不正确。 119 0x0077系统不支援所要求的指令。 120 0x0078此项功能仅在 Win32 模式有效。 121 0x0079 semaphore超过逾时期间。 122 0x007A传到系统呼叫的资料区域太小。 123 0x007B档名、目录名称或储存体标 124 0x007C系统呼叫层次不正确。 125 0x007D磁碟没有设定标 126 0x007E找不到指定的模组。 127 0x007F找不到指定的程序。 128 0x0080没有子行程可供等待。 129 0x0081 %1这个应用程式无法在 Win32 模式下执行。 130 0x0082 Attempt to use a file handle to an open disk partition for an operation other than raw disk I/O. 131 0x0083尝试将档案指标移至档案开头之前。 132 0x0084无法在指定的装置或档案，设定档案指标。 133 0x0085 JOIN 或 SUBST指令无法用於内含事先结合过的磁碟机。 134 0x0086尝试在已经结合的磁碟机，使用JOIN 或 SUBST 指令。 135 0x0087尝试在已经替换的磁碟机，使用 JOIN 或 SUBST 指令。 136 0x0088系统尝试删除未连结过的磁碟机的连结关系。 137 0x0089系统尝试删除未替换过的磁碟机的替换关系。 138 0x008A系统尝试将磁碟机结合到已经结合过之磁碟机的目录。 139 0x008B系统尝试将磁碟机替换成已经替换过之磁碟机的目录。 140 0x008C系统尝试将磁碟机替换成已经替换过之磁碟机的目录.

回4楼aliyunwangdan的帖子 备案订单号： 23420000046 当前备案状态： 管局审核中 已经提交了 ------------------------- 回4楼aliyunwangdan的帖子 我的备案啥时候才能通过，已经一个月了，为什么别人几天就过，我的就要一个月没过？20号发个工单，客服让等等，这一等，这一个多星期又过去了，还让我怎么等，我买服务器不是玩单机的啊 如果在我等了一个月后，才告诉我没通过，你让我情何以堪？ 我是不是就该自认倒霉，然后重头再来，再搞一个月？ ------------------------- 回7楼anxiaohan的帖子 就从提交管局的日期算，也已经过去20天了，你说的这20天左右是左右到什么时候，那你们干脆说一个月不得了。。。。。。。。。 ------------------------- 回4楼aliyunwangdan的帖子 ------------------------- 回10楼aliyunwangdan的帖子 “专人”在哪里？没见到啊，别给我处理了，没啥事了

在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，分成以下 6 种解决方案。（一）规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。优点：解决（规避）了分布式事务。缺点：显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。由于这个方法存在明显缺点，通常不建议使用。（二）经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。eBay 方式的主要思路如下。Base：一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。（三）去哪儿网分布式事务方案随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢？最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过，使用异步消息 Consumer 端需要实现幂等。幂等有两种方式，一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：重试 B，直到 B 成功，事务记录表里记录了各项调用参数等信息；执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。总结起来，其实两种方式的根本原理是类似的，也就是将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性。（四）蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？方案选型服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性，所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦，通过订阅方消费 MQ 消息时的 ACK 机制，保证消息一定消费成功，达到最终一致性。由于消息可能会被重发，消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。我们在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。（五）支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。主要思路如下，大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说，DTS 框架有如下特性：最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。协议简单：DTS 定义了类似 2PC 的标准两阶段接口，业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上，与底层协议无关。与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的 confirm 操作，在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较，没有单独的 Prepare 阶段，降低协议成本。系统故障容忍度高，恢复简单（六）农信网数据一致性方案电商业务公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说，电商部门的订单支付，需要调用支付平台的支付接口来处理订单；同时需要调用积分中心的接口，按照业务规则，给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。用户信息变更公司的用户信息，统一由用户中心维护，而用户信息的变更需要同步给各业务子系统，业务子系统再根据变更内容，处理各自业务。用户中心作为 MQ 的 producer，添加通知给 MQ。APP Server 订阅该消息，同步本地数据信息，再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制，目前主要使用 ActiveMQ，基于 Virtual Topic 的订阅方式，保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点 (technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种： 第一种是集中式 LB 方案，如下图 Fig 1，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。LB 上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向 LB 发起请求，由 LB 以某种策略（比如 Round-Robin）做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢？通常的做法是通过 DNS，运维人员为服务配置一个 DNS 域名，这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单，在 LB 上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题，所有服务调用流量都经过 LB，当服务数量和调用量大的时候，LB 容易成为瓶颈，且一旦 LB 发生故障对整个系统的影响是灾难性的。另外，LB 在服务消费方和服务提供方之间增加了一跳 (hop)，有一定性能开销。 第二种是进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案，下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的 LB 组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高，一般采用能满足高可用分布式一致的组件（例如 Zookeeper, Consul, Etcd 等）来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案，LB 和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架，对应的组件分别是：Eureka 服务注册表，Karyon 服务端框架支持服务自注册和健康检查，Ribbon 客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡，见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案，没有单点问题，一个 LB 进程挂了只影响该主机上的服务调用方，服务调用方和 LB 之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架，对应组件分别是：Zookeeper 作为服务注册表，Nerve 独立进程负责服务注册和健康检查，Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes，其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关 (Service Gateway)，见图 Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用： 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试 (Surgical debugging)，金丝雀测试 (Canary Testing)，数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层，有一定的计算逻辑，一般以集群方式部署，前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul，特点是动态可热部署的过滤器 (filter) 机制，其它如 HAproxy，Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务 Middle Tier Service）和前端服务（也称边缘服务 Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如 PC，Pad 或者 Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似 Proxy 代理或者 Façade 门面模式，而服务注册表和服务自注册自发现类似 IoC 依赖注入模式，微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源 (线程，队列等) 被耗尽，造成所谓的雪崩效应 (Cascading Failure，见图 Fig 7)，严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括： Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态 (Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态 (Open)，后续一段时间内的所有调用都会被拒绝 (Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态 (Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子，假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务，且部署 A 的容器一共有 120 个工作线程，采用线程隔离机制，可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程，当 Svc2 慢了，给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽，线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响，如果没有这种隔离机制，当 Svc2 慢的时候，120 个工作线程会很快全部被对 Svc2 的调用吃光，整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量 (秒杀，双十一) 时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许 100 个并发调用，对超过这个限制的请求要拒绝并回退。回退 (fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败 (Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中，凡是需要容错的依赖点 (服务，缓存，数据库访问等)，开发人员只需要将调用封装在 Hystrix Command 里头，则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证，是 Netflix 微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。 服务框架微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑，包括： Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查，假定采用进程内 LB 方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。监控日志，框架一方面要记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。REST/RPC 和序列化，框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来，HTTP/REST 是当前主流 API 暴露方式，在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出 Ajax 友好的 JSON 消息格式，而对无线设备上的 Native App，框架支持输出性能高的 Binary 消息格式。配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon，Spring 的 Spring Boot/Cloud，阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境 (开发 / 测试 / 生产) 一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销 (假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf，360 的 QConf，Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司，几年前，Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括： Eureka:　服务注册发现框架Zuul:　服务网关Karyon:　服务端框架Ribbon:　客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系，来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品，主要是基于对 Netflix 开源组件的进一步封装，方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。 原文地址：https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

Java之JVM垃圾回收 内存结构以及垃圾回收算法前言：由于小组技术分享的需要，懂的不是很多所以我就找了这个我自己感兴趣的知识点给大家做个简单的介绍。由于是新人，算不了很懂，只是总结性的讲了些概念性的东西。给大家分享的同时，算是给自己做个笔记吧。作为Java语言的核心之一，JVM垃圾回收帮我们解决了让我们很头疼的垃圾回收问题。我们不需要像VC++一样，作为内存管理的统治者需要我们对我们分配的每一块内存进行回收，否则就会造成内存泄露问题。是不是只要有JVM存在我们就不会出现内存泄露问题，出现内存泄露问题我们又该怎么办，如果我们想提高我们程序的稳定性和其他性能我们能从什么地方下手！！！相信这些问题是我们程序过程中不可逾越的。了解JVM的内存分配及其相应的垃圾回收机制，不仅仅是可以了解底层的JVM运行机制，而且对于程序性能的优化和提升还是很有必要的。一、JVM内存分配区域结构图一从图一可以看出JVM中的内存分配包括PC Register(PC寄存器) JVM栈 堆（Heap） 方法区域（MethodArea）运行时常量池（RuntimeConstant Pool） 本地方法堆栈（NativeMethod Stacks），这几部分区域但是从程序员的角度来看我们只关注JVM Heap和JVM Stack，因为这两部分是直接关系程序运行期间的内存状态，所以我会主要介绍这两部分内存，其他的我只是给出了简单的一些概念性解释：PC Register(Program Counter 寄存器):主要作用是记录当前线程所执行的字节码的行号。方法区域（MethodArea）:方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，法区域也是全局共享的，它在虚拟机启动时在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。运行时常量池（RuntimeConstant Pool):存放的为类中的固定的常量信息、方法和Field的引用信息等，其空间从方法区域中分配。本地方法堆栈（NativeMethod Stacks）:JVM采用本地方法堆栈来支持native方法的执行，此区域用于存储每个native方法调用的状态。JVM栈：主要存放一些基本类型的变量和对象的引用变量。JVM堆：用来存放由 new 创建的对象和数组Java 虚拟机的自动垃圾回收器来管理（注意数组也是对象，所以说数组也是存放在JVM堆中）。由于栈中存放的是主要存放一些基本类型的变量和对象的引用变量，所以当过了变量的作用区域或者是当程序运行结束后它所占用的内存会自动的释放掉，所以不用来关心，下面我们主要来说的是堆内存的分配以及回收的算法。二、JVM堆内存介绍工欲善其事，必先利其器。所以了解堆内存的内部结构是很必要的。在Jvm中堆空间划分为三个代：年轻代（Young Generation）、年老代（Old Generation）和永久代（Permanent Generation）。年轻带主要是动态的存储，年轻带主要储存新产生的对象，年老代储存年龄大些的对象，永久带主要是存储的是java的类信息，包括解析得到的方法、属性、字段等。永久带基本不参与垃圾回收。所以说我们说的垃圾回收主要是针对年轻代和年老代。图二年轻代又分成3个部分，一个eden区和两个相同的survior区。刚开始创建的对象都是放置在eden区的。分成这样3个部分，主要是为了生命周期短的对象尽量留在年轻带。当eden区申请不到空间的时候，进行minorGC，把存活的对象拷贝到survior。年老代主要存放生命周期比较长的对象，比如缓存对象。（经过IBM的一个研究机构研究数据表明，基本上80%-98%的对象都会在年轻代的Eden区死掉从而本回收掉，所以说真正进入到老年代的对象很少，这也是为什么MinorGC比MajorGC更加频繁的原因）具体JVM内存垃圾回收过程描述如下 ：1、对象在Eden区完成内存分配2、当Eden区满了，再创建对象，会因为申请不到空间，触发minorGC，进行young(eden+1survivor)区的垃圾回收3、minorGC时，Eden不能被回收的对象被放入到空的survivor（Eden肯定会被清空），另一个survivor里不能被GC回收的对象也会被放入这个survivor，始终保证一个survivor是空的4、当做第3步的时候，如果发现survivor满了，则这些对象被copy到old区，或者survivor并没有满，但是有些对象已经足够Old，也被放入Old区 XX:MaxTenuringThreshold5、当Old区被放满的之后，进行fullGC补充： MinorGC：年轻代所进行的垃圾回收，非常频繁，一般回收速度也比较快。 MajorGC：老年代进行的垃圾回收，发生一次MajorGC至少伴随一次MinorGC，一般比MinorGC速度慢十倍以上。 FullGC：整个堆内存进行的垃圾回收，很多时候是MajorGC 以后就是堆内存结构已经大致的垃圾回收过程。三、对象分配原则1.对象优先分配在Eden区，如果Eden区没有足够的空间时，虚拟机执行一次Minor GC。2.大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。3.长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄计数器，如果对象经过了1次Minor GC那么对象会进入Survivor区，之后每经过一次Minor GC那么对象的年龄加1，知道达到阀值对象进入老年区。4.动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代。5.空间分配担保。每次进行Minor GC时，JVM会计算Survivor区移至老年区的对象的平均大小，如果这个值大于老年区的剩余值大小则进行一次Full GC，如果小于检查HandlePromotionFailure设置，如果true则只进行Monitor GC,如果false则进行Full GC。四、垃圾收集器作为JVM中的核心之一垃圾收集器，主要完成的功能包括：（1）发现无用信息对象；（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。所以说我们在实现垃圾收集器的同时就要实现两个算法一个是发现无用的对象第二就是回收该对象的内存。收集器主要分为引用计数器和跟踪收集器两种，Sun JDK中采用跟踪收集器作为GC实现策略。发现无用对象只要的实现算法包括引用计数法和根搜索算法，引用计数法主要是JVM的早期实现方法，因为引用计数无法解决循环引用的问题，所以现在JVM实现的主要是根搜索算法，引用计数法：堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时，引用计数器置为1。当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用)，引用计数器减1，一旦引用计数器为0，对象就不可用从而可以被回收。 根搜索算法：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。目前的收集器主要有三种：串行收集器：使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高并行收集器：对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用并发收集器：可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用五、垃圾收集器的回收算法Copying算法：算法：复制采用的方式为从根集合扫描出存活的对象，并将找到的存活对象复制到一块新的完全未使用的空间中。 过程： 此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。Mark-Sweep算法： 算法：标记-清除采用的方式为从根集合开始扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未标记的对象，并进行回收。 过程： 第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。它停止所有工作，收集器从根开始访问每一个活跃的节点，标记它所访问的每一个节点。走过所有引用后，收集就完成了，然后就对堆进行清除（即对堆中的每一个对象进行检查），所有没有标记的对象都作为垃圾回收并返回空闲列表。Mark-Compact算法： 算法：标记阶段与“Mark-Sweep”算法相同，但在清除阶段有所不同。在回收不存活对象所占用的内存空间后，会将其他所有存活对象都往左端空闲的空间进行移动，并更新引用其对象指针。过程：此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。Sun JDK GC策略：新生代算法实现：Copying,Copying,Copying旧生代算发实现：Mark-Sweep-Compact，Mark –Compact，Mark –Sweep！！六、JvisuaVM 工具如果我们想优化自己的程序，那么我们就必须清楚的了解不同代码程序所消耗的性能多少，作为JDK的一部分，这个工具给我们提供了很大的帮助。这个工具可以在JDK的bin目录下找到，功能很强大，可以注意利用

回 3楼(荣威090) 的帖子 您好， 请问您的ECS远程不到桌面了吗？ 在“连接管理终端”里，能看到系统的运行状态吗？ ------------------------- 回 1楼(51干警网) 的帖子 您好， 按这里的说明，应该是支持Windows 7的： https://help.aliyun.com/document_detail/ecs/operation-guide/image-operation/import.html ------------------------- 回 2楼(ivmmff) 的帖子 您好， 是的。因为这里仅是测试能不能安装Windows 7，并不确定Windows 7用得顺不顺手。 ------------------------- 回 10楼(tufu) 的帖子 您好， 要具体看您的应用要求喔。 如例子中2GB内存，装32位的Windows 7系统，基本操作算是流畅的。 但如果您的应用涉及到视频处理（如游戏之类的）那可能就不适合了，因为ECS没有视频处理特长（通俗一点说，没独立显卡）。 ------------------------- 回 13楼(shikelang) 的帖子 您好， 请问当前您的DNS服务器地址是什么呢？ 如果是阿里云内网的IP地址（如100.100.2.136），可尝试更换为公共可使用的谷歌DNS，8.8.8.8试试喔。 ------------------------- 回 16楼(史拂尘) 的帖子 您好， 目前的测试结果是：在Xen虚拟化平台里测试安装Windows Server 2016预览版本4，会无法识别网卡等设备。如果安装阿里云Windows 2012系统里的PCI设备驱动，会导致Windows 2016系统无法启动。 即，现在考虑的问题，可能是驱动问题。 如您有兴趣，可以在KVM虚拟化平台里测试安装哩。 ------------------------- 回 20楼(小小的小孩) 的帖子 您好， 可能您需要留意一下，系统中的两张网卡，哪张网卡是公网的。 假如您将公网的IP地址填写到内网的网卡上，是无效，导致系统不能与互联网连接的喔。 ------------------------- 回 25楼(seaway) 的帖子 您好， 欢迎来到阿里云论坛。 我当时没有用Windows 2012来测试， 您可以先将ECS更换到Windows 2008系统后，再次测试。 请问您的ECS是什么配置的呢？ ------------------------- 回 27楼(白色秋天) 的帖子 您好， 欢迎来到阿里云论坛。 可能原因是：如阿里云提供的是服务平台，首选是Windows Server系统，并不是如Windows 7的桌面系统。 在客户需求上，可能绝大多数是用于跑后端服务的，这需要Windows Server系统，个人觉得需求比例可能是1:1000（Windows 7: Windows Server）或以上。 ------------------------- 回 29楼(sgf) 的帖子 您好， 我没有尝试过使用dd命令来安装Windows 系统喔。 ------------------------- 回 31楼(李的的) 的帖子 您好， 欢迎来到阿里云论坛。 请问您原操作系统是64位的吗？ 如果是，且有保留原系统的目录，或许可以尝试搜寻一下，看是否有合适的驱动程序文件。 ------------------------- 回 34楼(fenglp) 的帖子 您好， 欢迎来到阿里云论坛。 或许您可以尝试在“管理终端”里运行这个软件，对比看看有没有不同的效果： https://help.aliyun.com/document_detail/25433.html ------------------------- 回 36楼(fenglp) 的帖子 您好， 意思是从“管理终端”里登录到Windows的桌面，再在桌面里运行软件程序哩。 ------------------------- 回 38楼(fenglp) 的帖子 您好， 很高兴听到您已经解决了问题，且更新了回复。 ------------------------- 回 44楼(萨德12213) 的帖子 版主回复： 请问当前系统是否可以识别到网卡设备呢？ ------------------------- 回 46楼(jikechenhao) 的帖子 版主回复： 请问您的ECS实例都是“专有网络”的带宽类型吗？ 实例们是在同一个虚拟交换机里吗？ ------------------------- 回 48楼(笔芯锅) 的帖子 版主回复： 可向微软购买，或在网上搜索下载试用版本。 ------------------------- 回 54楼(何谓浪子) 的帖子 您好，我没有在轻量应用服务器产品上测试过，但乐观地估计，可能差不多。