• 关于

    分布系统宕机的原因

    的搜索结果

回答

数据可靠性RocketMQ支持异步实时刷盘,同步刷盘,同步Replication,异步ReplicationKafka使用异步刷盘方式,异步Replication/同步Replication总结:RocketMQ的同步刷盘在单机可靠性上比Kafka更高,不会因为操作系统Crash,导致数据丢失。Kafka同步Replication理论上性能低于RocketMQ的同步Replication,原因是Kafka的数据以分区为单位组织,意味着一个Kafka实例上会有几百个数据分区,RocketMQ一个实例上只有一个数据分区,RocketMQ可以充分利用IO Group Commit机制,批量传输数据,配置同步Replication与异步Replication相比,性能损耗约20%~30%,Kafka没有亲自测试过,但是个人认为理论上会低于RocketMQ。性能对比Kafka单机写入TPS约在百万条/秒,消息大小10个字节RocketMQ单机写入TPS单实例约7万条/秒,单机部署3个Broker,可以跑到最高12万条/秒,消息大小10个字节总结:Kafka的TPS跑到单机百万,主要是由于Producer端将多个小消息合并,批量发向Broker。RocketMQ为什么没有这么做?Producer通常使用Java语言,缓存过多消息,GC是个很严重的问题Producer调用发送消息接口,消息未发送到Broker,向业务返回成功,此时Producer宕机,会导致消息丢失,业务出错Producer通常为分布式系统,且每台机器都是多线程发送,我们认为线上的系统单个Producer每秒产生的数据量有限,不可能上万。缓存的功能完全可以由上层业务完成。单机支持的队列数Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长。Kafka分区数无法过多的问题RocketMQ单机支持最高5万个队列,Load不会发生明显变化队列多有什么好处?单机可以创建更多Topic,因为每个Topic都是由一批队列组成Consumer的集群规模和队列数成正比,队列越多,Consumer集群可以越大消息投递实时性Kafka使用短轮询方式,实时性取决于轮询间隔时间,0.8以后版本支持长轮询。RocketMQ使用长轮询,同Push方式实时性一致,消息的投递延时通常在几个毫秒。消费失败重试Kafka消费失败不支持重试。RocketMQ消费失败支持定时重试,每次重试间隔时间顺延总结:例如充值类应用,当前时刻调用运营商网关,充值失败,可能是对方压力过多,稍后再调用就会成功,如支付宝到银行扣款也是类似需求。这里的重试需要可靠的重试,即失败重试的消息不因为Consumer宕机导致丢失。严格的消息顺序Kafka支持消息顺序,但是一台Broker宕机后,就会产生消息乱序RocketMQ支持严格的消息顺序,在顺序消息场景下,一台Broker宕机后,发送消息会失败,但是不会乱序Mysql Binlog分发需要严格的消息顺序定时消息Kafka不支持定时消息RocketMQ支持两类定时消息开源版本RocketMQ仅支持定时Level,定时Level用户可定制阿里云ONS支持定时Level,以及指定的毫秒级别的延时时间分布式事务消息Kafka不支持分布式事务消息阿里云ONS支持分布式定时消息,未来开源版本的RocketMQ也有计划支持分布式事务消息消息查询Kafka不支持消息查询RocketMQ支持根据Message Id查询消息,也支持根据消息内容查询消息(发送消息时指定一个Message Key,任意字符串,例如指定为订单Id)总结:消息查询对于定位消息丢失问题非常有帮助,例如某个订单处理失败,是消息没收到还是收到处理出错了。消息回溯Kafka理论上可以按照Offset来回溯消息RocketMQ支持按照时间来回溯消息,精度毫秒,例如从一天之前的某时某分某秒开始重新消费消息总结:典型业务场景如consumer做订单分析,但是由于程序逻辑或者依赖的系统发生故障等原因,导致今天消费的消息全部无效,需要重新从昨天零点开始消费,那么以时间为起点的消息重放功能对于业务非常有帮助。消费并行度Kafka的消费并行度依赖Topic配置的分区数,如分区数为10,那么最多10台机器来并行消费(每台机器只能开启一个线程),或者一台机器消费(10个线程并行消费)。即消费并行度和分区数一致。RocketMQ消费并行度分两种情况顺序消费方式并行度同Kafka完全一致乱序方式并行度取决于Consumer的线程数,如Topic配置10个队列,10台机器消费,每台机器100个线程,那么并行度为1000。消息轨迹Kafka不支持消息轨迹阿里云ONS支持消息轨迹开发语言友好性Kafka采用Scala编写RocketMQ采用Java语言编写Broker端消息过滤Kafka不支持Broker端的消息过滤RocketMQ支持两种Broker端消息过滤方式根据Message Tag来过滤,相当于子topic概念向服务器上传一段Java代码,可以对消息做任意形式的过滤,甚至可以做Message Body的过滤拆分。消息堆积能力理论上Kafka要比RocketMQ的堆积能力更强,不过RocketMQ单机也可以支持亿级的消息堆积能力,我们认为这个堆积能力已经完全可以满足业务需求。开源社区活跃度Kafka社区更新较慢RocketMQ的github社区有250个个人、公司用户登记了联系方式,QQ群超过1000人。成熟度Kafka在日志领域比较成熟RocketMQ在阿里集团内部有大量的应用在使用,每天都产生海量的消息,并且顺利支持了多次天猫双十一海量消息考验,是数据削峰填谷的利器。

王晨纯 2019-12-02 01:44:21 0 浏览量 回答数 0

回答

两阶段提交协议是一种经典的强一致性中心化副本控制协议。虽然在工程中该协议有较多 的问题,但研究该协议能很好的理解分布式系统的几个典型问题。 流程描述 两阶段提交协议是一种典型的“中心化副本控制”协议。在该协议中,参与的 节点分为两类:一个中心化协调者节点(coordinator)和N 个参与者节点(participant)。每个参与 者节点即上文背景介绍中的管理数据库副本的节点。 两阶段提交的思路比较简单,在第一阶段,协调者询问所有的参与者是否可以提交事务(请参 与者投票),所有参与者向协调者投票。在第二阶段,协调者根据所有参与者的投票结果做出是否事 务可以全局提交的决定,并通知所有的参与者执行该决定。在一个两阶段提交流程中,参与者不能 改变自己的投票结果。两阶段提交协议的可以全局提交的前提是所有的参与者都同意提交事务,只 要有一个参与者投票选择放弃(abort)事务,则事务必须被放弃。 流程:两阶段提交协调者流程 写本地日志“begin_commit”, 并进入WAIT 状态; 向所有参与者发送“prepare 消息”; 等待并接收参与者发送的对“prepare 消息”的响应; 3.1 若收到任何一个参与者发送的“vote-abort 消息”; 3.1.1 写本地“global-abort”日志,进入ABORT; 3.1.2 向所有的参与者发送“global-abort 消息”; 3.1.3 进入ABORT 状态; 3.2 若收到所有参与者发送的“vote-commit”消息; 3.2.1 写本地“global-commit”日志,进入COMMIT 状态; 3.1.2 向所有的参与者发送“global-commit 消息”; 等待并接收参与者发送的对“global-abort 消息”或“global-commit 消息”的确认响应消息, 一旦收到所有参与者的确认消息,写本地“end_transaction” 日志流程结束。 流程:两阶段提交协调者流程 写本地日志“init”记录,进入INIT 状态 等待并接受协调者发送的“prepare 消息”,收到后 2.1 若参与者可以提交本次事务 2.1.1 写本地日志“ready”,进入READY 状态 2.1.2 向协调者发送“vote-commit”消息 2.1.4 等待协调者的消息 2.1.4.1 若收到协调者的“global-abort”消息 2.1.4.1.1 写本地日志“abort”,进入ABORT 状态 2.1.4.1.2 向协调者发送对“global-abort”的确认消息 2.1.4.2 若收到协调者的“global-commit”消息 2.1.4.1.1 写本地日志“commit”,进入COMMIT 状态 2.1.4.1.2 向协调者发送对“global-commit”的确认消息 2.2 若参与者无法提交本次事务 2.2.1 写本地日志“abort”,进入ABORT 状态 2.2.2 向协调者发送“vote-abort”消息 2.2.3 流程对该参与者结束 2.2.4 若后续收到协调者的“global-abort”消息可以响应 即使流程结束,但任何时候收到协调者发送的“global-abort”消息或“global-commit”消息 也都要发送一个对应的确认消息。 异常处理 宕机恢复 协调者宕机恢复 协调者宕机恢复后,首先通过日志查找到宕机前的状态。 如果日志中最后是“begin_commit”记录,说明宕机前协调者处于WAIT 状态,协调者可能已经 发送过“prepare 消息”也可能还没发送,但协调者一定还没有发送过“global-commit 消息”或 “global-abort 消息”,即事务的全局状态还没有确定。此时,协调者可以重新发送“prepare 消息” 继续两阶段提交流程,即使参与者已经发送过对“prepare 消息”的响应,也不过是再次重传之前的 响应而不会影响协议的一致性。 如果日志中最后是“global-commit”或“global-abort”记录,说明宕机前协调者处于COMMIT 或ABORT 状态。此时协调者只需重新向所有的参与者发送“global-commit 消息”或“global-abort 消息”就可以继续两阶段提交流程。 参与者宕机恢复 参与者宕机恢复后,首先通过日志查找宕机前的状态。 如果日志中最后是“init”记录,说明参与者处于INIT 状态,还没有对本次事务做出投票选择, 参与者可以继续流程等待协调者发送的“prepare 消息”。 如果日志中最后是“ready”记录,说明参与者处于REDAY 状态,此时说明参与者已经就本次 事务做出了投票选择,但宕机前参与者是否已经向协调者发送“vote-commit”消息并不可知。所以 此时参与者可以向协调者重发“vote-commit”,并继续协议流程。 如果日志中最后是“commit”或“abort”记录,说明参与者已经收到过协调者的“global-commit 消息”(处于COMMIT 状态)或者“global-abort 消息”(处于ABORT 状态)。至于是否向协调者发 送过对“global-commit”或“global-abort”的确认消息则未知。但即使没有发送过确认消息,由于 协调者会不断重发“global-commit”或“global-abort”,只需在收到这些消息时发送确认消息既可, 不影响协议的全局一致性。 协议分析 两阶段提交协议在工程实践中真正使用的较少,主要原因有以下几点: 两阶段提交协议的容错能力较差。从上文的分析可以看出,两阶段提交协议在某些情况 下存在流程无法执行下去的情况,且也无法判断流程状态。在工程中好的分布式协议往往总是可以 在即使发生异常的情况下也能执行下去。例如,回忆Lease 机制(2.3 ),一旦lease 发出,无论出 现任何异常,Lease 服务器节点总是可以通过时间判定出Lease 是否有效,也可以用等待Lease 超时 的方法收回Lease 权限,整个Lease 协议的流程不存在任何流程被阻塞而无法执行下去的情况。与 Lease 机制的简单有效相比,两阶段提交的协议显得较为复杂且容错能力差。 两阶段提交协议的性能较差。一次成功的两阶段提交协议流程中,协调者与每个参与者 之间至少需要两轮交互4 个消息“prepare”、“vote-commit”、“global-commit”、“确认global-commit”。 过多的交互次数会降低性能。另一方面,协调者需要等待所有的参与者的投票结果,一旦存在较慢 的参与者,会影响全局流程执行速度。 虽然存在一些改进的两阶段提交协议可以提高容错能力和性能,然而这类协议依旧是在工程中 使用较少的一类协议,其理论价值大于实践意义。

kun坤 2020-04-24 15:32:58 0 浏览量 回答数 0

问题

HBase 优化实战

pandacats 2019-12-20 21:12:25 0 浏览量 回答数 0

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

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

回答

