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

在业务开发中经常遇到限流场景，本文主要介绍四种经典的限流算法：固定窗口计数器、滑动窗口计数器、漏桶算法、令牌桶算法，在做限流的场景时可以借鉴这几种经典的限流算法，掌握其使用场景级优缺点。 一、固定窗口计数器（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实现分布式S ...

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

一、高效执行与持续优化1.1 独立人格 独立承担责任 独立坚守原则 1.2 什么是执行力以规则为标注，第一时间把目标变成结果的行动。 1.3 预见结果的4A工具1.目标（Aim）2.指标（Advocacy）3.行动措施（Action）4.承诺（Acceptance） 1.4 执行的是三种状态 机械执行：只看行为是否发生 热情执行：看行为质量如何去做 同理执行：按照需求倒退实施 1.5 任务与结果的三大区别任务是三事 例行公事：该走的程序都走了 完成差事：该做的行动都做了 敷衍了事：该干的任务都干了 结果是三有 有时间：凡事有期限 有价值：凡事被需要 有证据：凡事能检查 二、如何做执行人才2.1 执行人才的特点百分百责任1.客户、领导、同事、岗位 2.2 执行团队是那个统一 统一思想：把需求和目标进行结合 统一声音：声音一致，避免杂音 统一动作：以思想和声音统一为前提 2.3 主动反馈的六大时机 任务执行完后 阶段性结果完成后 执行中遇到困难需要领导支持 执行中遇到更好的资源、机会、信息 领导格外关注的环节完成后 例行反馈 2.4 执行人才的三大素养 服从 主动 自律 2 ...

一、背景简介Prometheus由于对云原生的优秀的支持，成为各企业上云监控选型的首选，本文主要介绍Prometheus监控指标采集后图表的配置。 Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。详见：Prometheus简介 二、监控指标数据Prometheus使用Pull模式主动拉取监控数据，在应用内部我们实现监控指标数据采集并暴露一个数据采集端口，在Prometheus服务侧配置监控指标采集任务进行监控数据采集（Prometheus默认15s采集一次监控数据）。 指标数据格式 在spring-boot应用中，默认监控采集路径为： http://172.16.1.15:31744/actu ...

最近几年读了一些书，经历了一些事，想清楚了一些事，这篇文章记录日常中能够引起共鸣的一些名言名句以及自我的一些思考、认知和感悟。 一、名言名句幸福不是拥有你想要的，而是想要你已经拥有的。 灵魂所需的必需品，一件也不需要用钱去买。把目光朝向内心，你就会看到，你心中有千个地区尚未被发现。到这些地方去旅行吧，成为内心宇宙志的专家。 高山仰止，景行行止，虽不能至，心向往之。 让时光在指尖转动。 视此虽近，邈若山河。 曾国藩座右铭：物来顺应，未来不迎，当时不杂，既过不恋。 世上只有一种英雄主义，就是在认清生活真相之后依然热爱生活。 回头看，轻舟已过万重山；向前看，长路漫漫亦灿灿；抬头看，万里明灯照人间；低头看，脚下黄士千年绵；人心看，满腔热血为国燃； 世人慌慌张张，不过是图碎银几两；偏偏这碎银几两，能解世间万般惆怅。 牢骚太盛防肠断，风物长宜放眼量。——毛泽东 真正美丽的东西从不刻意求关注，美一旦自知便容易滑向造作。 一个人所说的必须真实，但没有义务把所有的真实都说出来——康德 向阳而生，逐光而行；心有暖阳，满目芬芳，何惧人生沧桑。 父爱则母静，母静则子安，子安则家和，家和万事兴；父恶则母苦， ...

1.背景简介本文主要介绍常见的文本分类算法模型及其优缺点，下面关键收集自互联网，按需获取。 2.文本分类模型在文本分类中，有多种模型可以进行选择，如果您不知道选哪个，可以选择CNN 进行尝试，兼顾了运行效率和最终结果。以下是模型的说明，您可以根据自己的具体场景，选择一个更适合的模型。 FastText : 分类模型速度快，计算资源要求低，适合样本数量大、类别标签多，适合不需要太多语义理解的任务。 CNN: 分类模型相比FastText 模型，CNN 适用复杂度更高的场景，可捕捉更多、更广、更细致的文本特征，适合需要一定语义理解的任务。对比FastText 通常效果要好一些，但训练时间也会更长。 Self-Attention: 分类模型相比FastText 模型，Self-Attention 适应复杂度更高的场景，可捕捉更多、更广、更细致的特征；跟CNN 相比，能更好地捕捉文本里的长期依赖。适合需要一定语义理解的任务。训练时间跟效果跟 CNN 类似。 BERT: 小样本分类模型，主要原理为使用 BERT模型 从大量无标注语料进行预训练。适用于标注语料有限的场景，训练和预测时间较长 ...

背景简介JMeter是我们日常开发中最常用的压测工具，我们经常会直接在本地启动JMeter对本地或远程应用进行简单的压测。但是这种压测场景下得出的压测结果并不严谨，受以下两方面影响： 本地机器硬件配置差，压测中本机的性能最先达到瓶颈 本地机器和远程服务端网络延时较高，导致压测性能比预期差所以我们做一些简单的验证可以在本地直接启动JMeter进行压测，但是如果要做真实的性能测试，需要使用专用的压测服务器对服务端应用进行压测。而压测服务器一般都是Linux系统，所以需要在Linux系统上使用JMeter进行操作。 JMeter配置下载JMeter压测工具登录Linux压测服务器，下载JMeter压测工具，官网下载地址。 curl -O https://dlcdn.apache.org//jmeter/binaries/apache-jmeter-5.6.2.zip 注意：请确保压测服务器已经安装了JDK1.8 解压并配置JMeter 说明：配置JMeter环境变量是为了方便在任意路劲下使用jmeter命令，如果不配置环境变量， ...

问题背景在k8s环境下部署应用，在web页面根据时间条件查询数据，无法查询到数据。但是在查询条件的范围内，是有数据插入到数据库的。查看数据库表中的记录发现数据库中的时间比北京时间晚了8小时。很明显这是一个时区问题，关于时区的配置，包括有以下几个部分： MySQL数据库服务器的时区设置 MySQL数据库时区配置 JDBC数据库连接的时区配置 应用服务器时区配置 应用容器的时区配置 问题排查出现时区不一致的情况主要是由于应用层和数据库层的时区不一致导致，所以问题的排查主要围绕应用和数据的时区配置。 服务器时区首先我们先确认各个服务器的时区，确认服务器的时区一致命令：date 或者是 date -R,可以确认服务器的时间均为东八区时间CST。 [root@host-172 ~]$ date 2023年 11月 15日 星期三 21:19:02 CST [root@host-172 ~]$ date -R Wed, 15 Nov 2023 21:19:06 +0800 数据库时区在确认服务器时区后，进一步确认数据库的时区，在数据库执行下面命令： show variables like ' ...