chaos

链接: http://acm.hdu.edu.cn/contests/contest_showproblem.php?pid=1009&cid=872 题意: 在 dota2 中有一个叫做祈求者(Invoker)的英雄，在游戏中他有三个基础技能：冰(Quas)，雷(Wex)，火(Exort)，每施展一个技能就可以获得相应属性的一个法球(element)。 但是祈求者同时最多只能有三个法球，即如果他在有三个法球的状态下又使用了某个法球技能，那么他会获得该法球，并失去之前三个法球中最先获得的一个。 不难得出，祈求者身上的三个法球的 无顺序 组合有 10 种，每一种都对应着一个组合技能： 急速冷却(Cold Snap)，无序组合 QQQ，用 Y 表示 幽灵漫步(Ghost Walk)，无序组合 QQW，用 V 表示 寒冰之墙(Ice Wall)，无序组合 QQE，用 G 表示 电磁脉冲(EMP)，无序组合 WWW，用 C 表示 强袭飓风(Tornado)，无序组合 QWW，用 X 表示 灵动迅捷(Alacrity)，无序组合 WWE，用 Z 表示 阳炎冲击(Sun Strike)，无序组合 EEE，用 T 表示 熔炉精灵(Forge Spirit)，无序组合 QEE，用 F 表示 混沌陨石(Chaos Meteor)，无序组合 WEE，用 D 表示 超震声波(Deafening

作者 | RocketMQ社区 来源| 阿里巴巴云原生公众号 “童年的雨天最是泥泞，却是记忆里最干净的曾经。凛冬散尽，星河长明，新的一年，万事顺遂，再见，2020！” 走过这个岁末，万众期待的 Apache RocketMQ 4.8.0 终于发布 了，在这个版本中社区对 RocketMQ 完成大量的优化和问题修复。更重要的是，该版本从性能、稳定性、功能三个方面大幅度提升 DLedger 模式能力。 DLedger 是 OpenMessaging 中一个基于 Raft 的 CommitLog 存储库实现，从 RocketMQ 4.5.0 版本开始，RocketMQ 引入 DLedger 模式来解决了 Broker 组内自动故障转移的问题，而在 4.8.0 版本中社区也对 RocketMQ DLedger 模式进行了全面升级。 性能升级 异步化 pipeline 模式 RocketMQ 4.7.0 重新升级了同步双写的架构，利用异步化 pipeline 模式大幅提升了同步双写的性能。在 RocketMQ 4.8.0 中，社区将这一改进应用到 DLedger 模式中, 下图展示了 DLedger 模式下 broker 处理发送消息的过程。在原本的架构中, SendMessageProcessor 线程对每一个消息的处理，都需要等待多数派复制成功确认，才会返回给客户端，而在新版本中，利用

前言 由于外部环境的复杂以及硬件的不可靠，互联网服务的高可用面临着巨大的挑战，由于断网、断电等事故导致的各大互联网公司服务不可用的案例也不在少数。业务不可用，小到带来经济损失影响企业口碑，大到微信、支付宝这些国民级应用，影响国计民生。面对难以避免的天灾人祸，容灾架构的建设就成为了数字化企业的迫切诉求。 2020 年 12 月份，阿里云应用高可用产品 AHAS（Application High Availability Service）发布了新的功能模块 AHAS-MSHA，它是在阿⾥巴巴电商业务环境演进出来的多活容灾架构解决⽅案。本篇文章我们首先介绍容灾领域的几个重要概念，然后将结合一个的电商微服务案例，分享一下如何基于 AHAS 的异地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）帮助业务实现容灾架构的高可用实践。 容灾与评价指标 1. 什么是容灾？ 容灾（Disaster Tolerance）是指在相隔较远的异地，建立两套或多套功能相同的系统，系统之间可以相互进行健康状态监视和功能切换，当一处系统因意外（如火灾、洪水、地震、人为蓄意破坏等）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。 2. 容灾能力如何评估？ 容灾系统主要为了在灾难发生时业务不发生中断，那么容灾能力如何评估和量化呢

随着云原生技术的迅猛发展，IT 基础设施正在发生巨大变革，许多企业都将其架构迁移至云原生平台，通过云原生技术，使得企业在公有云、私有云和混合云等云环境中，构建和运行应用变得更加容易，更能充分利用云环境的优势。 作为早期的云原生技术布道者与实践者，PingCAP 联手 CNCF、VMware 、网易数帆与阿里云，共同举办 2020 Cloud Native Day（2020 云原生生态大会）。为期两天的线上主题分享，您将有机会听到云原生领军企业和组织分享的云原生战略与实践，剖析云原生技术带来的挑战和机遇，推进云原生技术与企业 IT 的融合，更有来自头部用户的技术实践和创新分享。 PingCAP 重磅议题抢先剧透 Is Shared-nothing dead？云原生数据库设计新思路 黄东旭 | PingCAP 联合创始人兼 CTO 云计算从 AWS 初创时的牛刀小试到如今巨大的行业和生态，显现出不可逆转的趋势。未来一切都会在云上，云上生态也需要新的基础软件。本次演讲将系统化分析云改变了什么？云基础设施和软件融合有哪些新方向？ TiDB Cloud 可观测性 郑佳金 | PingCAP DBaaS 工程师 TiDB Cloud 依托于公有云提供开箱即用的云数据库托管服务，通过水平扩展拥有近乎无限的存储容量和计算能力，支持多云多租户。本议题主要分享如何在云上监控多个 TiDB 与