虽然现在有很多的人呼吁使用混合云,因其可以利用私有云与公有的好处。但混合云也不是完全没有缺点的,它仍旧包含了一些安全障碍,要谨记下面五个问题。 公有云提供商提供重要的资源,以确保其基础架构在终端用户需要时有效且可访问。尽管云提供商进了最大努力,问题仍不可避免。大量宣传的宕机事件突出了将应用运转在单一数据中心且没有在其他数据中心进行故障恢复的风险。云架构师需要跨数据中心的冗余来减缓单一数据中心宕机的影响。缺少冗余对于混合云来说可能是严重的安全风险,尤其是如果数据冗余备份没有跨数据中心分布。在数据中心之间转移虚拟机(VM)实例比在大型数据集之间容易的多。云架构师可以使用一个厂商的多个数据中心实现冗余,或者多个公共云厂商或者是混合云。同时可以用混合云改善业务连续性,因为这并不是实现这个模型的唯一原因。同时使用来自单一厂商的多个数据中心,你可以节省成本,达到减少类似风险的水平。 维护和证明混合云法规尊重从更加困难。你不但要确保你的公有云提供商和私有云提供商符合法规,而且你必须证明两个云之间的协调是顺从的。比如,如果你的企业处理支付卡数据,你可能能够证明你的内部系统和你的云提供商遵从支付卡行业数据安全标准(PaymentCardIndustryDataSecurityStandard(PCIDSS))。引入了混合云,你必须确保两个云之间的数据转移是受到保护的。此外,你还需要确保卡数据不会从一个私有云上的法规遵从数据中心转移到一个较少安全性的公有云存储系统。你内部系统使用的预防漏洞的方法可能不直接转化到公有云上。 你可能坚信你的公有云提供商能够始终如一的符合服务水平协议(SLA)中期望的详细说明,但是你的私有云是否有同样的SLA?如果没有,你可能需要基于两个云的期望创建SLA,很可能就是基于你自己的私有云了。在你的私有云的可用性和性能的显示工作负载下收集数据。集成公有云和私有云寻求潜在的问题都会破坏服务。例如,如果一个私有云的关键业务驱动在本地保持敏感和机密数据,然后你的SLA应该体现出在公有云中使用这些服务的限制性。 从业务角度,信息安全是管理管理风险的。云计算(尤其是混合云)使用新的应用程序接口(API),要求复杂的网络配置,并对传统的系统管理员的知识和能力范围造成挑战。这些因素引入了新型的威胁。云计算并不比内部基础架构一样安全,但是混合云是个复杂的系统,管理员在管理上有限的经验,可能就造成了风险。 现有的安全控制,像身份认证、授权和身份认证管理需要在公有云和私有云中共同工作。整合这些安全协议,你只能选择其一:在两个云中复制控制并保持安全数据同步,或者使用身份认证管理服务,提供单一的服务运转在云端。在计划和时间阶段分配足够的时间,以便解决这些相当复杂的整合问题。

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

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

封神 2019-12-02 02:00:50 0 浏览量 回答数 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

问题

性能测试技术怎么进行?

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

回答

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

问题

怎样实现数据存储的管理维护

elinks 2019-12-01 21:14:17 9098 浏览量 回答数 0

问题

支付宝的性能测试

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

问题

达达O2O后台架构演进实践:从0到4000高并发请求背后的努力:报错

kun坤 2020-06-09 15:20:48 4 浏览量 回答数 1

回答

Kafka 是目前主流的分布式消息引擎及流处理平台,经常用做企业的消息总线、实时数据管道,本文挑选了 Kafka 的几个核心话题,帮助大家快速掌握 Kafka,包括: Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多,本文尽量做到深入浅出,全面的介绍 Kafka 原理及核心组件,不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台,经常用做企业的消息总线、实时数据管道,有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统,目前则演变成了一个成熟的分布式消息引擎,以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式,生产者发送消息到 broker 中某一个 topic 的具体分区里,消费者从一个或多个分区中拉取数据进行消费。拓扑图如下: 目前,Kafka 依靠 Zookeeper 做分布式协调服务,负责存储和管理 Kafka 集群中的元数据信息,包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语: Producer:生产者,消息产生和发送端。 Broker:Kafka 实例,多个 broker 组成一个 Kafka 集群,通常一台机器部署一个 Kafka 实例,一个实例挂了不影响其他实例。 Consumer:消费者,拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组,一条消息只能被消费组中一个 Consumer 消费。 Topic:主题,服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition:topic 的分区,分布式存储在各个 broker 中, 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费,达到消费者高吞吐量。一个分区拥有多个副本(Replica),这是Kafka在可靠性和可用性方面的设计,后面会重点介绍。 message:消息,或称日志消息,是 Kafka 服务端实际存储的数据,每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset:偏移量,分区中的消息位置,由 Kafka 自身维护,Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷(缓冲)、系统解构以及冗余的作用,主要特点有: 高吞吐、低延时:这是 Kafka 显著的特点,Kafka 能够达到百万级的消息吞吐量,延迟可达毫秒级; 持久化存储:Kafka 的消息最终持久化保存在磁盘之上,提供了顺序读写以保证性能,并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展:Kafka 的数据是分布式存储在不同 broker 节点的,以 topic 组织数据并且按 partition 进行分布式存储,整体的扩展性都非常好。 高容错性:集群中任意一个 broker 节点宕机,Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要,这也是 Kafka 高吞吐的基础,生产端的基本流程如下图所示: 主要有以下方面的设计: 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API,新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后,再是经过 Partition 分区器处理,决定消息落到 topic 具体某个分区中,最后把消息发送到客户端的消息缓冲池 accumulator 中,交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制,默认是 32M,当生产消息的速度过快导致 buffer 满了的时候,将阻塞 max.block.ms 时间,超时抛异常,所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch,分批次的发送到 broker 端,批次大小由参数 batch.size 控制,默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端,所以一般减小 batch 大小有利于降低消息延时,增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时,才会批量发送到服务端呢?答案是否定的,Kafka 生产端提供了另一个重要参数 linger.ms,该参数控制了 batch 最大的空闲时间,超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外,Kafka 生产端支持重试机制,对于某些原因导致消息发送失败的,比如网络抖动,开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制,参数含义代表重试次数,默认值为 0 表示不重试,建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本(Replica)的概念,副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本,由 broker 端参数 default.replication.factor 控制,默认值为 1,通常我们会修改该默认值,或者命令行创建 topic 时指定 replication-factor 参数,生产建议设置 3 副本。副本作用主要有两方面: 消息冗余存储,提高 Kafka 数据的可靠性; 提高 Kafka 服务的可用性,follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举,继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区,生产消费端所有的读写请求都是由 leader 副本处理的,follower 副本的主要工作就是从 leader 副本处异步拉取消息,进行消息数据的同步,并不对外提供读写服务。 Kafka 之所以这样设计,主要是为了保证读写一致性,因为副本同步是一个异步的过程,如果当 follower 副本还没完全和 leader 同步时,从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步,引入 ISR(In-Sync Replicas)副本集合的概念,ISR 是分区中正在与 leader 副本进行同步的 replica 列表,且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的,任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的,并不是所有的分区副本都在 ISR 列表中,哪些副本会被包含在 ISR 列表中呢?副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的,参数含义是副本同步落后于 leader 的最大时间间隔,默认10s,意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s,就会被从 ISR 中排除。Kafka 之所以这样设计,主要是为了减少消息丢失,只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举,这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的,所以 ISR 列表就有为空的时候,ISR 为空说明 leader 副本也“挂掉”了,此时 Kafka 就要重新选举出新的 leader。但 ISR 为空,怎么进行 leader 选举呢? Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”,这些副本中的消息远远落后于 leader,如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable,用于控制是否允许非同步副本参与 leader 选举;如果开启,则当 ISR 为空时就会从这些副本中选举新的 leader,这个过程称为 Unclean leader 选举。 前面也提及了,如果开启 Unclean leader 选举,可能会造成数据丢失,但保证了始终有一个 leader 副本对外提供服务;如果禁用 Unclean leader 选举,就会避免数据丢失,但这时分区就会不可用。这就是典型的 CAP 理论,即一个系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)中的两个。所以在这个问题上,Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举,这里建议关闭 Unclean leader 选举,因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器(Controller)是 Kafka 的核心组件,它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色,但在运行过程中,只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper,因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树,ZNode 是 Zookeeper 中的数据节点,是 Zookeeper 存储数据的最小单元,每个 ZNode 可以保存数据,也可以挂载子节点,根节点是 /。基本的拓扑图如下: Zookeeper 有两类 ZNode 节点,分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后,该节点依旧存在,直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起,客户端与 Zookeeper 断开会话后,临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性,它可以在 ZNode 节点上绑定监听事件,比如可以监听节点数据变更、节点删除、子节点状态变更等事件,通过这个事件机制,可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时,都会尝试去 Zookeeper 中创建 /controller 节点,第一个成功创建 /controller 节点的 broker 则会被指定为控制器,其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时,其他 broker 能够快速地感知到,然后再次尝试创建 /controller 节点,创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了,控制器主要作用是管理和协调 Kafka 集群,那么 Kafka 控制器都做了哪些事情呢,具体如下: 主题管理:创建、删除 topic,以及增加 topic 分区等操作都是由控制器执行。 分区重分配:执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作,也是由控制器实现。 Preferred leader 选举:这里有一个概念叫 Preferred replica 即优先副本,表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时,会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理:控制器能够监控新 broker 的增加,broker 的主动关闭与被动宕机,进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制,控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务:控制器上保存了最全的集群元数据信息,其他所有 broker 会定期接收控制器发来的元数据更新请求,从而更新其内存中的缓存数据。 从上面内容我们大概知道,控制器可以说是 Kafka 的心脏,管理和协调着整个 Kafka 集群,因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作,特别是在 0.11 版本中对控制器进行了重构,其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案,消除了多线程的资源消耗和线程安全问题,另外一个改进是把之前同步操作 Zookeeper 改为了异步操作,消除了 Zookeeper 端的性能瓶颈,大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时,提到了消费组的概念,一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组 ,一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言,有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程,在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 的完成。因为要停止消费等待重平衡完成,因此 Rebalance 会严重影响消费端的 TPS,是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance,总结起来有三种情况: 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的,比如为了提高消息吞吐量增加 topic 分区数,这些情况一般是不可避免的,后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前,先来认识下 Kafka 的协调器 Coordinator,和之前 Kafka 控制器类似,Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器: 组协调器(Group Coordinator) 消费者协调器(Consumer Coordinator) Kafka 为了更好的实现消费组成员管理、位移管理,以及 Rebalance 等,broker 服务端引入了组协调器(Group Coordinator),消费端引入了消费者协调器(Consumer Coordinator)。每个 broker 启动的时候,都会创建一个 GroupCoordinator 实例,负责消费组注册、消费者成员记录、offset 等元数据操作,这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外,每个 Consumer 实例化时,同时会创建一个 ConsumerCoordinator 实例,负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理: 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况,一种是有新的消费者加入,通常是我们为了提高消费速度增加了消费者数量,比如增加了消费线程或者多部署了一份消费程序,这种情况可以认为是正常的;另一种是有消费者退出,这种情况多是和我们消费端代码有关,是我们要重点避免的。 正常情况下,每个消费者都会定期向组协调器 Group Coordinator 发送心跳,表明自己还在存活,如果消费者不能及时的发送心跳,组协调器会认为该消费者已经“死”了,就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数:session.timeout.ms 和 heartbeat.interval.ms,含义分别是组协调器认为消费组存活的期限,和消费者发送心跳的时间间隔,其中 heartbeat.interval.ms 默认值是3s,session.timeout.ms 在 0.10.1 版本之前默认 30s,之后默认 10s。另外,0.10.1 版本还有两个值得注意的地方: 从该版本开始,Kafka 维护了单独的心跳线程,之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms,表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔,默认值 5min,对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组,此时将发生一次 Rebalance。 此外,如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿,从而引发 Rebalance。因此,我们总结如何避免消费组 Rebalance 问题,主要从以下几方面入手: 合理配置 session.timeout.ms 和 heartbeat.interval.ms,建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms,通常建议调大避免 Rebalance,但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况,避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数,可以减少生产环境中 Rebalance 发生的几率,提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制,Kafka 控制器、消费端 Rebalance 机制等各方面核心原理,通过本文的介绍,相信你已经对 Kafka 的内核知识有了一定的掌握,更多的 Kafka 原理实践后面有时间再介绍。

剑曼红尘 2020-04-16 18:15:45 0 浏览量 回答数 0

问题

该来的终于来了:“第一起”基于 IPv6 的 DDoS 攻击

驻云科技 2019-12-01 21:44:35 4186 浏览量 回答数 1

问题

某政务网站性能优化

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

回答

