精华内容
下载资源
问答
  • 产品可用性分析实例
    2021-03-01 18:10:03

    一、以用户为中心的设计概论

    UX & UCD

    User Experience用户体验是指用户在使用或预计要使用某产品,系统及服务时,产生的主观感受和反应。由 战略层、范围层、结构层、框架层、表现层 这五层组成。

    用户体验与可用性测试

    User Centered Design以用户为中心的设计:是一种能设计出优秀UX的方法,可以避免在考虑问题、设计产品时钻牛角尖,进而能够从用户的角度出发开发产品。主要流程包括调查、分析、设计、评测、改进、反复。

    产品可用性

    可用性定义:特定的用户在特定的使用场景下,为了达到特定的目标而使用某产品时,所感受到的有效性、效率及满意度。

    • 有效性指的是用户能够达成自己的目标。
    • 效率就是用户不必做无用功,就能以最短路径达成目的。
    • 满意度就是即使有效性和效率两方面都没有大问题,也要从更深层面来考虑,即有没有给用户带来不愉快的体验。

    产品失败的原因

    橡胶用户:产品不能用的常见原因之一就是“用户定义失败”,根据设计人员的想象而随心所欲地变化用户群。

    产品使用背景:产品使用背景不同,即使是同一系统或产品,也可能会出现不能用或非常好用这两种截然相反的结果。

    用户体验的点与线:即使整体解决了一些大问题,在重要路线上仍然残留多个问题。

    UCD的最新四原则

    不要盲从用户意见:我们需要关注的并不是用户的意见,而是用户的体验。

    只为一个人设计:大胆设想“不要为所有用户设计,而只为一个人设计产品”。抛弃那些没用的功能,确保产品的简洁性。

    边做边想:一个人绞尽脑汁的想,或者一群人在会议室里无休止的讨论,相比之下,边做边想(绘制一些简单的图,用身边的工具先做起来)反而更能发散思维。

    早期试错:在设计的最初阶段反复进行测试,要“善于”失败。

    二、用户调查法

    老套的访谈方法

    用户意见的局限性:用户并未察觉自己出错的情况并不少见,即使意识到了问题点,用户也无法正确分析原因。所以设计团队应该分析的不是用户意见,而是用户的行为

    焦点小组访谈的局限性:小组访谈以提意见为主,所以参加者会受到他人的影响。

    一对一访谈的局限性:老套的计划好的访谈帮不上忙。

    师徒式访谈

    在之前“访问者和被访问者”关系下的访谈,无论如何深入挖掘,都只能得到已经归纳过的信息和一部分有用的用户体验。于是出现了一种全新的访谈方式——师徒式访谈用户为师,采访人员为徒,采访人员以“拜师”的心情进行访谈。

    它的基本基本步骤是:请教 -> 刨根问底 -> 核实

    请教。访谈暖场后,慢慢将话题移到需要的主题,进而引出深入的交谈。

    刨根问底。跟传统访谈的目的是获取信息不同, 师徒式访谈更重视完全理解用户所讲的内容。

    核实。大致理解后,把理解的内容复述给用户进行核对。

    情景剧本

    情景剧本:就是用户使用产品时的情景剧,以写故事的手法,把用户使用产品时的背景、为了达到何种目的、如何使用、及其结果描绘出来。其最大好处就是不会丢失背景信息。

    情景剧本写法:访谈结束后就要尽快创作,依靠笔记和记忆,先写短小的故事,再反复推敲后完成的情景剧本,并且写完需要访谈的那位用户检查剧本。完成后的情景剧本要向设计团队全体成员公开。

    三、原型

    什么是原型

    在用户为中心的设计里,原型是为了“让用户试着用一下”才被制作出来。原型的本质与使用的工具的优劣没有关系。只要能够做出可以达成设计团队目标的最低限度的界面,随便什么工具都可以拿来制作原型。

    怎么进行用户体验与可用性测试?

    四、产品可用性评价方法

    什么是评价

    在学校里,对学习成果的检测可以分为总结性评价形成性评价两大类。

    总结性评价:是指检测对学习成果的综合掌握程度。比较典型的产品可用性总结性评价方法是性能测试法。(界面性能测试)

    形成性评价:是在某 学习阶段 进行的。是收集学生的理解程度、以及为了让学生理解应如何改进教学等反馈信息的一种方法。比较典型的产品可用性形成性评价法是发声思考法。(安排5-6名用户一边“把正在想的内容说出来”,一边使用用户界面)

    产品可用性评价方法也可以分成分析法实验法。

    分析法:是一种让产品可用性工程师及界面设计专家基于专业知识和经验进行评价的一种方法。

    实验法:收集货真价实的用户使用数据,比较典型的是用户测试、问卷调查

    分析法可以在设计初期就用来评价,并且时间和费用的消耗小,但分析法在意见不一致时,被指出的可用性问题有时并不能够得出最终结论,更无法讨论寻找解决方案,此时就必须引进实验法了。

    产品可用性检验

    可用性检测是指专家根据自身知识见解、参照用户界面设计的指导手册进行界面评价的分析法总称。

    分析法是评价人员基于自身的专业知识及经验进行评价的一种方法,评价标准是一个很模糊的概念。极端的讲,评价人员很可能会给人一种 “我就是标准” 的感觉。为了评价具备客观性,尼尔森博士在分析了很多产品的可用性问题后,提出了隐藏在产品背后的可用性原则,这些原则称为启发式评估十原则(也叫尼尔森十大交互原则),内容如下:

    • 系统状态的可视性:系统必须在一定的时间内做出适当的反馈,必须把现在正在执行的内容通知用户。
    • 系统与现实的协调:必须使用用户很熟悉的词汇、句子来和用户对话、遵循现实中用户的习惯。
    • 用户操控与自由程度:必须提供任何时候都能从当前状态跳出来的出口,保证能够及时取消或再运行执行过的操作。(广告可跳过)
    • 一贯性和标准化:要求保证用户在相同的操作下得到相同结果。
    • 防止错误:一开始就防止错误、防患于未然的设计要比适当的错误消息更重要。(表单 必填项 加标记)
    • 识别好过回忆:尽量不要让用户从当前对话切换到别的会话时还必须要记住某些信息。(购物车显示完整的商品名、数量、金额)
    • 灵活性和效率:提供定制化服务,通过其他途径向高级用户提供其他服务,这样就可以满足更多的用户需求。
    • 简洁美观的设计:尽量不要包含不相关及几乎用不到的信息,弱化和剔除无关信息。
    • 帮助用户认知、判断及修复错误:通俗的语句表示错误信息,明确指出问题,并提出建设性的解决方案。(不要404代码)
    • 帮助文档及用户手册:在设计无需查看用户手册也能使用的基础上,还应该提供帮助文档和用户手册。

    启发式评估局限性:查处的问题过多,实施成本大。

    用户测试的基础理论

    用户测试是以反证为目的的测试。

    反证法:首先假设该用户界面具备可用性,那么在理论上,用户应该可以使用该界面有效、高效、心情愉悦的完成任务,但如果发现违反了这些可用性问题,那么就是该假设的“反证”,说明该用户界面具备可用性的假设不成立。

    测试的五个步骤:测试准备->招募->测试执行->分析报告->再设计。

    后记

    UCD和质量管理一样,属于系统性工作,会存在层次差异。机构想新开展UCD相关的工作,需要根据自己情况从初级到高级循序渐进开展。

    用户可用性成熟度模型:
    1、原始期(用户界面的设计完全依赖于界面设计师和软件工程师的个人能力);
    2、黎明期(将用户测试作为产品公开前的最终检测加以实施);
    3、摇篮期-前期/后期(用户测试作为一种有效的设计手段固定存在项目中);
    4、活跃期(通过开发剧本和虚拟角色来探索用户需求);
    5、扩充期(会跟踪调查产品发布后的使用情况);
    6、成熟期(建立产品可用性知识数据库)。

    更多相关内容
  • 数据库系统可用性是考察数据库系统性能的基本指标之一,对其分析通常着眼于系统的总体性能。说明了这种分析的不足,提出了数据资源可用性考察方法并应用于分布式并行数据库系统DPDBS。在对DPDBS中服务器群进行逻辑...
  • 本文分析了目前采用较多的保障MySQL可用性方案。MySQLReplication是MySQL官方提供的主从同步方案,用于将一个MySQL实例的数据,同步到另一个实例中。Replication为保证数据安全做了重要的保证,也是现在运用最广的...
  • 通过面向心力衰竭疗效分析的需求实例,获得了与数据的完整性和一致性相关的10个度量指标,并对某省级区域平台的数据进行了可用性评估。结果发现,与临床科研相关的数据的完整性和一致性都仍有待提高。
  • 数据库系统可用性是考察数据库系统性能的基本指标之一,对其分析通常着眼于系统的总体性能。说明了这种分析的不足,提出了数据资源可用性考察方法并应用于分布式并行数据库系统DPDBS。在对DPDBS中服务器群进行逻辑...
  • 通过层次化模块化分解技术,将复杂系统动态故障树分解为相互独立的模块,对独立模块分别进行可用度求解,再利用自下而上递归的方法实现复杂系统可用性分析 。提出和推导出等效时变的可用度参数模型,分析了层次化模块化...
  • 可用性测试是用户调研中一种定性研究的方法,让产品更好的服务用户,可以说是一种低成本高回报的一种研究方法。今天我主要通过以下几个层面来讲解可用性测试的亲身操刀经验:1.什么是可用性测试?2.可用性测试的好处...
  • 依据层次分析法、模糊数学原理,结合问题的背景知识建立了设备模糊综合可用性层次分析模型。并利用该模型研究了发动机缸体生产线设备可用性的评价问题。以设备的平均无故障时间(MTBF)、平均维修周期(MTTR)、年均...
  • 以Web上的产品评论为数据,利用观点挖掘的方法从非结构化评论中抽取结构化数据,选取与可用性相关的产品特征,使用因子分析法提取影响产品可用性的公共因子,建立产品可用性模型。对产品可用性进行评价,结果表明,...
  • 本文主要探讨那些容易被忽略的用户体验基本原则,并提供实例可用性分析,关于视觉设计、信息构建及可用性分析等方面提供实用的建议。打造非凡的交互体验,设计一个可用性强的网站,对任何一个设计者来说都不失为一...
  • 可用性99.9

    千次阅读 2021-08-10 01:40:10
    可用性99.9 内容精选换一换云数据库 RDS服务支持切换主备实例可用性策略,以满足不同业务需求。可选择 “可靠性优先”或者“可用性优先”两种策略。调用接口前,您需要了解API 认证鉴权。该接口仅支持MySQL引擎。...

    可用性99.9 内容精选

    换一换

    c8a5a5028d2cabfeeee0907ef5119e7e.png

    云数据库 RDS服务支持切换主备实例的可用性策略,以满足不同业务需求。可选择 “可靠性优先”或者“可用性优先”两种策略。调用接口前,您需要了解API 认证鉴权。该接口仅支持MySQL引擎。仅支持主备实例,即:HA实例。实例在创建、数据库升级、创建用户、删除用户状态下不能进行此操作。URI格式PUT /v3/{project_id}/ins

    指标项名称:KerberosAdmin服务可用性指标项含义:系统对KerberosAdmin服务状态进行检查,如果检查结果不正常,则KerberosAdmin服务不可用。恢复指导:如果该指标项检查结果不正常,原因可能是KerberosAdmin服务所在节点故障,或者SlapdServer服务不可用。操作人员进行KerberosAdmin服

    可用性99.9 相关内容

    分析云上业务的资源分布情况,识别云服务高可用、云服务部署实践、云服务使用限制3个方面的风险,提供针对性的优化建议。云服务高可用:聚焦云服务可用区(AZ)内高可用设计,业务设计为主备、集群等方式。云服务部署实践:侧重云服务部署,包括云服务资源规格选型、云服务使用方式等。云服务使用限制:列举云服务使用限制,包括云服务资源配额、带宽限速等。包年

    虚拟IP(Virtual IP Address,简称VIP)是一个未分配给真实弹性云服务器网卡的IP地址。弹性云服务器除了拥有私有IP地址外,还可以拥有虚拟IP地址,用户可以通过其中任意一个IP(私有IP/虚拟IP)访问此弹性云服务器。同时,虚拟IP地址拥有私有IP地址同样的网络接入能力,包括VPC内二三层通信、VPC之间对等连接访问,以

    可用性99.9 更多内容

    f3b8b8d84706868f201fb0c4780edbab.png

    NAT网关后台已通过双机热备实现自动容灾,同时为用户提供云监控和告警服务,降低风险提高可用性。

    6fc16b91fddf423fbce11d0989b79e5d.png

    指标项名称:KerberosAdmin服务可用性指标项含义:系统对KerberosAdmin服务状态进行检查,如果检查结果不正常,则KerberosAdmin服务不可用。恢复指导:如果该指标项检查结果不正常,原因可能是KerberosAdmin服务所在节点故障,或者SlapdServer服务不可用。操作人员进行KerberosAdmin服

    628a76026f26a9b0192a8fa75416b71f.png

    本章节指导用户如何查看站点的监控数据,从可用性、响应时间、可用探测点等趋势来展示当前站点的访问情况。登录管理控制台。单击“服务列表 > 云监控服务”。单击左侧导航栏的“站点监控”。进入“站点监控”界面。系统展示用户当前所有站点概况。包括站点名称、站点地址、探测类型、监控频率、可用探测点百分比、平均响应时间等。进入“站点监控”界面。系统展示

    e08a3c1d383ce0289aa478984d9adca2.png

    许多企业已经在公有云上部署了SAP HANA系统来运行它们的业务,为了保障SAP业务的连续性,SAP解决方案所提供的高可用(HA)和容灾(DR)方案是这些企业选择云上部署的重要因素。除了SAP软件本身提供的高可用机制外,公有云自身的高可用与容灾方案进一步加强了包括SAP在内的许多应用程序的高可用性,云端高可用跟传统高可用相比,有如下的优点

    b80c406dd1bff1336ad2b20072f4b1ca.png

    许多企业已经在公有云上部署了SAP HANA系统来运行它们的业务,为了保障SAP业务的连续性,SAP解决方案所提供的高可用(HA)和容灾(DR)方案是这些企业选择云上部署的重要因素。除了SAP软件本身提供的高可用机制外,公有云自身的高可用与容灾方案进一步加强了包括SAP在内的许多应用程序的高可用性,云端高可用跟传统高可用相比,有如下的优点

    9bf196c9a2e0b7b0bc69748c838418a5.png

    虚拟IP(Virtual IP Address,简称VIP)是一个未分配给真实弹性云服务器网卡的IP地址。弹性云服务器除了拥有私有IP地址外,还可以拥有虚拟IP地址,用户可以通过其中任意一个IP(私有IP/虚拟IP)访问此弹性云服务器。同时,虚拟IP地址拥有私有IP地址同样的网络接入能力,包括VPC内二三层通信、VPC之间对等连接访问,以

    be6c0fefabcd88eafba576089843e93b.png

    CSE采用的是ETCD和golang自研的API-Server层服务管理中心。与仅仅管理路由动态数据的Eureka不同,CSE的服务管理中心提供了对静态元数据丰富的管理能力,例如提供了“应用-服务-实例”的整体元数据管理,基于服务的不同版本管理和Tag管理以支持灰度发布功能,根据服务发现的动作记录服务依赖关系等等。在Eureka仅仅管理动

    784b2dc537fb8677eac9c3453eafe288.png

    应用原理:在一个高并发的复杂事务型系统中,当写事务占的比例相对读事务较小时,DM提供的独具创新的方案读写分离集群方案(DMRWC),可通过客户端驱动程序来实现读、写事务的自动分离,读事务在备机执行,写事务在主机执行,减轻主机的负载。可配置多台备机,通过增加备机节点资源,提高系统的并发能力,增强系统性能。场景典型参考架构:场景特点:具有复杂

    55a2638139d68369d49b3058cd5d88e8.png

    通过该功能查看网点报告,包括总览、网点统计、告警统计信息。

    91fba63c5e17e5f0e99d0f8174c4b31b.png

    Kudu是专为Apache Hadoop平台开发的列式存储管理器,具有Hadoop生态系统应用程序的共同技术特性:在通用的商用硬件上运行,可水平扩展,提供高可用性。Kudu的设计具有以下优点:能够快速处理OLAP工作负载支持与MapReduce,Spark和其他Hadoop生态系统组件集成与Apache Impala的紧密集成,使其成为将

    784dc64e49dbbf1bc7916486d97eab2c.png

    YARN中的ResourceManager负责整个集群的资源管理和任务调度,在Hadoop2.4版本之前,ResourceManager在YARN集群中存在单点故障的问题。YARN高可用性方案通过引入冗余的ResourceManager节点的方式,解决了这个基础服务的可靠性和容错性问题。ResourceManager的高可用性方案是通过设

    展开全文
  • 可在MATLAB中进行判断矩阵的权重计算,包括算术平均值,特征值,并进行一致检验,亲测可用
  • RabbitMQ高可用性分析

    千次阅读 2018-11-20 16:28:24
    rabbitmq有三种模式:单机模式,普通集群模式,镜像集群模式 1)单机模式 就是demo级别的,一般就是你本地启动了玩玩儿的,没人生产用单机模式。...你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从...

    rabbitmq有三种模式:单机模式,普通集群模式,镜像集群模式
    1)单机模式
    就是demo级别的,一般就是你本地启动了玩玩儿的,没人生产用单机模式。
    2)普通集群模式
    在这里插入图片描述
    意思就是在多台机器上启动多个rabbitmq实例,每个机器启动一个。但是你创建的queue,只会放在一个rabbtimq实例上,但是每个实例都同步queue的元数据。你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从queue所在实例上拉取数据过来。

    这种方式确实很麻烦,也不怎么好,没做到所谓的分布式,就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据,要么固定连接那个queue所在实例消费数据,前者有数据拉取的开销,后者导致单实例性能瓶颈。而且如果那个放queue的实例宕机了,会导致接下来其他实例就无法从那个实例拉取,如果你开启了消息持久化,让rabbitmq落地存储消息的话,消息不一定会丢,得等这个实例恢复了,然后才可以继续从这个queue拉取数据。

    所以这就没有什么所谓的高可用性可言了,这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个queue的读写操作。

    3)镜像集群模式
    在这里插入图片描述
    这种模式,才是所谓的rabbitmq的高可用模式,跟普通集群模式不一样的是,你创建的queue,无论元数据还是queue里的消息都会存在于多个实例上,然后每次你写消息到queue的时候,都会自动把消息到多个实例的queue里进行消息同步。
    这样的话,好处在于,你任何一个机器宕机了,别的机器都可以用。坏处在于,第一,这个性能开销也太大了吧,消息同步所有机器,导致网络带宽压力和消耗很重!第二,这么玩儿就没有扩展性可言了,如果某个queue负载很重,你加机器,新增的机器也包含了这个queue的所有数据,并没有办法线性扩展你的queue
    那么怎么开启这个镜像集群模式呢?其实很简单rabbitmq有很好的管理控制台,就是在后台新增一个策略,这个策略是镜像集群模式的策略,指定的时候可以要求数据同步到所有节点的,也可以要求就同步到指定数量的节点,然后你再次创建queue的时候,应用这个策略,就会自动将数据同步到其他的节点上去了。

    (2)kafka的高可用性
    在这里插入图片描述
    kafka一个最基本的架构认识:多个broker组成,每个broker是一个节点;你创建一个topic,这个topic可以划分为多个partition,每个partition可以存在于不同的broker上,每个partition就放一部分数据。
    这就是天然的分布式消息队列,就是说一个topic的数据,是分散放在多个机器上的,每个机器就放一部分数据。
    实际上rabbitmq之类的,并不是分布式消息队列,他就是传统的消息队列,只不过提供了一些集群、HA的机制而已,因为无论怎么玩儿,rabbitmq一个queue的数据都是放在一个节点里的,镜像集群下,也是每个节点都放这个queue的完整数据。

    kafka 0.8以前,是没有HA机制的,就是任何一个broker宕机了,那个broker上的partition就废了,没法写也没法读,没有什么高可用性可言。

    kafka 0.8以后,提供了HA机制,就是replica副本机制。每个partition的数据都会同步到吉他机器上,形成自己的多个replica副本。然后所有replica会选举一个leader出来,那么生产和消费都跟这个leader打交道,然后其他replica就是follower。写的时候,leader会负责把数据同步到所有follower上去,读的时候就直接读leader上数据即可。只能读写leader?很简单,要是你可以随意读写每个follower,那么就要care数据一致性的问题,系统复杂度太高,很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上,这样才可以提高容错性。

    这么搞,就有所谓的高可用性了,因为如果某个broker宕机了,没事儿,那个broker上面的partition在其他机器上都有副本的,如果这上面有某个partition的leader,那么此时会重新选举一个新的leader出来,大家继续读写那个新的leader即可。这就有所谓的高可用性了。

    写数据的时候,生产者就写leader,然后leader将数据落地写本地磁盘,接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了,就会发送ack给leader,leader收到所有follower的ack之后,就会返回写成功的消息给生产者。(当然,这只是其中一种模式,还可以适当调整这个行为)

    消费的时候,只会从leader去读,但是只有一个消息已经被所有follower都同步成功返回ack的时候,这个消息才会被消费者读到。

    展开全文
  • 本文通过介绍GaussDB(for MySQL)读写路径,分析可用性

    简介

    数据持久性服务可用性是数据库服务的关键特征。

    在实践中,通常认为拥有 3 份数据副本,就足以保证持久性。

    但是 3 份副本,对于可用性的要求是不够的。维护 3 份一致的副本意味着,这些副本必须同时在线,系统才能保证可用。当数据库跨多个节点分片时,某些节点不可用的概率会随着节点数量的增加而呈指数增长。

    在 GaussDB(for MySQL) 中,我们针对日志和数据采用不同副本策略,并采用一种新颖的恢复算法,来解决可用性的问题。

    下面首先介绍写路径,然后介绍读路径,最后分析理论上的可用性估计,并与其它副本策略进行比较。

    写路径

     

    写路径如上图所示,下面对每一个步骤进行说明。

    1)用户事务导致对数据库页面的更改,从而生成描述更改的日志记录(redo log,下面简称 redo)。

    2)将 redo 写入到 Log Stores。写入 3 份副本,并且采用强一致性,即 3 份均写入成功才算成功。

    3)将事务标记为已提交(committed)。

    只要集群中有三个或以上的 Log Stores 可用,该数据库就可以进行写操作(因为写入只需要选择可用的节点即可,并不规定一定要写入某个节点)。对于成千上万个节点的群集,这实际上意味着 100% 的写入可用性

    4)redo 写入 Log Stores 之后,会将此 redo 放入到 SAL 的 write buffer 中,之后将此 buffer 写入到管理对应 slice 的 Page Store 上。

    5)当任何一个 Page Store 副本返回成功,此写入成功,SAL 的 write buffer 被释放。

    6)不同的 Page Store 副本之间使用 gossip 协议检测和修复缺失的日志。

    空间回收

    数据库运行过程中,会源源不断地产生 redo 日志。如果不将不需要的 redo 删除,可以预见,最终肯定会耗尽磁盘空间。在成功将 redo 写入所有 Slice 副本,并且所有数据库的读副本(read replica)都可以看到该记录之后,就可以将该日志从 Log Store 中删除。独立地跟踪每条 redo 的持久性很费资源,因此我们选择基于 LSN 来跟踪持久性。

    对于 Page Store 的每个 slice,都有一个 persistent LSN,它的含义是 slice 接收到的所有日志记录中,保证连续(没有空洞)的最大 LSN。(譬如某个 slice 接收到 LSN 为 1 的 redo log 后,persistent LSN 变为 1,此时如果接收到 LSN 为 3 的 redo log,persistent LSN 依然为 1。之后如果接收到 LSN 为 2 的 redo log,即补齐了空洞之后, persistent LSN 变为 3)。

    7)SAL 可以通过定期调用 api 或者在读写接口中获取每个 slice 的 persistent LSN(在恢复中也会使用)。

    8)SAL 也会跟踪每个 PLog 的 LSN 范围。如果 PLog 中的所有 redo 的 LSN 都小于数据库 persistent LSN(3 副本中最小 persistent LSN),该 PLog 可被删除。

    通过上面的机制,我们能够保证每条 redo 都至少会有三个节点上存在副本(一开始在 Plog Store 节点上有 3 副本,保证在 Page Store 节点上有 3 副本之后,将 Plog Store 节点上的副本删除,以回收磁盘资源)。

    读路径

    数据库前端以 page 粒度读取数据。

    读取或者修改数据时,相应的 page 必须在 buffer pool 中。当 buffer pool 已满,我们又需要引入一个 page 时,必须将某些页面从 buffer pool 中淘汰。

    我们对淘汰算法进行了修改,保证只有当所有相关 redo 日志都写入至少 1 个 Page Store 副本后,脏页才能被淘汰。因此,在最新的 redo 记录到达 Page Store 之前,保证相应的页面可从 buffer pool 中获得。 之后,可以从 Page Store 中读取页面。

    对于每一个 slice,SAL 保存最新 redo log 的 LSN。主节点读取 page 时,读请求首先到达 SAL,SAL 会使用上述 LSN 下发读请求。读请求会被路由到时延最低的 Page Store。如果被选择的 Page Store 不可用或者还没有收到提供 LSN 之前的所有 redo,会返回错误。之后 SAL 会尝试下一个 Page Store,遍历所有副本,直到读请求可以被正确响应。

    可用性分析

    quorum replication

    目前业界最广泛使用的强一致性复制技术基于 quorum replication。如果每份数据在 N 个节点上存在副本,每个读取操作必须从NR个节点接收响应,并写入NW个节点。

    为了保证强一致性,必须满足 NR + NW > N 。业界许多系统使用 quorum replication 的不同组合方式。 例如,

    1)RAID1 磁盘阵列中通常使用 N = 3,NR = 1,NW = 3;

    2)PolarDB 中,N = 3,NR = 2,NW = 2;

    3)Aurora 中,N = 6,NR = 3,NW = 4。

    下面的分析中,仅考虑节点单独出现不可用的场景(不考虑譬如因为断点导致所有节点不可用的场景)。

    假设 1 个节点不可用的概率为 x,则当 N - NW + 1  N 个节点同时不可用时,写请求会失败。 即一个写请求失败的概率可用如下公式计算:

     

    同理,一个读请求失败的概率计算公式如下:

     

    GaussDB(for MySQL)

    在前面的写路径一节中已经提到,GaussDB(for MySQL) 的写 redo,不需要写到特定的 Log Store 上,所以公式 (1) 并不适用。对于写请求,只有当所有 PLog Store 都不可用时,才会失败。如果集群中 Log Store 足够多,这个概率几乎接近于 0。

    对于读,每个 Page Store 节点都可以基于其 persistent LSN 决定是否可以为读提供服务。如果不能,它将返回错误,告诉 SAL 尝试另一个节点。在极少数情况下,由于级联故障,没有节点可以提供读服务(并非节点不可用),SAL 会识别这种情况并使用 Log Store 来修复数据。在这种情况下,性能可能下降,但是存储层仍然可用。

    SAL 无法恢复的唯一情况是,包含 Slice 副本的所有 Page Store 都不可用,这样的概率是 x^3。

    下表对比了 GaussDB(for MySQL) 和几种典型 quorum replication 场景的可用性:

     

    结论

    1)对于写,GaussDB(for MySQL) 总是可用的,优于 quorum replication 方案;

    2)对于读,除了 x = 0.01 且 quorum 的节点个数为 6 的情况,GaussDB(for MySQL) 总是能提供比 quorum replication 相同或更好的的可用性。并且在上面的场景下,提供的可用性已经足够高,与 quorum replication  相差并不远。


    点击这里→了解更多精彩内容

     

    展开全文
  • 第九章 可用性分析和评估 1.可用性和可用性工程(第二版 P225) 可用性定义:  可用性是指特定的用户在特定的环境下使用产品并达到特定目标的效力、效率和满意的程度。 可用性五个方面:  有效性(effective)...
  • (行为塑造)幼儿攻击行为的个案分析(1)可用.pdf
  • 两位作者通过丰富的实例,明确阐述了如何从表单的关系、对话和外观三层模型出发,设计出具有高可用性的优质网页表单,并通过可用性测试及早发现表单的潜在问题。通过阅读本书,读者能够了解到如何定义需求,如何提出...
  • AHP层次分析法计算小程序,界面友好,亲测可用,适用于windows10
  • 本文分析了目前采用较多的保障MySQL可用性方案。 MySQL Replication MySQL Replication是MySQL官方提供的主从同步方案,用于将一个MySQL实例的数据,同步到另一个实例中。Replication为保证数据安全
  • 产品可用性测试在产品投入开发前期的设计产出与产品迭代规划投产前都有显著的指导意义,它不仅可以很大程度上避免/纠正产品设计过程中团队或者PM对于产品的理解偏差,精简产品架构,优化产品设计,并为产品带来良好...
  • MySQL高可用性分析

    千次阅读 2016-11-11 14:02:17
    版权声明:本文由易固武原创文章,转载请注明出处:  ... ...   MySQL数据库是目前开源应用最大的关系型数据库,有海量的应用将数据存储在MySQL数据库中。存储数据的安全和可靠是生产数据库的关注重点
  • 微服务可用性设计(一):隔离,超时

    千次阅读 2022-01-18 12:38:52
    微服务最关键的问题一个是数据一致化,另一个就是可用性可用性的核心就是围绕出了事故如何处理,一般事故可分为责任事故和非责任事故。所谓责任事故就是不按照标准作业流程(SOP)操作最终造成的事故。本片讲的...
  • 提高系统可用性的那些架构策略

    千次阅读 2021-12-08 13:26:57
    在实际业务中,出现资源不可用的原因种类可能很多,有的概率很低,比如网线被挖断了,机房失火,地震等等导致网络不可用,有的概率相对来说很高比如服务器硬件资源不足,服务器故障等等。这些问题都可能会导致对应的资源不...
  • 谈一谈软件系统的可用性

    千次阅读 2021-06-17 18:58:32
    什么是可用性 系统的可用性用如下公式表示: 其中: MTBF:即平均无故障工作时间,英文全称是“Mean Time Between Failure”。是衡量一个产品(尤其是电器产品)的可靠性指标。单位为毫秒、秒钟、分钟、小时等 ...
  • 云计算的高可用性

    千次阅读 2021-07-17 16:40:39
    云计算的高可用性... 1 一、可用性相关概念... 2 1.1 可用性定义... 2 1.2 高可用性定义... 2 1.3 高可用性度量标准... 2 二、云计算相关概念... 3 2.1 云计算定义... 3 2.2 云计算的服务模式分类... 3 2.3 ...
  • 通过求解降维微分方程获得故障子树的时变可用度参数,采用由下至上的递归处理算法快速实现复杂系统的可用性定量分析,既解决了复杂系统可用度计算的“组合爆炸”问题,又通过考虑时变参数保证了可用度解算的精度 。实例...
  • 阿里云服务器云引擎ACE可用性分析与案例 ACE(Aliyun Cloud Engine)是一款弹性、分布式的应用托管环境,支持Java、php多种语言环境。帮助开发者快速开发和部署服务端应用程序,并且简化了系统维护工作。搭载了丰富...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 287,089
精华内容 114,835
热门标签
关键字:

产品可用性分析实例