• 关于

    业务点未响应

    的搜索结果

问题

Windows2008R2资源占用不高情况下假死

烟上一颗柳 2019-12-01 21:22:53 2850 浏览量 回答数 3

问题

简单分析下阿里云此次秒杀活动失败,细节上的客观因素

enj0y 2019-12-01 20:57:58 12895 浏览量 回答数 12

问题

性能测试技术怎么进行?

猫饭先生 2019-12-01 21:26:08 1341 浏览量 回答数 0

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

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

问题

【推荐】Windows系统Hang(停止响应)应该如何处理

boxti 2019-12-01 22:06:09 1276 浏览量 回答数 0

问题

某政务网站性能优化

猫饭先生 2019-12-01 21:25:38 1412 浏览量 回答数 0

回答

与Windows蓝屏类似,Windows系统 Hang(停止响应)也是客户经常遇到的操作系统难度较高的问题。所谓的操作系统hang(停止响应) ,可能有如下情况: 机器运行一段时间后,无论远程桌面还是管理控制台,背景不变,鼠标无法移动 用户可以看到密码输入页面,输入密码后,出现白色背景,蓝色背景或者黑色背景,无法登入操作系统 操作系统仍然在运行,但是无法ping通,无法通过网络访问应用。 可能原因 系统有多种原因导致hang,例如: 病毒影响、三方应用(杀毒软件)引起的兼容性问题 系统设备驱动程序与操作系统兼容性引起 Windows 操作系统自身bug 系统内存核心资源(Committed Charge, Paged Pool, Non-paged Pool等)耗尽 机器执行启动、登录脚本、组策略由于线程死锁等原因导致登录缓慢 最佳实践 与系统蓝屏问题处理相同,根据与微软官方的建议以及日常排查经验,为了防止系统停止响应,我们建议客户: 请在ECS上启用安骑士防护或其它商业版杀毒防护工具,定期杀毒,定期更新杀毒软件版本,防止病毒或者杀毒软件驱动与操作系统兼容性引起的系统hang。 请定期运行Windows Update,确保微软最新安全更新已经安装。 请不要将重要数据放在系统盘,而是使用数据盘。 定期对系统盘、数据盘进行快照,以便问题情况下恢复数据。 请在修改系统注册表前备份注册表文件,避免修改系统文件。 请经常检查系统负载,确保运行的三方应用程序不存在资源泄露或线程死锁,定期更新三方应用程序到最新版本。 解决方案 对于系统hang,需要在问题发生情况下抓取核心内存转储文件(蓝屏crash dump)出现系统hang停止响应的情况。但是由于蓝屏日志的分析非常耗时,可能耗费一周或更多的时间。考虑到业务快速恢复,我们强烈建议客户在遇到系统hang的情况,重启机器后,参考如上的最佳实践。尤其是,根据我们的经验,一般病毒、三方杀毒软件和系统bug是最可能的原因,您可以采用如下3条来避免潜在的已知问题: <1> 卸载系统所有三方杀毒软件 注: 禁用杀毒软件的防护功能,杀毒软件内核驱动可能仍然运行,继续影响操作系统行为。 <2> 安全模式下,使用微软Msert离线杀毒工具或者商业版本杀毒软件杀毒。 <3> 运行 Windows Update,安装所有更新。 如果问题仍然发生,建议参考知识点“ECS Windows开启内核转储(Core Dump)配置说明”收集数据,工单反馈进一步分析。 阅读须知 本文仅供用户使用 ECS Windows 时参考,文中引用的微软官方链接,版权归属微软。请注意文章适用的操作系统范围,以及微软 Windows 产品迭代或者文档未及时更新可能带来的问题,阿里云官方不对引用的微软官方链接内容负责。

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

问题

高可用服务

云栖大讲堂 2019-12-01 21:34:33 1169 浏览量 回答数 0

回答

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

1210119897362579 2019-12-02 00:14:25 0 浏览量 回答数 0

回答

