• 关于 准同步网是什么 的搜索结果

回答

一、什么是同步通知 同步通知是指在请求参数中传入return_url参数,支付成功后跳转到return_url地址后携带的返回参数,如下可以在同步跳转的地址栏看到同步返通知: return_url参数 后面?拼接的就是同步返回参数。 注:目前在支付接口中只有手机网站支付的接口和电脑网站支付的接口可以传入return_url参数 来接收到同步通知 其他的支付接口 如APP支付和当面付的接口都是不支持的。 二、什么是异步通知 异步通知是指在请求参数中传入notify_url参数,在用户支付成功后,支付宝服务器会按照这个异步地址使用post方式给notify_url来发送交易信息,如下: gmt_create=2018-06-19 10:45:21&charset=UTF-8&seller_email=$$$&subject=使用充值:0.01元&sign=$$$&body=欢迎使用&buyer_id=208***29999&invoice_amount=0.01&notify_id=fa5f28482957168bb30be6230000bb7m3l&fund_bill_list=[{"amount":"0.01","fundChannel":"ALIPAYACCOUNT"}]&notify_type=trade_status_sync™_status=TRADE_SUCCESS&receipt_amount=0.01&app_id=201803***999&buyer_pay_amount=0.01&sign_type=RSA2&seller_id=208***999&gmt_payment=2018-06-19 10:45:22&notify_time=2018-06-19 10:59:12&passback_params=1007511859282415616&version=1.0&out_trade_no=20180619109999&total_amount=0.01™_no=2018061921001004790596169999&auth_app_id=20180***99&buyer_logon_id=124***@qq.com&point_amount=0.00 notify_url地址由商户自己定义保证可以正常使用外网post方式访问,否则是无法正常接收到异步通知的。 三、同步通知和异步通知的区别 1、接收方法不同同步通知是在同步返回的页面使用get方式来获取的 异步通知是使用post方式发送到异步地址上的,只能使用post方式来接收。 2、返回的参数不同 同步通知返回的参数比异步通知返回的参数是要少一些的,最明显的就是异步返回参数会返回trade_status(交易状态)参数 但是同步返回的参数是没有的,所以建议使用异步返回的参数来确认交易是否成功 如果trade_status=TRADE_SUCCESS 表示就是交易成功了 3、发送的时间不同 一般情况下,异步通知比同步通知稍慢(几乎无感知)。同步和异步通知的发送和网络环境、服务器处理速度等因素关系较大,具体是先接收到同步通知还是异步通知,建议以实际接收到的为准。 4、参数返回的逻辑不一样 (1.)同步通知是在支付成功后的页面跳转,一般是用于展示给用户的进行浏览。比如想在用户支付成功跳转到对应的某个页面,那就把对应的return_url值配置要跳转的页面地址即可。 (2)异步通知参数是直接由支付宝服务器发送到商户的异步地址上的 不存在页面跳转是直接的服务器交互。

保持可爱mmm 2020-05-05 17:08:49 0 浏览量 回答数 0

回答

回1楼服务器之家的帖子 求问该服务有无必须默认开启的必要性? ------------------------- Re求问centos下开的ntpd服务有什么用处 一直以为ntpd是充当时钟服务器让其他服务器同步时间的 ntpdate是同步时间的客户端服务 刚百度了下两者的区别,果断很是景仰阿里云的技术人员: 在Linux操作系统设置与上级NTP时钟源同步是很基本的操作,Linux提供了ntpd和ntpdate两种方式来实现时间同步,但它们在同步原理上则有着本质的区别:ntpd在实际同步时间时是一点点的校准时间的,也可以理解为ntpd是平滑同步;而ntpdate不会考虑其他程序是否会阵痛,就立即同步。因此在生产环境中慎用ntpdate。 我们可以结合一个应用场景来加强对ntpd和ntpdate的理解: 网站限制用户注册1小时后才能发帖。 数据库服务器在 10:00分接受了我的注册邀请; 10:03分,ntpdate将数据库时间强行改成9:35分; 然后10:05分(9:37分)我尝试发帖,系统判断我注册时间是否满一小时会使用:9:37 – 10:00 最后电脑就逻辑混乱了。。。 类似的案例在网上也有很详细的说明,贴出来给大家看看: 时钟的跃变,有时候会导致很严重的问题。许多应用程序依赖连续的时钟。毕竟,这是一项常见的假定,即:取得的时间是线性的,一些操作,例如数据库事务,通常会地依赖这样的事实:时间不会往回“跳跃”。 不幸的是,ntpdate调整时间的方式就是我们所说的“跃变”,这就导致了几个非常明显的问题: 1. 这样做不安全。ntpdate的设置依赖于ntp服务器的安全性,攻击者可以利用一些软件设计上的缺陷,拿下ntp服务器并令与其同步的服务器执行某些消耗性的任务。由于ntpdate采用的方式是跳变,跟随它的服务器无法知道是否发生了异常(时间不一样的时候,唯一的办法是以服务器为准)。 2. 这样做不精确。一旦ntp服务器宕机,跟随它的服务器也就会无法同步时间。与此不同,ntpd不仅能够校准计算机的时间,而且能够校准计算机的时钟。 3. 这样做不够优雅。由于是跳变,而不是使时间变快或变慢,依赖时序的程序会出错(例如,如果ntpdate发现你的时间快了,则可能会经历两个相同的时刻,对某些应用而言,这是致命的)。 因而,唯一可以令时间发生跳变的点,是计算机刚刚启动,但还没有启动很多服务的那个时候。其余的时候,理想的做法是使用ntpd来校准时钟,而不是调整计算机时钟上的时间。 NTPD 在和时间服务器的同步过程中,会把 BIOS 计时器的振荡频率偏差,或者说 Local Clock 的自然漂移(drift)记录下来。这样即使网络有问题,本机仍然能维持一个相当精确的走时。 所以最后的建议是:如果首次安装操作系统还未启动业务之前,建议先ntpdate,然后再开启ntpd服务与时间服务器进行实时平滑同步。

