## Pod 容忍节点异常时间调整 ### 1. 原理说明 Kubernetes 集群节点处于异常状态之后需要有一个等待时间，才会对节点上的 Pod 进行驱逐。那么针对部分关键业务，是否可以调整这个时间，便于在节点发生异常时及时将 Pod 驱逐并在别的健康节点上重建？ 要解决这个问题，我们首先要了解 Kubernetes 在节点异常时驱逐 Pod 的机制。 在 Kubernetes 1.13 参数，指定当节点出现异常（如 NotReady）时 Pod 还将在这个节点上运行多长的时间。 那么，节点发生异常到 Pod 被驱逐的时间，就取决于两个参数：1. 节点实际异常到被判断为不健康的时间；2. Pod 对节点不健康的容忍时间。 Kubernetes 集群中默认节点实际异常到被判断为不健康的时间为 40s, Pod 对节点 NotReady 的容忍时间为 5min, 也就是说, 节点实际异常 5min40s(340s) ControllerManager 配置文件/etc/kubernetes/controller-manager 中添加参数 --node-monitor-grace-period=20s，将节点被标记为不健康的容忍时间调整为 20s，修改前请做好配置文件备份； 2. 执行 systemctl restart kubecontroller-manager 重启 ControllerManager; 3. 执行

## Kubernetes 异常配置检测框架 顾静, 阿里云 邓隽, 阿里云 ## 我们来自阿里云容器服务 • 顾静，研发工程师 • 邓隽，技术专家 ## 我们参与打造 • 容器服务（ACK/ASK） • 容器镜像服务（ACR） • 服务网格（ASM） 1 Kubernetes 典型异常 2 检测框架演进 3 生产实践 4 总结 ## Kubernetes 使用日常 使用日常 • 应用部署 • 集群扩容 • 组件升级 · ... • 找出集群不正常工作的原因：( ## Kubernetes 典型异常 ## 组件异常 • API Server Load Balancer 异常 • API Server Pod 异常 ## 影响 - 通过 API Server 访问集群概率失败 • 升级集群失败 Load Balancer ![Image](/u API Server Pod Master API Server Pod Master ## Kubernetes 典型异常 ## 网络异常 • 安全组、路由表配置错误 • 节点防火墙软件等修改 iptables、内核参数 • 网络链路长，手动排查成本高 ## 异常影响 • 应用间无法正常通信 • 集群内 Controller 无法正常工作 ![Image](/uploads/d

208亿次互动 ## 极端并发下的架构设计理念 • 从数万QPS的“高并发”到数千万QPS的“极端并发” √大量的技术沉淀和积累 √针对性的专项设计 - 墨菲定律：凡是可能出错的事就一定会出错 ✓为异常而设计，按“万无一失”去设计 - 以大化小，层级分治 弹性、智能、动态、自愈 高效能，控制总成本 ANYTHING THAT CAN GO WRONG WILL GO WRONG. ## 小程序（预加载，资源预置） 高效语音模型+调度 整体监控系统 特供内容 柔性架构 主流程 时间轴 任务系统 系统分级+柔性 视频红包+小程序 登录交互与session 钱袋子 全链路压测系统 多级Cache与预充 基础设施与服务 数据分析系统 分布式存储 安全防攻击 用户登录 提现-度小满 短信验证码 ☐ ☐ ☐ ☐ ☐ 服务器 机房 IDC网络 CDN PaaS与调度 e3a7db198e/p9_14.jpg) 智能小程序 ## 摇一摇红包系统 - 每秒数千万用户并发 ✓+内部逻辑放大 - 单个分布式巨型系统？ ✓问题：子系统扩展性瓶颈 ✓问题：故障容忍能力 ✓问题：测试与验证的复杂性 - 以大化小（以巨化大），SET化 ✓条带化，多个单元化集群 ✓业务优化适配 ✓可防止故障扩散 ✓更可控的预案 接入 扩展 → 业务 扩展 → 存储

# Java 应用与开发 异常处理 王晓东 wangxiaodong@ouc.edu.cn 中国海洋大学 October 30, 2018   ## 学习目标 1. 掌握 Java 异常的概念和分类 2. 深入理解 Java 异常处理机制 异常的概念及分类 ## 大纲 异常的概念及分类 Java 异常处理机制 ## C++ 中的异常处理 ## 《The C++ Programming Language》 一个库的作者可以检测出发生了运行时错误，但一般不知 ## 提供异常处理机制的基本思想 让一个函数在发现了自己无法处理的错误时抛出（throw）一个异常，然后它的（直接或者间接）调用者能够处理这个问题。 ## 《C++ primer》 将问题检测和问题处理相分离。 (Exceptions let us separate problem detection from problem resolution.) ## C++ 中的异常处理 ##

