三十而立，是一个被赋予了太多期望的词。我们曾以为，到了这个年纪就该事业有成、家庭美满，活成一个”标准答案”。然而，当31岁的里程碑悄然来临，我们才发现，人生没有标准答案，只有不断叩问自己、与自己和解的过程。 一、焦虑，是成长的必经之路最近，我常常感到一种莫名的焦虑。它不像年轻时的迷茫，那种对未来的不确定性。现在的焦虑更像是站在一个山顶，回头望去，有起有落，有清晰的足迹，但前方却又是一片迷雾。 我开始意识到，31岁不再是那个可以肆意挥霍时间的少年。我们开始算计沉没成本，每一次选择都背负着更高的风险。肩上的责任越来越重，它不只是工作的 KPI，更是对家人、对未来的承诺。 曾国藩说：”物来顺应，未来不迎，当时不杂，既过不恋。“ 这句话曾被我奉为圭臬。但真正的感悟，是在这31年的人生轨迹里，我才明白它不是让我们被动接受，而是告诉我们，面对焦虑，与其被动逃避，不如主动剖析，搞清楚焦虑的根源，才能真正与之和解。 二、撕开自我的”理想画像”，看见真实的自己为了看清前路，我决定做一次深度自我解剖，将自己的人生分成两个阶段：毕业前和工作后。这不是简单的履历罗列，而是去洞察那些塑造了我、也 ...

一、背景简介虚拟机部署的Java应用没有集成SpringBoot自带监控Actuator，需要额外手动配置采集JVM监控。JMX-Exporter作为Prometheus生态系统中重要的组件，能够将JMX（Java Management Extensions）指标转换为Prometheus格式，实现对Java应用的深度监控。 核心解决问题： 传统Java应用缺乏现代化监控指标暴露 需要统一监控数据格式对接Prometheus 实现JVM性能指标的实时采集和分析 二、JMX Agent部署步骤2.1. 部署文件在开始部署之前，需要准备以下核心文件： 文件类型 文件名称 说明 JVM监控Agent jmx_prometheus_javaagent-1.2.0.jar JMX指标收集器 监控配置文件 exporter.yaml JMX指标采集规则配置 exporter.yamlrules: - pattern: ".*" 版本说明： 建议使用JMX Prometheus JavaAgent 1.2.0或更新版本 配置文件需要根据应用 ...

一、背景简介生产环境的MySQL监控面临着部署复杂、标签不统一、管理困难等问题。传统方式中每个MySQL实例都需要单独部署一个exporter，部署方式繁琐，采集的指标标签不统一，无法在监控图表上快速检索查看。 核心解决问题： 简化MySQL监控的部署流程 统一监控指标标签格式 支持灵活的多实例监控管理 提供安全的认证信息存储 本方案采用Helm部署mysql-exporter实现MySQL监控采集，可以灵活增加mysql监控实例，大大简化了运维管理复杂度。 二、部署文件准备2.1. 必需文件清单 文件类型 文件名称 说明 Helm Charts prometheus-mysql-exporter-2.10.0.tgz prometheus-mysql-exporter chart部署包 配置文件 mysql-exporter-values.yaml mysql-exporter配置文件 版本说明： 推荐使用prometheus-mysql-exporter 2.10.0或更新版本 Chart包包含了完整的Kubernetes资源定义 values.ya ...

一、背景简介生产之前出现过许多业务异常的情况未能及时发现，这些异常出现时有大量的异常日志打印，但是由于缺乏日志监控，未能及时发现异常并进行处理。 该方案计划对生产所有的异常日志进行监控及告警配置，及时发现生产日志异常，快速响应处理。 二、日志及监控采集方案生产的日志采集和监控均基于Promtail组件实现，具体的原理如下： Promtail监听日志文件变化，主动将日志数据推送到Loki服务端实现日志数据采集； Promtail采集日志内容时根据配置做日志监控指标聚合运算，Prometheus主动到Promtail拉取聚合的日志监控指标； 图：基于Promtail的日志和日志监控采集架构 2.1. 日志监控两种实现方式对比日志监控两种实现方式包括：Promtail 中的 metrics 阶段和 Loki 的 ruler 组件。 方案一：Promtail在日志采集时进行日志监控指标的收集 监控指标采集速度高、无延迟 告警规则使用Prometheus的告警规则即可 需要在Promtail侧配置日志告警指标 方案二：Loki的Ruler组件定时根据配置查询 根据配置的告警 ...

一、背景简介生产环境的Redis监控告警一直存在准确性问题，通过深入排查发现redis-exporter采集方式不正确，导致监控指标偏差和告警误报。为了解决这些问题，采用标准化的Helm部署方式来实现Redis集群监控采集。 核心解决问题： 修复Redis监控指标采集不准确的问题 统一Redis集群监控部署方式 提供安全的认证信息管理 支持多集群的灵活配置管理 本方案通过Helm部署redis-exporter实现Redis集群监控采集，确保监控数据的准确性和可靠性。 二、部署文件准备2.1. 必需文件清单 文件类型 文件名称 说明 Helm Charts prometheus-redis-exporter-6.9.0.tgz prometheus-redis-exporter chart部署包 配置文件 redis-exporter-values.yaml redis-exporter配置文件 版本说明： 推荐使用prometheus-redis-exporter 6.9.0或更新版本 Chart包包含了完整的Kubernetes资源定义 values ...

