高可用

典型回答 全链路压测诞生于阿里巴巴双11备战过程，如果说双11大促是阿里业务的“期末考试”，全链路压测就是大考前的“模拟考试”。全链路压测通过在生产环境对业务大流量场景进行高仿真模拟，获取最真实的线上实际承载能力、执行精准的容量规划，确保系统可用性。 因为对于像阿里这种大型互联网公司来说，尤其是电商业务，一个业务流程涉及到的上下游实在是太多了。任何一个节点都可能成为整个系统的瓶颈。 而在单链路压测时，往往只关注自己的系统，就会不可避免忽略掉一些资源竞争及外部干扰，最终得到一个过于乐观的结果。 并且在分布式场景中，我们和上下游之间的依赖关系错综复杂，只有在全链路压测中才能真正的暴露出真实环境中的各种问题。 全链路压测可以从网络到Nginx反向代理、到应用服务器、系统间依赖、数据库、缓存、磁盘等全方位的找出系统瓶颈。 但是全链路压测和单链路压测有个比较大的不同，那就是对于很多下游系统来说，他需要能识别出压测流量，一方面可以对这些流量做一些特殊处理，比如某个系统大促当天会被降级，那么他就可以直接把压测流量过滤掉，不参加压测。 还有就是，很多时候压测都不仅仅是读操作，还有很多写操作，那就会在很多系统中产生数据，那么就需要把这部分流量识别出来，把这部分数据做好隔离。 所以，全链路压测中比较重要的就是流量识别及数据隔离。 流量识别 在流量识别方面，一般都是通过流量染色实现的，其实就是对各种服务框架进行改造，比如DUBBO、REDIS、TDDL、MQ等所有的系统间交互以及存储等需要用到的组件中做改造。 比如定义一个特殊的字段，如full_chain_stress_tag，把他在整个链路中都传递下去，然后这样各个系统就可以有效的识别出压测流量了。 这个也可以和分布式链路追踪结合着来做，理论上大家要该干的事儿是一样的。 数据隔离 数据隔离一般都是用影子表。比如我们有一张order表，那么在压测前就需要创建一张order__shadow表，作为他的影子表。 这样在数据库持久层，就需要识别出压测流量，然后把压测数据写入到影子表中。这样就可以避免对真实数据产生影响。 除了数据库，还有缓存，也一样，也需要识别压测流量，然后写入到对应的影子缓存中。还有日志，如果有需要，也可以做隔离。 工具 目前市面上可以用的全链路压测工具有Takin、Quake（美团）、Rhino（字节）、ForceBot 以下是一些行业内大厂的一些压测的分享（外链）： 史上最复杂业务场景，逼出阿里高可用三大法宝 阿里双十一大促，技术准备只做了这两件事情？ 独家揭秘 | 阿里怎么做双11全链路压测？ 10年5次进化，双11容量规划如何实现成本与稳定的最佳平衡？ 阿里巴巴高可用技术专家襄玲：压测环境的设计和搭建 字节跳动全链路压测(Rhino)的实践 全链路压测平台（Quake）在美团中的实践 京东全链路压测军演系统(ForceBot) 饿了么全链路压测的探索与实践 携程全链路测试实践 有赞全链路压测实战