Redis常见的几种主要使用方式: Redis 单副本 Redis 多副本(主从) Redis Sentinel(哨兵) Redis Cluster(集群) Redis 自研 Redis各种使用方式的优缺点: 1 Redis单副本 Redis各种使用方式的优缺点: Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 2 Redis多副本(主从) Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 3 Redis Sentinel(哨兵) Redis Sentinel是社区版本推出的原生高可用解决方案,Redis Sentinel部署架构主要包括两部分:Redis Sentinel集群和Redis数据集群,其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。 优点: 1、Redis Sentinel集群部署简单 2、能够解决Redis主从模式下的高可用切换问题 3、很方便实现Redis数据节点的线形扩展,轻松突破Redis自身单线程瓶颈,可极大满足对Redis大容量或高性能的业务需求。 4、可以实现一套Sentinel监控一组Redis数据节点或多组数据节点 缺点: 1、部署相对Redis 主从模式要复杂一些,原理理解更繁琐 2、资源浪费,Redis数据节点中slave节点作为备份节点不提供服务 3、Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换,对Redis的数据节点做失败判定分为主观下线和客观下线两种,对于Redis的从节点有对节点做主观下线操作,并不执行故障转移。 4、不能解决读写分离问题,实现起来相对复杂 建议: 1、如果监控同一业务,可以选择一套Sentinel集群监控多组Redis数据节点的方案,反之选择一套Sentinel监控一组Redis数据节点的方案 2、sentinel monitor 配置中的 建议设置成Sentinel节点的一半加1,当Sentinel部署在多个IDC的时候,单个IDC部署的Sentinel数量不建议超过(Sentinel数量 – quorum)。 3、合理设置参数,防止误切,控制切换灵敏度控制 quorum down-after-milliseconds 30000 failover-timeout 180000 maxclient timeout 4、部署的各个节点服务器时间尽量要同步,否则日志的时序性会混乱 5、Redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率 6、自行搞定配置中心(zookeeper),方便客户端对实例的链接访问 4 Redis Cluster(集群) Redis Cluster是社区版推出的Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。Redis Cluster集群节点最小配置6个节点以上(3主3从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。Redis Cluster采用虚拟槽分区,所有的键根据哈希函数映射到0~16383个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。 优点: 1、无中心架构 2、数据按照slot存储分布在多个节点,节点间数据共享,可动态调整数据分布。 3、可扩展性,可线性扩展到1000多个节点,节点可动态添加或删除。 4、高可用性,部分节点不可用时,集群仍可用。通过增加Slave做standby数据副本,能够实现故障自动failover,节点之间通过gossip协议交换状态信息,用投票机制完成Slave到Master的角色提升。 5、降低运维成本,提高系统的扩展性和可用性。 缺点: 1、Client实现复杂,驱动要求实现Smart Client,缓存slots mapping信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。 2、节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout),被判断下线,这种failover是没有必要的。 3、数据通过异步复制,不保证数据的强一致性。 4、多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。 5、Slave在集群中充当“冷备”,不能缓解读压力,当然可以通过SDK的合理设计来提高Slave资源的利用率。 6、key批量操作限制,如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询,所以执行mset、mget、sunion等操作支持不友好。 7、key事务操作支持有限,只支持多key在同一节点上的事务操作,当多个key分布于不同的节点上时无法使用事务功能。 8、key作为数据分区的最小粒度,因此不能将一个很大的键值对象如hash、list等映射到不同的节点。 9、不支持多数据库空间,单机下的redis可以支持到16个数据库,集群模式下只能使用1个数据库空间,即db 0。 10、复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。 11、避免产生hot-key,导致主库节点成为系统的短板。 12、避免产生big-key,导致网卡撑爆、慢查询等。 13、重试时间应该大于cluster-node-time时间 14、Redis Cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。 使用场景 数据量较大 Redis 集群版可以有效的扩展数据规模,相比标准版支持存储量更大的64、128、256 GB 集群版,可以有效的满足数据扩展需求。 QPS 压力较大 标准版 Redis 无法支撑较大的 QPS,需要采用多节点的部署方式来冲破 Redis 单线程的性能瓶颈。 吞吐密集型应用 相比标准版,Redis 集群版的内网吞吐限制相对较低,针对热点数据读取、大吞吐类型的业务可以友好的支持。 对 Redis 协议不敏感的应用 由于集群版的架构引入了多个组件,在 Redis 协议支持上相比标准版有一定限制。

剑曼红尘 2020-04-27 14:41:57 0 浏览量 回答数 0

问题

HBase最佳实践-读性能优化策略

pandacats 2019-12-20 21:02:08 0 浏览量 回答数 0

问题

全球级的分布式数据库 Google Spanner原理 热:报错

kun坤 2020-06-09 15:26:35 4 浏览量 回答数 1

回答

前言 这期我想写很久了,但是因为时间的原因一直拖到了现在,我以为一两天就写完了,结果从构思到整理资料,再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的,所以我肯定不会一本正经的写,我想了好几个切入点,最后决定用一个完整的电商系统作为切入点,带着大家看看,我们需要学些啥,我甚至还收集配套视频和资料,暖男石锤啊,这期是呕心沥血之作,不要白嫖了。 正文 在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你,傻瓜,肤浅。 我们可不能闭门造车,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet,request、response、cookie、session这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。 Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。 前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始讲后端了。 网关层: 互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。 微服务,分布式,负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢? 负载均衡,LVS 我们机器都是IP访问的,那怎么通过我们申请的域名去请求到服务器呢? DNS 大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验? CDN 我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等? zk 这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。 这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开zk这一层,我们继续往下看。 服务层: 这一层有点东西了,算是整个框架的核心,如果你跟我帅丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。 我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,TCP协议,什么三次握手,四次挥手。 还有进程、线程、协程,什么内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而丙丙还做得不够)。 了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。 JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架,设计模式(包括创建型、结构型、行为型),多线程和并发,I/O流,Stream,网络编程你都需要了解。 代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle,提交代码的时候会去写项目版本管理工具Git。 代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,查看进程,查看文件,各种Vim操作等等。 系统的优化很多地方没优化的空间了,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。 这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud。 了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty。 代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。 他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ,因为他自带了分布式事务的解决方案,大数据的场景你又看到了Kafka。 我上面提到过zk,像Dubbo、Kafka等中间件都是用它做注册中心的,所以很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。 此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化,你可能就会去了解容器化的知识,像**Docker,Kubernetes(K8s)**等。 微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。 好啦我们继续沿着图往下看,那再往下是啥呢? 数据层: 数据库可能是整个系统中最值钱的部分了,在我码文字的前一天,刚好发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,没想到还是照进了现实。 这里也提一点点吧,36小时的故障,其实在互联网公司应该是个笑话了吧,权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的,备份,全量备份,增量备份,延迟备份,异地容灾全部都考虑一下应该也不至于这样,一家上市公司还是有点点不应该。 数据库基本的事务隔离级别,索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全,不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是MongoDB、memcache也有各自的应用场景。 Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制…… 他的大容量存储有问题,你可能需要去了解Pika…. 其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。 你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。 数据接触完了,计算引擎Spark你是不是也不能放过…… 搜索引擎: 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。 那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。 这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现,帅丙只是一直在介绍每个层级的技术栈,并没说到具体的一个路线,那是因为我想让大家先有个认知或者说是扫盲吧,我一样用脑图的方式汇总一下吧,如果图片被平台二压了。 资料/学习网站 Tip:本来这一栏有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。 如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。 总结 我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。 你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。 技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。 但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙,一个在互联网苟且偷生的工具人。 创作不易,本期硬核,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见! 本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。 该回答来自:敖丙

剑曼红尘 2020-03-06 11:35:37 0 浏览量 回答数 0

问题

HBase 高可用原理与实践