域名和路径转发介绍 七层负载均衡服务支持配置域名或者URL转发策略,将来自不同域名或者URL的请求转发给不同的ECS处理。 URL转发支持字符串匹配,按照前缀最长匹配原则,例如有/abc和/abcd两个规则,访问/abcde,优先匹配/abcd规则。 域名转发策略支持精确匹配和通配符匹配两种模式: 精确域名:www.aliyun.com 通配符域名(泛域名): *.aliyun.com, *.market.aliyun.com 当前端请求同时匹配多条域名策略时,策略的匹配优先级为:精确匹配高于小范围通配符匹配, 小范围通配符匹配高于大范围通配符匹配,如下表所示。 模式 请求测试URL 配置的转发域名策略 www.aliyun.com *.aliyun.com *.market.aliyun.com 精确匹配 www.aliyun.com ✓ × × 泛域名匹配 market.aliyun.com × ✓ × 泛域名匹配 info.market.aliyun.com × × ✓ 您可以在一个监听下添加多条转发策略,每条转发策略关联不同的虚拟服务器组(一个虚拟服务器组由一组ECS实例组成)。例如您可以将所有读请求转发到一组后端服务器上而将写请求转发到另一组后端服务器上,这样可以更灵活地适配业务需求,合理分配资源。 如下图所示,在配置了转发策略后,负载均衡系统将按照以下策略转发前端请求: 如果能匹配到相应监听关联的转发策略,则按转发策略,将请求转发到对应的虚拟服务器组。 如果未匹配,而对应监听启用并配置了虚拟服务器组,则将请求转发到对应的虚拟服务器组。 如果均未匹配,则转发到负载均衡实例默认服务器组中的ECS。 添加域名和路径转发策略 在配置域名和路径转发策略前,确保您已经: 添加HTTP监听或添加HTTPS监听。 创建虚拟服务器组 完成以下步骤,配置基于域名和路径的转发策略: 登录负载均衡管理控制台。 选择地域,查看该地域的所有负载均衡实例。 单击负载均衡实例的ID。 选择监听页签。 单击目标七层监听的添加转发策略选项。 在添加转发策略页签,根据以下信息配置转发策略: 域名:输入要转发的请求域名。域名只能使用字母、数字、连字符(-)、点(.)。 URL:输入请求路径。路径必须以/开头,只能包含字母、数字和特殊字符(-./%?#&)。 说明 如果您只想配置域名转发策略,则不需要配置URL。 虚拟服务器组:选择关联的虚拟服务器组。 备注:输入描述。 单击添加转发策略。 单击添加域名或添加规则再添加一个域名或URL策略。 一个HTTP或HTTPS监听最多可添加转发策略个数请参见使用限制。 编辑转发策略 您可以修改转发策略关联的后端服务器。 完成以下操作,编辑转发策略: 登录负载均衡管理控制台。 选择地域,查看该地域的所有负载均衡实例。 单击负载均衡实例的ID。 选择监听页签。 单击目标七层监听的添加转发策略选项。 在转发策略列表区域,单击目标转发策略的编辑选项。 编辑转发策略,根据以下信息自定义转发策略的调度算法、会话保持和健康检查等配置。 说明 当前仅支持在以下地域自定义已有转发策略的高级配置: 华北2(北京) 华东1(杭州) 华东2(上海) 华北3(张家口) 华北5(呼和浩特) 中国香港 新加坡 日本 高级配置 说明 调度算法 负载均衡支持轮询、加权轮询(WRR)、加权最小连接数(WLC)三种调度算法。 加权轮询:权重值越高的后端服务器,被轮询到的次数(概率)也越高。 轮询:按照访问顺序依次将外部请求依序分发到后端服务器。 加权最小连接数:除了根据每台后端服务器设定的权重值来进行轮询,同时还考虑后端服务器的实际负载(即连接数)。当权重值相同时,当前连接数越小的后端服务器被轮询到的次数(概率)也越高。 开启会话保持 选择是否开启会话保持。 开启会话保持功能后,负载均衡会把来自同一客户端的访问请求分发到同一台后端服务器上进行处理。 HTTP协议会话保持基于Cookie。负载均衡提供了两种Cookie处理方式: 植入Cookie:您只需要指定Cookie的过期时间。 客户端第一次访问时,负载均衡会在返回请求中植入Cookie(即在HTTP/HTTPS响应报文中插入SERVERID),下次客户端携带此Cookie访问,负载均衡服务会将请求定向转发给之前记录到的后端服务器上。 重写Cookie:可以根据需要指定HTTPS/HTTP响应中插入的Cookie。您需要在后端服务器上维护该Cookie的过期时间和生存时间。 负载均衡服务发现用户自定义了Cookie,将会对原来的Cookie进行重写,下次客户端携带新的Cookie访问,负载均衡服务会将请求定向转发给之前记录到的后端服务器。详情参考会话保持规则配置。 开启健康检查 健康检查端口:健康检查服务访问后端时的探测端口。 默认值为配置监听时指定的后端端口。 健康检查路径:用于健康检查页面文件的URI,建议对静态页面进行检查。 健康检查域名(可选):默认使用各后端服务器的内网IP为域名。 正常状态码:选择健康检查正常的HTTP状态码。 默认值为http_2xx和http_3xx。 健康检查响应超时时间:接收来自运行状况检查的响应需要等待的时间。如果后端ECS在指定的时间内没有正确响应,则判定为健康检查失败。 健康检查间隔时间:进行健康检查的时间间隔。 默认为2秒。 健康不检查健康阈值:同一LVS节点服务器针对同一ECS服务器,从成功到失败的连续健康检查失败次数。 可选值2-10,默认为3次。 健康检查健康阈值:同一LVS节点服务器针对同一ECS服务器,从失败到成功的连续健康检查成功次数。 可选值2-10,默认为3次。 单击确定。 删除转发策略 完成以下操作,删除转发策略: 登录负载均衡管理控制台。 选择地域,查看该地域的所有负载均衡实例。 单击负载均衡实例的ID。 选择监听页签。 单击目标七层监听的添加转发策略选项。 在转发策略列表区域,单击目标转发策略的删除选项。

保持可爱mmm 2020-03-29 11:50:33 0 浏览量 回答数 0

回答

本文详细列出了从云服务器ECS(Linux)访问SMB文件系统时的常见问题、原因与解决方案。 无法挂载SMB文件系统 通常原因: 使用了低版本或者不兼容的Linux操作系统版本,SMB文件系统支持如下的Linux分发版本。 CentOS 7.6 64bit (3.10.0-957.5.1.el7.x86_64) Ubuntu 18.04 64bit(4.15.0-48-generic) Debian 9.9 64bit(4.9.0-9-amd64) Suse Enterprise Server 12 SP2 64bit(4.4.74-92.35-default) OpenSUSE 42.3 64bit(4.4.90-28-default) Aliyun Linux(4.19.34-11.al7.x86_64) CoreOS(4.19.43-coreos VersionID=2079.4.0) 客户端上未安装CIFS挂载工具(cifs-utils)或者mount.cifs不在PATH指定的命令搜寻目录中。 云服务器ECS(Linux)和SMB文件系统的网络不通。 云服务器ECS(Linux)和SMB文件系统不属于同一个阿里云用户。 云服务器ECS(Linux)和SMB文件系统不在同一个阿里云地域(region)。 云服务器ECS(Linux)和SMB文件系统不处于可连通的网络(VPC或经典网络)中。 说明 NAS支持本地挂载,如果Linux客户端在用户IDC中,可能是该IDC和SMB文件系统所处的的网络(VPC或经典网络)没有通过阿里云高速通道连接成功。 SMB文件系统的白名单设置不允许云服务器ECS(Linux)连接。 云服务器ECS(Linux)防火墙设置为不允许访问SMB文件系统的IP地址或445端口。 云服务器ECS(Linux)试图通过不受支持的TCP端口连接,现在SMB只支持445端口。 说明 您可以通过ping 和 telnet 445检查连通性。 如果端口445未打开,请在目标ECS实例的安全组中添加关于端口445的安全组规则,详情请参见添加安全组规则。 云服务器ECS(Linux)管理员没有root权限或者没有被设置为有mount命令的sudo权限。 挂载时使用的文件系统类型不是cifs。 挂载时使用的vers选项不是2.0。 挂载时没有指定guest方式挂载。 挂载时指定的uid、gid、dir_mode或者file_mode不正确。 挂载的目标目录的SELINUX设置不正确。 云服务器ECS(Linux)挂载连接数太多,超过了单文件系统挂载上限(1000)。这个在容器场景较容易发生。 解决方案: 参见通过云服务器ECS(Linux)访问SMB文件系统及上述可能原因,自行排查。 检查/var/log/messages和dmesg输出,自行排查。 联系阿里云NAS团队排查。 同时请提供Linux版本信息、具体挂载命令、/var/log/messages和dmesg输出。 文件系统性能不佳 如果SMB文件系统性能不佳,您可以从以下方面进行排查。 原因1:SMB单个文件系统的吞吐能力与存储量是相联系的。单文件系统的吞吐(读+写)上限与当前存储量呈线性关系。 解决方案:使用fio工具来测试SMB文件系统性能,详情请参见NAS性能测试。 原因2:云服务器ECS(Linux)的单机网络带宽较小。 解决方案:使用多个云服务器ECS(Linux)达到文件系统的总体预期性能。 原因3:禁用了SMB文件系统的客户端缓存。 解决方案:在挂载SMB文件系统时,cache=none表示禁用缓存,默认或者cache=strict表示使用缓存;您可以通过sudo mount | grep cifs命令检查所用的选项是否正确。 原因4:没有设置合适的SMB客户端的I/O大小。 解决方案:根据业务需求调整rsize/wsize,缺省值:1048576。 原因5:云服务器ECS(Linux)的CPU或内存的规格过低,或被其它业务占有过多。 解决方案:选择合适的云服务器ECS(Linux)规格、检查系统其它应用资源,确保系统满足CPU和内存要求。 您可以通过top命令检查系统cpu、mem使用情况。 原因6:挂载时使用了atime选项。 解决方案:如果您的业务不是对文件的访问时间(atime)极为敏感请不要在挂载时使用atime选项。 原因7:遇到大量小文件频繁读、少量写但需要写时通知的WebServer场景。 解决方案:您可以在客户端配置该WebServer(如Apache)产品特定的缓存机制或者联系阿里云NAS团队开通WebServer场景加速功能。 迁移/复制文件系统中的文件时速度缓慢 如果已经排除了上述文件系统本身的性能问题,则可能原因是您没有使用并发式迁移/复制文件。您可以通过以下开源工具进行迁移/复制。 GNU Parallel 说明 根据系统资源,选择合适的线程数。 示例:find * -type | parallel --will-cite -j 10 cp {} /mnt/smb/ & Fpart Fpsync multi 访问文件系统时,报错:Permission denied 原因:Linux管理员在挂载时使用了不正确的uid、gid、file_mode、dir_mode。 解决方案:检查是否正确设置了uid、gid、file_mode、dir_mode等挂载选项,详情请参见通过云服务器ECS(Linux)访问SMB文件系统。 文件名大小写变更 SMB文件系统对文件名大小写不敏感,和Windows系统保持一致。但在文件名大小写改名这个场景暂时没有支持。 您可以先从大写文件名改成一个其它名字的文件,再改成小写文件名,反之亦然。 不能改变文件owner,文件/目录mode 现在暂时不支持动态改变,只能在挂载时指定,详情请参见通过云服务器ECS(Linux)访问SMB文件系统。 并发访问同一文件时,客户端出现无响应35s现象 原因:当前Linux SMB 内核驱动有缺陷,会造成在使用vers=2.1 or 3.0挂载时,在某些并发场景不能发出服务器端期待的SMB BreakAck协议包,导致服务器端无响应35s。 解决方案:挂载文件系统时,使用vers=2.0 协议。 不能使用ACL 暂时不支持使用ACL,如果您有强烈需求,请联系阿里云NAS团队。 SMB挂载点无响应 原因:在Linux内核为3.10.0-514之前的Linux分发版中,SMB内核驱动在并发场景有时会crash(内核stack如下所示),导致挂载点无法被访问。内核日志中有如下类似信息: ... [ ] cifs_oplock_break+0x1f1/0x270 [cifs] [ ] process_one_work+0x17a/0x440 [ ] rescuer_thread+0x294/0x3c0 ... 解决方案: 使用cache=none重新挂载(性能会受影响)。 升级云服务器ECS(Linux)的操作系统。

1934890530796658 2020-03-31 22:23:33 0 浏览量 回答数 0

问题

支付宝的性能测试

云效平台 2019-12-01 21:47:13 5472 浏览量 回答数 1

问题

【精品问答】性能测试 PTS

montos 2020-04-08 13:18:48 2 浏览量 回答数 1

回答

Nginx服务器错误一般有以下几点原因: 1、请求的header过大。nginx默认的header长度上限是4k,如果超过了这个值,nginx会直接返回400错误. 解决方法:配置nginx.conf相关设置。可以通过以下2个参数来调整header上限: client_header_buffer_size 16k;large_client_header_buffers 4 16k。 2、上传文件过程中出现错误。这时浏览器显示“413 Request Entity Too Large”。这是因为没有设置client_max_body_size,这个参数默认只是1M,也就是说发布的文章内容大小不能超过1M。 解决方法:增加如下两行到nginx.conf的http{}段, 增大nginx上传文件大小限制:设置允许发布内容为8M:client_max_body_size 8M;client_body_buffer_size 128k。 另外如果运行的是php,那么还要检查php.ini,这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误:post_max_size = 8M;upload_max_filesize = 6M。 修改完配置后,别忘记重新加载。 3、客户端在为等到服务器相应返回前就关闭了客户端描述符。一般出现在客户端设置超时后,服务器主动关闭。 解决方法:根据实际Nginx后端服务器的处理时间修改客户端超时时间。 4、脚本错误(php语法错误、lua语法错误)。 解决方法:查看nginx_err_log php_err_log。 5、访问量过大,系统资源限制,不能打开过多文件。 磁盘空间不足。(access log开启可能导致磁盘满溢,服务器主动关闭)。 解决方法:修改/etc/sysctl.conf文件,并使用下面的命令确认: #sysctl -p。要使 limits.conf 文件配置生效,必须要确保 pam_limits.so 文件被加入到启动文件中。 6、后端服务无法处理,业务中断。 解决方法:从后端日志获取错误原因,解决后端服务器问题。 7、后端服务器在超时时间内,未响应Nginx代理请求。 解决方法:根据后端服务器实际处理情况,调正后端请求超时时间。 8、网站页面缓存过大。 解决方法:配置nginx.conf相关设置:fastcgi_buffers 8 128k;send_timeout 60。 “答案来源于网络,供您参考” 希望以上信息可以帮到您!

牧明 2019-12-02 02:17:24 0 浏览量 回答数 0

问题

添加域名或URL转发规则

行者武松 2019-12-01 21:36:14 4107 浏览量 回答数 0

问题

方法追踪有哪几种?

猫饭先生 2019-12-01 21:03:55 875 浏览量 回答数 0

问题

DRDS 实例中的连接怎么实现?

猫饭先生 2019-12-01 21:20:56 1087 浏览量 回答数 0

问题

消息服务的如何处理消息时长?

轩墨 2019-12-01 22:08:26 953 浏览量 回答数 0

回答

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

景凌凯 2019-12-02 02:05:12 0 浏览量 回答数 0

问题

SSH面试题

琴瑟 2019-12-01 21:46:22 3489 浏览量 回答数 0

问题

福布斯:云计算推动传统CIO职能转型

lindadli 2019-12-01 20:02:51 10813 浏览量 回答数 0

问题

高级接口的使用

云栖大讲堂 2019-12-01 21:08:59 1628 浏览量 回答数 1

回答

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

游客ih62co2qqq5ww 2020-06-15 13:55:41 0 浏览量 回答数 0

回答

先说结论: 不要对接!不要对接!不要对接! 开个玩笑,以上仅代表个人观点,大家也知道这种“三体式警告”根本没有用的,我自己也研究如何对接,说不定做完后就觉得“真香”了。 为什么要对接? 首先讨论一下为什么要把 Flutter 对接到 Web 生态。 Flutter 现在是一个炙手可热的跨平台技术,能够一套代码运行在 Android、iOS、PC、IoT 以及浏览器上,被认为是下一代跨平台技术。相比于 Weex 和 React Native 可以很好地解决多平台一致性问题,原生渲染性能相近,上层没有 JS 那么厚的封装层次,整体性能会略好一些。 但是大部分兴冲冲去学 Flutter 的人疑惑的第一个问题就是:为什么 Flutter 要用 Dart?一个全新的语言意味着新的学习成本,难道 JS 不香吗?JS 不香不是还有 TypeScript 吗!事实上 Flutter 抛弃的岂止是 JS 这门语言,也抛弃了 HTML 和 CSS,设计了一套解耦得更好的 Widget 体系,Flutter 抛弃的是整个 Web,致力于打造一个新的生态,但是这个生态无法复用 Web 生态的代码和解决方案。尤其是之前所有跨平台方案 Hybrid、React Native、Weex 都是对接 Web 生态的,这让 Flutter 显得有些格格不入,也让大部分前端开发者望而却步。 下面是我整理出来的,前端开发者使用 Flutter 的各方面成本: 因为 Flutter 的开发模式和前端框架比较像(可以说就是抄的 React),所以框架的学习成本并不高,稍微高一些的是 Dart 语言的学习成本,另外还要学习如何用 Widget 组装 UI,虽然很多布局 Widget 设计得和 CSS 很像,灵活度还是差了很多。要想在真实项目中用起来,还要改造整个工具链,以“Native First”的视角做开发,开发 Flutter 和开发原生应用的链路是比较像的,和开发前端页面有较大差异。最高的还是生态成本,前端生态的积累无论是代码还是技术方案都很难复用,这是最痛的一点,生态也是 Flutter 最弱的一环。 无论是为了先进的技术理念还是出于商业私心,先不管 Flutter 为什么抛弃 Web 生态,现实问题是最大的 UI 开发者群体是前端,最丰富的生态是 Web 生态,我觉得 Web 技术也是开发 UI 最高效的方式。如果能在上层使用 Web 技术栈开发,在底层使用 Flutter 实现跨平台渲染,不是可以很好的兼顾开发效率、性能和跨平台一致性吗?还能复用 Web 技术栈大量的技术积累。 可能这些理由也不够充分,暂且先照着这个假设继续分析,最后再重新讨论到底该不该对接。 关于 Flutter 和 Web 生态的对接涉及两个方面: 从 Web 到 Flutter。就是使用 Web 技术栈来开发,然后对接到 Flutter 上实现跨平台渲染。对 Web 来说是解决性能和跨平台一致性问题,对 Flutter 来说是解决生态复用问题。从 Flutter 到 Web。就是官方已经实现的 Web support for Flutter,把已经用 Dart 开发好的 App 编译成 HTML/JS/CSS 然后运行在浏览器上,可以用于降级和外投场景。 如何实现“从 Web 到 Flutter”? 首先分析一下 Flutter 的架构图,看看可以从哪里下手。 Flutter 可以分为 Framework 和 Engine 两部分,Engine 部分比较底层也比较稳定了,最好不要动,需要改的是用 Dart 实现的 Framework。要想对接 Web 生态的话,JS 引擎肯定是要引入的,至于是否保留 Dart VM 有待讨论。图中最上面 Material 和 Cupertino 两个 UI 库前端是不需要的,前端有自己的。关键是 Widget 这部分,是替换成 HTML/CSS 的方式写 UI,还是继续保留 Widget 但是把语言换成 JS,不同方案给出的解法也不一样。 有不少方案可以实现对接,业界有挺多尝试的,我总结了下面三种方式: - TS 魔改:用 JS 引擎替换掉 Dart VM,用 JS/TS 重新实现 Flutter Framework(或者直接 dart2js 编译过来)。 - JS 对接:引入 JS 引擎同时保留 Dart VM,用前端框架对接 Flutter Framework。 - C++ 魔改:用 JS 引擎替换掉 Dart VM,用 C++ 重新实现 Flutter Framework。 TS 魔改 TS 魔改就是完全抛弃掉 Dart VM,用 TypeScript 重新实现一遍用 Dart 写的 Flutter Framework。 为啥是 TS 而不是 JS?这不是因为 TS 是个大热门嘛,而且向下兼容 JS,现在几乎所有时髦的框架都要用 TS 重写了。 这种方案的出发点是“如果能把 Flutter 的 Dart 换成 JS 就好了”,最容易想到的路就是把 Dart 翻译成 TS,或者直接用 dart2js 把代码编译成 js,但是编译出来的代码包含很多 dart:ui 之类的库的封装,生成的包也挺大的,也比较难定制需要导出的接口,不如干脆用 TS 重写一遍,工具链更熟悉一些,还可以加一些定制。 理论上讲翻译之后 Flutter 绝大部分功能都依然支持,可以复用各种 npm 包,还可以动态化,但是丧失了 AOT 能力,JS 语言的执行性能应该是不如 Dart 的。而且所有节点的布局运算都发生在 JS,底层只需要提供基础的图形能力就好了,就好像是基于 Canvas API 写了一套 UI 框架,性能未必有现存前端框架的性能高。 此外最大的问题是如何与官方 Flutter 保持一致,假如现在是从 v1.13 版本翻译过来的,以后官方升级到了 v1.15 要不要同步更新?这个过程没啥技术含量,而且需要持续投入,做起来比较恶心。 另外还需要考虑上层是用 Widget 的方式写 UI,还是用前端熟悉的 HTML+CSS。如果依然用 Widget 的话,那大部分前端组件还是用不了的,UI 还是得重写一遍。反正要重写的话,成本也没降下来,那就用 Dart 重写呗…… 直接用官方原版 Flutter 也避免每次更新都要翻译一遍 Dart 代码。所以既然选择了对接前端生态,那就要对接 CSS,不然就没有足够的价值。然而 CSS 和 Widget 的对接也是很繁琐的过程,而且存在完备性问题。 JS 对接 翻译代码的方式不够优雅,那就保留 Dart,把 JS/CSS 对接到 Widget 上面不就好了? 当然可以,这种方式是仅把 Flutter 当做了底层的渲染引擎,上层保持前端框架的写法,仅把渲染部分对接到 Flutter。现存的很多前端框架都把底层渲染能力做了抽象,可以对接到不同渲染引擎上,如 Vue/Rax 同时支持浏览器和 Weex,用同样的方式,可以再支持一个 Flutter。 这种方式对前端框架的兼容性比较好,但是链路太长了,业务代码调用前端框架接口做渲染,一顿操作之后发出了渲染指令,这个渲染指令要基于通信的方式传给 Flutter Framework,这中间涉及一次 JS 到 C++ 再到 Dart 的跨语言转换,然后再接收到渲染指令之后还要转成相应的 Widget 树,从 CSS 到 Widget 的转换依然很繁琐。而且 Widget 本身是可以带有状态的,本身就是响应式更新的,在更新时会重新生成 widget 并 diff,如果在前端更新 UI 的话,前端框架在 js 里 diff 一次 vdom,传到 Flutter 之后又 diff 一次 widget。 如果要绕过 Widget 直接对接图中的 Rendering 这一层,可以绕过 widget diff 但是得改 Flutter Framework 的渲染链路,既然要改 Flutter Framework 那为什么不直接用 TS 魔改呢,还绕过了 JS 到 Dart 的通信,又回到了第一种方案。 总结来说,这个方案的优点是:实现简单、能最大化保留前端开发体验,缺点是:渲染链路长、通信成本高、响应式逻辑冲突、CSS 转 Widget 不完备等。 C++ 魔改 想要干掉 Dart VM,就需要用其他语言重新实现用 Dart 开发的 Framework,用 JS/TS 可以,用 C++ 当然可以,最硬核的方式就是用 C++ 重新实现 Flutter 的 Framework,然后接入 JS 引擎,通过 binding 把 C++ 接口透出到 JS 环境,上层应用还是用 JS 做开发。 把 Framework 层下沉到 C++ 之后,不仅会有更好的性能,也能支持更多语言。原本 Flutter Framework 是在 Dart VM 之上的,必须依赖 Dart VM 才能运行,所以对 Dart 有强依赖;用 C++ 重新实现之后,JS 引擎是在 C++ 版 Framework 之上的,框架本身并不依赖 JS 引擎,还可以对接其他各种语言,如对接了 JVM 之后可以支持 Java 和 Kotlin,对接回 Dart VM 可以继续支持 Dart。 这个方案可以增强性能,也能保持和 Flutter 的一致性,但是改造成本和维护成本都相当高。C++ 的开发效率肯定不如 Dart,当 Flutter 快速迭代之后如何跟进是很大的问题,如果跟进不及时或者实现不一致那很可能就分化了。从 CSS 到 Widget 的转换也是不得不面对的问题。 几种方案对比 把上面几种方案画在同一张图里是这个样子的: 图中实线部分表示了跨语言的通信,太过频繁会影响性能,虚线部分表示了其他对接可能性。 从下到上,Flutter Engine 是不需要动的,这一层是跨平台的关键。Framework 则有三种语言版本,JS/TS、Dart、C++,性能是 C++ 版本最好,成本是 Dart 版本最低。然后还需要向上处理 HTML/CSS 和 Widget 的问题,可以直接对接一个前端框架,也可以直接在 C++ 层实现(不然需要透出的 binding 接口就太多了,用通信的方式也太过频繁了)。 如何实现“从 Flutter 到 Web”? 这个功能官方已经实现了,可以把使用 Dart 开发的 App 编译成 Web App 运行在浏览器上,官方文档以介绍用法和 API 为主,我这里简单分析一下内部具体的实现方案。 实现原理 结合 Flutter 的架构图来看,要实现 Web 到 Flutter 需要改造的是上层 Framework,要实现 Flutter 到 Web 需要改造的则是底层 Engine。 Framework 对 Engine 的核心依赖是 dart:ui,这是库是在 Engine 里实现的,抽象出了绘制 UI 图层的接口,底层对接 skia 的实现,向上透出 Dart 语言的接口。这样来看,对接方式就比较简单了: 使用 dart2js 把 Framework 编译成 JS 代码。基于浏览器的 API 重新实现 dart:ui,即 dart:web_ui。 把 Dart 编译成 JS 没什么问题,性能可能会有一点影响,功能都是可以完全保留的,关键是 dart:web_ui 的实现。在原生 Engine 中,dart:ui 依赖 skia 透出的 SkCanvas 实现绘制,这是一套很底层的图形接口,只定义了画线、画多边形、贴图之类的底层能力,用浏览器接口实现这一套接口还是很有挑战的。上图可以看到 Web 版 Engine 是基于 DOM 和 Canvas 实现的,底层定义了 DomCanvas 和 BitmapCanvas 两种图形接口,会把传来的 layer tree 渲染成浏览器的 Element tree,但是节点上仅包含了 position, transform, opacity 之类的样式,只用到 CSS 很小的一个子集,一些更复杂的绘制直接用 2D canvas 实现。 存在的问题 我编译了一个还算复杂的 demo 试了一下,性能很不理想,滑动不流畅,有时候图片还会闪动。生成出来的 js 代码有 1.1MB (minify 之后,未 gzip),节点层次也比较深,我评估这个页面用前端写不会超过 300KB,节点数可以少一半以上。 另外再看一下 Flutter 仓库的 issue,过滤出 platfrom-web 相关的,可以看到大量:文字编辑失效、找不到光标、ListView 在 ios 上不可滚动、checkbox/button 行为不正常、安卓滚动卡顿图片闪烁、字体失效、某些机型视频无法播放、文字选中后无法复制、无法调试…… 感觉 flutter for web 已经陷入泥潭,让人回想起前端当年处理各种浏览器兼容性的噩梦。 这些性能和兼容性问题,核心原因是浏览器未暴露足够的底层能力,以及浏览器处理手势、用户输入和方式和 Flutter 差异巨大。 实现 Flutter Engine 需要的是底层的图形接口和系统能力,虽然canvas 提供了相似的图形接口,如果全部用 canvas 实现的话很难处理可访问性、文本选择、手势、表单等问题,也会存在很多兼容性问题。所以真实方案里用的是 Canvas + DOM 混合的方式,封装层次太高了,渲染链路太长。就好像 Flutter Framework 里进行了一顿猛如虎的操作之后,节点生成好了、布局算好了、绘制属性也处理好了,就差一个画布画出来了,然后交到浏览器手里,又生成一遍 Element,再算一遍布局,在处理一遍绘制,最终才交给了底层的图形库画出来。 再比如长页面的滚动,浏览器里只要一条 CSS (overflow:scroll) 就可以让元素可滚动,手势的监听以及页面的滚动以及滚动动画都是浏览器原生实现的,不需要与 JS 交互,甚至不需要重新 layout 和 paint,只需要 compositing。如上图所示,在 Flutter 中 Animation 和 Gesture 是用 Dart 实现的,编译过来就是 JS 实现的,浏览器本身并不知道这个元素是否可滚,只是不断派发 touchmove 事件,JS 根据事件属性计算节点偏移,然后运算动画,然后把 transform 或者新的 position 作用到节点上,然后浏览器再来一遍完整的渲染流程…… 优化方案 性能和兼容性的问题还是要解决的,短期内先把 issue 解掉,长线的优化方案,官方有两种尝试: 使用 CSS Painting API 做绘制。 a, 这是还处于提案状态的新标准,可以用 JS 实现一些绘制功能,自定义 CSS 属性。 b. 目前还未实现,需要等浏览器先把 CSS Houdini 支持好。 使用 WebAssembly 版本的 Skia 做绘制 https://skia.org/user/modules/canvaskit a, 这样可以发挥 wasm 的性能优势,并且保持 skia 功能的一致。但是目前 wasm 在浏览器环境里未必有性能优势,这里不展开讨论了。 b. 已经部分实现,参考这里的配置启用功能: https://github.com/flutter/flutter/issues/41062#issuecomment-533952994 这两个方案都是想更多的利用到浏览器的底层能力,只有浏览器暴露了更多底层能力,才能更好的实现 Flutter 的 Web Engine。不过这个要等挺久的时间,我们也参与不了,现阶段想要使用 flutter for web,还是得保持现有架构,一起参与进去把 issue 解决掉,优先保障功能,其次优化性能。 一种适应性更好的架构 如果理想化一点,能不能从架构角度让 Flutter 和 Web 生态融合的更好一些呢? 回顾文章最开始的官方架构图,上面是 Framework(Dart),下面是 Engine(C++),切分在 Foundation 这一层,双方之间的交互是几何图形信息。如果还保持这个架构,把切分层次划分的更靠上一些,如下图所示,划分在 Widgets 和 Rendering 这一层,理论上讲对 Flutter 的开发者来说是无感知的,因为上层的开发语言和 Widget 接口都是不变的。 切分在这一层,Framework 和 Engine 之间的交互就不再是几何图形而是节点信息,Widget 的组合、setState 响应式更新、Widget diff 都还在 Dart 中,展开后的 RenderObject 的布局、绘制、裁剪、动画全都在 C++ 中,不仅有更好的性能,还可以与 Engine 有更好的结合。 或者说,还原本保留 Engine 的设计,把下沉的这部分逻辑上划分成 Renderer,就有了如下三层的结构: 这样划分出来的每一层都有明确的定位: Framework: 开发框架。为开发者提供可编程 API,实现响应式的开发模式,提供细粒度 Widget 供开发者自由封装和组合。Renderer: 渲染引擎。专门实现布局、绘制、动画、手势的的处理,这部分功能相对独立,是可以与开发框架解耦的,也不必与特定语言绑定。Engine: 图形引擎。实现跨平台一致的图形接口,合成输入的层并绘制到屏幕上,处理好平台力的接入和适配。 这样切分除了有性能优势以外,也使得渲染引擎摆脱了对 Dart 的依赖,能够支持多种语言,也能支持多种开发模式。对接到 Dart VM 就可以用 Dart 写代码,对接到 JS 引擎就可以用 JS 写代码,对接到 JVM 还可以写 Java,但是无论怎么写,底层的渲染能力是一样的,一套统一的布局算法,动画和手势的处理行为也是一致的。 在这样的架构下,对接 Web 生态就更容易了。Dart 和 Widget 是前端不想要的,希望能换成 JS 和 CSS,但是又想要底层的跨平台一致渲染引擎,那从 Renderer 层开始对接就好了,绕过了所有不想要的,也保留了所有想要的。 要实现 Flutter for Web 也更简单了一些。在 Engine 层做对接,一直苦于浏览器透出的底层能力不够,如果是在 Renderer 之上做对接就更容易一些,基于 JS/CSS/DOM/Canvas 的能力封装出一套 Rendering 接口,供 Widget 调用就好了,这样可以使渲染链路更短一些,但是依然要处理 Widget 和 DOM/CSS 之间的兼容性问题。 再讨论一遍:为什么要对接? 技术上已经分析完了,要想搞定 Flutter 生态和 Web 生态的对接,需要投入很大的成本,所以真正决定做之前,要先讨论清楚为什么要做对接?到底要不要做对接? 首先 Google 官方对 Flutter 的定位就是个问题。Flutter 设计之初就是不考虑 Web 生态的,甚至在刻意回避,倡导的是更贴近原生的开发方式。我之所以在开头说不要对接,原因也很简单:两种技术设计理念不同,不是朝着一个方向发展的,生态不通,技术方案不通,强行融合很可能让彼此都丧失了优势。但是业界又有很多团队在做这种尝试,说明需求是存在的,如果 Google 抵制这个方向,那就不好做了。不过现在官方已经支持了 Flutter for Web,已经向 Web 生态迈了一步,未来是否进一步与 Web 融合,也是有可能的。 另外就是跨平台技术本身的问题,浏览器发展了二三十年,已经是个很强大的跨平台产品了,几乎是 Web 的代名词了,这一点无人能敌。但是也臃肿不堪,有大量历史包袱,性能和体验不够好,和 Native 的结合度差,尤其在移动和 IoT 平台。虽然硬件性能在不断提升,但这是所有软件共享的,浏览器的性能和体验总会比 Native 差一些,差的这一些很可能就是新业务和新场景的发挥空间。观察一下近几年新诞生的业务场景,很多都是利用到了 Native 新提供的能力才火爆起来的,如 AI/AR/ 视频 / 直播 等,有因为新的 Web API 而孵化生出来的商业模式吗? 原文链接: https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650405725&idx=1&sn=0b7476f7c7c01df7fdafda578f9ceb98&chksm=83953345b4e2ba53917ac30b709c07be15bd1c2fd5ae2a8ecfbb129b3813f771621b8fac95ca&scene=27#wechat_redirect

剑曼红尘 2020-03-10 09:54:40 0 浏览量 回答数 0

问题

域名转入

yq传送门 2019-12-01 20:13:38 37209 浏览量 回答数 30

问题

Web测试方法

技术小菜鸟 2019-12-01 21:41:32 7022 浏览量 回答数 1

回答

XSS 攻击有两⼤要素: 攻击者提交恶意代码。浏览器执⾏恶意代码。 针对第⼀个要素:我们是否能够在⽤户输⼊的过程,过滤掉⽤户输⼊的恶意代码呢? 输⼊过滤 在⽤户提交时,由前端过滤输⼊,然后提交到后端。这样做是否可⾏呢? 答案是不可⾏。⼀旦攻击者绕过前端过滤,直接构造请求,就可以提交恶意代码了。 那么,换⼀个过滤时机:后端在写⼊数据库前,对输⼊进⾏过滤,然后把“安全的”内容,返回给前端。这样是否可⾏呢? 我们举⼀个例⼦,⼀个正常的⽤户输⼊了 5 < 7 这个内容,在写⼊数据库前,被转义,变成了 5 < 7 。 问题是:在提交阶段,我们并不确定内容要输出到哪⾥。 这⾥的“并不确定内容要输出到哪⾥”有两层含义: ⽤户的输⼊内容可能同时提供给前端和客户端,⽽⼀旦经过了 escapeHTML() ,客户端显示的内容就变成了乱码(5< 7)。 在前端中,不同的位置所需的编码也不同。 当5 < 7 作为 HTML 拼接⻚⾯时,可以正常显示: <div title="comment">5 < 7</div> 当5 < 7 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接⽤于 Vue 等模板的展示,也不能直接⽤于内容⻓度计算。不能⽤于标题、alert 等 所以,输⼊侧过滤能够在某些情况下解决特定的 XSS 问题,但会引⼊很⼤的不确定性和乱码问题。在防范 XSS 攻击时应避免此类⽅法 当然,对于明确的输⼊类型,例如数字、URL、电话号码、邮件地址等等内容,进⾏输⼊过滤还是必要的 既然输⼊过滤并⾮完全可靠,我们就要通过“防⽌浏览器执⾏恶意代码”来防范 XSS。这部分分为两类: 防⽌ HTML 中出现注⼊防⽌ JavaScript 执⾏时,执⾏恶意代码 预防存储型和反射型 XSS 攻击 存储型和反射型 XSS 都是在服务端取出恶意代码后,插⼊到响应 HTML ⾥的,攻击者刻意编写的“数据”被内到“代码”中,被浏览器所执⾏。 预防这两种漏洞,有两种常⻅做法: 改成纯前端渲染,把代码和数据分隔开。对 HTML 做充分转义。 纯前端渲染 纯前端渲染的过程: 浏览器先加载⼀个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。然后浏览器执⾏ HTML 中的 JavaScript。JavaScript 通过 Ajax 加载业务数据,调⽤ DOM API 更新到⻚⾯上。 在纯前端渲染中,我们会明确的告诉浏览器:下⾯要设置的内容是⽂本( .innerText ),还是属性( .setAttribute ),还是样式( .style )等等。浏览器不会被轻易的被欺骗,执⾏预期外的代码了。 但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload 事件和 href 中的 javascript:xxx 等,请参考下⽂”预防 DOM 型 XSS 攻击“部分)。 在很多内部、管理系统中,采⽤纯前端渲染是⾮常合适的。但对于性能要求⾼,或有 SEO 需求的⻚⾯,我们仍然要⾯ 对拼接 HTML 的问题。 转义 HTML 如果拼接 HTML 是必要的,就需要采⽤合适的转义库,对 HTML 模板各处插⼊点进⾏充分的转义。 常⽤的模板引擎,如 doT.js、ejs、FreeMarker 等,对于 HTML 转义通常只有⼀个规则,就是把 & < > " ' / 这⼏个字符转义掉,确实能起到⼀定的 XSS 防护作⽤,但并不完善: 所以要完善 XSS 防护措施,我们要使⽤更完善更细致的转义策略。 例如 Java ⼯程⾥,常⽤的转义库为 org.owasp.encoder 。以下代码引⽤⾃ org.owasp.encoder 的官⽅说明。 <!-- HTML 标签内⽂字内容 --> <div><%= Encode.forHtml(UNTRUSTED) %></div> <!-- HTML 标签属性值 --> <input value="<%= Encode.forHtml(UNTRUSTED) %>" /> <!-- CSS 属性值 --> <div style="width:<= Encode.forCssString(UNTRUSTED) %>"> <!-- CSS URL --> <div style="background:<= Encode.forCssUrl(UNTRUSTED) %>"> <!-- JavaScript 内联代码块 --> <script> var msg = "<%= Encode.forJavaScript(UNTRUSTED) %>"; alert(msg); </script> <!-- JavaScript 内联代码块内嵌 JSON --> <script> var __INITIAL_STATE__ = JSON.parse('<%= Encoder.forJavaScript(data.to_json) %>'); </script> <!-- HTML 标签内联监听器 --> <button onclick="alert('<%= Encode.forJavaScript(UNTRUSTED) %>');"> click me </button> <!-- URL 参数 --> <a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top"> <!-- URL 路径 --> <a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>"> <!-- URL. 注意:要根据项⽬情况进⾏过滤,禁⽌掉 "javascript:" 链接、⾮法 scheme 等 --> <a href='<%= urlValidator.isValid(UNTRUSTED) ? Encode.forHtml(UNTRUSTED) : "/404" %>'> link </a> 可⻅,HTML 的编码是⼗分复杂的,在不同的上下⽂⾥要使⽤相应的转义规则。 预防 DOM 型 XSS 攻击 DOM 型 XSS 攻击,实际上就是⽹站前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执⾏了。 在使⽤ .innerHTML 、 .outerHTML 、 document.write() 时要特别⼩⼼,不要把不可信的数据作为 HTML 插到⻚⾯上,⽽应尽量使⽤ .textContent 、 .setAttribute() 等。 如果⽤ Vue/React 技术栈,并且不使⽤ v-html / dangerouslySetInnerHTML 功能,就在前端 render 阶段避免innerHTML 、 outerHTML 的 XSS 隐患。 DOM 中的内联事件监听器,如 location 、 onclick 、 onerror 、 onload 、 onmouseover 等, 标签的 href 属性,JavaScript 的 eval() 、 setTimeout() 、 setInterval() 等,都能把字符串作为代码运⾏。如果不可信的数据拼接到字符串中传递给这些 API,很容易产⽣安全隐患,请务必避免。 <!-- 内联事件监听器中包含恶意代码 --> ![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/3e724ce0.data:image/png,) <!-- 链接内包含恶意代码 --> <a href="UNTRUSTED">1</a> <script> // setTimeout()/setInterval() 中调⽤恶意代码 setTimeout("UNTRUSTED") setInterval("UNTRUSTED") // location 调⽤恶意代码 location.href = 'UNTRUSTED' // eval() 中调⽤恶意代码 eval("UNTRUSTED") </script> 如果项⽬中有⽤到这些的话,⼀定要避免在字符串中拼接不可信数据。 其他 XSS 防范措施 虽然在渲染⻚⾯和执⾏ JavaScript 时,通过谨慎的转义可以防⽌ XSS 的发⽣,但完全依靠开发的谨慎仍然是不够的。 以下介绍⼀些通⽤的⽅案,可以降低 XSS 带来的⻛险和后果。 Content Security Policy 严格的 CSP 在 XSS 的防范中可以起到以下的作⽤: 禁⽌加载外域代码,防⽌复杂的攻击逻辑禁⽌外域提交,⽹站被攻击后,⽤户的数据不会泄露到外域禁⽌内联脚本执⾏(规则较严格,⽬前发现 GitHub 使⽤)禁⽌未授权的脚本执⾏(新特性,Google Map 移动版在使⽤)合理使⽤上报可以及时发现 XSS,利于尽快修复问题 输⼊内容⻓度控制 对于不受信任的输⼊,都应该限定⼀个合理的⻓度。虽然⽆法完全防⽌ XSS 发⽣,但可以增加 XSS 攻击的难度。 其他安全措施 HTTP-only Cookie: 禁⽌ JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注⼊后也⽆法窃取此 Cookie。验证码:防⽌脚本冒充⽤户提交危险操作。 过滤 Html 标签能否防⽌ XSS? 请列举不能的情况? ⽤户除了上传 <script>alert('xss');</script> 还可以使⽤图⽚ url 等⽅式来上传脚本进⾏攻击 <table background="javascript:alert(/xss/)"></table> <img src="javascript:alert('xss')"> 还可以使⽤各种⽅式来回避检查, 例如空格, 回⻋, Tab <img src="javas cript: alert('xss')"> 还可以通过各种编码转换 (URL 编码, Unicode 编码, HTML 编码, ESCAPE 等) 来绕过检查 <img%20src=%22javascript:alert('xss');%22> <img src="javascript&#58alert(/xss/)">