典型回答 SLA是Service Level Agreement的缩写，意为服务等级协议。它是指供应商和客户之间达成的一份正式协议，规定了供应商应该向客户提供的服务水平、质量、可靠性和响应时间等指标。 SLA通常会涉及到各种服务指标，例如服务可用性、服务等待时间、故障修复时间、数据保密性、客户支持等，旨在确保供应商向客户提供高质量、高可靠性、高安全性的服务。 SLA通常用于云计算、SaaS、PaaS等服务领域，对于企业用户和服务提供商之间的合作非常重要。通过制定合适的SLA，双方可以达成共识，从而更好地维护业务合作关系。 一般作为甲方在采购乙方的服务的时候，乙方都会提供一些SLA指标，这些指标包括但不限于以下几个方面： 可用性：指服务在一定时间范围内能够正常使用的时间比例，通常以百分比表示。例如，“四个九”（99.99%）可用性要求表示一年内服务最多只能停机不超过52.56分钟。 响应时间：指服务响应请求的时间，通常以毫秒或秒为单位表示。例如，网络服务的响应时间可要求在100毫秒以内。 吞吐量：指系统在单位时间内能够处理的请求量，通常以每秒钟处理的请求量（QPS）或每分钟处理的请求量（RPM）为单位。 故障处理时间：指故障发生后系统能够恢复正常运行的时间，通常以分钟或小时为单位。例如，“四个九”（99.99%）可用性要求通常要求故障处理时间在52分钟以内。 数据可靠性：指系统能够保证数据的完整性、一致性、可用性和安全性。例如，在数据库系统中，可要求采用主从同步、备份等技术手段来保证数据的可靠性。 服务支持：指服务提供商提供的技术支持、客户服务等方面的指标。例如，在运营云服务时，可要求服务提供商提供24小时客户服务、及时响应客户请求等。 其他指标：根据具体业务需求和服务类型，还可以定义其他指标，如安全性、可扩展性、性能等。 SLA的指标需要根据业务需求、技术能力和市场标准等因素来进行制定，同时要具备可量化和可监控的特性，以确保双方都能够达成共识并得到有效执行。 扩展知识 4个9、5个9 SLA 4个9指的是服务的可用性要求，也被称为“四个九”，通常表示服务的可用性达到99.99%。 具体地说，四个九表示在一年的时间内，服务最多只能停机不超过52.56分钟（365*24*60*(1-0.9999)）。这意味着服务需要保持高可用性，并且具备足够的弹性和韧性，以应对突发的故障和异常情况。 同理，3个9、5个9等也是类似的算法。

典型回答 冷备、热备和暖备是备份和恢复方案中常见的术语，它们表示备份和恢复方案的不同类型和不同级别。 冷备（Cold Backup）：冷备是指在关闭系统或服务后，将数据备份到离线介质中的一种备份方式。在备份过程中，系统或服务不可用。恢复时需要将备份的数据还原到系统中，并启动系统或服务。由于备份和恢复过程中系统处于离线状态，因此冷备的恢复时间较长，但成本相对较低。 举例：在深夜停机时备份整个数据库、在一个网站的低峰期备份数据库。 热备（Hot Backup）：热备是指在系统或服务运行期间，对数据进行备份的一种备份方式。在备份过程中，系统或服务仍然可以提供服务。热备的恢复时间相对较短，但需要额外的资源来支持备份和恢复，因此成本较高。 举例：使用数据库备份工具在生产服务器上运行备份任务，而无需停机，以确保数据持续可用。就像我们通常做的数据库的主从同步，其实就是热备的一种实现。 暖备（Warm Backup）：暖备是介于冷备和热备之间的备份方式。在进行暖备时，备份数据与原始数据之间的同步是定期进行的，备份数据的时间间隔通常比热备长，但比冷备短。暖备的恢复时间比热备长，但比冷备短，因为需要将备份数据还原到原来的位置，并进行一些必要的同步操作。 举例：一般是在某个应用程序的特定功能模块关闭或限制访问的情况下备份数据，以减轻备份操作对业务的影响。 综合来看，冷备、热备和暖备的选择应该根据具体的业务需求和资源限制来进行综合考虑。一般而言，如果数据要求高可用性和实时性，应该采用热备方式；如果数据要求较高，但可用性和实时性要求相对较低，可以采用暖备方式；如果数据要求不是很高，可以采用冷备方式。