pandacats 2019-12-20 21:19:02 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本服务条款是阿里云计算有限公司(以下简称“阿里云”)与您就消息队列服务(Message Queue,简称 MQ)的相关事项所订立的有效合约。您通过盖章、网络页面点击确认或以其他方式选择接受本服务条款,包括但不限于未点击确认本服务条款而事实上使用了阿里云企业级分布式应用服务,即表示您与阿里云已达成协议并同意接受本服务条款的全部约定内容。如若双方盖章文本与网络页面点击确认或以其他方式选择接受之服务条款文本,存有不一致之处,以双方盖章文本为准。 关于本服务条款,提示您特别关注限制、免责条款,阿里云对您违规、违约行为的认定处理条款,以及管辖法院的选择条款等。限制、免责条款可能以加粗或加下划线形式提示您注意。在接受本服务条款之前,请您仔细阅读本服务条款的全部内容。如果您对本服务条款的条款有疑问的,请通过阿里云相关业务部门进行询问,阿里云将向您解释条款内容。如果您不同意本服务条款的任意内容,或者无法准确理解阿里云对条款的解释,请不要进行后续操作。 服务内容 1.1 本条款中“服务”指:阿里云向您提供 www.aliyun.com 网站上所展示的企业级分布式应用服务以及相关的技术及网络支持服务。 1.2 阿里云提供的服务必须符合本服务条款的约定。 服务费用 2.1. 您可以通过支付宝或网上银行等途径向您的阿里云账户充值用以支付您使用消息队列(MQ)的费用,与之有关的具体规则详见 www.aliyun.com 上的页面公告。 2.2. MQ 的价格体系(价格、计费模式等)及扣费规则将在阿里云官网页面(www.aliyun.com) 列明,阿里云将以页面公布的当时有效的价格体系为准自您的阿里云账户中予以扣划服务费用。您未在下单后7天内付费的,本服务条款以及与您就服务所达成的一切行为失效。 2.3.阿里云保留在您未按照约定支付全部费用之前不向您继续提供服务和/或技术支持,或者终止服务和/或技术支持的权利,同时,阿里云有权要求您支付阿终止服务前您尚未支付的服务费用。 2.4. 您完全理解阿里云价格体系中所有的赠送服务项目或活动均为阿里云在正常服务价格之外的一次性特别优惠,优惠内容不包括赠送服务项目的修改、更新及维护费用,并且赠送服务项目不可折价冲抵服务价格。 权利义务 3.1. 您的权利、义务 3.1.1. 您同意遵守本服务条款以及服务展示页面的相关管理规范及流程。您了解上述协议及规范等的内容可能会不时变更,如本服务条款的任何内容发生变动,阿里云应通过提前 30 天在 www.aliyun.com 的适当版面公告向您提示修改内容。如您不同意阿里云对本服务条款相关条款所做的修改,您有权停止使用阿里云的服务,此等情况下,您应将业务数据迁出并与阿里云进行服务费用结算;如您继续使用阿里云服务,则视为您接受阿里云对本服务条款相关条款所做的修改。 3.1.2. 您应按照阿里云的页面提示及本服务条款的约定支付相应服务费用。 3.1.3. 您承诺: 3.1.3.1.如果您利用阿里云提供的服务进行经营或非经营的活动需要获得国家有关部门的许可或批准的,应获得该有关的许可或批准。 3.1.3.2. 除阿里云明示许可外,不得修改、翻译、改编、出租、转许可、在信息网络上传播或转让阿里云提供的服务或软件,也不得逆向工程、反编译或试图以其他方式发现阿里云提供的服务或软件的源代码; 3.1.3.3. 若阿里云的服务涉及第三方软件之许可使用的,您同意遵守相关的许可协议的约束; 3.1.3.4. 不散布电子邮件广告、垃圾邮件(Spam):不利用阿里云提供的服务散发大量不受欢迎的或者未经请求的电子邮件、电子广告或包含反动、色情等有害信息的电子邮件; 3.1.3.5. 不利用阿里云提供的资源和服务上传(Upload)、下载(Download)、储存、发布如下信息或者内容,不为他人发布该等信息提供任何便利(包括但不限于设置 URL、Banner 链接等): 3.1.3.5.1. 违反国家规定的政治宣传和/或新闻信息; 3.1.3.5.2. 涉及国家秘密和/或安全的信息; 3.1.3.5.3. 封建迷信和/或淫秽、色情、下流的信息或教唆犯罪的信息; 3.1.3.5.4. 博彩有奖、赌博游戏、“私服”、“外挂”等非法互联网出版活动; 3.1.3.5.5. 违反国家民族和宗教政策的信息; 3.1.3.5.6. 妨碍互联网运行安全的信息; 3.1.3.5.7. 侵害他人合法权益的信息和/或其他有损于社会秩序、社会治安、公共道德的信息或内容; 3.1.3.5.8. 其他违反法律法规、部门规章或国家政策的内容。 3.1.3.6. 不进行任何破坏或试图破坏网络安全的行为(包括但不限于钓鱼,黑客,网络诈骗,网站或空间中含有或涉嫌散播:病毒、木马、恶意代码,及通过虚拟服务器对其他网站、服务器进行涉嫌攻击行为如扫描、嗅探、ARP 欺骗、DOS 等); 3.1.3.7. 不进行任何改变或试图改变阿里云提供的系统配置或破坏系统安全的行为; 3.1.3.8. 不从事其他违法、违规或违反阿里云服务条款的行为; 3.1.3.9. 如阿里云发现您违反上述条款的约定,有权根据情况采取相应的处理措施,包括但不限于立即终止服务、中止服务或删除相应信息等。如果第三方机构或个人对您提出质疑或投诉,阿里云将通知您,您有责任在规定时间内进行说明并出具证明材料,如您未能提供相反证据或您逾期未能反馈的,阿里云将采取包括但不限于立即终止服务、中止服务或删除相应信息等处理措施。因您未及时更新联系方式或联系方式不正确而致使未能联系到您的,亦视为您逾期未能反馈。 3.1.4. 您不应在阿里云服务或平台之上安装、使用盗版软件;您对自己行为(如自行安装的软件和进行的操作)所引起的结果承担全部责任。 3.1.5. 您对自己存放在阿里云云平台上的数据以及进入和管理阿里云云平台上各类产品与服务的口令、密码的完整性和保密性负责。因您维护不当或保密不当致使上述数据、口令、密码等丢失或泄漏所引起的一切损失和后果均由您自行承担。 3.1.6. 您应向阿里云提交执行本服务条款的联系人和管理用户网络及云平台上各类产品与服务的人员名单和联系方式并提供必要的协助。如以上人员发生变动,您应自行将变动后的信息进行在线更新并及时通知阿里云。因您提供的人员的信息不真实、不准确、不完整,以及因以上人员的行为或不作为而产生的结果,均由您负责。 3.1.7. 您对自己存放在阿里云 MQ 中的数据内容负责,阿里云提示您谨慎判断数据内容的合法性并对此予以监督,如因上传、储存的内容违反法律法规、部门规章或国家政策或危害国家安全,由此造成的全部结果及责任由您自行承担,并且阿里云将保留在未通知您即暂停或终止您的 MQ 服务的权利及删除相应信息的权利,而无须承担任何义务和责任。 3.1.8. 您须依照《互联网信息服务管理办法》等法律法规的规定保留自己网站的访问日志记录,包括发布的信息内容及其发布时间、互联网地址(IP)、域名等,国家有关机关依法查询时应配合提供。您自行承担未按规定保留相关记录而引起的全部法律责任。 3.1.9. 您了解阿里云无法保证其所提供的服务毫无瑕疵(如阿里云安全产品并不能保证您的硬件或软件的绝对安全),但阿里云承诺不断提升服务质量及服务水平。所以您同意:即使阿里云提供的服务存在瑕疵,但上述瑕疵是当时行业技术水平所无法避免的,其将不被视为阿里云违约。您同意和阿里云一同合作解决上述瑕疵问题。 3.1.10.在您使用阿里云 MQ 服务前,您应仔细阅读阿里云就该服务在阿里云网站上的服务说明,依照相关操作指引进行操作,请您自行把握风险谨慎操作。如未按照相关指引操作可能导致包括但不限于数据库被删除、计算结果错误、计算性能低下等后果;您理解并认可,您将对自行操作行为所产生的结果负责。 3.1.11. 您理解并确认,备份您存储于阿里云 MQ 之上的数据,是您的责任。 3.1.12. 您可以通过 MQ 服务中的用户与授权管理功能,将您对 MQ 服务的全部或部分操作权限授权给您指定的一个或多个被授权账户,任一被授权账户下进行的所有操作行为,均将被视为您通过本人账户所进行的行为,您理解并同意,使用用户与授权管理功能是您自行独立审慎判断的结果,该被授权账户下的所有操作行为以及由此产生的结果,都将由您自行承担全部责任,并承担相应服务费用。 3.2. 阿里云的权利、义务 3.2.1. 阿里云应按照服务条款约定提供服务。 3.2.2. 服务期限内,阿里云将为您提供如下客户服务: 3.2.2.1. 阿里云为付费用户提供7×24售后故障服务,并为付费用户提供有效的联系方式并保证付费用户能够联系到故障联系人。故障联系人在明确故障后及时进行反馈; 3.2.2.2. 阿里云提供7×24小时的在线工单服务系统,解答客户在使用中的问题。 3.2.3.阿里云仅负责操作系统以下的底层部分及阿里云提供的软件的运营维护,即企业级分布式应用服务的相关技术架构及操作系统等。操作系统之上部分(如您在系统上安装的应用程序)由您自行负责。此外,您自行升级操作系统可能会造成宕机等不良影响,请自行把握风险并谨慎操作。 3.2.4. 阿里云将消除您非人为操作所出现的故障,但因您原因和/或不可抗力以及非阿里云控制范围之内的事项除外。 3.2.5. 阿里云应严格遵守保密义务。 用户数据的保存、销毁与下载 4.1. 阿里云可能会使用您提交的注册账户的信息,向您发出产品、服务的推广营销信息。 4.2. 您的用户数据将在下述情况下部分或全部被披露: 4.2.1. 经您同意,向第三方披露; 4.2.2. 根据法律的有关规定,或者行政或司法机构的要求,向第三方或者行政、司法机构披露; 4.2.3. 如果您出现违反中国有关法律法规的情况,需要向第三方披露; 4.2.4. 为提供您所要求的软件或服务,而必须和第三方分享您数据; 4.2.5. 其他出于法律法规要求或维护公共利益,而须披露或公开的。 4.3. 除法定及阿里云和您另行约定外,自本服务条款期满或因任何原因导致本服务条款提前终止之日起的 7 个自然日内,阿里云应继续存储您的数据,逾期将不再保留您数据,您需自行承担其数据被销毁后引发的一切后果。 知识产权 5.1. 您应保证提交阿里云的素材、对阿里云服务的使用及使用阿里云服务所产生的成果未侵犯任何第三方的合法权益。如有第三方基于侵犯版权、侵犯第三人之权益或违反中国法律法规或其他适用的法律等原因而向阿里云提起索赔、诉讼或可能向其提起诉讼,则您应赔偿阿里云因此承担的费用或损失,并使阿里云完全免责。 5.2. 如果第三方机构或个人对您使用阿里云服务所涉及的相关素材的知识产权归属提出质疑或投诉,您有责任出具相关知识产权证明材料,并配合阿里云相关投诉处理工作。 5.3. 您承认阿里云向您提供的任何资料、技术或技术支持、软件、服务等的知识产权均属于阿里云或第三方所有。除阿里云或第三方明示同意外,您无权复制、传播、转让、许可或提供他人使用上述资源,否则应承担相应的责任。 保密条款 6.1. 保密资料指由一方向另一方披露的所有技术及非技术信息(包括但不限于产品资料,产品计划,价格,财务及营销规划,业务战略,客户信息,客户数据,研发资料,软件硬件,API 应用数据接口,技术说明,设计,特殊公式,特殊算法等)。 6.2. 本服务条款任何一方同意对获悉的对方之上述保密资料予以保密,并严格限制接触上述保密资料的员工遵守本条之保密义务。除非国家机关依法强制要求或上述保密资料已经进入公有领域外,接受保密资料的一方不得对外披露。 6.3. 本服务条款双方明确认可保密资料是双方的重点保密信息并是各自的重要资产,本服务条款双方同意尽最大的努力保护上述保密资料等不被披露。一旦发现有上述保密资料泄露事件,双方应合作采取一切合理措施避免或者减轻损害后果的产生。 6.4. 本条款不因本服务条款的终止而失效。 服务的期限及终止 7.1. 服务期限自您创建服务之日(支付成功之时)起计算,而非以您获得管理员身份(包括获取了管理员登录号和密码)为依据,服务期限将以您订购的套餐期限为准。 7.2. 发生下列情形,阿里云终止向您提供消息队列服务(MQ): 7.2 1. 双方协商一致终止; 7.2.2. 阿里云由于自身经营政策的变动,提前通过发网站内公告、在网站内合适版面发通知或给您发站内通知、书面通知的方式,终止本服务条款项下的服务; 7.2.3 由于您严重违反本服务条款(包括但不限于 a.您未按照本服务条款的约定履行付款义务,及/或 b.您严重违反本服务条款中所做的承诺,及/或 c.您严重违反法律规定等),阿里云有权按本服务条款的相关约定单方面终止服务。 7.2.4. 您理解并充分认可,虽然阿里云已经建立(并将根据技术的发展不断完善)必要的技术措施来防御包括计算机病毒、网络入侵和攻击破坏(包括但不限于 DDOS)等危害网络安全的事项或行为(以下统称该等行为),但鉴于网络安全技术的局限性、相对性以及该等行为的不可预见性,因此如因您遭遇该等行为而给阿里云或者阿里云的其他的网络或服务器(包括但不限于本地及外地和国际的网络、服务器等)带来危害,或影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,阿里云可决定暂停或终止服务,如果终止服务的,将按照实际提供服务月份计算(不足一个月的按一个月计)服务费用,将剩余款项(如有)返还。 7.2.5. 阿里云可提前30天在 www.aliyun.com 上通告或给您发网站内通知或书面通知的方式终止本服务条款,届时阿里云应将您已支付但未消费的款项退还至您的阿里云账户。 违约责任 8.1. 本服务条款任何一方违约均须依法承担违约责任。 8.2. 您理解,鉴于计算机、互联网的特殊性,下述情况不属于阿里云违约: 8.2.1. 阿里云在进行服务器配置、维护时,需要短时间中断服务; 8.2.2. 由于 Internet 上的通路阻塞造成您网站访问速度下降。 8.3. 如因阿里云原因,造成您连续72小时不能正常使用服务的,您可以终止服务,但非阿里云控制之内的原因引起的除外。 8.4. 在任何情况下,阿里云均不对任何间接性、后果性、惩戒性、偶然性、特殊性的损害,包括您使用阿里云服务而遭受的利润损失承担责任(即使您已被告知该等损失的可能性)。 8.5. 在任何情况下,阿里云对本服务条款所承担的违约赔偿责任总额不超过违约服务对应之服务费总额。 不可抗力 9.1. 因不可抗力或者其他意外事件,使得本服务条款的履行不可能、不必要或者无意义的,遭受不可抗力、意外事件的一方不承担责任。 9.2. 不可抗力、意外事件是指不能预见、不能克服并不能避免且对一方或双方当事人造成重大影响的客观事件,包括但不限于自然灾害如洪水、地震、瘟疫流行等以及社会事件如战争、动乱、政府行为、电信主干线路中断、黑客、网路堵塞、电信部门技术调整和政府管制等。 法律适用及争议解决 10.1. 本服务条款受中华人民共和国法律管辖。 10.2. 在执行本服务条款过程中如发生纠纷,双方应及时协商解决。协商不成时,任何一方可直接向杭州市西湖区人民法院提起诉讼。 附则 11.1. 阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面是本服务条款不可分割的一部分。如果 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面与本服务条款有不一致之处,以本服务条款为准。 11.2. 阿里云有权以提前30天在 www.aliyun.com 上公布、或给您发网站内通知或书面通知的方式将本服务条款的权利义务全部或者部分转移给阿里云的关联公司。 11.3. 如果任何条款在性质上或其他方面理应地在此协议终止时继续存在,那么应视为继续存在的条款,这些条款包括但不局限于保证条款、保密条款、知识产权条款、法律适用及争议解决条款。

2019-12-01 23:31:01 0 浏览量 回答数 0

问题

高效运维最佳实践(03):Redis集群技术及Codis实践

柚子 2019-12-01 21:48:00 29893 浏览量 回答数 1

问题

企业运营对DevOps的「傲慢与偏见」

