Redis集群监控配置-Helm部署方案
一、背景简介生产环境的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资源定义 va...
生产应用日志监控告警方案
一、背景简介生产之前出现过许多业务异常的情况未能及时发现，这些异常出现时有大量的异常日志打印，但是由于缺乏日志监控，未能及时发现异常并进行处理。 该方案计划对生产所有的异常日志进行监控及告警配置，及时发现生产日志异常，快速响应处理。 二、日志及监控采集方案生产的日志采集和监控均基于Promtail组件实现，具体的原理如下： Promtail监听日志文件变化，主动将日志数据推送到Loki服务端实现日志数据采集； Promtail采集日志内容时根据配置做日志监控指标聚合运算，Prometheus主动到Promtail拉取聚合的日志监控指标； 图：基于Promtail的日志和日志监控采集架构 2.1. 日志监控两种实现方式对比日志监控两种实现方式包括：Promtail 中的 metrics 阶段和 Loki 的 ruler 组件。 方案一：Promtail在日志采集时进行日志监控指标的收集 监控指标采集速度高、无延迟 告警规则使用Prometheus的告警规则即可 需要在Promtail侧配置日志告警指标 方案二：Loki的Ruler组件定时根据配置查询 根据配置...
海量业务数据加解密方案的落地与实践
一、背景简介根据数据安全规范与标准及企业合法合规运营，业务系统需要对海量的业务数据进行加密，保护数据的安全。 1.1 业务数据的安全性要求 敏感业务数据需要加密存储 数据查询需要进行解密 加密数据的密钥支持定期轮换 二、方案预研对于上述业务数据的加密要求，一般采用加密性能较高的对称加密算法，如：AES、国密SM4等。系统的数据加解密及密钥的管理及定期轮换，行业内一般是采用密钥管理服务（Key Management Service，简称KMS）来解决，下面我们就预研一下KMS的使用。 2.1 密钥管理服务KMS密钥管理，即密钥管理服务（Key Management Service，KMS），是一种安全、可靠、简单易用的密钥托管服务，帮助您轻松创建和管理密钥，保护密钥的安全。 KMS通过使用硬件安全模块HSM（Hardware Security Module）保护密钥的安全，所有的用户密钥都由HSM中的根密钥保护，避免密钥泄露。 KMS对密钥的所有操作都会进行访问控制及日志跟踪，提供所有密钥的使用记录，满足审计和合规性要求。 2.2 KMS服务选型密钥管理服务使用硬件安全模块HSM...
单域名多网站Nginx配置
一、背景简介在搭建个人博客或站点时，为方便用户记住访问站点，我们大多站点管理者会使用域名进行网站的访问。 二、域名Nginx配置2.1 global.confserver { listen 443 ssl; server_name mpoom.cn; #ssl on; ssl_certificate cert/mpoom.cn.pem; ssl_certificate_key cert/mpoom.cn.key; ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; client_max_body_size 100M; location / ...
目标与计划管理
管理者的必修课——目标与计划管理。 一、工作目标是用来干什么的？1.证明自己的努力是有结果的2.给自己的奔跑找一个加油站3.人们总是在不断的认可中前进4.用节点的目标评估自己走过的路5.用来评定工作绩效标准 1.1给自己一个努力的理由1.强迫自己有计划有方向的努力2.用以激励和鼓舞自己和团队 统一一群人的节奏 二、为什么目标年年长？ 三、目标和任务的区别 四、怎样制定工作目标 五、怎样表述工作目标 生气是用别人的错误来惩罚自己。 二、如何分解任务 2.1 目标和任务之间的关系1.一个目标需要分解成多个任务2.一个大任务需要分解成N个小任务3.每个任务必须有一个负责人4.如果任务有交叉，主线负责人为主 2.2 任务的人接逻辑逐级向下分解 2.3 部门、个人目标如何获得公司愿景-》公司目标-》部门目标-》个人目标 2.4 分解原则1.上一级负责本级的任务分解2.负责辅导和审核下一集的任务分解 2.5 分解的层次1.业务目标逐层分解2.其它三个维度的目标在本层内具体（以BSC为例） 2.6 不同管理层级的分解动作略有不同1.管理者也分为带带多编制队伍和多岗位队伍的差异2.生产销售的基层...
10万TPS级高并发系统——10万量级文本关键字匹配过滤
一、背景简介消息发送管控平台中有个很重要的能力就是文本关键字检测，比如检测一段话中是否含有法轮功等敏感字段，这就涉及到关键字匹配算法。在该项目中每条消息都要经过关键词过滤，通过后才能下发。关键字匹配有两种形式，分为单一关键字和逻辑关键字。 1.1 单一关键字单一关键字指单个单词，如：法轮功，炸金花，一条龙服务等涉恐、涉赌、涉黄等关键字，单个的关键字在系统数据库中的数量在9万+，消息下发时需要检测文本中是否包含数据库中单个关键字。 1.2 逻辑关键字逻辑关键字由多个单一关键字组合&&、||、!逻辑运算符，即匹配到的关键字满足逻辑关键字中的逻辑运算逻辑才进行管控。 例如：逻辑关键字点击&&登录&&!验证码, 表示内容包含点击、登录关键字并且不包含验证码关键字，如果文本中包含的内容符合该逻辑，则进行拦截管控。 二、性能要求消息发送管控平台关键字整体数据规模为10万量级，其中单一关键字数量为9万，逻辑关键字数量为1万。消息管控平台的安全审核接口整体的平均响应时间为50ms。 三、方案预研我们先分析梳理常用的关键词匹配算法，再根据上述业务...
常用的关键字匹配算法
一、背景简介二、常用算法2.1. 暴力匹配算法（Brute Force）从文本的每一个可能的起始位置开始，逐个字符地与模式串进行比较。 优点： 简单易懂，容易实现。 缺点： 效率低，时间复杂度为O(m * n)，其中m为模式串长度，n为文本长度。 不适合处理大规模数据和长模式串。 适用场景： 小规模数据或者模式串较短的简单匹配场景。 性能表现： 在规模较小的情况下能够工作，但随着数据规模增大，性能迅速下降。 2.2. KMP算法（Knuth-Morris-Pratt算法） 利用前缀函数（partial match table）避免对已匹配部分的重复比较，实现跳跃式的匹配。 优点： 时间复杂度为O(m + n)，其中m为模式串长度，n为文本长度。 适用于处理大规模数据和长模式串，性能稳定。 缺点： 算法实现稍复杂，需要构建和理解前缀函数。 在某些特定情况下，性能可能不如Boyer-Moore算法。 适用场景： 需要处理长模式串或者大量数据的字符串匹配任务。 性能表现： 对于大规模数据和长模式串有较好的性能表现，常用于实际应用中。 2.3. B...
10万TPS级高并发系统——30亿级发送量频次管控（一）
一、背景简介在客户的业务场景中，需要在全局开启终端用户消息发送的频次管控，避免消息重复发送以及段时间内下发大量消息对终端用户进行信息轰炸，从而引起终端用户投诉。目前业务平台每日最高的消息发送量为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 Wind...
10万TPS级高并发系统——2亿级黑名单过滤
一、背景简介在消息发送管控平台中，黑名单过滤是保障消息发送安全的重要环节。系统需要对发送的每条消息进行黑名单检查，包括全局黑名单、账号级黑名单、投诉黑名单、退订黑名单等多种类型。在日发送量达到30亿条消息的场景下，黑名单数据规模庞大，系统需要支持2亿级黑名单数据的高效过滤。 1.1 技术挑战在2亿级黑名单数据规模下，传统的数据结构面临严重挑战： 存储方式 内存占用 查询性能 主要问题 HashMap<String,Object> ~20GB O(1) 内存占用过大，GC压力巨大 HashSet ~15GB O(1) 装箱拆箱开销，内存碎片 传统BitSet ~250MB O(1) 稀疏数据浪费严重，不支持分片 RoaringBitmap ~5-50MB O(1) 内存高效，压缩率高 核心问题：2亿个11位手机号码如果用传统HashMap存储，需要占用约20GB内存，这对系统资源是巨大的挑战。而且在高并发场景下，大量的HashMap查询会产生严重的GC问题，影响系统性能。 1.2 RoaringBitmap优势RoaringBitmap是...