一致性协议 多副本：写三次？一致性协议一致性：WARO（Write-all-read-one）、Quorum WARO • 所有副本写成功 • 读可用性高：可以读任一副本 • 写可用性较低，任一副本异常写失败 Quorum • 大多数副本写成功 - 读写服务可用性做一个折中 • 写性能提升，速度取决于写的较快的大多数  ## 架构简介 — 数据放置 ## 使用多级哈希的方式 根据 offset, len, name.. 生成 ObjectID rbd\udata.6855c174a277a30.00000000005c2 对ObjectID进行哈希并取模（复制组数量）得到pgid 使用WARO一致性协议 • 所有副本写完成返回客户端 • 延迟取决于所有副本中最慢的那一个 ## 复制策略 • 主动拷贝、链式复制、splay复制 ## 异常处理 • PG有23种状态：Peering，Degraded等 • 强一致性协议对异常的容忍较差 ## 块存储场景 为云主机提供云盘，云盘提供随机读写、快照（数据备份，灾备使用）、镜像（模板，自定义）功能。 ![Image](/uploa

SimpleResponse{ Payload: newPayload(in.GetResponseType(), in }, nil ## Cache 模仿cpu使用多级cache； L1 cache：不经常修改，大量访问对性能要求极致的，我们使用go map缓存信息，使用COW保证无锁更新和访问； 使用redis作为核心的cache store; 使用hash

议采用支持 802.3ad 协议的交换机以实现多网口的链路聚合，这样，在操作系统层面，多个物理网口将聚合并表现为一个 IP 地址，当任何的网络或者交换机出现故障时，在操作系统级别将不会有任何的连接性异常的感知，只是网络带宽出现下降，整个数据库集群的 Instance 状态将不会受到任何影响。如果选择将 Primary 和 Mirror 分布在不同的网段，出现任何的网络故障时，总会有 Instance 限的时间窗口内完成大量数据的装载。GP通过外部表(External Table)支持高速并行数据装载。外部表可以使用[单条记录出错隔离]模式，以允许在装载数据过程中将出错的数据记录下来。可以设置错误容忍的阈值，以实现对数据装载质量的控制。也可以对错误信息进行分析，以帮助改善数据装载的质量。 结合使用外部表和 GP 的并行文件分发服务 (gpfdist)，管理员可以实现最大化的利用网络带宽资源以实现高速并行装载。 conf 文件中: max connections=500 max prepared transactions=100 ## 修改最大连接数的步骤 1. 通过 gpstate 命令确认数据库状态无异常，如： $ gpstate -e $ gpstate $ gpstate -f 2. 使用 gpconfig 命令修改参数值: $ gpconfig -c max_connections -v

设计模式二三事 647 基于代价的慢查询优化建议 670 Java 系列 | 远程热部署在美团的落地实践 692 日志导致线程 Block 的这些坑，你不得不防 713 基于 AI 算法的数据库异常监测系统的设计与实现 775 Replication（上）：常见复制模型 & 分布式系统挑战 792 Replication（下）：事务，一致性与共识 818 TensorFlow 在美团外卖推荐场景的 标准化思想及组装式架构在后端 BFF 中的实践 992 外卖广告大规模深度学习模型工程实践 | 美团外卖广告工程实践专题连载 1013 数据库全量 SQL 分析与审计系统性能优化之旅 1048 数据库异常智能分析与诊断 1059 美团外卖广告智能算力的探索与实践（二） 1079 Linux 下跨语言调用 C++ 实践 1101 GPU 在外卖场景精排模型预估中的应用实践 1130 美团集群调度系统的云原生实践 较好地解决了重参数化结构的量化问题。 #### 2.1.1 RepOpt RepOpt $ ^{[3]} $ 对重参数化结构量化困难的问题进行了研究，发现重参数结构的分支融合操作，显著放大了权重参数分布的标准差。异常的权重分布产生了过大的网络激活层数值分布，进一步导致该层量化损失过大，因此模型精度损失严重。 鉴于此，我们统计了基于 RepVGG 结构的 YOLOv6 模型（YOLOv6s_repvgg）各层的权重及激活数值分布，分析了

最后，在运营配置上线后，如果发现问题，可以通过快速回滚，最大限度地实现“止损”。 ||事前|事中|事后| |---|---|---|---| |机制保证|测试预览、穿越预览|多重审核|回滚| |解决问题|C端展示问题、链接异常、平台差异|敏感内容过审、图片质量|出错处理、排期问题、最大限度止损| ## 接口SDK化 对于运营数据，无论是通过数据库的落地方案、还是通过分布式缓存的方案，都无法彻底解决服务中心化和服务抖动 技术优势 实时处理：信息的价值会随时间锐减，尤其是在事故处理过程中。 - 全量数据：全量采集指标数据，便于深度分析故障案例。 - 高可用：故障的还原与问题定位，需要高可用监控来支撑。 ● 故障容忍：故障不影响业务正常运转、对业务透明。 • 高吞吐：海量监控数据的收集，需要高吞吐能力做保证。 - 可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统。 ## 使用现状 目前，CAT 已 或者其他 NIO 框架： 1. 使用 JDK 自带的 NIO 需要了解太多的概念，编程复杂。 2. Netty 底层 IO 模型随意切换，而这一切只需要做微小的改动。 3. Netty自带的拆包解包，异常检测等机制让我们从 NIO 的繁重细节中脱离出来，只需关心业务逻辑即可。 4. Netty解决了JDK的很多包括空轮训在内的Bug。 5. Netty底层对线程，Selector做了很多细小的优