忆远0711 2019-12-01 21:32:29 9823 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本服务条款是阿里云计算有限公司(以下简称“阿里云”)与您就云盾DDoS防护服务的相关事项所订立的有效合约。您通过盖章、网络页面点击确认或以其他方式选择接受本服务条款,或实际使用阿里云提供的云盾DDoS防护服务,即表示您与阿里云已达成协议并同意接受本服务条款的全部约定内容。如若双方盖章文本与网络页面点击确认或以其他方式选择接受之服务条款文本,存有不一致之处,以双方盖章文本为准。 在接受本服务条款之前,请您仔细阅读本服务条款的全部内容(特别是以粗体及/或下划线标注的内容)。如果您对本服务条款的条款有疑问的,请通过阿里云官网(www.aliyun.com)公布的联系方式,进行询问,阿里云将向您解释条款内容。如果您不同意本服务条款的任意内容,或者无法准确理解阿里云对条款的解释,请不要进行后续操作。 1 定义 1.1 本条款中的“您”是指:所有使用阿里云云盾DDoS防护服务的主体(包括但不限于个人、团队、公司、组织等),或称“用户”。 1.2 本条款中“服务”指:阿里云向您提供 www.aliyun.com 网站上所展示的云盾DDoS防护服务以及相关的技术及网络支持服务。 1.3 DDoS: Distributed Denial of Service,即分布式拒绝服务攻击,在云端该攻击表现为,通过仿冒大量的正常服务请求来阻止用户访问其在云端数据、应用程序或网站。 1.4 清洗:本服务对进入用户的数据流量进行实时监控,及时发现包括DDoS攻击在内的异常流量。在不影响正常业务的前提下,清洗掉异常流量, 即将可疑流量从原始网络路径中重定向到净化产品上进行恶意流量的识别和剥离,还原出的合法流量回注到原网络中转发给目标系统。 1.5 DDoS防护服务:基于流量清洗、黑洞技术等方式为用户提供的DDoS攻击防护服务,用户在购买了对应流量峰值的DDoS防护服务套餐后,在被DDoS攻击时,且未超过流量峰值的情况下,用户的云服务器可正常运行。 1.6 触发清洗阈值:指的是触发流量清洗所需要的最低值,包括每秒流量,每秒报文数量,每秒HTTP请求数三个触发清洗的阈值,用户云服务器的流量超过三个中的任意一个,都会触发清洗。 1.7 流量峰值:指某一段时间内云服务器产生的流量最大值。 2 服务费用 2.1 阿里云将在阿里云官网公布云盾DDoS防护服务的计费模式、价格体系等信息。具体计费规则请您查看 www.aliyun.com 上的页面公告,且按照页面公布的当时有效的计费模式与标准为准。 2.2 在您付费之后,阿里云才开始为您提供服务。您未在下单后7天内付费的,本服务条款以及与您就服务所达成的一切行为失效。 2.3 服务期满双方愿意继续合作的,您至少应在服务期满前7天前支付续费款项,以使服务得以继续进行。如续费时阿里云对产品体系、名称或价格进行调整的,双方同意按照届时有效的新的产品体系、名称或价格履行。 2.4 阿里云保留在您未按照约定支付全部费用之前不向您提供服务和/或技术支持,或者终止服务和/或技术支持的权利,同时,阿里云保留对后付费服务中的欠费行为追究法律责任的权利。 2.5 您理解并同意,阿里云有权根据经营情况,不定期的对云盾DDoS防护服务的产品体系、名称或价格、计费模式等进行调整。阿里云将尽合理范围内的最大努力,将前述调整及变化,通过官网公告、站内通知等方式提前告知您,或提前发送至您预留的联系方式。 2.6 阿里云有权根据其自身业务推广的需要不时推出优惠活动,您完全理解,所有的优惠活动以及业务推广服务都是阿里云提供的一次性特别优惠,优惠内容不包括赠送服务项目的修改、更新及维护费用,并且赠送服务项目不可折价冲抵服务价格。 3 权利义务 3.1 您的权利、义务 3.1.1 您同意遵守本服务条款以及服务展示页面的相关管理规范及流程。您了解上述协议及规范等的内容可能会不时变更。如本服务条款的任何内容发生变动,阿里云应通过提前30天在 www.aliyun.com 的适当版面公告向您提示修改内容。如您不同意阿里云对本服务条款所做的修改,您有权停止使用阿里云的服务,此等情况下,阿里云应与您进行服务费结算(如有),并且您应将业务迁出。如您继续使用阿里云服务,则视为您接受阿里云对本服务条款相关条款所做的修改。 3.1.2 您应按照阿里云的页面提示及本服务条款的约定支付相应服务费用。 3.1.3 您承诺: 3.1.3.1 不利用本服务从事DDoS防护、DNS防护等防护售卖业务; 3.1.3.2 不得将云盾DDoS防护服务各个部分分开用于任何目的; 3.1.3.3 除阿里云明示许可外,不得修改、翻译、改编、出租、转许可、在信息网络上传播或转让阿里云提供的软件,也不得逆向工程、反编译或试图以其他方式发现阿里云提供的软件的源代码; 3.1.3.4 若阿里云的服务涉及第三方软件之许可使用的,您同意遵守相关的许可协议的约束; 3.1.3.5 您利用云盾DDoS防护服务进行防护的业务须为正常的商业、科研等符合国家法律规定的业务,不得用于从事任何非法业务,包括但不限于: 3.1.3.5.1 违反国家规定的政治宣传和/或新闻; 3.1.3.5.2 涉及国家秘密和/或安全; 3.1.3.5.3 封建迷信和/或淫秽、色情和/或教唆犯罪; 3.1.3.5.4 博彩有奖、赌博游戏、“私服”、“外挂”等非法互联网出版活动; 3.1.3.5.5 违反国家民族和宗教政策; 3.1.3.5.6 妨碍互联网运行安全; 3.1.3.5.7 侵害他人合法权益和/或其他有损于社会秩序、社会治安、公共道德的活动; 3.1.3.5.8 其他违反法律法规、部门规章或国家政策的内容。 3.1.3.6 不建立或利用有关设备、配置运行与所购服务无关的程序或进程,或者故意编写恶意代码导致大量占用阿里云云计算资源(如云盾DDoS防护服务、网络带宽、存储空间等)所组成的平台(以下简称“云平台”)中的服务器内存、CPU或者网络带宽资源,给阿里云云平台或者阿里云的其他用户的网络、服务器(包括但不限于本地及外地和国际的网络、服务器等)、产品/应用等带来严重的负荷,影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,或者导致阿里云云平台产品与服务或者阿里云的其他用户网站所在的服务器宕机、死机或者用户基于云平台的产品/应用不可访问等; 3.1.3.7 不进行任何破坏或试图破坏网络安全的行为(包括但不限于钓鱼,黑客,网络诈骗,网站或空间中含有或涉嫌散播:病毒、木马、恶意代码,及通过虚拟服务器对其他网站、服务器进行涉嫌攻击行为如扫描、嗅探、ARP欺骗、DDoS等); 3.1.3.8 不进行任何改变或试图改变阿里云提供的系统配置或破坏系统安全的行为; 3.1.3.9 不利用阿里云提供的服务从事损害阿里云、阿里云的关联公司或阿里巴巴集团内包括但不限于阿里巴巴、淘宝、支付宝、阿里妈妈、阿里金融等(以下统称为阿里巴巴公司)各公司、网站合法权益之行为,前述损害阿里巴巴公司、网站合法权益的行为包括但不限于违反阿里巴巴公司公布的任何服务协议/条款、管理规范、交易规则等规范内容、破坏或试图破坏阿里巴巴公司公平交易环境或正常交易秩序等; 3.1.3.10 不从事其他违法、违规或违反阿里云服务条款的行为; 3.1.3.11 如阿里云发现您违反上述条款的约定,有权根据情况采取相应的处理措施,包括但不限于立即中止服务、终止服务等。如因您违反上述保证而给阿里云(包括阿里云关联公司)或阿里云合作伙伴造成损失的,您还应自行承担一切法律责任并赔偿损失; 3.1.3.12 如果第三方机构或个人对您提出质疑或投诉,阿里云将通知您,您有责任在规定时间内进行说明并出具证明材料,如您未能提供相反证据或您逾期未能反馈的,阿里云将采取包括但不限于立即中止服务或终止服务等处理措施。因您未及时更新联系方式或联系方式不正确而致使未能联系到您的,亦视为您逾期未能反馈; 3.1.3.13 阿里云依据第3.1.3.11条、第3.1.3.12条对您采取了中止服务、终止服务等措施而给您造成任何损失的,阿里云不承担任何责任。 3.1.4 您不应在阿里云服务或平台之上安装、使用盗版软件;您对自己行为(如自行安装的软件和进行的操作)所引起的结果承担全部责任。 3.1.5 您对自己存放在阿里云云平台上的数据以及进入和管理阿里云云平台上各类产品与服务的口令、密码的完整性和保密性负责。因您维护不当或保密不当或操作不当致使上述数据、口令、密码等丢失或泄漏所引起的一切损失和后果均由您自行承担。 3.1.6 您应向阿里云提交执行本服务条款的联系人和管理用户网络及云平台上各类产品与服务的人员名单和联系方式并提供必要的协助。如以上人员发生变动,您应自行将变动后的信息进行在线更新并及时通知阿里云。因您提供的人员的信息不真实、不准确、不完整,以及因以上人员的行为或不作为而产生的结果,均由您负责。 3.1.7 您了解阿里云无法保证其所提供的服务毫无瑕疵(如阿里云安全产品并不能保证您的硬件或软件的绝对安全),但阿里云承诺不断提升服务质量及服务水平。所以您同意:即使阿里云提供的服务存在瑕疵,但上述瑕疵是当时行业技术水平所无法避免的,其将不被视为阿里云违约。您同意和阿里云一同合作解决上述瑕疵问题。 3.1.8 您应仔细阅读阿里云就云盾DDoS防护服务在阿里云网站上的服务说明,自行判断云盾DDoS防护服务与您选择适用的操作系统、云服务器等产品或服务的适配性。 3.1.9 您应依照相关操作指引进行操作。由您手动设置的部分(如您对触发清洗阈值等参数的设置)及其产生的结果由您自行负责,请您自行把握风险并谨慎操作。 3.1.10 您将在所选购套餐的流量峰值范围内享受DDoS防护服务。如攻击流量超过您所购买的流量峰值,您应及时升级至更高流量峰值套餐,否则您的云服务器可能会被攻击导致服务中断。 3.2 阿里云的权利、义务 3.2.1 阿里云应按照本服务条款的约定及产品页面的服务标准,向您提供服务。 3.2.2 服务期限内,阿里云将为您提供如下客户服务: 3.2.2.1 阿里云为付费用户提供7×24售后故障服务,并为付费用户提供有效的联系方式并保证付费用户能够联系到故障联系人。故障联系人在明确故障后及时进行反馈; 3.2.2.2 阿里云提供7*24小时的在线工单服务系统,解答客户在使用中的问题。 3.2.3 阿里云将消除您非人为操作所出现的故障,但因您的原因和/或不可抗力以及非阿里云控制范围之内的事项除外。 3.2.4 阿里云提供本服务条款规定的技术支持,但不承担由于您的原因(包括但不限于代码质量,人为管理疏漏,自身安全管理等)造成的影响和损失。 3.2.5 阿里云应严格遵守保密义务。 4 知识产权 4.1 您承认阿里云向您提供的任何资料、技术或技术支持、软件、服务等的知识产权均属于阿里云或第三方所有。除阿里云或第三方明示同意外,您无权复制、传播、转让、许可或提供他人使用上述资源,否则应承担相应的责任。 5 保密条款 5.1 保密资料指由一方向另一方披露的所有技术及非技术信息(包括但不限于产品资料,产品计划,价格,财务及营销规划,业务战略,客户信息,客户数据,研发,软件硬件,API应用数据接口,技术说明,设计,特殊公式,特殊算法等)。 5.2 本服务条款任何一方同意对获悉的对方之上述保密资料予以保密,并严格限制接触上述保密信息的员工遵守本条之保密义务。除非国家机关依法强制要求或上述保密资料已经进入公有领域外,接受保密资料的一方不得对外披露。 5.3 本服务条款双方明确认可各自用户信息和业务数据等是各自的重要资产及重点保密信息。本服务条款双方同意尽最大的努力保护上述保密信息等不被披露。一旦发现有上述保密信息泄露事件,双方应合作采取一切合理措施避免或者减轻损害后果的产生。 5.4 本条款不因本服务条款的终止而失效。 6 期限与终止 6.1 阿里云云盾DDoS防护服务自您开通服务之日起即可使用,至法律规定或本服务条款约定的终止情形出现之时终止。 6.2 发生下列情形,云盾DDoS防护服务终止: 6.2.1 双方协商一致终止; 6.2.2 由于您严重违反本服务条款(包括但不限于a.您未按照本服务条款的约定履行付款义务,及/或b.您严重违反本服务条款中所做的承诺,及/或c.您严重违反法律规定等),阿里云有权按本服务条款的相关约定单方面终止服务,并不退还您已经支付的费用; 6.2.3 如因用户网站遭遇计算机病毒、网络入侵和攻击破坏(包括但不限于DDoS)等危害网络安全事项或行为(以下统称该等行为),阿里云云盾服务将在用户所选购套餐的流量峰值范围内提供DDoS防护服务,如果超过流量峰值或超过服务说明中防护范围,为使用户免受攻击,将会占用用户的网站或服务之相关资源及可能会造成用户的网站或服务在一定时间内不可被最终用户访问(以下统称“服务不可用”),用户理解并确认,该类服务不可用为阿里云履行云盾DDoS防护服务的正常履行行为,并将不视为阿里云对相关服务的违约;如该等行为给阿里云带来危害,或影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,阿里云将保留在未通知用户即暂停或终止用户在阿里云其他服务的权利,而无须承担任何义务和责任。 6.2.4 阿里云由于自身经营政策的变动,提前通过提前30天发网站内公告、在网站内合适版面发通知或给您发站内通知、书面通知的方式,终止本服务条款项下的服务; 6.2.5 在业务接入高防IP后,系统显示未发生攻击的情况下,支持5天无理由退款(提交工单)。 7 违约责任 7.1 本服务条款任何一方违约均须依法承担违约责任。 7.2 如果因阿里云原因造成您连续72小时不能正常使用服务的,您可终止接受服务,但非阿里云控制之内的原因引起的除外。 7.3 在任何情况下,阿里云均不对任何间接性、后果性、惩戒性、偶然性、特殊性的损害,包括您使用阿里云服务而遭受的利润损失承担责任(即使您已被告知该等损失的可能性)。 7.4 在任何情况下,阿里云对本服务条款所承担的违约赔偿责任总额不超过向您收取的该违约行为所对应的云盾DDoS防护服务之服务费总额。 8 不可抗力 8.1 因不可抗力或者其他意外事件,使得本服务条款的履行不可能、不必要或者无意义的,遭受不可抗力、意外事件的一方不承担责任。 8.2 不可抗力、意外事件是指不能预见、不能克服并不能避免且对一方或双方当事人造成重大影响的客观事件,包括但不限于自然灾害如洪水、地震、瘟疫流行等以及社会事件如战争、动乱、政府行为、电信主干线路中断、黑客、网路堵塞、电信部门技术调整和政府管制等。 9 法律适用及争议解决 9.1 本服务条款受中华人民共和国法律管辖。 9.2 在执行本服务条款过程中如发生纠纷,双方应及时协商解决。协商不成时,任何一方可直接向杭州市西湖区人民法院提起诉讼。 10 附则 10.1.阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面是本服务条款不可分割的一部分,如果阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面与本服务条款有不一致之处,以本服务条款为准。 10.2 阿里云有权以提前30天在 www.aliyun.com 上公布或给您发站内通知或书面通知的方式将本服务条款的权利义务全部或者部分转移给阿里云的关联公司。 10.3 如果任何条款在性质上或其他方面理应地在此协议终止时继续存在,那么应视为继续存在的条款,这些条款包括但不局限于保证条款、保密条款、知识产权条款、法律适用及争议解决条款。 10.4 本服务条款项下,阿里云对您的所有通知均可通过网页公告、网站内通知、电子邮件、手机短信或书面信函等任一方式进行;该等通知于发送之日即视为已送达收件人。

