我要提问
- 关于
数据可用性常见故障
的搜索结果
回答
关于云服务器稳定性：
云服务器是很稳定的，您也可以通过配置负载均衡来消除单点故障提升应用系统的可用性。
关于云服务器地域选择：
根据目标用户所在地理位置选择：地域是指云服务器的物理数据中心所在位置，所以目标用户距离云服务器地域越近网络延迟越小，速度越快。
根据云产品选择：您不仅需要ECS云服务器，还需要搭配云数据库，这就需要确保同地域下都有您需要选择的规格，这样ECS实例和云数据库实例可以通过内网互通。 关于地域和可用区选择可以参考：地域和可用区常见问题及解答
关于云服务器规格选择：
建议先确定云服务器配置，CPU和内存多少合适，然后再根据配置选择ECS实例规格。阿里云根据系统架构以及使用场景将ECS云服务器分为多种规格，关于规格的详细介绍可以参考：实例规格族详解 - 阿里云
回答
关于云服务器稳定性：
云服务器是很稳定的，您也可以通过配置负载均衡来消除单点故障提升应用系统的可用性。
关于云服务器地域选择：
根据目标用户所在地理位置选择：地域是指云服务器的物理数据中心所在位置，所以目标用户距离云服务器地域越近网络延迟越小，速度越快。 根据云产品选择：您不仅需要ECS云服务器，还需要搭配云数据库，这就需要确保同地域下都有您需要选择的规格，这样ECS实例和云数据库实例可以通过内网互通。 关于地域和可用区选择可以参考：地域和可用区常见问题及解答
关于云服务器规格选择：
建议先确定云服务器配置，CPU和内存多少合适，然后再根据配置选择ECS实例规格。阿里云根据系统架构以及使用场景将ECS云服务器分为多种规格，关于规格的详细介绍可以参考：实例规格族详解 - 阿里云
回答
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 协议支持上相比标准版有一定限制。
回答
可以使用阿里云ACM。应用配置管理（Application Configuration Manangement，简称 ACM），是一款在分布式架构环境中对应用配置进行集中管理和推送的工具类产品。基于该产品，您可以在微服务、DevOps、大数据等场景下极大地减轻配置管理的工作量，增强配置管理的服务能力。在应用生命周期管理中，开发人员通常会将应用中需要变更的一些配置项或者元数据从代码中分离出来，放在单独的配置文件中管理，称为应用配置。应用配置是管理应用变更的常见手段之一。发布应用后，运维人员或最终用户可以通过调整配置来适配环境，调整应用程序的运行行为。ACM 是分布式系统的配置中心。通过提供配置变更、配置推送、历史版本管理、灰度发布、配置变更审计等配置管理工具，ACM 帮助您集中管理所有应用环境中的配置，降低分布式系统中管理配置的成本，并降低因错误的配置变更带来可用性下降甚至发生故障的风险。
回答
在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，分成以下 6 种解决方案。（一）规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。优点：解决（规避）了分布式事务。缺点：显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。由于这个方法存在明显缺点，通常不建议使用。（二）经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。eBay 方式的主要思路如下。Base：一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。（三）去哪儿网分布式事务方案随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢？最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过，使用异步消息 Consumer 端需要实现幂等。幂等有两种方式，一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：重试 B，直到 B 成功，事务记录表里记录了各项调用参数等信息；执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。总结起来，其实两种方式的根本原理是类似的，也就是将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性。（四）蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？方案选型服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性，所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦，通过订阅方消费 MQ 消息时的 ACK 机制，保证消息一定消费成功，达到最终一致性。由于消息可能会被重发，消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。我们在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。（五）支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。主要思路如下，大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说，DTS 框架有如下特性：最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。协议简单：DTS 定义了类似 2PC 的标准两阶段接口，业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上，与底层协议无关。与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的 confirm 操作，在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较，没有单独的 Prepare 阶段，降低协议成本。系统故障容忍度高，恢复简单（六）农信网数据一致性方案电商业务公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说，电商部门的订单支付，需要调用支付平台的支付接口来处理订单；同时需要调用积分中心的接口，按照业务规则，给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。用户信息变更公司的用户信息，统一由用户中心维护，而用户信息的变更需要同步给各业务子系统，业务子系统再根据变更内容，处理各自业务。用户中心作为 MQ 的 producer，添加通知给 MQ。APP Server 订阅该消息，同步本地数据信息，再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制，目前主要使用 ActiveMQ，基于 Virtual Topic 的订阅方式，保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。
回答
服务网格 ASM 主要适用于需要对应用服务进行流量管理、安全管理、故障恢复、观测监控以及微服务架构迁移的应用场景。本文介绍 ASM 的常见应用场景。
流量管理 通过 ASM，可以轻松实现基于配置的流量管理：
将流量管理与基础设施管理分隔开来，并提供了许多立于应用代码之外的流量管理功能，在部署规模逐步扩大的过程中帮助简化流量管理。 管理服务网格的服务发现、流量路由和负载均衡，简化服务级属性的配置，例如超时和重试等。 服务安全 通过 ASM，可以轻松实现服务之间的双向 TLS 认证：
支持以渐进方式实现 mTLS 双向认证，可以确保服务间通信以及最终用户与服务之间通信的安全。 双向 TLS 认证在实现过程中不需要更改服务代码，可以为每个服务提供基于角色的强大身份认证机制，以实现跨集群、跨云端的交互操作。 通过 ASM，可以轻松实现服务之间的授权：
借助 Istio 授权机制，ASM 确保只能从经过严格身份认证和授权的客户端访问包含敏感数据的服务。 支持对网格中的服务进行基于命名空间级别、服务级别和方法级别的访问权限控制，包括使用基于角色的语义、服务到服务和最终用户到服务的授权，并在角色和角色绑定方面提供灵活的自定义属性支持。 通过 ASM，可以轻松实现密钥管理：
基于 Istio 的密钥管理系统，支持自动生成、分发、轮换与撤消密钥和证书。 故障恢复 通过 ASM，可以轻松实现开箱即用的故障恢复功能：
分布式系统存在高度复杂性，在基础设施、应用逻辑、运维流程等环节都可能存在稳定性风险导致业务系统的失效。 提供了基于 Istio 的混沌工程能力，包括如何使用连接池配置和异常检测实现熔断能力，支持针对服务的重试和故障注入等能力。 服务可观测性 通过 ASM，可以轻松实现服务之间的可观测性，借助强大可靠且易于使用的监控功能，快速有效地检测和修复问题。
通过集成的阿里云链路追踪服务，为分布式应用的开发者提供完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高开发诊断效率。
微服务架构 通过 ASM，可以实现敏捷开发和部署落地，加速企业业务迭代。企业生产环境中，通过合理微服务拆分，将每个微服务应用存储在阿里云镜像仓库帮您管理。您只需迭代每个微服务应用，由阿里云提供调度、编排、部署和灰度发布能力。
负载均衡和服务发现支持 4 层和 7 层的请求转发和后端绑定。 丰富的调度和异常恢复策略支持服务级别的亲和性调度，支持跨可用区的高可用和灾难恢复。 微服务监控和弹性伸缩支持微服务和容器级别的监控，支持微服务的自动伸缩。
回答
本文档介绍如何快速创建文件系统，并将其挂载至云服务器ECS（Linux系统）上。
前提条件 已注册阿里云账号，并完成实名认证，详情请参见阿里云账号注册流程。 说明 如果您要使用RAM账户实现细粒度的权限管理，详情请参见创建自定义权限策略。 已开通NAS服务。 首次登录NAS控制台时，根据页面提示开通NAS服务。
已完成云资源访问授权。 首次使用极速型NAS时，在概览页面的常见入口区域，单击授权管理。 单击极速型和CPFS默认服务授权右侧的前往授权。 单击同意授权，完成AliyunNASMangeENIRole授权。云资源访问授权 在需要创建文件系统的地域，已有可用的专有网络VPC，详情请参见创建专有网络和交换机。 在需要创建文件系统的地域，已有可用的云服务器ECS，并将此云服务器ECS归属到已创建的专有网络VPC下，详情请参见创建ECS实例。 步骤一：创建文件系统 登录NAS控制台。 选择文件系统 > 文件系统列表，单击创建文件系统。 在极速型区域，单击按量付费。 此处以按量付费类型为例进行说明。如果您要包年包月，请单击包年包月。包年包月是在按量付费的基础上推出的更加优惠的计费方式。 在购买页面，配置相关参数。 参数 说明 地域 选择要创建文件系统的地域。 说明 不同地域的文件系统与云服务器ECS不互通。 可用区 可用区是指在同一地域内，电力和网络互相独立的物理区域。 同一地域不同可用区之间的文件系统与云服务器ECS互通。 单击下拉框选择可用区，建议和云服务器ECS在同一可用区，避免跨可用区产生的时延。
协议 选择NFS。 说明 极速型NAS只支持NFS v3。 类型 包括标准型和高级型。 容量 选择合适的容量。 吞吐 选择合适的吞吐。 数据加密 使用KMS服务托管密钥，对文件系统落盘数据进行加密存储。在读写加密数据时，无需解密，详情请参见数据加密。 如果启用了数据加密功能，则在创建快照时，也会自动加密数据。
单击立即购买，根据页面提示，完成购买。 说明 创建文件系统成功后会绑定默认的权限组。如果您要修改权限组，请参见修改挂载点的权限组。 步骤二：添加挂载点 在文件存储NAS中，需要通过挂载点将文件系统挂载至云服务器ECS。极速型NAS只支持专有网络类型的挂载点，具体操作如下所示。 说明 每个文件系统最多可添加1个挂载点。 登录NAS控制台。 选择文件系统 > 文件系统列表。 找到目标文件系统，单击更多 > 添加挂载点。 在添加挂载点页面，配置相关参数。 参数 说明 VPC网络 选择已创建的VPC网络。如果还未创建 ，请前往VPC控制台创建。 说明 必须与云服务器ECS选择一样的VPC网络和交换机。如果是不同的VPC，则需要先通过云企业网打通网络，才能挂载文件系统，详情请参见跨VPC挂载文件系统。 交换机 选择VPC网络下创建的交换机。 权限组 根据需求选择权限组。 初始情况下，每个账号都会自动生成一个VPC默认权限组，允许同一VPC环境下的任何IP地址通过该挂载点访问文件系统。如果您要创建权限组，请参见管理权限组。
单击确定，创建挂载点。 步骤二：安装NFS客户端 在Linux系统中将NFS文件系统挂载至云服务器ECS，您需要先安装NFS客户端。
登录云服务器ECS。 运行以下命令，安装NFS客户端。 如果您使用CentOS、Redhat、Aliyun Linux操作系统，运行以下命令。 sudo yum install nfs-utils 如果您使用Ubuntu或Debian操作系统，运行以下命令。 sudo apt-get update sudo apt-get install nfs-common 将同时发起的NFS请求数量修改为128， 详情请参见如何修改同时发起的NFS请求数量。 步骤四：挂载文件系统 登录云服务器ECS。 挂载NFS文件系统。 sudo mount -t nfs -o vers=3,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport file-system-id.region.extreme.nas.aliyuncs.com:/share /mnt 挂载命令中的参数说明如下表所示：
参数 描述 file-system-id.region.extreme.nas.aliyuncs.com:/share /mnt 表示<挂载点地址>：<NAS文件系统目录> <当前服务器上待挂载的本地路径>，请根据实际情况替换。 挂载点地址：file-system-id.region.extreme.nas.aliyuncs.com，您可以在文件存储NAS控制台上，找到目标文件系统，单击管理，进入详情页面获取挂载点地址。 NAS文件系统目录：极速型NAS的共享目录必须以/share开头，例如：/share、/share/subdir。 当前服务器上待挂载的本地路径：服务器（如ECS linux）的根目录（/）或任意子目录（如/mnt），如果是子目录，请确保子目录已存在。 vers 文件系统版本，目前只支持nfs v3。 挂载选项 挂载文件系统时，可选择多种挂载选项，详情情参见下表。 注意 配置参数时，应注意以下内容： 如果您必须更改IO大小参数 （rsize和wsize），建议您尽可能使用最大值 （1048576），以避免性能下降。 如果您必须更改超时参数 （timeo），建议您使用150或更大的值。该timeo参数的单位为0.1 秒，因此150表示的时间为15秒。 不建议使用soft选项，有数据一致性风险。如果您要使用soft选项，相关风险需由您自行承担。 避免设置不同于默认值的任何其他挂载选项。如果更改读或写缓冲区大小或禁用属性缓存，会导致性能下降。 挂载选项使用逗号分隔列表的形式，具体选项与说明如下表所示。 选项 说明 rsize 定义数据块的大小，用于在您的客户端与云中的文件系统之间读取数据。建议值：1048576。 wsize 定义数据块的大小，用于在您的客户端与云中的文件系统之间写入数据。建议值：1048576。 hard 指定在NAS暂时不可用的情况下，使用文件系统上某个文件的本地应用程序时应停止并等待该文件系统恢复在线状态。建议启用该参数。 timeo 指定时长（单位为 0.1 秒），即NFS客户端在重试向云中的文件系统发送请求之前等待响应的时间。建议值：600（60秒）。 retrans 指定NFS客户端应重试请求的次数。建议值：2。 noresvport 指定在网络重连时使用新的TCP端口，保障在网络发生故障恢复的时候不会中断连接。建议启用该参数。 执行mount -l命令，查看挂载结果。 如果回显包含如下类似信息，说明挂载成功。
查看挂载结果 挂载成功后，您可以在ECS上访问NAS文件系统，执行读取或写入操作。 您可以把NAS文件系统当作一个普通的目录来访问和使用，例子如下所示。
读写操作 常见错误排查 如果挂载失败，请参见挂载失败的排查与处理方法进行排查。
回答
本文档介绍如何快速创建文件系统，并将其挂载至云服务器ECS（Linux系统）上。
前提条件 已注册阿里云账号，并完成实名认证，详情请参见阿里云账号注册流程。 说明 如果您要使用RAM账户实现细粒度的权限管理，详情请参见创建自定义权限策略。 已开通NAS服务。 首次登录NAS控制台时，根据页面提示开通NAS服务。
已完成云资源访问授权。 首次使用极速型NAS时，在概览页面的常见入口区域，单击授权管理。 单击极速型和CPFS默认服务授权右侧的前往授权。 单击同意授权，完成AliyunNASMangeENIRole授权。云资源访问授权 在需要创建文件系统的地域，已有可用的专有网络VPC，详情请参见创建专有网络和交换机。 在需要创建文件系统的地域，已有可用的云服务器ECS，并将此云服务器ECS归属到已创建的专有网络VPC下，详情请参见创建ECS实例。 步骤一：创建文件系统 登录NAS控制台。 选择文件系统 > 文件系统列表，单击创建文件系统。 在极速型区域，单击按量付费。 此处以按量付费类型为例进行说明。如果您要包年包月，请单击包年包月。包年包月是在按量付费的基础上推出的更加优惠的计费方式。 在购买页面，配置相关参数。 参数 说明 地域 选择要创建文件系统的地域。 说明 不同地域的文件系统与云服务器ECS不互通。 可用区 可用区是指在同一地域内，电力和网络互相独立的物理区域。 同一地域不同可用区之间的文件系统与云服务器ECS互通。 单击下拉框选择可用区，建议和云服务器ECS在同一可用区，避免跨可用区产生的时延。
协议 选择NFS。 说明 极速型NAS只支持NFS v3。 类型 包括标准型和高级型。 容量 选择合适的容量。 吞吐 选择合适的吞吐。 数据加密 使用KMS服务托管密钥，对文件系统落盘数据进行加密存储。在读写加密数据时，无需解密，详情请参见数据加密。 如果启用了数据加密功能，则在创建快照时，也会自动加密数据。
单击立即购买，根据页面提示，完成购买。 说明 创建文件系统成功后会绑定默认的权限组。如果您要修改权限组，请参见修改挂载点的权限组。 步骤二：添加挂载点 在文件存储NAS中，需要通过挂载点将文件系统挂载至云服务器ECS。极速型NAS只支持专有网络类型的挂载点，具体操作如下所示。 说明 每个文件系统最多可添加1个挂载点。 登录NAS控制台。 选择文件系统 > 文件系统列表。 找到目标文件系统，单击更多 > 添加挂载点。 在添加挂载点页面，配置相关参数。 参数 说明 VPC网络 选择已创建的VPC网络。如果还未创建 ，请前往VPC控制台创建。 说明 必须与云服务器ECS选择一样的VPC网络和交换机。如果是不同的VPC，则需要先通过云企业网打通网络，才能挂载文件系统，详情请参见跨VPC挂载文件系统。 交换机 选择VPC网络下创建的交换机。 权限组 根据需求选择权限组。 初始情况下，每个账号都会自动生成一个VPC默认权限组，允许同一VPC环境下的任何IP地址通过该挂载点访问文件系统。如果您要创建权限组，请参见管理权限组。
单击确定，创建挂载点。 步骤二：安装NFS客户端 在Linux系统中将NFS文件系统挂载至云服务器ECS，您需要先安装NFS客户端。
登录云服务器ECS。 运行以下命令，安装NFS客户端。 如果您使用CentOS、Redhat、Aliyun Linux操作系统，运行以下命令。 sudo yum install nfs-utils 如果您使用Ubuntu或Debian操作系统，运行以下命令。 sudo apt-get update sudo apt-get install nfs-common 将同时发起的NFS请求数量修改为128， 详情请参见如何修改同时发起的NFS请求数量。 步骤四：挂载文件系统 登录云服务器ECS。 挂载NFS文件系统。 sudo mount -t nfs -o vers=3,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport file-system-id.region.extreme.nas.aliyuncs.com:/share /mnt 挂载命令中的参数说明如下表所示：
参数 描述 file-system-id.region.extreme.nas.aliyuncs.com:/share /mnt 表示<挂载点地址>：<NAS文件系统目录> <当前服务器上待挂载的本地路径>，请根据实际情况替换。 挂载点地址：file-system-id.region.extreme.nas.aliyuncs.com，您可以在文件存储NAS控制台上，找到目标文件系统，单击管理，进入详情页面获取挂载点地址。 NAS文件系统目录：极速型NAS的共享目录必须以/share开头，例如：/share、/share/subdir。 当前服务器上待挂载的本地路径：服务器（如ECS linux）的根目录（/）或任意子目录（如/mnt），如果是子目录，请确保子目录已存在。 vers 文件系统版本，目前只支持nfs v3。 挂载选项 挂载文件系统时，可选择多种挂载选项，详情情参见下表。 注意 配置参数时，应注意以下内容： 如果您必须更改IO大小参数 （rsize和wsize），建议您尽可能使用最大值 （1048576），以避免性能下降。 如果您必须更改超时参数 （timeo），建议您使用150或更大的值。该timeo参数的单位为0.1 秒，因此150表示的时间为15秒。 不建议使用soft选项，有数据一致性风险。如果您要使用soft选项，相关风险需由您自行承担。 避免设置不同于默认值的任何其他挂载选项。如果更改读或写缓冲区大小或禁用属性缓存，会导致性能下降。 挂载选项使用逗号分隔列表的形式，具体选项与说明如下表所示。 选项 说明 rsize 定义数据块的大小，用于在您的客户端与云中的文件系统之间读取数据。建议值：1048576。 wsize 定义数据块的大小，用于在您的客户端与云中的文件系统之间写入数据。建议值：1048576。 hard 指定在NAS暂时不可用的情况下，使用文件系统上某个文件的本地应用程序时应停止并等待该文件系统恢复在线状态。建议启用该参数。 timeo 指定时长（单位为 0.1 秒），即NFS客户端在重试向云中的文件系统发送请求之前等待响应的时间。建议值：600（60秒）。 retrans 指定NFS客户端应重试请求的次数。建议值：2。 noresvport 指定在网络重连时使用新的TCP端口，保障在网络发生故障恢复的时候不会中断连接。建议启用该参数。 执行mount -l命令，查看挂载结果。 如果回显包含如下类似信息，说明挂载成功。
查看挂载结果 挂载成功后，您可以在ECS上访问NAS文件系统，执行读取或写入操作。 您可以把NAS文件系统当作一个普通的目录来访问和使用，例子如下所示。
读写操作 常见错误排查 如果挂载失败，请参见挂载失败的排查与处理方法进行排查。
回答
网络性能主要有主动测试，被动式测试以及主动被动相结合测试三种方法 1.主动测量是在选定的测量点上利用测量工具有目的地主动产生测量流量注入网络，并根据测量数据流的传送情况来分析网络的性能。 主动测量在性能参数的测量中应用十分广泛，因为它可以以任何希望的数据类型在所选定的网络端点间进行端到端性能参数的测量。最为常见的主动测量工具就是“Ping”，它可以测量双向时延，IP 包丢失率以及提供其它一些信息，如主机的可达性等。主动测量可以测量端到端的IP 网络可用性、延迟和吞吐量等。因为一次主动测量只是查验了瞬时的网络质量，因此有必要重复多次，用统计的方法获得更准确的数据。 要对一个网络进行主动测量，则需要一个面向网络的测量系统，这种主动测量系统应包括以下几个部分： - 测量节点：它们分布在网络的不同端点上，进行测量数据包的发送和接收，若要进行单向性能的测量，则它们之间应进行严格的时钟同步； - 中心服务器：它与各个测量节点通信，进行整个测量的控制以及测量节点的配置工作； - 中心数据库：存储各个节点所收集的测量数据； - 分析服务器：对中心数据库中的数据进行分析，得到网络整体的或具体节点间的性能状况 在实际中，中心服务器，中心数据库和分析服务器可能位于同一台主机中。 主动测量法依赖于向网络注入测量包，利用这些包测量网络的性能，因此这种方法肯定会产生额外的流量。另一方面，测量中所使用的流量大小以及其他参数都是可调的。主动测量法能够明确地控制测量中所产生的流量的特征，如流量的大小、抽样方法、发包频率、测量包大小和类型(以仿真各种应用)等，并且实际上利用很小的流量就可以获得很有意义的测量结果。主动测量意味着测量可以按测量者的意图进行，容易进行场景的仿真，检验网络是否满足QoS 或SLA 非常简单明了。 总之，主动测量的优点在于可以主动发送测量数据，对测量过程的可控制性比较高，比较灵活机动，并易于对端到端的性能进行直观的统计；其缺点是注入测量流量本身就改变了网络的运行情况，即改变了被测对象本身，使得测量的结果与实际情况存在一定的偏差，而且注入网络的测量流量还可能会增加网络的负担。 2.被动测量是指在链路或设备（如路由器，交换机等）上对网络进行监测，而不需要产生流量的测量方法。 被动测量利用测量设备监视经过它的流量。这些设备可以是专用的，如Sniffer，也可以是嵌入在其它设备(如路由器、防火墙、交换机和主机)之中的，如RMON, SNMP 和netflow 使能设备等。控制者周期性地轮询被动监测设备并采集信息(在SNMP 方式时，从MIB 中采集)，以判断网络性能和状态。被动测量主要有三种方式： - 通过SNMP 协议采集网络上的数据信息，并提交至服务器进行处理。 - 在一条指定的链路上进行数据监测，此时数据的采集和分析是两个独立的处理过程。这种方法的问题是OC48（2.5Gbit/s）以上的链路速度超过了 PCI 总线（64bit，33MHz）的能力，因此对这些高速链路的数据采集只能采用数据压缩，聚合等方式，这样会损失一定的准确性。 - 在一台主机上有选择性的进行数据的采集和分析。这种工具只是用来采集分析网络上数据包的内容特性，并不能进行性能参数的测量，如Ethereal 等工具。 被动测量非常适合用来测量和统计链路或设备上的流量，但它并不是一个真正的 QoS 参数，因为流量只是当前网络（设备）上负载情况的一个反映，通过它并不能得到网络实际的性能情况，如果要通过被动测量的方法得到终端用户所关心的时延，丢包，时延抖动等性能参数，只能采用在被测路径的两个端点上同时进行被动测量，并进行数据分析，但这种分析将是十分复杂的，并且由于网络上数据流量特征的不确定性，这种分析在一定程度上也是不够准确的。只有链路带宽这个流量参数可以通过被动测量估算出来。 被动测量法在测量时并不增加网络上的流量，测量的是网络上的实际业务流量，理论上说不会增加网络的负担。但是被动测量设备需要用轮询的方法采集数据、陷阱(trap)和告警（利用SNMP 时），所有这些都会产生网络流量，因此实际测量中产生的流量开销可能并不小。 另外，在做流分析或试图对所有包捕捉信息时，所采集的数据可能会非常大。被动测量的方法在网络排错时特别有价值，但在仿真网络故障或隔离确切的故障位置时其作用会受到限制。 总之，被动测量的优点在于理论上它不产生流量，不会增加网络的负担；其缺点在于被动测量基本上是基于对单个设备的监测，很难对网络端到端的性能进行分析，并且可能实时采集的数据量过大，且存在用户数据泄漏等安全性问题。 3.主动、被动相结合测试 主动测量与被动测量各有其有缺点，而且对于不同的参数来说，主动测量和被动测量也都有其各自的用途。对端到端的时延，丢包，时延变化等参数比较适于进行主动测量；而对于路径吞吐量等流量参数来说，被动测量则更适用。因此，对网络性能进行全面的测量需要主动测量与被动测量相结合，并对两种测量结果进行对比和分析，以获得更为全面科学的结论。
来自百度知道初夏0535