典型回答 压测是一种非常常见的帮我们做性能评估的手段。通过模拟用户请求，帮助我们发现系统的瓶颈以及评估系统的整体水位。 以下是进行压测的一般步骤： 确定测试目标：明确进行压测的目标，具体是哪个接口，那个方法，哪种具体的case。以及这次压测我们要实现什么目的，是测试300QPS能不能扛得住，还是看看系统的整体水位咋样。 制定压测计划：确定压测的具体策略，包括测试的时间、持续多久、并发量要压到多少、是一次性压到指标还是脉冲式压上去、测试环境配置等。 创建环境并准备脚本：压测可以在测试环境也可以在生产环境，但是不管是硬件配置、部署架构还是代码，都需要和线上环境尽量保持一致。并且需要准备好压测数据及脚本，是不同的用户，还是相同的用户，是写数据还是读数据。都是不一样的。 执行压测：根据测试计划，执行压测并收集性能指标。可以逐步增加负载，观察系统的响应情况。 监控系统性能：施压不是目的，目的是在施压过程中，观察系统的整体情况。包括但不限于： QPS、RT、失败率、CPU利用率、Load、内存情况、GC次数、GC时长、网络IO情况、堆内存情况、线上报警情况等。 分析结果：对压测结果进行分析，确定系统的性能瓶颈和潜在问题，并采取相应的优化措施。 优化和再测试：根据分析结果，进行必要的优化和改进，并重新进行压测，直到系统能够满足预期的性能要求。 常用的压测工具包括JMeter、Apache Bench等，它们可以帮助自动化执行压测脚本，并提供详细的测试报告和性能分析。在进行压测时，需要特别注意对生产环境的影响，确保不会对实际用户造成不良影响。因此，在压测前务必仔细准备，并充分评估风险。 扩展知识 JMeter JMeter是一个功能强大的开源性能测试工具，由Apache软件基金会开发和维护。它主要用于进行压力测试、负载测试和性能测试，以评估Web应用程序、Web服务、数据库和其他类型的服务在不同负载条件下的性能。 jmeter官网：https://jmeter.apache.org/ 给大大家推荐一篇我同事写的jemer实践经验：https://www.talkwithtrend.com/Article/245389 ，想要了解这个工具怎么用的，可以看下这篇文章。 总之，这个是目前比较主流的压测工具。 全链路压测 ✅什么是全链路压测？

典型回答 异地多活是一种分布式系统架构模式，可以让多个数据中心在不同地理位置提供相同的服务，并且能够实现数据的实时同步和故障切换。通常用于需要在全球范围内提供高可用性和低延迟的应用程序，例如在线游戏、社交媒体、金融交易等。 在异地多活架构中，多个数据中心之间通过高速网络连接进行数据同步和负载均衡。每个数据中心都具有完整的应用程序和数据副本，可以同时提供服务并处理客户端请求。当一个数据中心发生故障时，可以通过自动切换和故障转移机制将流量转移到其他健康的数据中心，从而保证系统的可用性和可靠性。 异地多活架构需要考虑多个因素，例如数据同步和冲突解决、负载均衡和故障切换、安全性和隐私保护等。通常需要采用分布式数据库、消息队列、负载均衡器、DNS解析等技术来支持异地多活架构。 扩展知识 同城容灾 同城容灾和异地多活一样，也是一种分布式系统架构模式，可以在同一城市或地理区域内提供高可用性和容灾能力。它通过将不同的服务器和存储设备组合在一起，构建出一个分布式系统，可以实现数据的实时同步和故障切换。 在同城容灾架构中，多个数据中心之间通过高速网络连接进行数据同步和负载均衡。每个数据中心都具有完整的应用程序和数据副本，可以同时提供服务并处理客户端请求。当一个数据中心发生故障时，可以通过自动切换和故障转移机制将流量转移到其他健康的数据中心，从而保证系统的可用性和可靠性。 同城容灾架构相比于异地多活架构来说，更加适用于数据中心距离较近的情况。它可以通过使用复制、镜像和数据同步等技术来实现数据的备份和容灾，从而提高系统的可用性和可靠性。同时，同城容灾架构还可以提供低延迟和高带宽的网络连接，以支持高吞吐量的应用程序。

典型回答 设计一个高可用架构需要考虑多个方面，包括可用性、可靠性、性能、扩展性、安全性等。下面是一些设计高可用架构的一般性原则和方法： 设计集群架构：采用多节点的集群架构可以提高系统的可用性和可靠性，从而避免单点故障导致系统不可用。 采用分布式架构：采用分布式架构可以将系统的负载分散到多个节点上，从而提高系统的性能和可扩展性。 ✅什么是分布式系统？和集群的区别？ 实现故障转移和容错机制：通过使用冗余组件、备份数据等技术手段，可以实现故障转移和容错机制。例如，采用主从复制、备份、快速切换等技术来确保数据不丢失、系统快速恢复。 限流降级熔断：通过限流、降级、熔断等手段，有效的放置一些突发流量、部分系统不可用等问题导致的整体的雪崩。 ✅限流、降级、熔断有什么区别？ 多活设计：通过建设多个数据中心或者多个机房实现服务的互相备份，并且能够同时提供服务。每个数据中心都可以独立运行，确保即使某个数据中心故障，其他数据中心仍然可以接管流量，保证服务不间断。 ✅什么是异地多活？ 容灾和备份：需要设置容灾和备份计划，以确保在自然灾害、人为错误或其他紧急情况下能够快速恢复服务。可以使用云备份和容灾服务，以提高备份和恢复的效率和可靠性。 ✅什么是异地多活？ 设计监控和自动化工具：通过使用监控工具和自动化工具可以实现对系统的实时监控和自动化维护。例如，通过使用系统监控工具、自动化运维工具等来实现自动化运维、自动化扩容等功能，从而减少手动操作和人为错误。 实现数据安全保护：通过采用多层次的安全策略来保护数据的安全性。例如，使用加密技术、防火墙、入侵检测等技术来保护系统和数据的安全。 进行容量规划和性能优化：通过进行容量规划和性能优化，可以提高系统的性能和可扩展性。例如，通过使用缓存、调整配置参数、优化代码等技术手段来提高系统的性能和稳定性。 设计自动化扩容和弹性伸缩：通过设计自动化扩容和弹性伸缩功能，可以根据业务需求和系统负载情况来自动调整系统资源。例如，通过使用自动化扩容工具和自动化弹性伸缩策略来实现系统资源的自动分配和调整。 需要注意的是，设计高可用架构需要综合考虑业务需求、技术方案、资源投入等因素，同时需要不断进行优化和改进，以实现最优的性能和可用性。