2019-12-01 23:32:33 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本服务条款是阿里云计算有限公司(以下简称“阿里云”)与您就云盾DDoS防护服务的相关事项所订立的有效合约。您通过盖章、网络页面点击确认或以其他方式选择接受本服务条款,或实际使用阿里云提供的云盾DDoS防护服务,即表示您与阿里云已达成协议并同意接受本服务条款的全部约定内容。如若双方盖章文本与网络页面点击确认或以其他方式选择接受之服务条款文本,存有不一致之处,以双方盖章文本为准。 在接受本服务条款之前,请您仔细阅读本服务条款的全部内容(特别是以粗体及/或下划线标注的内容)。如果您对本服务条款的条款有疑问的,请通过阿里云官网(www.aliyun.com)公布的联系方式,进行询问,阿里云将向您解释条款内容。如果您不同意本服务条款的任意内容,或者无法准确理解阿里云对条款的解释,请不要进行后续操作。 1 定义 1.1 本条款中的“您”是指:所有使用阿里云云盾DDoS防护服务的主体(包括但不限于个人、团队、公司、组织等),或称“用户”。 1.2 本条款中“服务”指:阿里云向您提供 www.aliyun.com 网站上所展示的云盾DDoS防护服务以及相关的技术及网络支持服务。 1.3 DDoS: Distributed Denial of Service,即分布式拒绝服务攻击,在云端该攻击表现为,通过仿冒大量的正常服务请求来阻止用户访问其在云端数据、应用程序或网站。 1.4 清洗:本服务对进入用户的数据流量进行实时监控,及时发现包括DDoS攻击在内的异常流量。在不影响正常业务的前提下,清洗掉异常流量, 即将可疑流量从原始网络路径中重定向到净化产品上进行恶意流量的识别和剥离,还原出的合法流量回注到原网络中转发给目标系统。 1.5 DDoS防护服务:基于流量清洗、黑洞技术等方式为用户提供的DDoS攻击防护服务,用户在购买了对应流量峰值的DDoS防护服务套餐后,在被DDoS攻击时,且未超过流量峰值的情况下,用户的云服务器可正常运行。 1.6 触发清洗阈值:指的是触发流量清洗所需要的最低值,包括每秒流量,每秒报文数量,每秒HTTP请求数三个触发清洗的阈值,用户云服务器的流量超过三个中的任意一个,都会触发清洗。 1.7 流量峰值:指某一段时间内云服务器产生的流量最大值。 2 服务费用 2.1 阿里云将在阿里云官网公布云盾DDoS防护服务的计费模式、价格体系等信息。具体计费规则请您查看 www.aliyun.com 上的页面公告,且按照页面公布的当时有效的计费模式与标准为准。 2.2 在您付费之后,阿里云才开始为您提供服务。您未在下单后7天内付费的,本服务条款以及与您就服务所达成的一切行为失效。 2.3 服务期满双方愿意继续合作的,您至少应在服务期满前7天前支付续费款项,以使服务得以继续进行。如续费时阿里云对产品体系、名称或价格进行调整的,双方同意按照届时有效的新的产品体系、名称或价格履行。 2.4 阿里云保留在您未按照约定支付全部费用之前不向您提供服务和/或技术支持,或者终止服务和/或技术支持的权利,同时,阿里云保留对后付费服务中的欠费行为追究法律责任的权利。 2.5 您理解并同意,阿里云有权根据经营情况,不定期的对云盾DDoS防护服务的产品体系、名称或价格、计费模式等进行调整。阿里云将尽合理范围内的最大努力,将前述调整及变化,通过官网公告、站内通知等方式提前告知您,或提前发送至您预留的联系方式。 2.6 阿里云有权根据其自身业务推广的需要不时推出优惠活动,您完全理解,所有的优惠活动以及业务推广服务都是阿里云提供的一次性特别优惠,优惠内容不包括赠送服务项目的修改、更新及维护费用,并且赠送服务项目不可折价冲抵服务价格。 3 权利义务 3.1 您的权利、义务 3.1.1 您同意遵守本服务条款以及服务展示页面的相关管理规范及流程。您了解上述协议及规范等的内容可能会不时变更。如本服务条款的任何内容发生变动,阿里云应通过提前30天在 www.aliyun.com 的适当版面公告向您提示修改内容。如您不同意阿里云对本服务条款所做的修改,您有权停止使用阿里云的服务,此等情况下,阿里云应与您进行服务费结算(如有),并且您应将业务迁出。如您继续使用阿里云服务,则视为您接受阿里云对本服务条款相关条款所做的修改。 3.1.2 您应按照阿里云的页面提示及本服务条款的约定支付相应服务费用。 3.1.3 您承诺: 3.1.3.1 不利用本服务从事DDoS防护、DNS防护等防护售卖业务; 3.1.3.2 不得将云盾DDoS防护服务各个部分分开用于任何目的; 3.1.3.3 除阿里云明示许可外,不得修改、翻译、改编、出租、转许可、在信息网络上传播或转让阿里云提供的软件,也不得逆向工程、反编译或试图以其他方式发现阿里云提供的软件的源代码; 3.1.3.4 若阿里云的服务涉及第三方软件之许可使用的,您同意遵守相关的许可协议的约束; 3.1.3.5 您利用云盾DDoS防护服务进行防护的业务须为正常的商业、科研等符合国家法律规定的业务,不得用于从事任何非法业务,包括但不限于: 3.1.3.5.1 违反国家规定的政治宣传和/或新闻; 3.1.3.5.2 涉及国家秘密和/或安全; 3.1.3.5.3 封建迷信和/或淫秽、色情和/或教唆犯罪; 3.1.3.5.4 博彩有奖、赌博游戏、“私服”、“外挂”等非法互联网出版活动; 3.1.3.5.5 违反国家民族和宗教政策; 3.1.3.5.6 妨碍互联网运行安全; 3.1.3.5.7 侵害他人合法权益和/或其他有损于社会秩序、社会治安、公共道德的活动; 3.1.3.5.8 其他违反法律法规、部门规章或国家政策的内容。 3.1.3.6 不建立或利用有关设备、配置运行与所购服务无关的程序或进程,或者故意编写恶意代码导致大量占用阿里云云计算资源(如云盾DDoS防护服务、网络带宽、存储空间等)所组成的平台(以下简称“云平台”)中的服务器内存、CPU或者网络带宽资源,给阿里云云平台或者阿里云的其他用户的网络、服务器(包括但不限于本地及外地和国际的网络、服务器等)、产品/应用等带来严重的负荷,影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,或者导致阿里云云平台产品与服务或者阿里云的其他用户网站所在的服务器宕机、死机或者用户基于云平台的产品/应用不可访问等; 3.1.3.7 不进行任何破坏或试图破坏网络安全的行为(包括但不限于钓鱼,黑客,网络诈骗,网站或空间中含有或涉嫌散播:病毒、木马、恶意代码,及通过虚拟服务器对其他网站、服务器进行涉嫌攻击行为如扫描、嗅探、ARP欺骗、DDoS等); 3.1.3.8 不进行任何改变或试图改变阿里云提供的系统配置或破坏系统安全的行为; 3.1.3.9 不利用阿里云提供的服务从事损害阿里云、阿里云的关联公司或阿里巴巴集团内包括但不限于阿里巴巴、淘宝、支付宝、阿里妈妈、阿里金融等(以下统称为阿里巴巴公司)各公司、网站合法权益之行为,前述损害阿里巴巴公司、网站合法权益的行为包括但不限于违反阿里巴巴公司公布的任何服务协议/条款、管理规范、交易规则等规范内容、破坏或试图破坏阿里巴巴公司公平交易环境或正常交易秩序等; 3.1.3.10 不从事其他违法、违规或违反阿里云服务条款的行为; 3.1.3.11 如阿里云发现您违反上述条款的约定,有权根据情况采取相应的处理措施,包括但不限于立即中止服务、终止服务等。如因您违反上述保证而给阿里云(包括阿里云关联公司)或阿里云合作伙伴造成损失的,您还应自行承担一切法律责任并赔偿损失; 3.1.3.12 如果第三方机构或个人对您提出质疑或投诉,阿里云将通知您,您有责任在规定时间内进行说明并出具证明材料,如您未能提供相反证据或您逾期未能反馈的,阿里云将采取包括但不限于立即中止服务或终止服务等处理措施。因您未及时更新联系方式或联系方式不正确而致使未能联系到您的,亦视为您逾期未能反馈; 3.1.3.13 阿里云依据第3.1.3.11条、第3.1.3.12条对您采取了中止服务、终止服务等措施而给您造成任何损失的,阿里云不承担任何责任。 3.1.4 您不应在阿里云服务或平台之上安装、使用盗版软件;您对自己行为(如自行安装的软件和进行的操作)所引起的结果承担全部责任。 3.1.5 您对自己存放在阿里云云平台上的数据以及进入和管理阿里云云平台上各类产品与服务的口令、密码的完整性和保密性负责。因您维护不当或保密不当或操作不当致使上述数据、口令、密码等丢失或泄漏所引起的一切损失和后果均由您自行承担。 3.1.6 您应向阿里云提交执行本服务条款的联系人和管理用户网络及云平台上各类产品与服务的人员名单和联系方式并提供必要的协助。如以上人员发生变动,您应自行将变动后的信息进行在线更新并及时通知阿里云。因您提供的人员的信息不真实、不准确、不完整,以及因以上人员的行为或不作为而产生的结果,均由您负责。 3.1.7 您了解阿里云无法保证其所提供的服务毫无瑕疵(如阿里云安全产品并不能保证您的硬件或软件的绝对安全),但阿里云承诺不断提升服务质量及服务水平。所以您同意:即使阿里云提供的服务存在瑕疵,但上述瑕疵是当时行业技术水平所无法避免的,其将不被视为阿里云违约。您同意和阿里云一同合作解决上述瑕疵问题。 3.1.8 您应仔细阅读阿里云就云盾DDoS防护服务在阿里云网站上的服务说明,自行判断云盾DDoS防护服务与您选择适用的操作系统、云服务器等产品或服务的适配性。 3.1.9 您应依照相关操作指引进行操作。由您手动设置的部分(如您对触发清洗阈值等参数的设置)及其产生的结果由您自行负责,请您自行把握风险并谨慎操作。 3.1.10 您将在所选购套餐的流量峰值范围内享受DDoS防护服务。如攻击流量超过您所购买的流量峰值,您应及时升级至更高流量峰值套餐,否则您的云服务器可能会被攻击导致服务中断。 3.2 阿里云的权利、义务 3.2.1 阿里云应按照本服务条款的约定及产品页面的服务标准,向您提供服务。 3.2.2 服务期限内,阿里云将为您提供如下客户服务: 3.2.2.1 阿里云为付费用户提供7×24售后故障服务,并为付费用户提供有效的联系方式并保证付费用户能够联系到故障联系人。故障联系人在明确故障后及时进行反馈; 3.2.2.2 阿里云提供7*24小时的在线工单服务系统,解答客户在使用中的问题。 3.2.3 阿里云将消除您非人为操作所出现的故障,但因您的原因和/或不可抗力以及非阿里云控制范围之内的事项除外。 3.2.4 阿里云提供本服务条款规定的技术支持,但不承担由于您的原因(包括但不限于代码质量,人为管理疏漏,自身安全管理等)造成的影响和损失。 3.2.5 阿里云应严格遵守保密义务。 4 知识产权 4.1 您承认阿里云向您提供的任何资料、技术或技术支持、软件、服务等的知识产权均属于阿里云或第三方所有。除阿里云或第三方明示同意外,您无权复制、传播、转让、许可或提供他人使用上述资源,否则应承担相应的责任。 5 保密条款 5.1 保密资料指由一方向另一方披露的所有技术及非技术信息(包括但不限于产品资料,产品计划,价格,财务及营销规划,业务战略,客户信息,客户数据,研发,软件硬件,API应用数据接口,技术说明,设计,特殊公式,特殊算法等)。 5.2 本服务条款任何一方同意对获悉的对方之上述保密资料予以保密,并严格限制接触上述保密信息的员工遵守本条之保密义务。除非国家机关依法强制要求或上述保密资料已经进入公有领域外,接受保密资料的一方不得对外披露。 5.3 本服务条款双方明确认可各自用户信息和业务数据等是各自的重要资产及重点保密信息。本服务条款双方同意尽最大的努力保护上述保密信息等不被披露。一旦发现有上述保密信息泄露事件,双方应合作采取一切合理措施避免或者减轻损害后果的产生。 5.4 本条款不因本服务条款的终止而失效。 6 期限与终止 6.1 阿里云云盾DDoS防护服务自您开通服务之日起即可使用,至法律规定或本服务条款约定的终止情形出现之时终止。 6.2 发生下列情形,云盾DDoS防护服务终止: 6.2.1 双方协商一致终止; 6.2.2 由于您严重违反本服务条款(包括但不限于a.您未按照本服务条款的约定履行付款义务,及/或b.您严重违反本服务条款中所做的承诺,及/或c.您严重违反法律规定等),阿里云有权按本服务条款的相关约定单方面终止服务,并不退还您已经支付的费用; 6.2.3 如因用户网站遭遇计算机病毒、网络入侵和攻击破坏(包括但不限于DDoS)等危害网络安全事项或行为(以下统称该等行为),阿里云云盾服务将在用户所选购套餐的流量峰值范围内提供DDoS防护服务,如果超过流量峰值或超过服务说明中防护范围,为使用户免受攻击,将会占用用户的网站或服务之相关资源及可能会造成用户的网站或服务在一定时间内不可被最终用户访问(以下统称“服务不可用”),用户理解并确认,该类服务不可用为阿里云履行云盾DDoS防护服务的正常履行行为,并将不视为阿里云对相关服务的违约;如该等行为给阿里云带来危害,或影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,阿里云将保留在未通知用户即暂停或终止用户在阿里云其他服务的权利,而无须承担任何义务和责任。 6.2.4 阿里云由于自身经营政策的变动,提前通过提前30天发网站内公告、在网站内合适版面发通知或给您发站内通知、书面通知的方式,终止本服务条款项下的服务; 6.2.5 在业务接入高防IP后,系统显示未发生攻击的情况下,支持5天无理由退款(提交工单)。 7 违约责任 7.1 本服务条款任何一方违约均须依法承担违约责任。 7.2 如果因阿里云原因造成您连续72小时不能正常使用服务的,您可终止接受服务,但非阿里云控制之内的原因引起的除外。 7.3 在任何情况下,阿里云均不对任何间接性、后果性、惩戒性、偶然性、特殊性的损害,包括您使用阿里云服务而遭受的利润损失承担责任(即使您已被告知该等损失的可能性)。 7.4 在任何情况下,阿里云对本服务条款所承担的违约赔偿责任总额不超过向您收取的该违约行为所对应的云盾DDoS防护服务之服务费总额。 8 不可抗力 8.1 因不可抗力或者其他意外事件,使得本服务条款的履行不可能、不必要或者无意义的,遭受不可抗力、意外事件的一方不承担责任。 8.2 不可抗力、意外事件是指不能预见、不能克服并不能避免且对一方或双方当事人造成重大影响的客观事件,包括但不限于自然灾害如洪水、地震、瘟疫流行等以及社会事件如战争、动乱、政府行为、电信主干线路中断、黑客、网路堵塞、电信部门技术调整和政府管制等。 9 法律适用及争议解决 9.1 本服务条款受中华人民共和国法律管辖。 9.2 在执行本服务条款过程中如发生纠纷,双方应及时协商解决。协商不成时,任何一方可直接向杭州市西湖区人民法院提起诉讼。 10 附则 10.1.阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面是本服务条款不可分割的一部分,如果阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面与本服务条款有不一致之处,以本服务条款为准。 10.2 阿里云有权以提前30天在 www.aliyun.com 上公布或给您发站内通知或书面通知的方式将本服务条款的权利义务全部或者部分转移给阿里云的关联公司。 10.3 如果任何条款在性质上或其他方面理应地在此协议终止时继续存在,那么应视为继续存在的条款,这些条款包括但不局限于保证条款、保密条款、知识产权条款、法律适用及争议解决条款。 10.4 本服务条款项下,阿里云对您的所有通知均可通过网页公告、网站内通知、电子邮件、手机短信或书面信函等任一方式进行;该等通知于发送之日即视为已送达收件人。

