逐光の博客

一、背景简介在搭建个人博客或站点时，为方便用户记住访问站点，我们大多站点管理者会使用域名进行网站的访问。 二、域名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.生产销售的基层...

一、背景简介消息发送管控平台中有个很重要的能力就是文本关键字检测，比如检测一段话中是否含有法轮功等敏感字段，这就涉及到关键字匹配算法。在该项目中每条消息都要经过关键词过滤，通过后才能下发。关键字匹配有两种形式，分为单一关键字和逻辑关键字。 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...

一、背景简介在客户的业务场景中，需要在全局开启终端用户消息发送的频次管控，避免消息重复发送以及段时间内下发大量消息对终端用户进行信息轰炸，从而引起终端用户投诉。目前业务平台每日最高的消息发送量为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...

一、背景简介在消息发送管控平台中，黑名单过滤是保障消息发送安全的重要环节。系统需要对发送的每条消息进行黑名单检查，包括全局黑名单、账号级黑名单、投诉黑名单、退订黑名单等多种类型。在日发送量达到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是...

一、压测准备1.1 系统背景消息发送管控平台需要支持10万TPS的接口调用，要求单次请求处理耗时在50ms以内。系统采用集群化部署，通过弹性负载均衡实现高可用和性能扩展。 核心技术指标： 目标TPS：10万 响应时间：≤50ms 日发送量：30亿条 平均发送速度：3.47万条/秒 1.2 压测环境 组件 规格配置 数量 管控API服务 16核/32GB/500G高IO 15节点 Redis集群 256G/32分片 32实例 MySQL数据库 16核/32GB/1TB超高IO 主从 负载均衡器 中型II/500M带宽 1台 压测客户端 8核/16GB 3台 1.3 压测工具选型选用 JMeter 作为压测工具： 支持高并发场景 可视化报表 分布式压测 插件丰富 二、压测方案设计2.1 压测场景场景一：基础功能压测 并发用户数：1000 → 3000 → 5000 持续时间：每阶段10分钟 目标：验证基础性能 场景二：峰值压测 并发用户数：5000 持续时间：3...

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

一、概念简介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 Avail...