• 关于 备份技术如何看配置 的搜索结果

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 34170 浏览量 回答数 10

问题

【我是分享王】多台阿里云服务器结合SLB和RDS,碉堡了!

irvinchoi 2019-12-01 20:23:10 19050 浏览量 回答数 9

问题

数据库百问,教你快速上手数据库

yq传送门 2019-12-01 20:16:46 29208 浏览量 回答数 21

新用户福利专场,云服务器ECS低至102元/年

新用户专场,1核2G 102元/年起,2核4G 699.8元/年起

回答

微服务 (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

auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

回答

Re万网阿里云服务器ECS电话技术支持人员太不专业 看贴回贴好习惯,楼主自己做 ------------------------- Re万网阿里云服务器ECS电话技术支持人员太不专业 引用第2楼weili于2014-12-06 23:48发表的  : 这个问题我先记录下,周一上班了我反馈跟进一下 [url=http://bbs.aliyun.com/job.php?action=topost&tid=187226&pid=591064][/url] 原来管理员在民间啊,感谢你的回复,解不解决一回事,这个话听着舒服,不过我们还是不等了,因为不知你们产品后方会不会加需要的镜象,今天我给做成2008系统+2005企业版数据库了,你们唯一可选的2003标准版真心用不了! ------------------------- Re万网阿里云服务器ECS电话技术支持人员太不专业 重在落实和准确的时间进度! 自从我们发了这个贴子,已经有多个你们的用户主动联系我问我如何解决,他们遇到了同样的问题,刚才有一个客户和我讲他在别的区买的更高配置的装这个版本的系统也是同样的问题,为了证明你们这个系统镜象问题他有在线下载微软系统在线重新安装修复系统,修复后的系统可以安装,也有反馈给你们售后,换掉有问题的镜象增加无问题的镜象这对你们应是一件好事吧,有这么难,迟迟不能解决,我们那台我查了下是2号买的,十来天了还是反馈中....... ------------------------- Re万网阿里云服务器ECS电话技术支持人员太不专业 楼上的两位讲的真心没看懂,所以不回复了!是不是及时客户才有 发言权,取决于解决问题的时间 刚看了一下后台回复: 您好,您的问题我们会今天9点后反馈给产品核实。其次,目前新的系统等,短时间内可能无法增加,建议您可以尝试使用windows 2008 企业版 。 我就不评论什么了! 然后九点后的回复,我就更不想评论了: 您好,关于2003企业版镜像没有和2008企业版镜像同时提供的原因主要考虑的是微软在明年7月份停止支持,届时可能会产生较多的安全性。 您的这个问题我们已经反馈给产品,充分考虑这类需求,需要一个评估周期,还请您谅解。 ------------------------- Re万网阿里云服务器ECS电话技术支持人员太不专业 本着发贴要负责的态度,对使用阿里云遇到同样问题的客户,又因所需环境无法用2008系统代替换的客户,在这里公布一下热心用户自行解的方法,以供大家参考! 因为我司的提问从2号提出到现在,反馈结果无明显进度和实质解决,所以对此前询问我司此问题处理进度的客户表示遗憾和抱歉,我们的提议目前看短时间内不会被采纳! 客户可以偿试自行反馈!,我司无时间在跟进此产品支持问题! 据网易报道:对于微软对2003的升级支持问题,官方公布的时间是2015年7月14日停止对Windows Server 2003的支持,其实Windows Server 2003的企业用户大部分也是Windows XP用户,他们在微软与今年4月8日停止对XP的支持之前也收到过微软发出的最后期限警告,所以微软宣布将停止支持Windows Server 2003的消息并未让这些企业感到惊讶,但是考虑到即便微软停止了对XP的支持,该操作系统目前的使用情况仍然比较稳定,所以貌似他们没有更新操作系统的必要。 所以阿里云为微软和客户安全上的顾虑完全没有必要,在服务期内提供应提供的服务就可以了,未来的事客户自己决定比较好!微软以后还会停止对2008的升级支持,不能因为这个就提前停止,服务是有延续性的,而不是提前终止. 以下是使用阿里云热心用户在同样未能得到售后解决技术问题后,自行解决的办法: 他碰到的情况是相同的,但他有两台,一个可以装,一个不可以装,系统版本全是阿里提供的标准版,区别就是阿里原来的老镜象可以,新提供的镜象有问题装不了,基本排除和配置有关,因为他用为此事买了一个月2G内存的用此新镜象也装不了,初步结论是现在这个镜象问题,他在微软官方下了这个版本系统先自行在线修复了阿里云提供的系统,然后在安数据库,成功解决,大家可以偿试一他的方法,如果还有疑问请直接向阿里反馈,本人在此表示力不从心,无时间跟进此事,因此事结识的朋友欢迎以后交流其他问题,共同学习进步! 另外我司也和万网方面态度一至,建议用户提高系统版本,对不支持的软件方要求提供升级服务,本方法仅建议无法更换系统的用户测试,因未亲自测试,所以不保证什么,也不承担责任,偿式前请做好备份工作,特此提醒. 北京亿网技术---张(球球:574715671) ------------------------- Re回楼主北京亿网的帖子 引用第10楼sunfei于2014-12-10 13:37发表的 回 楼主(北京亿网) 的帖子 : 看了楼主的帖子,感觉楼主是个很认真做事的人,希望这个问题能早日解决,虽然我不用win系统(只用linux) [url=http://bbs.aliyun.com/job.php?action=topost&tid=187226&pid=592557][/url] 嗯,用什么系统主要看我们的客户需要,认真是技术人员的职业病,解决问题有很多方法,但在技术眼里查明问题才是最重要的,虽然阿里未给解决,但问题已经查明是阿里提供的镜象有问题,系统镜象简化到影响到正常功能,要用微软此版本系统修复才能用,我要求提供的企业版和服务版也可解决,但未能提供,这对我们来说已经不重要,只是苦了那些没技术人员的客户,我这还经常有客户来问怎么解决.

北京亿网 2019-12-02 01:11:35 0 浏览量 回答数 0

问题

阿里云服务器 如何处理网站高并发流量问题?(含教程)

元芳啊 2019-12-01 21:54:35 1511 浏览量 回答数 1

回答

无法启动一一想,前几天装了XAMPPP,是不是被挤掉了,马上跑到服务项里一看,啥都没,两者的服务都没。试试XAMPP,能启动。原生的APACHE就是启动不了,服务都不存在! 上网搜资料,都说是80端口被占用,马上netstat -aon|findstr "80",一看1388占用了80,可是这个是火狐浏览器。。。总不能不用浏览器吧。这个明显不对。既然服务都不存在,那解决办法应该是安装服务才对。 立马,安装服务。进入APACHE的BIN目录,命令行界面运行HTTPD,执行httpd -k install -n "apache",安装APACHE服务,命令行给出如下提示:Could not reliably determine the server's fully qualified domain name, using 192.168.5.201 for ServerName. 好办,打开httpd.conf配置文件,添加 ServerName localhost:80,再重新运行ApacheMonitor.exe,好了。看了下以前的备份配置文件,这一行被注释掉的。以前为什么行,后来安装 了其他集成套件就不行了,原因还不是很清楚。APACHE配置还要熟悉熟悉哈。 ----------------------还有一种情况---------------启动apache。但是启动时候却报错,无法重启。查看apache的错误日志文件,显示Unclean shutdown of previous Apache run?到网上搜了一下,一般有两种出错的可能性:第一:[warn] pid file D:/apache2.2/logs/httpd.pid overwritten — Unclean shutdown of previous Apache run?需要删除对应的apache pid文件。但是大多数人遇到的不是这种情况第二种情况:php模块添加错误。比如说dll文件没有按照规定放入php/ext目录下,比如说php.ini文件书写错误。如果都没有发现,那就试试把新添加的模块删除掉在试试。最大的可能就是新增加的扩展不兼容php对应的版本,以及扩展找不到等。可以先运行php.exe来测试下,如果是扩展问题,会弹窗提示的。 apache服务无法启动 提示服务启动后又停止系统:WindowsXP Professional Service Pack2wamp5集成安装包测试80端口显示:“Your port 80 is not actually used.”(即使更改apache的端口到8080同样无法启动) 错误日志如下: [Fri Nov 26 10:43:26 2010] [notice] Server built: Jan 18 2008 00:37:19[Fri Nov 26 10:43:26 2010] [notice] Parent: Created child process 1060[Fri Nov 26 10:43:26 2010] [notice] Child 1060: Child process is running[Fri Nov 26 10:43:26 2010] crit提供了一个无效的参数。 : Child 1060: setup_inherited_listeners(), WSASocket failed to open the inherited socket.[Fri Nov 26 10:43:27 2010] [crit] Parent: child process exited with status 3 -- Aborting.[Fri Nov 26 10:44:57 2010] [notice] Apache/2.2.8 (Win32) PHP/5.2.6 configured -- resuming normal operations[Fri Nov 26 10:44:57 2010] [notice] Server built: Jan 18 2008 00:37:19[Fri Nov 26 10:44:57 2010] [notice] Parent: Created child process 6100[Fri Nov 26 10:44:58 2010] [notice] Child 6100: Child process is running[Fri Nov 26 10:44:58 2010] crit提供了一个无效的参数。 : Child 6100: setup_inherited_listeners(), WSASocket failed to open the inherited socket.[Fri Nov 26 10:44:58 2010] [crit] Parent: child process exited with status 3 -- Aborting.[Fri Nov 26 10:45:50 2010] [notice] Apache/2.2.8 (Win32) PHP/5.2.6 configured -- resuming normal operations[Fri Nov 26 10:45:50 2010] [notice] Server built: Jan 18 2008 00:37:19[Fri Nov 26 10:45:50 2010] [notice] Parent: Created child process 4180[Fri Nov 26 10:45:50 2010] [notice] Child 4180: Child process is running[Fri Nov 26 10:45:50 2010] crit提供了一个无效的参数。 : Child 4180: setup_inherited_listeners(), WSASocket failed to open the inherited socket.[Fri Nov 26 10:45:50 2010] [crit] Parent: child process exited with status 3 -- Aborting. [Fri Nov 26 10:49:46 2010] [notice] Apache/2.2.8 (Win32) PHP/5.2.6 configured -- resuming 卸载此安装包N次并且每次都彻底删除,并且把注册表中的残余服务也删除干净,并安了N次,仍然不能启动apache服务(本安装包在网吧能正常安装并使用)。经过一番网搜以及我司技术员的讨论和探索,终于找到了解决办法:本地连接---属性----Internet 协议(TCP/IP)---属性---高级---wins----导入LMHOSTS(M)把 {apache2dir}binhttpd.exe 添加进去就可以启动了比如:httpd.exe的路径为“F:wamp2binapacheapache2.2.8binhttpd.exe”,那么{apache2dir}就是“F:wamp2binapacheapache2.2.8”Windows 系统下配置 Apache 服务有时会遇到Apache2 服务无法启动。发生服务特定错误: 1.请键入 NET HELPMSG 3547 以获得更多的帮助。的错误,这种错误可能有多种原因引起。我今天发现配置文件注释用得不对也是造成这个错误的一个原因:配置文件 httpd.conf 中如果写注释,注释以 # 开头必须单独放在一行中。而在某个配置项同一行写了 # 注释,就会造成以上无法启动的问题。解决办法就是把注释都单独放在一行。这只是无法启动的一个可能的原因 服务可以启动但是输入localhost无法打开页面这一般是netbios解析失败造成的。解决的办法很简单,步骤如下:1 在"网上邻居"上 点右键,菜单上选"属性(R)"。出来"网络连接"窗口,在"本地连接"上点右键,菜单中点"属性(R)"。出来"本地连接 属性"面板,在"此链接使用下列项目"中找到:"Internet 协议 (TCP/IP)",并点击它。在弹出的"Internet 协议 (TCP/IP) 属性"面板上,点击"高级(V)..."按钮。"高级 TCP/IP 设置"面板上点"WINS"选项标签,去掉"启用 LMHOSTS 查询(L)"前面的勾,点"确定"按钮。2 打开"控制面板",点击"Windows 防火墙",点击"高级"选项标签,选择"本地连接",并点击旁边的"设置(T)..."按钮。在服务选项中找到"安全 Web 服务器(HTTPS)",并把它勾选上,点"确定"按钮。最后一类问题 php文件无法解析当你万分惊喜的发现可以打开http://localhost 并看到apache的"IT works!"的页面时,你很激动的马上测试一个phpnifo的页面,却发现无法解析。这是因为,apache不知道如何解析php文件。虽然 LoadModule和AddType语句已经告诉apache 载入php模块并注意php后缀的文件,但是真正的解析还是要调用php5ts.dll等等文件,所以方案一:在path里添加php所在目录 并在httpd.conf里添加PHPiniDir "D:/php-5.2.5-Win32/"方案二:直接将php5ts.dll从php目录拷贝到apache的bin目录即可另外有一点需要注意 apache2.2以上的版本需要使用php5apache2_2.dll在php5.2.5 已经自带了 而使用以前的版本,譬如php5.1请到http://php.net下载补丁php5apache2.dll-php5.1.x.rar并解压.共有三个文件.vcredist_x86.exephp5apache2.dllhttpd.exe.manifest1.将 php5apache2.dll 覆盖掉你原来PHP目录下的 php5apache2.dll 文件.2.将 httpd.exe.manifest 文件复制到你的apache安装目录下的bin文件夹下.3.双击运行vcredist_x86.exe安装.(如果您的系统里已安装了 .NET framework 2.就可以省掉这一步)完成!重启你的apache2.2试试吧.当然,使用php5.2.5 完全不用管这个问题!

我的中国 2019-12-02 01:33:20 0 浏览量 回答数 0

回答

1.产品2.UI3.CSS4.JS5.后端(Java/php/python)6.DBA(mysql/oracle)7.运维(OP) 8.测试(QA)9.算法(分类/聚类/关系抽取/实体识别)10.搜索(Lucene/Solr/elasticSearch)11.大数据工程师(Hadoop)12.Android13.IOS14.运营 一.产品1 工作内容:了解用户需求,做竞品调研,画产品原型,写产品文档,讲解产品需求,测试产品Bug,收集用户反馈,苦练金刚罩以防止程序员拿刀砍。2 需要技能:PPT,Word, Axure,XP,MVP,行业知识,沟通。 二. UI1 工作内容:收到产品原型,给原型上色,偶尔会自作主张调整下原型的位置,出不同的风格给老板和客户选,然后听他们的意见给出一个自己极不喜欢的风格,最好给Android,IOS或者是CSS做好标注,还有的需要直接帮他们切好图,最后要练出来象素眼,看看这些不靠谱的程序员们有没有上错色或者是有偏差。2 需要技能:PS,Illustrator,Sketch,耐性,找素材。 三. CSS1 工作内容:产品设计好原型,UI做出来了效果图,剩下的就是CSS工程师用代码把静态文件写出来的。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【PS,域名,Html,Html5,CSS,CSS3】扩展【自适应,响应式,Bootstrap,Less,Flex】 四 .JS 1 工作内容:JS工程师其实分成两类,在之前讲CSS的时候已经提到过,一个是套页面的,一个是前后端分离的。对这两个概念还是分不太清的,可以回过头去看CSS的部分。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【Http,REST,跨域,语法,组件,F12,Json,Websocket】框架【JQuery,AngularJS,Bower,RequireJS,GruntJS,ReactJS,PhoneGap】业务【金融,教育,医疗,汽车,房产等等等等各种行业】 五 .后端(Java/python/go) 1 工作内容:大部分的后端工程师都停留在功能实现的层面上。这是现在国内二流或者是三流的公司的现状,甚至是在某些一流的公司。很多时候都是架构师出了架构设计,更多的外包公司根本就是有DBA来做设计,然后后端程序员从JS到CSS到Java全写,完全就是一个通道,所有的复杂逻辑全部交给DB来做,这也是几年前DBA很受重视的原因。 2 需要技能:环境【IDE(Idea/Eclipse,Maven,jenkins,Nexus,Jetty,Shell,Host),源码管理(SVN/Git) ,WEB服务器(nginx,tomcat,Resin)】基础【Http,REST,跨域,语法,Websocket,数据库,计算机网络,操作系统,算法,数据结构】框架【Spring,AOP,Quartz,Json TagLib,tiles,activeMQ,memcache,redis,mybatis,log4j,junit等等等等等】业务【金融,教育,医疗,汽车,房产等等等等各种行业】。 六 .DBA  1 工作内容:如果你做了一个DBA,基本上会遇到两种情况。一种是你的后端工程师懂架构,知道怎么合便使用DB,知道如何防止穿透DB,那么恭喜你,你只是需要当一个DB技术兜底的顾问就好,基本上没什么活可以做,做个监控,写个统计就好了。你可以花时间在MongoDB了,Hadoop了这些,随便玩玩儿。再按照我之前说的,做好数据备份。如果需求变动比较大,往往会牵涉到一些线上数据的更改,那么就在发布的时候安静的等着,等着他们出问题。。。。如果不出问题就可以回家睡觉了。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop】工具【各种DB的版本,工具,备份,日志等】。 七. 运维  1 工作内容:运维的工作大概分成几个部分,我对于修真院学习运维的少年们都这么说,大概是:A。基础环境的搭建和常用软件的安装和配置(兼网管的还有各种程控机),常用软件指的是SVN,Git,邮箱这种,更细节的内容请参考修真院对于运维职业的介绍。B。日常的发布和维护,如刚刚讲到的一样,测试环境和线上环境的发布和记录,原则上,对线上所有的变更都应该有记录。C。数据的备份和服务的监控&安全配置。各种数据,都要做好备份和回滚的手段,提前准备好各种紧急预案,服务的监制要做好。安全始终都是不怎么被重点考虑的问题,因为这个东西无底洞,你永远不知道做到什么程度算是比较安全了,所以大多数都是看着情况来。D。运维工具的编写。这一点在大的云服务器商里格外常见,大公司也是一样的。E。Hadoop相关的大数据体系架构的运维,确实有公司在用几百台机器做Hadoop,所以虽然不常见,我还是列出来吧。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop,nginx,apache,F5,lvs,vpn,iptable,svn,git,memcache,redis】工具【linux 常用工具,Mysql常用工具,Jenkins,zabbix,nagios】自动化运维【openstack,docker,ansible】语言【shell,python】 八 .QA  1 工作内容:QA需要了解需求,很多公司会要求QA写测试用例,我觉得是扯淡。完全是在浪费时间。通常开发三周,QA测试的时间只有一周到一周半。还有关于提前写测试用例的,都不靠谱。 2 需要技能:流程【Bug修复流程,版本发布流程】工具【禅道,BugZilla,Jira,Excel表格来统计Bug数,自动化测试】性格【严谨,耐心】 九. 算法工程师  1 工作内容:算法工程师的工作内容,大部分时间都是在调优。就是调各种参数和语料,寻找特征,验证结果,排除噪音。也会和Hadoop神马的打一些交道,mahout神马的,我那个时候还在用JavaML。现在并不知道有没有什么更好用的工具了。有的时候还要自己去标注语料---当然大部分人都不爱做这个事儿,会找漂亮的小编辑去做。2 需要技能:基础【机器学习,数据挖掘】工具【Mahout,JavaML等其他的算法工具集】 十. 搜索工程师  1 工作内容: 所以搜索现在其实分成两种。一种是传统的搜索。包括:A。抓取 B。解析C。去重D。处理E。索引F。查询另一种是做为架构的搜索。并不包括之前的抓取解析去重,只有索引和查询。A。索引B。查询 2 需要技能:环境【Linux】框架【Luence,Slor,ElasticSearch,Cassandra,MongoDB】算法【倒排索引,权重计算公式,去重算法,Facet搜索的原理,高亮算法,实时索引】 十一. 大数据工程师  1 工作内容:工作内容在前期会比较多一些,基础搭建还是一个挺讲究的事儿。系统搭建好之后呢,大概是两种,一种是向大数据部门提交任务,跑一圈给你。一种是持续的文本信息处理中增加新的处理模块,像我之前说的增加个分类啦,实体识别神马的。好吧第一种其实我也不记得是从哪得来的印象了,我是没有见到过的。架构稳定了之后,大数据部门的工作并不太多,常常会和算法工程师混到一起来。其他的应该就是大数据周边产品的开发工作了。再去解决一些Bug什么的。2 需要技能:环境【Linux】框架【Hadoo,spark,storm,pig,hive,mahout,zookeeper 】算法【mapreduce,hdfs,zookeeper】。 十二. Android工程师  1 工作内容:Android工程师的日常就是听产品经理讲需求,跟后端定接口,听QA反馈哪款机器不兼容,闹着申请各种测试机,以及悲催的用Android做IOS的控件。 2 需要技能:环境【Android Studio,Maven,Gradle】基础【数据结构,Java,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】 十三. IOS工程师  1 工作内容:IOS工程师的工作内容真的挺简单的,听需求,定接口。做个适配,抛弃一下iphone4。还有啥。。马丹,以我为数不多的IOS知识来讲,真的不知道还有啥了。我知道的比较复杂的系统也是各种背景高斯模糊,各种渐变,各种图片滤镜处理,其他并没有什么。支付,地图,统计这些东西。 嗯。2 需要技能:环境【Xcode】基础【数据结构,Object,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】

行者武松 2019-12-02 01:21:45 0 浏览量 回答数 0

问题

客户案例借助阿里云,我们终于可以只关注产品研发了【云上的故事】

pay 2019-12-01 21:57:35 7071 浏览量 回答数 1

问题

简单谈谈新手如何选择云主机或VPS或虚拟主机

ap2836i0b 2019-12-01 20:55:48 14063 浏览量 回答数 3

问题

运维人员处理云服务器故障方法七七云转载

杨经理 2019-12-01 22:03:10 9677 浏览量 回答数 2

问题

OSS让你体验超大文件上传、下载,飞一般的感觉(新手必看)

聚小编 2019-12-01 20:29:02 14239 浏览量 回答数 4

问题

让云计算真正省钱,解决云存储架构九个问题让云计算真正省钱

hamtyb 2019-12-01 20:27:33 11001 浏览量 回答数 4

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

问题

【每日一教程6.18】HHVM安装使用教程-高效的PHP运行环境提升PHP性能9倍

李逵 2019-12-01 22:01:57 13700 浏览量 回答数 6

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

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

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

回答

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

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

回答

概述 当客户端访问目标服务器出现ping丢包或ping不通时,可以通过tracert或mtr等工具进行链路测试来判断问题根源。本文介绍如何通过工具进行链路测试和分析。 详细信息 阿里云提醒您: 如果您对实例或数据有修改、变更等风险操作,务必注意实例的容灾、容错能力,确保数据安全。 如果您对实例(包括但不限于ECS、RDS)等进行配置与数据修改,建议提前创建快照或开启RDS日志备份等功能。 如果您在阿里云平台授权或者提交过登录账号、密码等安全信息,建议您及时修改。 本文分别介绍如下链路测试方法。 链路测试工具 测试结果的简要分析 常见的链路异常场景 链路测试步骤 测试完成后的解决方法 链路测试工具 操作系统类型不同,链路测试所使用的工具也有所不同。简要介绍如下。 Linux系统 此处简单介绍两个链路测试工具。 工具一:mtr命令 mtr(My traceroute)几乎是所有Linux发行版本预装的网络测试工具。其将ping和traceroute的功能合并,所以功能更强大。mtr默认发送ICMP数据包进行链路探测。您也可以通过“-u”参数来指定使用UDP数据包进行探测。相对于traceroute只会做一次链路跟踪测试,mtr会对链路上的相关节点做持续探测并给出相应的统计信息。所以,mtr能避免节点波动对测试结果的影响,所以其测试结果更正确,建议优先使用。 用法说明 mtr [-BfhvrwctglxspQomniuT46] [--help] [--version] [--report] [--report-wide] [--report-cycles=COUNT] [--curses] [--gtk] [--csv|-C] [--raw] [--xml] [--split] [--mpls] [--no-dns] [--show-ips] [--address interface] [--filename=FILE|-F] [--ipinfo=item_no|-y item_no] [--aslookup|-z] [--psize=bytes/-s bytes] [--order fields] [--report-wide|-w] [--inet] [--inet6] [--max-ttl=NUM] [--first-ttl=NUM] [--bitpattern=NUM] [--tos=NUM] [--udp] [--tcp] [--port=PORT] [--timeout=SECONDS] [--interval=SECONDS] HOSTNAME 常见可选参数说明 --report:以报告模式显示输出。 --split:将每次追踪的结果分别列出来,而非统计整个结果。 --psize:指定ping数据包的大小。 --no-dns:不对IP地址做域名反解析。 --address:主机有多个IP地址时,设置发送数据包的IP地址。 -4:只使用IPv4协议。 -6:只使用IPv6协议。 另外,也可以在mtr运行过程中,输入类似如下的字母来快速切换模式。 ?或h:显示帮助菜单。 d:切换显示模式。 n:启用或禁用DNS域名解析。 u:切换使用ICMP或UDP数据包进行探测。 命令输出示例 返回结果说明 默认配置下,返回结果中各数据列的说明如下。 第一列(Host):节点IP地址和域名。按 n 键可切换显示。 第二列(Loss%):节点丢包率。 第三列(Snt):每秒发送数据包数。默认值是10,可以通过“-c”参数指定。 第四列(Last):最近一次的探测延迟。 第五、六、七列(Avg、Best、Worst):分别是探测延迟的平均值、最小值和最大值。 第八列(StDev):标准偏差。越大说明相应节点越不稳定。 工具二:traceroute命令 traceroute也是几乎所有Linux发行版本预装的网络测试工具,用于跟踪Internet协议(IP)数据包传送到目标地址时经过的路径。traceroute先发送小的具有最大存活时间值(Max_TTL)的UDP探测数据包,然后侦听从网关开始的整个链路上的ICMP TIME_EXCEEDED响应。探测从TTL=1开始,TTL值逐步增加,直至接收到ICMP PORT_UNREACHABLE消息。ICMP PORT_UNREACHABLE消息用于标识目标主机已经被定位,或命令已经达到允许跟踪的最大TTL值。traceroute默认发送UDP数据包进行链路探测。可以通过“-I”参数来指定使用ICMP数据包进行探测。 用法说明 traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ] 常见可选参数说明 -d:使用Socket层级的排错功能。 -f:设置第一个检测数据包的存活数值TTL的大小。 -F:设置不要分段标识。 -g:设置来源路由网关,最多可设置8个。 -i:主机有多个网卡时,使用指定的网卡发送数据包。 -I:使用ICMP数据包替代UDP数据包进行探测。 -m:设置检测数据包的最大存活数值TTL的大小。 -n:直接使用IP地址而非主机名称(禁用DNS反查)。 -p:设置UDP传输协议的通信端口。 -r:忽略普通的Routing Table,直接将数据包发送到目标主机上。 -s:设置本地主机发送数据包的IP地址。 -t:设置检测数据包的TOS数值。 -v:详细显示指令的执行过程。 -w:设置等待远端主机回包时间。 -x:开启或关闭数据包的正确性检验。 命令输出示例 Windows系统 此处简单介绍两个链路测试工具。 工具一:WinMTR(建议优先使用) WinMTR是mtr工具在Windows环境下的图形化实现,但进行了功能简化,只支持部分mtr的参数。WinMTR默认发送ICMP数据包进行探测,无法切换。和mtr一样,相比tracert,WinMTR能避免节点波动对测试结果的影响,所以测试结果更正确。所以在WinMTR可用的情况下,建议优先使用WinMTR进行链路测试。 用法说明 WinMTR无需安装,直接解压运行即可。操作方法非常简单,说明如下。 如下图所示,运行程序后,在 Host 字段输入目标服务器域名或IP,注意不要包含空格。 单击 Start 开始测试。开始测试后,相应按钮变成了 Stop。 运行一段时间后,单击 Stop 停止测试。 其它选项说明如下。 Copy Text to clipboard:将测试结果以文本格式复制到粘贴板。 Copy HTML to clipboard:将测试结果以HTML格式复制到粘贴板。 Export TEXT:将测试结果以文本格式导出到指定文件。 Export HTML:将测试结果以HTML格式导出到指定文件。 Options:可选参数,包括的可选参数如下。 Interval(sec):每次探测的间隔(过期)时间。默认为1秒。 ping size(bytes):ping探测所使用的数据包大小,默认为64字节。 Max hosts in LRU list:LRU列表支持的最大主机数,默认值为128。 Resolve names:通过反查IP地址,以域名显示相关节点。 返回结果说明 默认配置下,返回结果中各数据列的说明如下。 第一列(Hostname):节点的IP或域名。 第二列(Nr):节点编号。 第三列(Loss%):节点丢包率。 第四列(Sent):已发送的数据包数量。 第五列(Recv):已成功接收的数据包数量。 第六、七、八、九列(Best 、Avg、Worst、Last):分别是到相应节点延迟的最小值、平均值、最大值和最后一次值。 工具二:tracert命令行工具 tracert(Trace Route)是Windows自带的网络诊断命令行程序,用于跟踪Internet协议(IP)数据包传送到目标地址时经过的路径。 tracert通过向目标地址发送 ICMP 数据包来确定到目标地址的路由。在这些数据包中,tracert使用了不同的IP“生存期”,即TTL值。由于要求沿途的路由器在转发数据包前必须至少将TTL减少1,因此TTL实际上相当于一个跃点计数器(hop counter)。当某个数据包的TTL达到0时,相应节点就会向源计算机发送一个ICMP超时的消息。 tracert第一次发送TTL为1的数据包,并在每次后续传输时将TTL增加1,直到目标地址响应或达到TTL的最大值。中间路由器发送回来的ICMP超时消息中包含了相应节点的信息。 用法说明 tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name 常见可选参数说明 -d:不要将地址解析为主机名(禁用DNS反解)。 -h:maximum_hops,指定搜索目标地址时的最大跃点数。 -j: host-list,指定沿主机列表的松散源路由。 -w:timeout,等待每个回复的超时时间(以毫秒为单位)。 -R:跟踪往返行程路径(仅适用于IPv6)。 -S:srcaddr,要使用的源地址(仅适用于IPv6)。 -4:强制使用IPv4。 -6:强制使用IPv6。 target_host:目标主机域名或IP地址。 命令输出示例 C:> tracert -d 223.5.5.5 通过最多 30 个跃点跟踪到 223.5.5.5 的路由 1 请求超时。 2 9 ms 3 ms 12 ms 192.168.X.X 3 4 ms 9 ms 2 ms X.X.X.X 4 9 ms 2 ms 1 ms XX.XX.XX.XX 5 11 ms 211.XX.X.XX 6 3 ms 2 ms 2 ms 2XX.XX.1XX.XX 7 2 ms 2 ms 1 ms 42.XX.2XX.1XX 8 32 ms 4 ms 3 ms 42.XX.2XX.2XX 9 请求超时。 10 3 ms 2 ms 2 ms 223.5.5.5 跟踪完成。 测试结果的简要分析 由于mtr(WinMTR)有更高的准确性,本文以其测试结果为例,参考如下要点进行分析。此处分析时以如下示例图为基础。 要点一:网络区域 正常情况下,从客户端到目标服务器的整个链路中会包含如下区域。 客户端本地网络,即本地局域网和本地网络提供商网络。如上图中的区域A。如果该区域出现异常,并且是客户端本地网络中的节点出现异常,则需要对本地网络进行相应的排查分析。如果是本地网络提供商网络出现异常,则需要向当地运营商反馈问题。 运营商骨干网络。如上图中的区域B。如果该区域出现异常,可以根据异常节点的IP查询其所属的运营商,直接向对应运营商进行反馈,或者通过阿里云技术支持,向运营商进行反馈。 目标服务器本地网络,即目标服务器所属提供商的网络。如上图中的区域C。如果该区域出现异常,需要向目标服务器所属的网络运营商反馈问题。 要点二:链路负载均衡 如上图中的区域D。如果中间链路某些部分启用了链路负载均衡,则mtr只会对首尾节点进行编号和探测统计。中间节点只会显示相应的IP或域名信息。 要点三:结合Avg(平均值)和StDev(标准偏差)综合判断 由于链路抖动或其它因素的影响,节点的Best和Worst值可能相差很大。Avg统计了自链路测试以来所有探测的平均值,所以能更好的反应出相应节点的网络质量。而StDev越高,则说明数据包在相应节点的延时值越不相同,即越离散。所以标准偏差值可用于协助判断Avg是否真实反应了相应节点的网络质量。例如,如果标准偏差很大,说明数据包的延迟是不确定的。可能某些数据包延迟很小,例如25ms,而另一些延迟却很大,例如350ms,但最终得到的平均延迟反而可能是正常的。所以,此时Avg并不能很好的反应出实际的网络质量情况。 综上,建议的分析标准如下。 如果StDev很高,则同步观察相应节点的Best和Worst,来判断相应节点是否存在异常。 如果StDev不高,则通过Avg来判断相应节点是否存在异常。 注:上述StDev高或者不高,并没有具体的时间范围标准。而需要根据同一节点其它列的延迟值大小来进行相对评估。比如,如果Avg为30ms,那么,当StDev为25ms,则认为是很高的偏差。而如果Avg为325ms,则StDev同样为25ms,反而认为是不高的偏差。 要点四:Loss%(丢包率)的判断 任一节点的Loss%(丢包率)如果不为零,则说明这一跳网络可能存在问题。导致相应节点丢包的原因通常有如下两种。 运营商基于安全或性能需求,限制了节点的ICMP发送速率,导致丢包。 节点确实存在异常,导致丢包。 结合异常节点及其后续节点的丢包情况,并参考如下内容,判定丢包原因。 如果随后节点均没有丢包,则通常表示异常节点丢包是由于运营商策略限制所致。可以忽略相关丢包。如上图中的第2跳所示。 如果随后节点也出现丢包,则通常说明异常节点确实存在网络异常,导致丢包。如上图中的第5跳所示。 另外,上述两种情况可能同时发生,即相应节点既存在策略限速,又存在网络异常。对于这种情况,如果异常节点及其后续节点连续出现丢包,而且各节点的丢包率不同,则通常以最后几跳的丢包率为准。如上图所示,在第 5、6、7跳均出现了丢包。所以,最终丢包情况,以第7跳的40%作为参考。 要点五:关于延迟 关于延迟,有如下两种场景。 场景一:延迟跳变 如果在某一跳之后延迟明显陡增,则通常判断该节点存在网络异常。如上图所示,从第5跳之后的后续节点延迟明显陡增,则推断是第5跳节点出现了网络异常。不过,高延迟并不一定完全意味着相应节点存在异常。如上图所示,第5跳之后,虽然后续节点延迟明显陡增,但测试数据最终仍然正常到达了目的主机。所以,延迟大也有可能是在数据回包链路中引发的。所以,需要结合反向链路测试一并分析。 场景二:ICMP限速导致延迟增加 ICMP策略限速也可能会导致相应节点的延迟陡增,但后续节点通常会恢复正常。如上图所示,第3跳有100%的丢包率,同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。所以判断该节点的延迟陡增及丢包是由于策略限速所致。 常见的链路异常场景 常见的链路异常场景及测试报告如下。 场景一:目标主机网络配置不当 示例数据如下。 [root@mycentos6 ~]# mtr —no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. ??? 3. 1XX.X.X.X 0.0% 10 521.3 90.1 2.7 521.3 211.3 4. 11X.X.X.X 0.0% 10 2.9 4.7 1.6 10.6 3.9 5. 2X.X.X.X 80.0% 10 3.0 3.0 3.0 3.0 0.0 6. 2X.XX.XX.XX 0.0% 10 1.7 7.2 1.6 34.9 13.6 7. 1XX.1XX.XX.X 0.0% 10 5.2 5.2 5.1 5.2 0.0 8. 2XX.XX.XX.XX 0.0% 10 5.3 5.2 5.1 5.3 0.1 9. 173.194.200.105 100.0% 10 0.0 0.0 0.0 0.0 0.0 在该示例中,数据包在目标地址出现了100%的丢包。从数据上看是数据包没有到达,其实很有可能是目标服务器相关安全策略(比如防火墙、iptables 等)禁用了ICMP所致,导致目的主机无法发送任何应答。所以,该场景需要排查目标服务器的安全策略配置。 场景二:ICMP限速 示例数据如下。 [root@mycentos6 ~]# mtr --no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 63.247.X.X 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.X.XX 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2 在该示例中,在第5跳出现了明显的丢包,但后续节点均未见异常。所以推断是该节点ICMP限速所致。该场景对最终客户端到目标服务器的数据传输不会有影响,所以,分析的时候可以忽略。 场景三:环路 示例数据如下。 [root@mycentos6 ~]# mtr —no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 63.247.7X.X 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.6X.X 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 在该示例中,数据包在第5跳之后出现了循环跳转,导致最终无法到达目标服务器。这通常是由于运营商相关节点路由配置异常所致。所以,该场景需要联系相应节点归属运营商处理。 场景四:链路中断 示例数据如下。 [root@mycentos6 ~]# mtr —no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 63.247.7X.X 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.6X.X 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 在该示例中,数据包在第4跳之后就无法收到任何反馈。这通常是由于相应节点中断所致。建议结合反向链路测试做进一步确认。该场景需要联系相应节点归属运营商处理。 链路测试步骤 通常情况下,链路测试步骤如下图所示。 相关步骤的详情说明如下。 步骤一:获取本地网络对应的公网IP 在客户端本地网络内访问淘宝IP地址库,获取本地网络对应的公网IP地址。 步骤二:正向链路测试(ping和mtr) 从客户端向目标服务器做如下测试。 从客户端向目标服务器域名或IP做持续的ping测试,建议至少ping 100个数据包,记录测试结果。 根据客户端操作系统的不同,使用WinMTR或mtr,设置测试目的地址为目标服务器域名或IP,然后进行链路测试,记录测试结果。 步骤三:反向链路测试(ping和mtr) 进入目标服务器系统内部做如下测试。 从目标服务器向步骤一获取的客户端IP做持续的ping测试,建议至少ping 100个数据包,记录测试结果。 根据目标服务器操作系统的不同,使用WinMTR或mtr,设置测试目的地址为客户端的IP地址,然后进行链路测试,记录测试结果。 步骤四:测试结果分析 参阅测试结果的简要分析,对测试结果进行分析。确认异常节点后,访问如下链接或其他可以查询IP归属地的网站,获取该异常节点的归属运营商信息。如果是客户端本地网络相关节点出现异常,则需要对本地网络进行相应排查分析。如果是运营商相关节点出现异常,则需要向运营商反馈问题。查询结果类似如下。 测试完成后的解决方法 当出现ping丢包或ping不通时,首先请参考云服务器ECS网络故障诊断,排查是否为网络故障。 如果确认是因系统中病毒导致使用ping命令测试ECS实例的IP地址间歇性丢包,则可参考使用ping命令测试ECS实例的IP地址间歇性丢包进行处理。 如果是因删除ECS实例的默认安全组规则导致无法ping通ECS实例,可参考删除ECS实例的默认安全组规则导致无法ping通ECS实例进行处理。 如果在Linux系统内核没有禁PING的情况下,是因系统内部防火墙策略设置导致ECS服务器PING不通。可参考Linux系统的ECS中没有禁PING却PING不通的解决方法。

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