srnpr 2019-12-02 03:11:39 0 浏览量 回答数 0

问题

域名预订

boxti 2019-12-01 21:36:35 1592 浏览量 回答数 0

新手开公司,教你化繁为简

开公司到底有没有那么难,传统的手续繁琐,线下跑断腿,场地搞不定等问题,通过阿里云”云上公司注册“解决你的烦恼。

回答

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

小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

回答

2014年12月第2周 1)SLB植入cookie和SLB重写cookie有什么区别? cookie植入,表示直接由SLB系统来分配和管理对客户端进行的cookie植入操作,用户在进行配置时 需要指定会话保持的超时时间; cookie重写,表示SLB系统会根据用户自定义cookie名称来分配和管理对客户端进行的cookie植入操 作,便于用户识别和区分自定义的cookie名称 http://help.aliyun.com/doc/view/13510025.html?spm=0.0.0.0.vwbsGF 2)SLB有没有对外提供API接口,因为我想做到用程序自动去控制SLB的操作? SLB api您可以参考http://help.aliyun.com/view/13621674.html? spm=5176.7114037.1996646101.1.9RoTFM&pos=1 3)使用slb怎么实现数据的单向同步和双向同步? 单向同步可以使用rsync,双向同步的话rsync需要借用别的服务来实现,如unison+inotify。 4)slb的vip是否可以实现远程登录? slb 的vip无法实现远程登录。 5)slb的带宽是所有后端ECS服务器的带宽总和吗? 不是,使您购买的slb实例带宽。 6)slb健康检查机制是什么? 用户开启健康检查功能后,当后端某个ECS健康检查出现问题时会将请求转发到其他健康检查正常的 ECS上,而当该ECS恢复正常运行时,SLB会将其自动恢复到对外或对内的服务中。 针对7层(HTTP协议)服务,SLB系统的健康检查机制为:默认通过SLB的后端系统来向该ECS应用服务 器配置的缺省首页发起http head请求(缺省通过在服务监听配置中指定的后端ECS端口进行访问), 返回200 OK后将视为后端ECS运行正常,否则视为后端ECS运行异常。如果用户用来进行健康检查的页 面并不是应用服务器的缺省首页,那么需要用户指定相应的URI。如果用户对http head请求限定了 host字段的参数,那么需要用户指定相应的URL。用户也可以通过设定健康检查的频率、健康阈值和 不健康阈值来更好的控制健康检查功能。 针对4层(TCP协议)服务,SLB系统的健康检查机制为:默认通过在服务监听配置中指定的后端ECS端 口发起访问请求,如果端口访问正常则视为后端ECS运行正常,否则视为后端ECS运行异常。 当用户后端ECS健康检查异常后,SLB系统会将该ECS的转发权重设置为0,从而确保新的连接不会再被 转发到该ECS上,而已经建立的连接的请求却不会被直接断掉。 针对可能引起健康检查异常的排查思路点击这里查看。 关于健康检查的参数配置,提供如下参考建议: 响应超时时间:5秒 健康检查间隔:2秒 不健康阈值:3 健康阈值:3 7)权重设置为0怎么办? 权重为0的服务器将无法提供服务。 8)健康检查异常的排查思路? 参考http://help.aliyun.com/doc/view/13510029.html?spm=0.0.0.0.Oa9Ezv ------------------------- 12月份第3周1)轮询与最小连接数方式的区别是什么?当前SLB支持轮询和最小连接数2种模式的转发规则。“轮询模式”会将外部和内部的访问请求依序分发给后端ECS进行处理,而“最小连接数模式”会将外部和内部的访问请求分发给当前连接数最小的一台后端ECS进行处理。2)SLB支持redis的主备?目前我们的SLB不支持主备模式(冷备),只支持"轮询"和"最小连接数"两种负载模式。关于SLB的原理您可以参阅如下博文:http://blog.aliyun.com/149 基于ECS的redis搭建,您可以参阅论坛中其它用户的分享案例:http://bbs.aliyun.com/read/161389.html3)负载均衡的多台服务器之间文件会不会自动同步?slb是不会自动同步的,需要您自行配置。4)四层和七层检查的区别是什么?如果是4层(TCP)配置,健康检查只是简单的TCP握手,不会真正去访问您的业务。但对于7层(HTTP)配置,会发HTTP请求(类似于正常访问),并根据返回状态码判断服务状态(2XX表示服务正常)。5)我有多个slb,之前一个slb由于被攻击被黑洞给屏蔽了外部请求,是否可以在slb 并屏蔽后 能够自动将请求分发到另外的slb?由于攻击导致屏蔽外部请求的话,slb没有自动切换的方法的。6)目前slb是否可以设置黑名单?暂不支持。7)我的slb实例控制台显示是停止,为什么?需要给监听的端口设置带宽才能正常。  8)我使用了 SLB那么ESC 需要购买带宽吗?不需要的。但如需要管理ECS,则可购买少些的带宽如1M来管理。9)slb变更计费方式需要多久才能生效?变更和计费将在第二日零点后生效。10)私网SLB的使用,是如何收费的呢?私网slb是不收取费用的。 ------------------------- 12月第4周1)最近用slb后打开网页老出现503 和504错误?一般都是从ECS获取站点信息等异常导致的。您首先先确保源站都可以正常的访问。2)slb检查时突然发现SLB监听错误,怎么回事?配置的健康检查的域名为空,检查的路径是/index.html,目前查看服务器中只有站点c绑定了空主机头,且站点目录下有index.html,而此站点是停止状态,现已帮您启用,查看服务器的健康检查状态已经正常。3)我想使用slb搭建一个负载均衡,后端使用windows服务器,想咨询一下后端服务器是否需要进行什么特别配置呢?另外使用了slb后,后端还能否得到用户的真实IP地址呢,要不要进行什么特殊配置才可以得到后端用户的真实IP。后端服务器的操作系统和web环境最好保持一致,硬件配置上没有什么特别的,4层tcp是可以直接获得前端用户访问的真实地址的,7层http需要在后端web服务端设置一下,参考http://help.aliyun.com/view/13502961.html?spm=5176.7114037.1996646101.1.oRpnOM&pos=14)slb支持https吗?slb您可以通过TCP协议配置443端口的方式来实现,但是安全证书需要保存在您的后端ECS上。5)健康检查后续是否提供多个域名?健康检查只支持一个域名。6)我想关闭负载均衡的健康检查,请问如何配置?4层tcp是无法关闭健康检查的,7层http可以在控制台关闭。健康检查是不会消耗您服务器的资源的,因为slb都是通过内网ip来进行健康检查。7)如何在BLS上 限制单个IP 禁止访问 我的网站呢?SLB暂时不支持设置屏蔽用户端IP。 ------------------------- Re:Re负载均衡SLB常见咨询问题(持续连载) 引用第2楼517449116于2014-12-17 15:54发表的 Re负载均衡SLB常见咨询问题(持续连载) : 如果开启健康检查,健康检查异常的话,是不是就不会给这个异常的ECS分发? [url=http://bbs.aliyun.com/job.php?action=topost&tid=188736&pid=596806][/url] 异常的话不会在分发。 ------------------------- 2015年1月第1周1)有2台ECS起名叫A和B做SLB,A权重设的100 B权重设的0.请问.当A死机时,SLB是否会转到权重是0的B上?如果有一台设置为0,永远都不会有请求转发到此服务器上,即使权重100的宕机也不会转发到0权重的。2)会话保持的选择?开启会话保持功能后,SLB会把来自同一客户端的访问请求分发到同一台后端ECS上进行处理。针对7层(HTTP协议)服务,SLB系统是基于cookie的会话保持。针对4层(TCP协议)服务,SLB系统是基于IP地址的会话保持。3)用nagios或zabbix监控网络带宽,是否可以监控 slb的流量?nagios或zabbix,cacti是要要被监控端安装snmp或者相关agent ,slb不支持安装这些,所以无法通过这条监控软件进行监控。您可以在slb的控制台里面进行查看流量等相关信息。4)用了负载均衡后升级带宽,是不是只用在负载上面升级就可以了,ECS是不是不用在升级了?SLB与后端服务器是经过内网通信,所以如果业务量增加,您对SLB的带宽调整就行,不需要对服务器ECS进行带宽的升级。 ------------------------- 2015年1月第2周 1)SLB到期之后,会对SLB有关联的云主机怎么处理?云主机还没到期的前提下  我想把网站域名解析到SLB上 如果SLB到期了 会影响到我的网站服务么? 云服务器是不会有什么影响的,会自动又变成单独的云服务器可以供您使用的。但是如果您的域名是解析到SLB上,那么会影响到您的站点访问的。服务器上不会有其他的问题感谢您的支持。 2)当SLB 状态为停止的时候 还计算费用吗?停止后公网slb会收取实例费用。SLB价格总览参考:http://help.aliyun.com/view/11108234_13502923.html?spm=0.0.0.0.kBLsVA 3)做了SLB负载均衡,四层和7层负载均衡是否都走slb带宽? 都走slb带宽。 4)我想 移除 slb下的ecs(用作其他用途),请问在移除的时候是否会影响被负载到这台 ecs上的服务的使用 ,也是说slb这是是怎么处理的? 您可以将要移除的主机的权重更改为0 ,这样默认就不会在分发到权重为0的主机上,这个时候您可以移除该主机。但要确保您的另外一台服务器可以承受所有的访问。 5)SLB实例如何释放? 您需要登录管理控制台点击负载均衡。查询您之前创建的实例在哪个节点下,然后释放您的实例。 6)SLB按照小时的带宽计费, 是否需要每小时调整?比如我可否按照一个比较高的上限, 比如3G,然后每个小时按照该小时的峰值进行独立计费呢?   在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效;比如用户在今天5月5日的10:00提交了变更计费方式,那么该变配申请将在明天5月6日00:00后生效。http://help.aliyun.com/view/13502923.html?spm=5176.7114037.1996646101.3.67L5dm&pos=2;SLB目前最大带宽是1000Mbps 7)SLB可以限制每个ip的访问频率吗?(工单1F684MN)slb不支持这样配置的。 8)为什么我设置SLB健康检查间隔为5S,但却每秒都有很多请求?因为用于健康检查的服务ip不止一个,每秒中都会有不同的内网ip进行健康检查,健康检查是通过内网方式,不会消耗您后端服务器的资源,您可以将健康检查间隔阈值跳大些,这样监测频率会降低很多。 ------------------------- Re:负载均衡SLB常见咨询问题(持续连载至2015年1月第3周) 2015年1月第3周 1.发现很多100.97.0.0/16 的ip段扫描,给我服务器带来很大压力,怎么办? 100.97.0.0/16 是我们slb的健康检查服务ip段,如果给服务器带来较大压力,请调整健康检查的设置;健康检查的话 1)调低检查频率 2)设置检查静态文件,而不是默认首页或者动态文件 3)设置一个不记录日志的virtualhost,专门用于健康检查。 2)SLB里的带宽 和后面对应服务器的带宽有什么关联关系?比如SLB我设置了带宽为10M, 但是我后 面2台服务器购买的带宽都只有2M, 这种情况带宽以哪个为准? 如果您设置的是常规7层slb负载均衡,那么网站访问所使用的带宽,都将通过slb而不需要消耗云服 务器的带宽,但是云服务器本身的系统更新,以及您更新网站等等也是需要带宽的,因此您保留2M 即可。 3)采用流量计费方式的话带宽是否没有限制? SLB按流量计费最大的带宽是1G。 4)请问我如何获得一个外网SLB期所对应的内网IP呢?比如现在我有一个外网SLB下挂了一个ECS, 而ECS的iptables里我想做一些配置,针对来自于这个SLB的请求做一个判断,我需要知道这个外网 SLB的内网IP。 目前SLB与后端通过如下地址段进行交互: 10.158.0.0/16 10.159.0.0/16 100.97.0.0/16 您可以针对上述地址段做相关配置。 5)如何确保SLB后端的多台ECS之间的数据同步呢? 目前,有很多类似的工具可以实现服务器之间的数据同步,比如:rsync。具体使用及选择,还请通 过其他途径获得更多的介绍资料及指导信息。您也可以将您的ECS配置成无状态的应用服务器,而数 据和文件统一存放在RDS和OSS服务上。 ------------------------- 2015年1月第4周1.为什么我的SLB实例突然消失了?请检查您的SLB服务是否设置了自动释放时间导致。2.我想关掉负载均衡,怎么操作?您直接登录到阿里云管理控制台——slb负载均衡——实例中查询创建的slb服务,后方有“释放”的按钮,您直接释放即可。3. 我现在有两个阿里账号里面都有ECS,我能不能在一个slb里面配置不同阿里云账户下的ECS?目前只能将同一账户下的服务器添加到SLB中,无法跨账户添加。4.ECS做负载均衡需要用户做额外的配置吗?可以参考http://help.aliyun.com/knowledge_detail.htm?knowledgeId=5973987。5. 云服务器上做数据库负载均衡如何实现,需要购买什么产品 ?文件服务器能否做负载均衡,比如10台文件服务器,包括读写这种的  ?1)数据库集群,用slb理论上是可以做的,但是如果您需要集群级别的数据库,建议使用我们的RDS。2)文件服务器也可以负载均衡,使用slb在均衡,保持会话,但是有一个问题是后端文件同步的,需要您自行同步,如 rsync。6.看SLB的说明是支持ddos的防护的,请问下,SLB的防护的峰值是多少,超过峰值黑洞时间是多少?这个与slb所在地区有关,和ecs的防御阀值是一样的,黑洞时间也是2.5小时。7. slb第七层是基于haproxy还是nginx还是tengine实现的?使用tengine实现的。8.7层和4层 SLB的超时时间是多少?7层超时时间是60s,4层超时时间是900s。9.负载均衡健康检查请求数量太多,怎么回事?因为slb前端机器是一组机器,所以健康检查请求较多,请您不要担心,集群内的每台服务都会对您的健康按照您设定的频率去做健康检查:您可以按照上述方法去优化您的健康检查项,看似请求量很大,但是对您资源消耗很少的,有2个建议给您:1)扩大健康检查的频率2)将检查页面配置为静态页面。这样请求消耗的资源会节省。10. SLB配置中的最小连接数是基于什么样判断?SLB会自动判断 当前ECS 的established 来判断是否转发。 ------------------------- 2015年2月第1周1)我想了解下SLB按流量计费是不是每小时需要扣0.02元?按量付费,国内节点配置费用是按照0.02/小时。流量单独计费。按带宽计费:采取按小时计费,以日结算(运行未满一日,按照当日实际使用小时数*当日开通的最高带宽的天价格/24)。如果您使用SLB实例的时间不足一小时,按一小时收费。2)请问健康检查发的什么请求? head 还是 get?head请求。3)SLB最大连接数如何来设置?目前暂不支持设置最大连接数限制。4)SLB 后端有两个服务器HA1和HA2,为什么我将HA1的权重设置成0,SLB的健康检查就有告警呢?slb四层的话,只要权重设置为0,那么健康检查就是显示异常。 ------------------------- 2015年2月第3周1)负载均衡SLB的实例防攻击防御是多少?我们有云盾的防御黑洞策略,比如以杭州节点的slb,其最高防御的流量阈值为5G,当最大流量超过5G,您的slb vip则会被加入到黑洞中,触发黑洞会使ecs或者slb正常使用中断2.5小时,这个您可以通过云盾管理控制台查看到这个说明。2) 我其他机房的服务器能添加到你们的负载均衡SLB中吗?不可以的,slb使用的是内网和后端的ECS互联,无法直接添加非阿里云主机的服务器,且slb后端的ecs需要使用同一节点的主机。3)负载均衡服务支持的最大负载均衡实例数目多少?总体峰值可支持每秒新建链接数大约多少?SLB对于后端服务器的数目是没有限制的。对于总体峰值每秒新建连接数是没有限制的。但是因为SLB前端是云盾服务,所以最大值取决于云盾中您配置的请求数。您可以查看云盾看到具体的值。4)SLB按量计费为什么需要设置带宽峰值?如果不设置带宽峰值,遇到攻击等情况,可能流量打的非常高的,带宽流量峰值您可以在slb控制台设置。5)在SLB控制面板看到的流入流量,要比后端服务器的eth0的income流量小很多, 请问slb的流入流量是否应该等于后端服务器的内网网卡入流量吗?不等于的,后端的eth0包括了slb的流量,还有其他的流量,包括ecs直接的内网通信等。slb只做转发,不处理请求的,slb通过内网转发到ecs。6)SLB中的月账单 是指我们拥有所有的 SLB 实例的计费呢,还是单独的某个 SLB 的计费?月账单是指您不同类型产品,截止当前日期内月内消费计费额度的,是所有SLB产品的。您也可以通过账单明细进行查询具体信息的。 ------------------------- 2014年2月第4周1)10.159.63.55,这个内网ip,总是恶意访问我们网站?SLB系统除了会通过系统服务器的内网IP将来自外部的访问请求转到后端ECS上之外,还会对ECS进行健康检查(前提是您已经开启了这一功能)和对您的SLB服务进行可用性监控,这些访问的来源都是由SLB系统发起的,具体包含的IP地址段是:杭州、青岛、北京、深圳节点SLB系统IP地址段:10.159.0.0/16,10.158.0.0/16和100.97.0.0/16,为了确保您对外服务的可用性,请确保对上述地址的访问配置放行规则。2)slb计费方式变更需要多久,业务会受到影响么?变更计费方式与变更配置说明1、支持用户在按使用流量和按公网带宽2种计费方式间切换;2、支持按固定带宽方式计费的用户灵活变更带宽配置;3、在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效;比如:用户在今天5月5日的10:00提交了变更计费方式,那么该变配申请将在明天5月6日00:00后生效。4、按固定带宽方式计费变更带宽配置即时生效,带宽计费取自然日内用户开通的最高带宽。5、对客户业务不会造成影响;3)负载均衡能将我的外部非阿里云服务器和ECS服务器放到一块?目前负载均衡SLB仅支持阿里云ECS,无法支持外部非阿里云服务器。4)slb是否有连接数限制,需要大量终端一直与平台保持长连接,阿里云能提多少长连接?SLB没有并发连接数限制的,slb是转发请求不做处理,实际连接数还要跟您后端的处理能力有关。 ------------------------- 2015年3月第1周1)调整权重会对SLB已经有的正常连接有影响吗?目前调整权重会对调整权重的这台主机已有的连接产生影响,会有连接卡主,卡住时间由健康检查配置的时间决定。2)slb是否支持UDP协议?目前SLB暂不支持UDP协议。3)现在TCP四层负载均衡的出口带宽受ECS机器的出口带宽限制吗?slb和ECS之间走的是内网流量,带宽是不受限制的。4)如果没有外网ip, 是否可以用slb的4层转发 ?没有带宽4层SLB也是可以使用的。 ------------------------- Re:负载均衡SLB常见咨询问题(持续连载至2015年3月第1周) 2015年3月第2周 1)SLB变更计费方式并支付成功后无法添加配置? SLB在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效查看您今天变更过一 次计费方式,开始时间:2015-03-09 00:00:00。原按使用流量计费,在2015-03-09 00:00:00后变更为按固定带宽计 费,带宽峰值: 2Mbps。同时在您新的计费方式生效之前,您是无法对该SLB进行修改配置的。 2)我的账户怎么欠费¥7.88,这是怎么回事? 查看您有使用负载均衡slb业务,在slb产品的账单欠费,请您登陆用户中心-消费记录-账单明细中查看 记录。 3)如何屏蔽健康检查探测的日志记录? 关闭或者屏蔽对test.php访问日志的方式: 在站点配置文件中添加内容: location ~ /test.php { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 注: 1、对test.php的location必须要放置在对php|php5处理前,否则会因为先被进行全局匹配导致无法生效。 2、还可以用另一种方案实现: a、在后端服务器中单独为用于健康检查的页面建立一个站点; b、关闭这个站点的日志记录: location ~ .*\.(php|php5)?$ { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 3、如果检查页面是其他格式,比如test.html,可以采用如下方式进行屏蔽: location ~ /test.html { access_log off; } 4.我想问下SLB的固定带宽,10M是不是上行和下行最大都能达到10M? 固定带宽指的是下行带宽最大达到10M,上行带宽没有限制。上行带宽指的是SLB的入流量(上行),就是进入SLB的 流量。带宽指的是SLB的出流量(下行),就是SLB对外发生给客户端的流量。 5.一般配置SLB的时候有个权重0到100,是如何选择数值的? 权重需要您根据后端机器的配置进行选择比如AB两台机器性能一致就分别设置50,这样请求就会在这两台机器上轮询 ,不同权重决定请求分发的分配。 ------------------------- 2015年3月第3周1)公网的SLB和ECS之间的流量是否收费?不收费。2) 想做SLB+两台ECS,附件OSS,程序Discuz。但是不知道如何实现?slb要求后端的两台ecs数据是一致的,为了保持数据的一致性,建议共享存数和数据,静态文件放置到oss里,数据库文件走自己搭建的主从或者,连接同一台rds。3)按流量计算是否需要设置峰值?按流量计费不需要设置峰值的。4)如何建一个子帐号来管理负载均衡SLB?子账户无法管理负载均衡服务。