一、背景简介消息发送管控平台中有个很重要的能力就是文本关键字检测，比如检测一段话中是否含有法轮功等敏感字段，这就涉及到关键字匹配算法。在该项目中每条消息都要经过关键词过滤，通过后才能下发。关键字匹配有两种形式，分为单一关键字和逻辑关键字。 1.1 单一关键字单一关键字指单个单词，如：法轮功，炸金花，一条龙服务等涉恐、涉赌、涉黄等关键字，单个的关键字在系统数据库中的数量在9万+，消息下发时需要检测文本中是否包含数据库中单个关键字。 1.2 逻辑关键字逻辑关键字由多个单一关键字组合&&、||、!逻辑运算符，即匹配到的关键字满足逻辑关键字中的逻辑运算逻辑才进行管控。 例如：逻辑关键字点击&&登录&&!验证码, 表示内容包含点击、登录关键字并且不包含验证码关键字，如果文本中包含的内容符合该逻辑，则进行拦截管控。 二、性能要求消息发送管控平台关键字整体数据规模为10万量级，其中单一关键字数量为9万，逻辑关键字数量为1万。消息管控平台的安全审核接口整体的平均响应时间为50ms。 三、方案预研我们先分析梳理常用的关键词匹配算法，再根据上述业务需求及 ...

一、背景简介在客户的业务场景中，需要在全局开启终端用户消息发送的频次管控，避免消息重复发送以及段时间内下发大量消息对终端用户进行信息轰炸，从而引起终端用户投诉。目前业务平台每日最高的消息发送量为30亿，去重后的消息接收人量在千万级到亿级，消息发送管控平台需要对每个消息接收人的消息发送时间进行缓存，并根据管控平台配置频次管控策略，检查最新下发的消息是否超过设置的频次，超过则进行拦截。 1.1 频次管控配置 限制项 限制频率 说明 接收频次管控 15次/1分钟 任意1分钟内，对同一个接收人发送消息最多15次，超出次数会被限制。 接收频次管控 50次/24小时 任意24小时内，对同一个接收人发送消息最多50次，超出次数会被限制。 内容频次管控 2次/59秒 任意59秒内，对同一个接收人发送同一内容（内容完全相同）最多2次，超出次数会被限制。 内容频次管控 5次/59分钟 任意59分钟内，对同一个接收人发送同一消息内容（内容完全相同）最多5次，超出次数会被限制。 二、需求分析基于上述业务场景，我们需要对每个消息接收者做消息接收 ...

在业务开发中经常遇到限流场景，本文主要介绍四种经典的限流算法：固定窗口计数器、滑动窗口计数器、漏桶算法、令牌桶算法，在做限流的场景时可以借鉴这几种经典的限流算法，掌握其使用场景级优缺点。 一、固定窗口计数器（Fixed Window）固定窗口计数器(Fixed Window)算法的实现思路非常简单，维护一个固定单位时间内的计数器，如果检测到单位时间已经过去就重置计数器为零。计数限首先维护一个计数器，将单位时间段当做一个窗口，计数器记录这个窗口接收请求的次数。 当次数少于限流阀值，就允许访问，并且计数器+1 当次数大于限流阀值，就拒绝访问 当前的时间窗口过去之后，计数器清零 二、 固定窗口算法的优缺点 优点：固定窗口算法非常简单，易于实现和理解，性能高。 缺点：存在明显的临界问题。 1.2 临界问题临界问题：假设限流阀值为5个请求，单位时间窗口是1s,如果我们在单位时间内的前0.8-1s和1-1.2s，分别并发5个请求。虽然都没有超过阀值，但是如果算0.8-1.2s,则并发数高达10，已经超过单位时间1s不超过5阀值的定义。 2.2 滑动窗口计数器（Sliding Window） ...

一、背景简介项目需要设计一个高并发的消息发送管控平台，实现业务消息发送安全管控。业务要求所有下发内容需要调用安全管控平台安全审核接口进行安全审核，根据管控策略进行放通、拦截及人工审核。目前线上日发送量峰值为30亿条左右，发送平均速度为3.47万条/秒,消息发送管控平台接口的TPS需要达到10万级别。 1.1 管控策略基于业务需求管控平台提供管控能力及管控策略配置，平台部分管控功能如下： 消息发送频次管控 重复内容发送管控 关键字匹配过滤 发送黑名单过滤 二、架构设计根据业务系统要求，管控平台安全审核接口需要实现10万tps，请求处理耗时在50ms以内。 2.1 业务架构图安全管控平台业务架构较为简单，包含3个核心模块： 管控后台：用于管理管控相关数据及查看、审核被管控的消息记录 网管管控API：提供统一安全管控接口，根据平台的管控策略要求，对下发消息进行审核管控 审核回调：用于向业务平台推送人工审核结果及相关变更数据 2.2 部署架构图上图为管控平台的部署架构图，Redis集群和MySQL数据库使用华为云的服务，应用模块均实现集群化部署： 管控后台：基于Redis实 ...

一、概念简介1.1 Base理论BASE 是 Basically Available（基本可用）、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。 1.2 CAP理论CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。 二、Base理论 BASE 理论起源于 2008 年， 由 eBay 的架构师 Dan Pritchett 在 ACM 上发表。 2.1 简介BASE是“Basically Available, Soft state, Eventually consistent(基本可用、软状态、最终一致性)”的首字母缩写。其中的软状态和最终一致性这两种技巧擅于对付存在分区的场合，并因此提高了可用性。 Basically Availabl ...