Chaos Mesh 是一个云原生的混沌测试平台，在去年的最后一天，我们开源了这个项目，以帮助大家更好的进行混沌实验。从开源到现在近一年的时间里，Chaos Mesh 在所有贡献者的共同努力下，在不断完善新功能的同时，也在易用性和稳定性上取得了阶段性的成果。 今天，我们自豪的宣布 Chaos Mesh 1.0 正式发布！ Chaos Mesh 1.0 是一个里程碑，不仅支持更多混沌注入的类型，提高了框架组件的稳定性，并且增加了 Chaos Dashboard 组件用来改善 Chaos Mesh 的易用性。下面请跟随我们的脚步梳理 Chaos Mesh 1.0 有什么样的惊喜。 核心亮点 1. 丰富易用的混沌实验类型 混沌实验的核心是注入故障，Chaos Mesh 从分布式系统的出发，充分考虑分布式系统可能出现的故障，提供更加全面、细粒度的故障类型，能全方位的帮用户对网络、磁盘、文件系统、操作系统等进行故障注入。同时，使用 Chaos Mesh，不需要应用做任何修改，做到真正的被测试系统无感知。Chaos Mesh 目前支持的故障注入有： pod-kill：模拟 Kubernetes Pod 被 kill。 pod-failure：模拟 Kubernetes Pod 持续不可用，可以用来模拟节点宕机不可用场景。 container-kill：模拟 Container 被 kill。

本文根据石鹏老师在〖deeplus直播第227期〗线上分享演讲内容整理而成。 （文末有获取本期PPT&回放的方式，不要错过） 我们都知道SRE是一个体系化的工程，SRE体系的建设涉及的内容繁多，比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等等；其中「故障」可以算作是这众多事项的一个交汇点。 故障处理是一个特别符合“台上一分钟，台下十年功”这句俗语的场景，一次故障就是一次考试。SRE团队的响应速度、对服务的掌控能力、监控告警的覆盖是否完整、配置是否合理，灾备预案的体系是否完善、是否做了充分的灾备演练、应急预案是否有效....这些都是用于考核SRE体系建设水平的一些指标，都会在「故障处理」的过程中得到淋漓尽致的体现。不管你是研发、测试、运维，或其他“工种”，只要你身处IT行业，「故障」怕都是大家避之唯恐不及却无法绕开的一个梦魇和话题。 我将围绕「故障管理」这个点跟大家聊一聊SRE的工作范畴，跟大家共同探讨SRE体系的建设。希望可以通过分享让大家对故障管理有一个宏观的框架，可以更从容淡定、有章可循地做服务稳定性建设。 本次分享将按照如下的顺序展开： 先聊一聊SRE的工作职责，聊一下我所理解的SRE的核心目标； 初步看一下稳定性建设的工作范畴，看一看从宏观上如何划分我们的工作内容； 然后我们由此进入今天的主题

从事前端开发的你，不知有没有被问过：「前端有架构吗？」 问你的人的身份，可能是你的 boss 或上司，可能是后端同事，也可能是前端同行；问你的人的目的，可能是刁难，可能是嘲讽，也可能是请教。 前端开发 众所周知，做前端开发所依赖的核心技术就是 HTML、CSS 和 JS，就像好基友一样形影不离，我们将它们仨亲切地并称为「三剑客」。 经过这二十多年，尤其是在 V8 引擎及 Node.js 出现之后，以「三剑客」为基础的衍生技术如雨后春笋般大量出现，前端及其关联社区与前端工程师这个职业得到了空前的蓬勃发展，甚至让很多人觉得一个前端工程师不仅仅可以做 web 前端开发，还可以写后端，替代客户端工程师——前端技术一统天下！ 工作内容 除了做网页，前端技术还能应用于命令行工具、客户端应用、服务端应用、聊天机器人、爬虫、IoT 等场景。只要脑洞足够大，就不怕场景不够多。 然而，绝大部分的前端工程师在工作中都会接触到这些吗？ 试想一下，自己的工作历程是不是这样的—— 在一家 150 人规模以下的创业公司，可能业务还在摸索期，需要不断地快速试错以找到可以铆足劲儿去发力的点。这时前端团队也没几个人，可能就三五个吧，并且 leader 不是什么大牛，也没有一套方法论作为团队建设的指导，也许你是这个团队里实力最强的。 这个时期所需要的就是能够快速迭代产出成果，然后去验证是否有效。根本不会给你时间去思考

简介： 模拟驾驶能力输出，赋能客户提升稳定性信心 1.背景 我们技术服务团队经常会遇到这样的状况，随时随地收到紧急电话，开始紧张地排查问题，处理故障以及恢复服务。硬盘故障、网络不通、大量不到终态、水位高、流量激增等问题不胜枚举，也许因为一个很小的变更，因某种不可预期的场景，引起蝴蝶效应，导致了大面积的系统混乱、故障和服务中断，对客户的业务造成严重影响。故障往往带来巨大的损失，然而由于分布式系统的特性，各种不可预期的突发事件在所难免，单靠人力并不能够百分之百地阻止其发生。与其担惊受怕系统会出现什么样的问题，不如化被动为主动，提前模拟线上环境可能出现的各种情况，来检验我们的系统是否能做到容错，是否在出现问题时仍然具有对外提供服务的能力。 模拟驾驶的初衷就是通过实验性的方法，主动找出系统中的脆弱环节，让人们建立起复杂分布式系统在生产中抵御突发事件的信心。任何足够复杂的系统都不可避免地带有让人意想不到的暗债，暗债是现代软件系统逐步复杂化进程中的副产品，它会威胁系统的正常运转。模拟驾驶的意义就在于，它会帮助你发现暗债，从而在暗债变成系统的严重问题之前加以应对，避免造成损失。 2.模拟驾驶 模拟驾驶是GTS-SRE混合云团队遵循混沌工程实验原理，并融合团队内部多年高可用体系沉淀下来的经验而打造的一款技术服务，提供丰富的故障场景、异常仿真的实现，能够帮助分布式系统提升容错性和可恢复性