前端问答 2019-12-23 12:43:05 0 浏览量 回答数 0

回答

 TTS</B>是Text To Speech的缩写,即“从文本到语音”。它是同时运用语言学和心理学的杰出之作,在内置芯片的支持之下,通过神经网络的设计,把文字智能地转化为自然语音流。TTS技术对文本文件进行实时转换,转换时间之短可以秒计算。在其特有智能语音控制器作用下,文本输出的语音音律流畅,使得听者在听取信息时感觉自然,毫无机器语音输出的冷漠与生涩感。TTS语音合成技术即将覆盖国标一、二级汉字,具有英文接口,自动识别中、英文,支持中英文混读。所有声音采用真人普通话为标准发音,实现了120-150个汉字/秒的快速语音合成,朗读速度达3-4个汉字/秒,使用户可以听到清晰悦耳的音质和连贯流畅的语调。现在有少部分MP3随身听具有了TTS功能。   TTS是语音合成应用的一种,它将储存于电脑中的文件,如帮助文件或者网页,转换成自然语音输出。TTS可以帮助有视觉障碍的人阅读计算机上的信息,或者只是简单的用来增加文本文档的可读性。现在的TTL应用包括语音驱动的邮件以及声音敏感系统。TTS经常与声音识别程序一起使用。现在有很多TTS的产品,包括Read Please 2000, Proverbe Speech Unit,以及Next Up Technology的TextAloud。朗讯、 Elan、以及 AT&T都有自己的语音合成产品。   除了TTS软件之外,很多商家还提供硬件产品,其中包括以色列WizCom Technologies公司的 Quick Link Pen,它是一个笔状的可以扫描也可以阅读文字的设备;还有Ostrich Software公司的Road Runner,一个手持的可以阅读ASCII文本的设备;另外还有美国DEC公司的DecTalk TTS,它是可以替代声卡的外部硬件设备,它包含一个内部软件设备,可以与个人电脑自己的声卡协同工作。 TTS文语转换用途很广,包括电子邮件的阅读、IVR系统的语音提示等等,目前IVR系统已广泛应用于各个行业(如电信、交通运输等)。   TTS所用的关键技术就是语音合成(SpeechSynthesis)。早期的TTS一般采用专用的芯片实现,如德州仪器公司的TMS50C10/TMS50C57、飞利浦的PH84H36等,但主要用在家用电器或儿童玩具中。   而基于微机应用的TTS一般用纯软件实现,主要包括以下几部分:   ●文本分析-对输入文本进行语言学分析,逐句进行词汇的、语法的和语义的分析,以确定句子的低层结构和每个字的音素的组成,包括文本的断句、字词切分、多音字的处理、数字的处理、缩略语的处理等。   ●语音合成-把处理好的文本所对应的单字或短语从语音合成库中提取,把语言学描述转化成言语波形。   ●韵律处理-合成音质(Qualityof Synthetic Speech)是指语音合成系统所输出的语音的质量,一般从清晰度(或可懂度)、自然度和连贯性等方面进行主观评价。清晰度是正确听辨有意义词语的百分率;自然度用来评价合成语音音质是否接近人说话的声音,合成词语的语调是否自然; 连贯性用来评价合成语句是否流畅。   要合成出高质量的语音,所采用的算法是极为复杂的,因此对机器的要求也非常高。算法的复杂度决定了目前微机并发进行多通道TTS的系统容量。 在一般的CTI应用系统中,都会有IVR(交互式语音应答系统)。IVR系统是呼叫中心的重要组成部分,通过IVR系统,用户可以利用音频按健电话输入信息,从系统中获得预先录制的数字或合成语音信息。具有TTS功能的IVR可以加快服务速度,节约服务成本,使IVR为呼叫者提供7*24小时的服务。   目前常见的IVR系统大都是通用的工控机平台上插入语音板卡组成,并支持中文语音合成TTS等技术。   一个典型的包含TTS服务的电话服务流程可分为:   用户电话拨入,系统IVR响应,获得用户按键等信息。   IVR根据用户的按键信息,向数据库服务器申请相关数据。   数据库服务器返回文本数据给IVR。   IVR通过其TCP通讯接口,将需要合成的文本信息发送给TTS服务器。   TTS服务器将用户文本合成的语音数据分段通过TCP通讯接口发送给IVR服务器。   IVR服务器把分段语音数据组装成为独立的语音文件。   IVR播放相应的语音文件给电话用户。   一般的公网接入(IVR)大都采用工控机+语音板卡,而合成的语音数据则通过局域网传给IVR。这种结构只适用于简单的应用场合。 包括中文语音处理和语音合成,利用中文韵律等相关知识对中文语句进行分词、词性判断、注音、数字符号转换,语音合成通过查询中文语音库得到语音。目前中文TTS系统,比较著名的有:IBM,Microsoft,Fujitsu,科大讯飞,捷通华声等研究的系统。目前比较关键的就是中文韵律处理、符号数字、多音字、构词方面有较多的问题,需要不断研究,使得中文语音合成的自然化程度较高。  CTI技术使电信和计算机相互融合,克服了传统电信和计算机服务相对单一的缺点,将两者完美结合了起来。其应用领域非常广泛,任何需要语音、数据通信,特别是那些希望把计算机网与通信网结合起来完成语音数据信息交换的系统都会用到CTI技术。   TTS即语音合成技术(Text To Speech),它涉及声学、语言学、数学信号处理技术、多媒体技术等多个学科技术,是中文信息处理领域的一项前沿技术,实现把计算机中任意出现的文字转换成自然流畅的语音输出。   TTS在CTI系统中可以应用在IVR(交互式语音应答)服务器上,以提供语音交互式平台,为用户电话来访提供语音提示,引导用户选择服务内容和输入电话事务所需的数据,并接受用户在电话拨号键盘上输入的信息,实现对计算机数据库等信息资料的交互式访问。   在IVR中应用TTS可以自动将文本信息转换为语音文件,或者实时地将文本信息合成语音并通过电话发布。实现文本与语音自动双向转换,以达到人与系统的自动交互,随时随地为客户服务。维护人员不必再人工录音,只须将电子文档引入系统中,系统可以自动将电子文档转换为语音信息播放给客户。数据库中存放的大量数据,无需事先进行录音,能够随时根据查询条件查出并合成语音进行播报,从而大大减少了座席人员的工作负担。   那么应如何将TTS功能附加到CTI应用中呢?某些比较先进的交换平台,已经在交换机的内部实现了TTS的功能,并作为标准接口的一部分对外提供,业务开发商只需要简单的调用他们即可以在业务中使用该功能。   对于未实现TTS功能的PBX,就需要业务开发商自己去选择合适的平台,在此基础上进行二次开发,即调用所选TTS平台提供的标准接口,实现语音合成功能。   目前CTI已经成为全球发展最为迅猛的产业之一,每年以50%的速度增长,CTI如同计算机产业一样是一个金字塔形的产业链,从上到下会以至少20倍的幅度增值。TTS作为一种诱人的新技术,如果能很好的嵌入到增值业务的应用中去,必将形成一个更好的应用前景。   杭州音通软件有限公司是由国家教育部和浙江省人民政府联办并依托浙江大学而成立的高新技术公司,音通公司主要致力于计算机语音技术的研发并逐步开拓语音识别、语音流媒体传输等其它语音领域的研究。其核心技术(Intone_TTS)是具有自主知识产权的中文语音合成技术,在由浙江省科技厅组织的鉴定中被专家一致鉴定为国内领先地位,并已申请多项国家专利。   Intone_TTS是一套把文本信息转换为语音信息的开发工具包,为系统集成商、软件开发商提供了完备的接口函数和编程示例,使用户能够灵活的进行调用,并集成到其它应用系统中。接口需要语音合成运行库的支持,适合多种开发环境。开发者可以根据具体的应用场合进行选择。   它能够对所有的汉字、英文、阿拉伯数字进行语音合成;   支持繁体字及多音字的编辑;   合成效果:自然、平滑;   规范的函数调用接口,同时支持微软SAPI的调用;支持同步调用和异步调用方式;   支持PCM Wave,uLaw/aLaw Wave,ADPCM,Dialogic Vox等多种语音格式;   支持GB2312码(简体中文)、BIG5码(繁体)、UNICODE码;   支持多路通道同时合成;   支持Dialogic、东进、三汇等主流语音板卡; TTS就是Text To Speech,文本转语音,文本朗读,差不多是一个意思。在语音系统开发中经常要用到。   目前市场上的TTS很多,实现方式也各式各样,有的很昂贵,如科大讯飞,据说当初得到863计划的资助,有很高的技术;有的相对便宜,如捷通华声, InfoTalk;也有免费的,如微软的TTS产品。   相对于ASR(Automatic Speech Recognition,自动语音识别)来说,实现一个TTS产品所需要的技术难度不算大,在我看来也就是个力气活。   要是让我们来做一个能够把汉语句子朗读出来的TTS,我们会怎么做呢?   有一种最简单的TTS,就是把每个字都念出来,你会问,岂不要录制6千多个汉字的语音?幸运的是,汉语的音节很少,很多同音字。我们最多只是需要录制: 声母数×韵母数×4,(其实不是每个读音都有4声),这样算来,最多只需要录制几百个语音就可以了。   在合成的时候需要一张汉字对应拼音的对照表,汉字拼音输入法也依赖这张表,可以在网上找到,不过通常没有4声音调,大不了自己加上,呵呵,要不怎么说是力气活呢。   这样做出来的TTS效果也还可以,特别是朗读一些没有特别含义的如姓名,家庭住址,股票代码等汉语句子,听起来足够清晰。这要归功于我们伟大的母语通常都是单音节,从古代的时候开始,每个汉字就有一个词,表达一个意思。而且汉字不同于英语,英语里面很多连读,音调节奏变化很大,汉字就简单多了。   当然,你仍然要处理一些细节,比如多音字,把“银行”读成“yin xing”就不对了;再比如,标点符号的处理,数字、字母的处理,这些问题对于写过很多程序的你,当然不难了。   国内的一些语音板卡带的TTS,不管是卖钱的还是免费的,大体都是这样做出来的,也就是这样的效果。   如果要把TTS的效果弄好一点,再来点力气活,把基本的词录制成语音,如常见的两字词,四字成语等,再做个词库和语音库的对照表,每次需要合成时到词库里面找。这样以词为单位,比以字为单位,效果自然是好多了。当然,这里面还是有个技术,就是分词的技术,要把复杂的句子断成合理的词序列,也有点技术。这也要怪新文化那些先驱们,当初倡导白话文,引进西文的横排格式、标点符号的时候,没有引进西文中的空格分词。不过即使分词算法那么不高效,不那么准确,也问题不大,如前面所说,汉字是单音节词,把声音合起来,大体上不会有错。   当然,科大讯飞的力气活又干的多了些,据说已经进化到以常用句子为单位来录音了,大家可以想像,这要耗费更多的力气,换来更好的效果。   至于增加一些衔接处的“词料”,弄一些修饰性的音调,我认为是无关紧要的,对整体的效果改进不是太大。   市面上商品化TTS一般还支持粤语,请个粤语播音员录音,把上面的力气活重做一遍就是了。   再说句题外话,很多人觉得录音最好找电台、电视台的播音员,其实找个你周围的女同事来录制,只要吐字清晰就可以了。在某种情况下,寻常声音比字正腔圆的新闻联播来得可爱。   再来说说文本的标识,对于复杂文本,某些内容程序没有办法处理,需要标识出来。比如,单纯的数字“128”,是应该念成“一百二十八”还是“一二八”?解决办法通常是加入XML标注,如微软的TTS:"<context ID = "number_cardinal">128</context>"念成“一百二十八”,"<context ID = "number_digit">128</context>"将念成“一二八”。TTS引擎可以去解释这些标注。遗憾的是,语音XML标注并没有形成大家都完全认可的标准,基本上是各自一套。   再说说TTS应用编程,微软的TTS编程接口叫SAPI,是COM接口,开发起来还是有点麻烦,还好MSDN的网站上资料很全面。微软的TTS虽然免费,但其中文角色目前是个男声,声音略嫌混浊,感觉不爽。   国内一般的厂家提供API调用接口,相对比较简单,可以方便地嵌入应用程序中去。   商品化的TTS还有个并发许可限制,就是限制同时合成的并发线程数,我觉得这个限制用处不大。无论哪种TTS,都可以将文本文件转换成语音文件,供语音卡播放。大部分应用句子比较短小,一般不会超过100个汉字,合成的时间是非常短的,弄个线程专门负责合成,其它应用向该线程请求就是了,万一句子很长,把它分解成多个短句子就是了,播放的速度总是比合成的速度慢。   也很多应用是脱机合成,没有实时性要求,就更不必买多个许可了。   更多情况下,我们甚至没有必要购买TTS,比如语音开发中常见的费用催缴,拨通后播放:“尊敬的客户,您本月的费用是:212元”,前面部分对所有客户都一样,录一个语音文件就是了,而数字的合成是很简单的,你只要录制好10个数字语音,再加上十,百,千,万,再加上金钱的单位“元”。   TTS(Training+Tool+Scheme)超越计划   针对目前成长型企业遇到的人力资源问题,立体化解决人力资源瓶颈、通过企业与专家共建、实现人才强企的人力资源方向的重大智业项目。为企业培养人力资源高级管理人才,提供先进人力资源管理工具,并协助企业建立现代人力资源战略规划。通过“培训(Training)+工具(Tool)+方案(Scheme)”的办法,为企业系统解决人力资源难点问题,进而搭建科学、完善的人力资源管理体系。   TTS TIANJIN TERMINAL SURCHARGE   天津港口附加费。09年从日韩经过的船所收的一个费用 答案来源网络,供参考,希望对您有帮助

问问小秘 2019-12-02 03:05:12 0 浏览量 回答数 0

问题

【精品问答】python技术1000问(2)

问问小秘 2019-12-01 22:03:02 3129 浏览量 回答数 1

回答

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

游客ih62co2qqq5ww 2020-03-27 23:56:48 0 浏览量 回答数 0

回答

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

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