典型回答 显然不能，这种想法太理想了。单纯通过机器数量线性推算QPS是不成立的！ 因为你的QPS，除了应用本身的影响之外，还瘦太多因素的影响了，包括网络层的负载均衡、服务调用这一层的网络延迟、负载均衡，消息这一层的消息堆积情况，数据存储这一层的线程池情况，CPU，内存等硬件情况都会对整体的QPS造成影响。 最简单的例子，单机压测的时候，压测到300，加到10台机器，如果负载均衡算法并不均衡呢？如果给某个单机的QPS分到了500呢？是不是就扛不住了。 就算分的比较均匀，每台机器都不超过300，那问题是单机压测时候数据库也抗到300，而10台机器的时候，数据库可要抗3000啊，3000你可没压测过啊。数据库如果扛不住了，系统整体不就也扛不住了么。 不只是数据库，还有很多中间件 ，Redis、MySQL、MQ、XXL-JOB等等，甚至一些外部服务，短信服务，支付服务，网关服务等等，都会有影响的。

典型回答 在压测的时候，一定是不能影响线上的真实用户的。那么如何避免呢？ 单独的压测环境 在进行压测之前，首先应该在一个独立的压测环境中进行测试。这个环境应该是与线上环境隔离的，包括独立的数据库、缓存和其他依赖服务。这样可以确保压测不会对线上用户产生任何影响。 这个压测环境可以是日常（测试）环境，也可以是预发布环境。 预发布环境：指的是和线上一样的环境，数据库、缓存都用的是同一份，机器配置也相同，但是正常用户无法访问，需要通过 host 绑定的方式来访问。 一般来说，针对新场景的压测，建议先从日常开始压测，然后再到预发布环境开始压。如果是老链路，可以直接去预发布环境压测。 为啥要在日常先压呢？ 1、日常压测的成本低，不会有任何影响，不用考虑脏数据问题，也不用考虑对用户的影响。 2、日常环境的配置相对更低一些，可以更容易发现压测链路上的薄弱点。 为啥还要去预发布压测呢？ 主要是因为日常环境的服务器配置、数据库情况、业务链路和线上有很大差别。无法还原线上的真实情况。 所以，需要日常和语法结合着去压测。 控制压测范围 确保只在指定的测试环境中进行压测，并且不要对线上生产环境发出任何测试请求。并且通过合理的配置和网络隔离，确保测试请求不会意外地进入线上系统。 而且，更重要的是压测数据不要写到线上库去，容易对真实用户的造成影响，就算压测数据不会被真实用户的看到，但是表中数据量大对性能也是有影响的。 所以，如果在预发布环境压测时，需要考虑影子表。 影子表：通常是指在数据库设计中的一种技术概念，用于在不影响主表的情况下进行数据备份、实时数据同步、数据修订或其他操作。也通常用在全链路压测中。 业务低峰期压测 选择在系统负载较低的时间段进行压测，例如深夜或者低峰时段。这样可以最大程度地避免影响线上用户的正常使用体验。 控制压测流量 在压测工具中设置适当的并发数和请求速率，以确保不会超出系统能够处理的范围。 最好是逐步放量，先并发的压，扛得住的话再一点点放量。