2019-12-01 23:32:33 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本服务条款是阿里云计算有限公司(以下简称“阿里云”)与您就云盾DDoS防护服务的相关事项所订立的有效合约。您通过盖章、网络页面点击确认或以其他方式选择接受本服务条款,或实际使用阿里云提供的云盾DDoS防护服务,即表示您与阿里云已达成协议并同意接受本服务条款的全部约定内容。如若双方盖章文本与网络页面点击确认或以其他方式选择接受之服务条款文本,存有不一致之处,以双方盖章文本为准。 在接受本服务条款之前,请您仔细阅读本服务条款的全部内容(特别是以粗体及/或下划线标注的内容)。如果您对本服务条款的条款有疑问的,请通过阿里云官网(www.aliyun.com)公布的联系方式,进行询问,阿里云将向您解释条款内容。如果您不同意本服务条款的任意内容,或者无法准确理解阿里云对条款的解释,请不要进行后续操作。 1 定义 1.1 本条款中的“您”是指:所有使用阿里云云盾DDoS防护服务的主体(包括但不限于个人、团队、公司、组织等),或称“用户”。 1.2 本条款中“服务”指:阿里云向您提供 www.aliyun.com 网站上所展示的云盾DDoS防护服务以及相关的技术及网络支持服务。 1.3 DDoS: Distributed Denial of Service,即分布式拒绝服务攻击,在云端该攻击表现为,通过仿冒大量的正常服务请求来阻止用户访问其在云端数据、应用程序或网站。 1.4 清洗:本服务对进入用户的数据流量进行实时监控,及时发现包括DDoS攻击在内的异常流量。在不影响正常业务的前提下,清洗掉异常流量, 即将可疑流量从原始网络路径中重定向到净化产品上进行恶意流量的识别和剥离,还原出的合法流量回注到原网络中转发给目标系统。 1.5 DDoS防护服务:基于流量清洗、黑洞技术等方式为用户提供的DDoS攻击防护服务,用户在购买了对应流量峰值的DDoS防护服务套餐后,在被DDoS攻击时,且未超过流量峰值的情况下,用户的云服务器可正常运行。 1.6 触发清洗阈值:指的是触发流量清洗所需要的最低值,包括每秒流量,每秒报文数量,每秒HTTP请求数三个触发清洗的阈值,用户云服务器的流量超过三个中的任意一个,都会触发清洗。 1.7 流量峰值:指某一段时间内云服务器产生的流量最大值。 2 服务费用 2.1 阿里云将在阿里云官网公布云盾DDoS防护服务的计费模式、价格体系等信息。具体计费规则请您查看 www.aliyun.com 上的页面公告,且按照页面公布的当时有效的计费模式与标准为准。 2.2 在您付费之后,阿里云才开始为您提供服务。您未在下单后7天内付费的,本服务条款以及与您就服务所达成的一切行为失效。 2.3 服务期满双方愿意继续合作的,您至少应在服务期满前7天前支付续费款项,以使服务得以继续进行。如续费时阿里云对产品体系、名称或价格进行调整的,双方同意按照届时有效的新的产品体系、名称或价格履行。 2.4 阿里云保留在您未按照约定支付全部费用之前不向您提供服务和/或技术支持,或者终止服务和/或技术支持的权利,同时,阿里云保留对后付费服务中的欠费行为追究法律责任的权利。 2.5 您理解并同意,阿里云有权根据经营情况,不定期的对云盾DDoS防护服务的产品体系、名称或价格、计费模式等进行调整。阿里云将尽合理范围内的最大努力,将前述调整及变化,通过官网公告、站内通知等方式提前告知您,或提前发送至您预留的联系方式。 2.6 阿里云有权根据其自身业务推广的需要不时推出优惠活动,您完全理解,所有的优惠活动以及业务推广服务都是阿里云提供的一次性特别优惠,优惠内容不包括赠送服务项目的修改、更新及维护费用,并且赠送服务项目不可折价冲抵服务价格。 3 权利义务 3.1 您的权利、义务 3.1.1 您同意遵守本服务条款以及服务展示页面的相关管理规范及流程。您了解上述协议及规范等的内容可能会不时变更。如本服务条款的任何内容发生变动,阿里云应通过提前30天在 www.aliyun.com 的适当版面公告向您提示修改内容。如您不同意阿里云对本服务条款所做的修改,您有权停止使用阿里云的服务,此等情况下,阿里云应与您进行服务费结算(如有),并且您应将业务迁出。如您继续使用阿里云服务,则视为您接受阿里云对本服务条款相关条款所做的修改。 3.1.2 您应按照阿里云的页面提示及本服务条款的约定支付相应服务费用。 3.1.3 您承诺: 3.1.3.1 不利用本服务从事DDoS防护、DNS防护等防护售卖业务; 3.1.3.2 不得将云盾DDoS防护服务各个部分分开用于任何目的; 3.1.3.3 除阿里云明示许可外,不得修改、翻译、改编、出租、转许可、在信息网络上传播或转让阿里云提供的软件,也不得逆向工程、反编译或试图以其他方式发现阿里云提供的软件的源代码; 3.1.3.4 若阿里云的服务涉及第三方软件之许可使用的,您同意遵守相关的许可协议的约束; 3.1.3.5 您利用云盾DDoS防护服务进行防护的业务须为正常的商业、科研等符合国家法律规定的业务,不得用于从事任何非法业务,包括但不限于: 3.1.3.5.1 违反国家规定的政治宣传和/或新闻; 3.1.3.5.2 涉及国家秘密和/或安全; 3.1.3.5.3 封建迷信和/或淫秽、色情和/或教唆犯罪; 3.1.3.5.4 博彩有奖、赌博游戏、“私服”、“外挂”等非法互联网出版活动; 3.1.3.5.5 违反国家民族和宗教政策; 3.1.3.5.6 妨碍互联网运行安全; 3.1.3.5.7 侵害他人合法权益和/或其他有损于社会秩序、社会治安、公共道德的活动; 3.1.3.5.8 其他违反法律法规、部门规章或国家政策的内容。 3.1.3.6 不建立或利用有关设备、配置运行与所购服务无关的程序或进程,或者故意编写恶意代码导致大量占用阿里云云计算资源(如云盾DDoS防护服务、网络带宽、存储空间等)所组成的平台(以下简称“云平台”)中的服务器内存、CPU或者网络带宽资源,给阿里云云平台或者阿里云的其他用户的网络、服务器(包括但不限于本地及外地和国际的网络、服务器等)、产品/应用等带来严重的负荷,影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,或者导致阿里云云平台产品与服务或者阿里云的其他用户网站所在的服务器宕机、死机或者用户基于云平台的产品/应用不可访问等; 3.1.3.7 不进行任何破坏或试图破坏网络安全的行为(包括但不限于钓鱼,黑客,网络诈骗,网站或空间中含有或涉嫌散播:病毒、木马、恶意代码,及通过虚拟服务器对其他网站、服务器进行涉嫌攻击行为如扫描、嗅探、ARP欺骗、DDoS等); 3.1.3.8 不进行任何改变或试图改变阿里云提供的系统配置或破坏系统安全的行为; 3.1.3.9 不利用阿里云提供的服务从事损害阿里云、阿里云的关联公司或阿里巴巴集团内包括但不限于阿里巴巴、淘宝、支付宝、阿里妈妈、阿里金融等(以下统称为阿里巴巴公司)各公司、网站合法权益之行为,前述损害阿里巴巴公司、网站合法权益的行为包括但不限于违反阿里巴巴公司公布的任何服务协议/条款、管理规范、交易规则等规范内容、破坏或试图破坏阿里巴巴公司公平交易环境或正常交易秩序等; 3.1.3.10 不从事其他违法、违规或违反阿里云服务条款的行为; 3.1.3.11 如阿里云发现您违反上述条款的约定,有权根据情况采取相应的处理措施,包括但不限于立即中止服务、终止服务等。如因您违反上述保证而给阿里云(包括阿里云关联公司)或阿里云合作伙伴造成损失的,您还应自行承担一切法律责任并赔偿损失; 3.1.3.12 如果第三方机构或个人对您提出质疑或投诉,阿里云将通知您,您有责任在规定时间内进行说明并出具证明材料,如您未能提供相反证据或您逾期未能反馈的,阿里云将采取包括但不限于立即中止服务或终止服务等处理措施。因您未及时更新联系方式或联系方式不正确而致使未能联系到您的,亦视为您逾期未能反馈; 3.1.3.13 阿里云依据第3.1.3.11条、第3.1.3.12条对您采取了中止服务、终止服务等措施而给您造成任何损失的,阿里云不承担任何责任。 3.1.4 您不应在阿里云服务或平台之上安装、使用盗版软件;您对自己行为(如自行安装的软件和进行的操作)所引起的结果承担全部责任。 3.1.5 您对自己存放在阿里云云平台上的数据以及进入和管理阿里云云平台上各类产品与服务的口令、密码的完整性和保密性负责。因您维护不当或保密不当或操作不当致使上述数据、口令、密码等丢失或泄漏所引起的一切损失和后果均由您自行承担。 3.1.6 您应向阿里云提交执行本服务条款的联系人和管理用户网络及云平台上各类产品与服务的人员名单和联系方式并提供必要的协助。如以上人员发生变动,您应自行将变动后的信息进行在线更新并及时通知阿里云。因您提供的人员的信息不真实、不准确、不完整,以及因以上人员的行为或不作为而产生的结果,均由您负责。 3.1.7 您了解阿里云无法保证其所提供的服务毫无瑕疵(如阿里云安全产品并不能保证您的硬件或软件的绝对安全),但阿里云承诺不断提升服务质量及服务水平。所以您同意:即使阿里云提供的服务存在瑕疵,但上述瑕疵是当时行业技术水平所无法避免的,其将不被视为阿里云违约。您同意和阿里云一同合作解决上述瑕疵问题。 3.1.8 您应仔细阅读阿里云就云盾DDoS防护服务在阿里云网站上的服务说明,自行判断云盾DDoS防护服务与您选择适用的操作系统、云服务器等产品或服务的适配性。 3.1.9 您应依照相关操作指引进行操作。由您手动设置的部分(如您对触发清洗阈值等参数的设置)及其产生的结果由您自行负责,请您自行把握风险并谨慎操作。 3.1.10 您将在所选购套餐的流量峰值范围内享受DDoS防护服务。如攻击流量超过您所购买的流量峰值,您应及时升级至更高流量峰值套餐,否则您的云服务器可能会被攻击导致服务中断。 3.2 阿里云的权利、义务 3.2.1 阿里云应按照本服务条款的约定及产品页面的服务标准,向您提供服务。 3.2.2 服务期限内,阿里云将为您提供如下客户服务: 3.2.2.1 阿里云为付费用户提供7×24售后故障服务,并为付费用户提供有效的联系方式并保证付费用户能够联系到故障联系人。故障联系人在明确故障后及时进行反馈; 3.2.2.2 阿里云提供7*24小时的在线工单服务系统,解答客户在使用中的问题。 3.2.3 阿里云将消除您非人为操作所出现的故障,但因您的原因和/或不可抗力以及非阿里云控制范围之内的事项除外。 3.2.4 阿里云提供本服务条款规定的技术支持,但不承担由于您的原因(包括但不限于代码质量,人为管理疏漏,自身安全管理等)造成的影响和损失。 3.2.5 阿里云应严格遵守保密义务。 4 知识产权 4.1 您承认阿里云向您提供的任何资料、技术或技术支持、软件、服务等的知识产权均属于阿里云或第三方所有。除阿里云或第三方明示同意外,您无权复制、传播、转让、许可或提供他人使用上述资源,否则应承担相应的责任。 5 保密条款 5.1 保密资料指由一方向另一方披露的所有技术及非技术信息(包括但不限于产品资料,产品计划,价格,财务及营销规划,业务战略,客户信息,客户数据,研发,软件硬件,API应用数据接口,技术说明,设计,特殊公式,特殊算法等)。 5.2 本服务条款任何一方同意对获悉的对方之上述保密资料予以保密,并严格限制接触上述保密信息的员工遵守本条之保密义务。除非国家机关依法强制要求或上述保密资料已经进入公有领域外,接受保密资料的一方不得对外披露。 5.3 本服务条款双方明确认可各自用户信息和业务数据等是各自的重要资产及重点保密信息。本服务条款双方同意尽最大的努力保护上述保密信息等不被披露。一旦发现有上述保密信息泄露事件,双方应合作采取一切合理措施避免或者减轻损害后果的产生。 5.4 本条款不因本服务条款的终止而失效。 6 期限与终止 6.1 阿里云云盾DDoS防护服务自您开通服务之日起即可使用,至法律规定或本服务条款约定的终止情形出现之时终止。 6.2 发生下列情形,云盾DDoS防护服务终止: 6.2.1 双方协商一致终止; 6.2.2 由于您严重违反本服务条款(包括但不限于a.您未按照本服务条款的约定履行付款义务,及/或b.您严重违反本服务条款中所做的承诺,及/或c.您严重违反法律规定等),阿里云有权按本服务条款的相关约定单方面终止服务,并不退还您已经支付的费用; 6.2.3 如因用户网站遭遇计算机病毒、网络入侵和攻击破坏(包括但不限于DDoS)等危害网络安全事项或行为(以下统称该等行为),阿里云云盾服务将在用户所选购套餐的流量峰值范围内提供DDoS防护服务,如果超过流量峰值或超过服务说明中防护范围,为使用户免受攻击,将会占用用户的网站或服务之相关资源及可能会造成用户的网站或服务在一定时间内不可被最终用户访问(以下统称“服务不可用”),用户理解并确认,该类服务不可用为阿里云履行云盾DDoS防护服务的正常履行行为,并将不视为阿里云对相关服务的违约;如该等行为给阿里云带来危害,或影响阿里云与国际互联网或者阿里云与特定网络、服务器及阿里云内部的通畅联系,阿里云将保留在未通知用户即暂停或终止用户在阿里云其他服务的权利,而无须承担任何义务和责任。 6.2.4 阿里云由于自身经营政策的变动,提前通过提前30天发网站内公告、在网站内合适版面发通知或给您发站内通知、书面通知的方式,终止本服务条款项下的服务; 6.2.5 在业务接入高防IP后,系统显示未发生攻击的情况下,支持5天无理由退款(提交工单)。 7 违约责任 7.1 本服务条款任何一方违约均须依法承担违约责任。 7.2 如果因阿里云原因造成您连续72小时不能正常使用服务的,您可终止接受服务,但非阿里云控制之内的原因引起的除外。 7.3 在任何情况下,阿里云均不对任何间接性、后果性、惩戒性、偶然性、特殊性的损害,包括您使用阿里云服务而遭受的利润损失承担责任(即使您已被告知该等损失的可能性)。 7.4 在任何情况下,阿里云对本服务条款所承担的违约赔偿责任总额不超过向您收取的该违约行为所对应的云盾DDoS防护服务之服务费总额。 8 不可抗力 8.1 因不可抗力或者其他意外事件,使得本服务条款的履行不可能、不必要或者无意义的,遭受不可抗力、意外事件的一方不承担责任。 8.2 不可抗力、意外事件是指不能预见、不能克服并不能避免且对一方或双方当事人造成重大影响的客观事件,包括但不限于自然灾害如洪水、地震、瘟疫流行等以及社会事件如战争、动乱、政府行为、电信主干线路中断、黑客、网路堵塞、电信部门技术调整和政府管制等。 9 法律适用及争议解决 9.1 本服务条款受中华人民共和国法律管辖。 9.2 在执行本服务条款过程中如发生纠纷,双方应及时协商解决。协商不成时,任何一方可直接向杭州市西湖区人民法院提起诉讼。 10 附则 10.1.阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面是本服务条款不可分割的一部分,如果阿里云在 www.aliyun.com 相关页面上的服务说明、价格说明和您确认同意的订购页面与本服务条款有不一致之处,以本服务条款为准。 10.2 阿里云有权以提前30天在 www.aliyun.com 上公布或给您发站内通知或书面通知的方式将本服务条款的权利义务全部或者部分转移给阿里云的关联公司。 10.3 如果任何条款在性质上或其他方面理应地在此协议终止时继续存在,那么应视为继续存在的条款,这些条款包括但不局限于保证条款、保密条款、知识产权条款、法律适用及争议解决条款。 10.4 本服务条款项下,阿里云对您的所有通知均可通过网页公告、网站内通知、电子邮件、手机短信或书面信函等任一方式进行;该等通知于发送之日即视为已送达收件人。

2019-12-01 23:32:33 0 浏览量 回答数 0

问题

HBase查询优化

pandacats 2019-12-20 21:09:28 0 浏览量 回答数 0

问题

Apache Flink常见问题汇总【精品问答】

黄一刀 2020-05-19 17:51:47 11230 浏览量 回答数 2

回答

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