qilu 2019-12-02 01:15:34 0 浏览量 回答数 0

回答

服务器和操作系统 1、主板的两个芯片分别是什么芯片,具备什么作用? 北桥:离CPU近,负责CPU、内存、显卡之间的通信。 南桥:离CPU远,负责I/O总线之间的通信。 2、什么是域和域控制器? 将网络中的计算机逻辑上组织到一起,进行集中管理,这种集中管理的环境称为域。 在域中,至少有一台域控制器,域控制器中保存着整个域的用户账号和安全数据,安装了活动目录的一台计算机为域控制器,域管理员可以控制每个域用户的行为。 3、现在有300台虚拟机在云上,你如何进行管理? 1)设定堡垒机,使用统一账号登录,便于安全与登录的考量。 2)使用ansiable、puppet进行系统的统一调度与配置的统一管理。 3)建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。 4、简述raid0 raid1 raid5 三种工作模式的工作原理及特点 磁盘冗余阵列(Redundant Arrays of Independent Disks,RAID),把硬盘整合成一个大磁盘,在大磁盘上再分区,存放数据、多块盘放在一起可以有冗余(备份)。 RAID整合方式有很多,常用的:0 1 5 10 RAID 0:可以是一块盘和N个盘组合 优点:读写快,是RAID中最好的 缺点:没有冗余,一块坏了数据就全没有了 RAID 1:只能2块盘,盘的大小可以不一样,以小的为准 10G+10G只有10G,另一个做备份。它有100%的冗余,缺点:浪费资源,成本高 RAID 5 :3块盘,容量计算10*(n-1),损失一块盘 特点:读写性能一般,读还好一点,写不好 总结: 冗余从好到坏:RAID1 RAID10 RAID 5 RAID0 性能从好到坏:RAID0 RAID10 RAID5 RAID1 成本从低到高:RAID0 RAID5 RAID1 RAID10 5、linux系统里,buffer和cache如何区分? buffer和cache都是内存中的一块区域,当CPU需要写数据到磁盘时,由于磁盘速度比较慢,所以CPU先把数据存进buffer,然后CPU去执行其他任务,buffer中的数据会定期写入磁盘;当CPU需要从磁盘读入数据时,由于磁盘速度比较慢,可以把即将用到的数据提前存入cache,CPU直接从Cache中拿数据要快的多。 6、主机监控如何实现? 数据中心可以用zabbix(也可以是nagios或其他)监控方案,zabbix图形界面丰富,也自带很多监控模板,特别是多个分区、多个网卡等自动发现并进行监控做得非常不错,不过需要在每台客户机(被监控端)安装zabbix agent。 如果在公有云上,可以使用云监控来监控主机的运行。 网络 7、主机与主机之间通讯的三要素有什么? IP地址、子网掩码、IP路由 8、TCP和UDP都可以实现客户端/服务端通信,这两个协议有何区别? TCP协议面向连接、可靠性高、适合传输大量数据;但是需要三次握手、数据补发等过程,耗时长、通信延迟大。 UDP协议面向非连接、可靠性低、适合传输少量数据;但是连接速度快、耗时短、延迟小。 9、简述TCP协议三次握手和四次分手以及数据传输过程 三次握手: (1)当主机A想同主机B建立连接,主机A会发送SYN给主机B,初始化序列号seq=x。主机A通过向主机B发送SYS报文段,实现从主机A到主机B的序列号同步,即确定seq中的x。 (2)主机B接收到报文后,同意与A建立连接,会发送SYN、ACK给主机A。初始化序列号seq=y,确认序号ack=x+1。主机B向主机A发送SYN报文的目的是实现从主机B到主机A的序列号同步,即确定seq中的y。 (3)主机A接收到主机B发送过来的报文后,会发送ACK给主机B,确认序号ack=y+1,建立连接完成,传输数据。 四次分手: (1)当主机A的应用程序通知TCP数据已经发送完毕时,TCP向主机B发送一个带有FIN附加标记的报文段,初始化序号seq=x。 (2)主机B收到这个FIN报文段,并不立即用FIN报文段回复主机A,而是想主机A发送一个确认序号ack=x+1,同时通知自己的应用程序,对方要求关闭连接(先发ack是防止主机A重复发送FIN报文)。 (3)主机B发送完ack确认报文后,主机B 的应用程序通知TCP我要关闭连接,TCP接到通知后会向主机A发送一个带有FIN附加标记的报文段,初始化序号seq=x,ack=x+1。 (4)主机A收到这个FIN报文段,向主机B发送一个ack确认报文,ack=y+1,表示连接彻底释放。 10、SNAT和DNAT的区别 SNAT:内部地址要访问公网上的服务时(如web访问),内部地址会主动发起连接,由路由器或者防火墙上的网关对内部地址做个地址转换,将内部地址的私有IP转换为公网的公有IP,网关的这个地址转换称为SNAT,主要用于内部共享IP访问外部。 DNAT:当内部需要提供对外服务时(如对外发布web网站),外部地址发起主动连接,由路由器或者防火墙上的网关接收这个连接,然后将连接转换到内部,此过程是由带有公网IP的网关替代内部服务来接收外部的连接,然后在内部做地址转换,此转换称为DNAT,主要用于内部服务对外发布。 数据库 11、叙述数据的强一致性和最终一致性 强一致性:在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求,也是最难实现的。关系型数据库更新操作就是这个案例。 最终一致性:和强一致性相对,在某一时刻用户或者进程查询到的数据可能都不同,但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。 12、MySQL的主从复制过程是同步的还是异步的? 主从复制的过程是异步的复制过程,主库完成写操作并计入binlog日志中,从库再通过请求主库的binlog日志写入relay中继日志中,最后再执行中继日志的sql语句。 **13、MySQL主从复制的优点 ** 如果主服务器出现问题,可以快速切换到从服务器提供的服务; 可以在从服务器上执行查询操作,降低主服务器的访问压力; 可以在从服务器上执行备份,以避免备份期间影响主服务器的服务。 14、redis有哪些数据类型? (一)String 最常规的set/get操作,value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。 (二)hash 这里value存放的是结构化的对象,比较方便的就是操作其中的某个字段。做单点登录的时候,就是用这种数据结构存储用户信息,以cookieId作为key,设置30分钟为缓存过期时间,能很好的模拟出类似session的效果。 (三)list 使用List的数据结构,可以做简单的消息队列的功能。另外还有一个就是,可以利用lrange命令,做基于redis的分页功能,性能极佳,用户体验好。 (四)set 因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重?因为我们的系统一般都是集群部署,使用JVM自带的Set,比较麻烦,难道为了一个做一个全局去重,再起一个公共服务,太麻烦了。 另外,就是利用交集、并集、差集等操作,可以计算共同喜好,全部的喜好,自己独有的喜好等功能。 (五)Zset Zset多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用,取TOP N操作。另外,sorted set可以用来做延时任务。最后一个应用就是可以做范围查找。 15、叙述分布式数据库及其使用场景? 分布式数据库应该是数据访问对应用透明,每个分片默认采用主备架构,提供灾备、恢复、监控、不停机扩容等整套解决方案,适用于TB或PB级的海量数据场景。 应用 16、Apache、Nginx、Lighttpd都有哪些特点? Apache特点:1)几乎可以运行在所有的计算机平台上;2)支持最新的http/1.1协议;3)简单而且强有力的基于文件的配置(httpd.conf);4)支持通用网关接口(cgi);5)支持虚拟主机;6)支持http认证,7)集成perl;8)集成的代理服务器;9)可以通过web浏览器监视服务器的状态,可以自定义日志;10)支持服务器端包含命令(ssi);11)支持安全socket层(ssl);12)具有用户绘画过程的跟踪能力;13)支持fastcgi;14)支持java servlets Nginx特点:nginx是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP代理服务器,处理静态文件,索引文件以及自动索引,无缓存的反向代理加速,简单的负载均衡和容错,具有很高的稳定性,支持热部署。 Lighttpd特点:是一个具有非常低的内存开销,CPU占用率低,效能好,以及丰富的模块,Lighttpd是众多opensource轻量级的webserver中较为优秀的一个,支持fastcgi,cgi,auth,输出压缩,url重写,alias等重要功能。 17、LVS、NGINX、HAPROXY的优缺点? LVS优点:具有很好的可伸缩性、可靠性、可管理性。抗负载能力强、对内存和CPU资源消耗比较低。工作在四层上,仅作分发,所以它几乎可以对所有的应用做负载均衡,且没有流量的产生,不会受到大流量的影响。 LVS缺点:软件不支持正则表达式处理,不能做动静分离,如果web应用比较庞大,LVS/DR+KEEPALIVED实施和管理比较复杂。相对而言,nginx和haproxy就简单得多。 nginx优点:工作在七层之上,可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则规则比haproxy更为强大和灵活。对网络稳定性依赖非常小。理论上能PING就能进行负载均衡。配置和测试简单,可以承担高负载压力且稳定。nginx可以通过端口检测到服务器内部的故障。比如根据服务器处理网页返回的状态码、超时等。并且可以将返回错误的请求重新发送给另一个节点,同时nginx不仅仅是负载均衡器/反向代理软件。同时也是功能强大的web服务器,可以作为中层反向代理、静态网页和图片服务器使用。 nginx缺点:不支持URL检测,仅支持HTTP和EMAIL,对session的保持,cookie的引导能力相对欠缺。 Haproxy优点:支持虚拟主机、session的保持、cookie的引导;同时支持通过获取指定的url来检测后端服务器的状态。支持TCP协议的负载均衡;单纯从效率上讲比nginx更出色,且负载策略非常多。 aproxy缺点:扩展性能差;添加新功能很费劲,对不断扩展的新业务很难对付。 18、什么是中间件?什么是jdk? 中间件介绍: 中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源 中间件位于客户机/ 服务器的操作系统之上,管理计算机资源和网络通讯 是连接两个独立应用程序或独立系统的软件。相连接的系统,即使它们具有不同的接口 但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递 通过中间件,应用程序可以工作于多平台或OS环境。 jdk:jdk是Java的开发工具包 它是一种用于构建在 Java 平台上发布的应用程序、applet 和组件的开发环境 19、日志收集、日志检索、日志展示的常用工具有哪些? ELK或EFK。 Logstash:数据收集处理引擎。支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储以供后续使用。 Kibana:可视化化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。 Elasticsearch:分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析,并能将这三者结合起来。Elasticsearch 基于 Lucene 开发,现在使用最广的开源搜索引擎之一,Wikipedia 、StackOverflow、Github 等都基于它来构建自己的搜索引擎。 Filebeat:轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说:Filebeat就是新版的 Logstash-fowarder,逐渐取代其位置。 20、什么是蓝绿发布和灰度发布? 蓝绿:旧版本-新版本 灰度:新旧版本各占一定比例,比例可自定义 两种发布都通过devops流水线实现

剑曼红尘 2020-03-23 15:51:44 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

iOS SDK是什么?

nicenelly 2019-12-01 21:28:04 1767 浏览量 回答数 0

问题

什么是Linux 实例常用内核网络参数介绍与常见问题处理

boxti 2019-12-01 22:01:36 2069 浏览量 回答数 0

问题

iOS SDK是什么?

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