自律使我自由

所谓的风险识别，主要是针对企业在运营过程中对于面向互联网的业务，可能由于运营人员的不规范操作，或系统本身存在漏洞，或业务规则存在漏洞，或被攻击，被褥羊毛等行为产生的损失。而风险识别就是为了能够快速发现、控制上述等行为的发生，尽可能的降低损失。本文将针对近些年来我们在日常的业务经营中发现的一些比较常见的风险事件进行梳理，并分享一些所采取的应对措施。

递归思维实质上体现了一种逆向推理的逻辑方式，即从最终结果回溯至初始条件。在一步步的倒推过程中，我们发现每一步要解决的问题本质上都是一样的。通过将复杂的大问题分解为多个相似的小规模子问题，进而揭示出解决问题的最基本单元，为寻找最简化的解决方案提供了有效途径。接下来，本篇文章通过几个例子带你感受下利用递归思维解决问题的魔力。

优惠券是一种使用频率最高的，用于营销类场景的工具。它有几个比较突出的特点：① 灵活易用，使用门槛低，规则简单，核算方便。② 可针对不同人群发不同券的方式，实现精细化运营，使利益最大化。③ 可承载多种多样的营销玩法，最终全部以优惠券的形式落地，比如金币-》券，积分-》券，XXX 值-》券等。④ 可快速实现以价格减免的方式完成交易，相比在定价上的调整，使用券则更简单。定价和优惠券都可以实现对价格上的调整，这里可以举一个简单的例子说明一下：假设，你是一个卖面包的，你制作了一款面包，成本价是 5 元。

解决方案也很简单了，在一开始的报错信息中已经说的很清楚了，可以用。

总之，流量治理是贯穿整个系统链路的过程，每个环节不但要各司其职，还要保证互不影响，稳定、可靠始终应当放在第一优先级来考虑，是关乎生死的问题，至于在保障稳定、可靠的前提之下，能做到多大的吞吐量，就取决于各自的能力了，从短期来看这是关乎业务能否继续扩大的问题，从长期来看，如果业务不能扩大，那一样是生死问题。

据统计2022年我国手机上网人数10.65亿人，互联网普及率为75.6%，其中农村地区互联网普及率为61.9%，居民使用互联网的平均时间为2小时42分钟，城镇居民3小时23分钟，农村居民1小时38分钟，流量的规模虽然看起来如此之大，但实际上却是被少数巨头垄断，比如微信、微博、头条、抖音等，对于大多数企业来说，能够通过自身获取流量的能力实在有限，留也留不住，买也买不起是普遍现象。所以，拥有持续的获客方式就变得非常的重要，而移动互联网时代最重要的获客方式是什么？那一定是裂变拉新，

你有没有遇到过，某天报表的数据突显异常，排查后发现原来是单位弄错了。你有没有遇到过，某组数据看起来没啥感觉，但做成报表组合到一起看问题则会非常明显。你有没有遇到过，有些凭直觉来感受的统计信息与仔细验算后的统计信息，最终得出的结论截然相反。你有没有遇到过，某些根据统计结果得出的结论看起来没问题，但总觉得哪里不对劲。我相信，只要你常看一些数据统计报表，或者会常做一些数据统计方面的工作，那你一定遇到过，大家常说数据不会骗人，但真的是这样吗？本篇文章主要就来揭秘一些既有趣、又能迷惑人的常见手段。

随着23年年末期间，各大厂争先恐后的出现的各种线上故障，一时间“降本增笑”、“开猿节流”成为了大家调侃的话题，我自己所在的公司其实也因为在年中时出现了几次线上故障，而面临着系统稳定性的考验。因此，也就想借本文跟大家分享、探讨一下到底如何才能打赢稳定性之战？

本文主要针对日常在进行代码review过程中发现的一些关于方法设计上的一些常见问题，改进这些问题能够有效的提升方法的可用性、健壮性、可维护性等方面问题。

注解的理解不深，但笔者认为在实际的业务开发中，难免会因为各种各样的原因而导致问题产生，对于一个方法的使用，不单单是要要求使用者能够完全了解，更重要的是方法本身在使用时会不会出现让使用者容易忽视的条件。反编译后发现（已过滤掉了部分无关代码内容），其实现方式就是通过。注解，就会缺少无参的构造方法，这严重违反了代码编写规范。主要是因为链式编程所带来的便捷性，实际上笔者更推荐使用。，它同样可以实现链式编程，同时还是避免多创建一个。通过反编译可以看出，问题就在于。方式构建，导致默认值丢失。对象，更重要的是可以避免。

1. 在具体应用之前，有必要先了解一下什么是Redis Bitmap？Redis Bitmap是一种数据结构，它通过比特位来记录信息，每一位都代表一个布尔值，这样它可以在一些大规模数据的存储和查询场景中比常规的记录方式更节省内存和高效。2. Redis Bitmap常用的命令Bitmap在Redis中是通过字符串实现的，每个字符串都是一个固定大小的位数组，常用的命令如下：SETBIT：设置指定偏移量上的位值。。：指定的键名。：指定的偏移量。：要设置的值，0或1。

CompletableFuture提供了一种优雅而强大的方式来处理并发请求和任务。然而，正如在处理高并发时使用过多的线程会导致资源浪费和效率下降一样，使用过多的 CompletableFuture 也会导致同样的问题。这种现象被称为 “线程调度问题”，它会导致性能下降和吞吐量下降（P99值较高）。因此，我们需要在使用 CompletableFuture 时考虑实际场景和负载情况，并根据需要使用恰当的技术来优化性能。

向内存申请，也就是说每接收到一个HTTP请求，都会向内存申请200MB的空间，所以，当请求并发上来以后，必然会导致OOM。线上OOM后，dump内存快照，通过MAT工具进行分析，如下图所示，有多个200MB的。来设置HTTP message header的大小，其默认为8KB，并通过。对象存在，这很不合理。排查相关配置后发现，被设置为200MB。

设计原则是一块比较难以理解与统一的编程规范，因为它不像其他规范一样，都有明确的准则、模板、公式等，设计原则更多的是理解，不同的人理解可能不一样，一段代码，有些人可能认为已经符合设计原则了，有些人则认为不符合，有些人认为封装的合适，有些人则认为是过度封装，所以对于设计原则更重要的应该是保持团队中的认知统一，让团队中的成员保持统一的衡量尺度，不断地提高团队的整体认知水平，这样才能充分发挥出设计原则的作用。

本文探讨了微服务架构的设计和优化，特别是在分分合合的过程中可能出现的问题，如沟通和协调问题、服务依赖关系问题、系统性能问题、部署和维护问题、集成问题和故障传播问题。针对这些问题，文章提出了链路追踪、应用架构设计优化和垂直域划分等解决方案，强调了在进行微服务改造时需要有架构演进的把控能力，并逐步完善和调整实施细节，积极听取组织内外的经验意见。

Garbage-First (G1)是一款非常具有特殊意义垃圾收集器的技术发展体现，因为相比G1之前的垃圾收集器，G1首次打破了基于老年代或者新生代一整块内存进行收集的设计思想，G1设计上依然有分代的思想，但是在内存上不再进行分代上的物理划分，也就是在一块大的内存区域中，既有年轻代也有老年代，G1适用于具有大内存的多核服务器，G1虽然与CMS一样都是追求低停顿时间的垃圾收集器，但是由于G1在设计上的突破，使其能在更大的内存空间回收时，保持优秀的垃圾回收效率，这是G1之前的所有垃圾收集器所不能做到的。

阻塞队列的设计起到了良好的缓冲作用，当面对突发流量到来时，先将任务丢到队列中，再慢慢来消费，其原理和MQ是类似的，一旦队列也被打满了，则说明消费能力与你的期望对比，已经严重不足了，此时maximumPoolSize参数的设计，又给了你一次处理的机会，你可以选择再开启一部分线程来应对突发状况，当危机接触后，再主动帮你回收这部分线程，或者选择使用拒绝策略。一个简单的任务处理，考虑各种实际运行中可能遇到的情况，对于线程池的使用者来说，也应了解线程池的任务处理流程，再结合自身的业务场景充分考虑其中的参数设置。

监控的是SIGTERM信号，SIGTERM是Linux提供的一种优雅关闭服务的方式，通过发出一个软件终止的信号来给应用程序一个缓冲的时间，相对于SIGKILL这种，就会直接杀掉进程。与Tomcat不同之处，正如官方文档中说明那样，Undertow在关闭期间对于请求会直接返回503，而Tomcat则不会。，则不会有任何提示以及等待活跃请求执行完成的行为，而是直接关闭服务。只需简单配置后，即可使用，启动服务，发起请求。输出日志中，可以看到，当发起停止服务时，打印了。，表示开始等待活跃的请求执行结束。

双键数据结构类型，底层由。实现，官方定义可以将两个。获取的API，注意无论是。，存在则直接取出，然后再。

使用Term query可以根据精确值查找相关文档数据，不过Term query查询与查询还是有区别的，有时候你会发现用可以查到，换成Term query却不行，本文整理一些使用Term query容易出错的点供参考。如果你查看Term query的官方文档，你就会发现，官网首先对Term query做了3项明确说明。避免是对text属性的字段使用Term query查询。会因为分词器的原因改变字段的值，所以如果想要精确匹配text类型的字段将会很难。如果查询text类型的字段，建议使用。

Caffeine是基于JDK1.8版本的高性能本地缓存库，它是Guava的增强版，与ConcurrentLinkedHashMap相似，支持并发，并且可以在O(1)的时间复杂度内查找、写入元素。

首先我们先明确，当没有任何设置的情况下undertow默认会获取JVM运行环境中的可用计算资源作为IO线程设置的依据（但保证最低不会少为2个），和16个工作线程。这一步是在Spring容器启动时，通过方法完成的调用方法调用方法验证一下物理机6核12线程XNIO-1 AcceptXNIO-1 I/O-1XNIO-2 I/O-1~12XNIO-2 Accept可以看出一组是12个I/O线程。线程是在执行方法的时候创建的worker线程在服务启动时并不会立刻启动，只有当真正发

前段时间线上遇到OOM问题，经排查分析发现是由于有一个接口一次性返回的数据量过多导致（大约200W个结果集），不过对于问题接口数据量虽然较多，但返回的数据只有一个长度为7的string类型的字段，所以200W条大约也就十几M，这还不至于造成OOM。直接分析无法解释导致OOM的原因了，那只有模拟了，于是本地启了一 个接口模拟返回的数据量，发现内存消耗巨大，远远超过十几M，于是将堆内存导出来分析。通过堆内存分析可以看出，原本7个字节的string类型，被包装成各种对象，并且被包装后占用空间剧增，最终达到1G多。

参数的合法性校验应该是每个接口必备的，无论是前端发起的请求，还是后端的其他调用都必须对参数做校验，比如：参数的长度、类型、格式，必传参数是否有传，是否符合约定的业务规则等等。推荐使用来快速实现一些基本的参数校验。参考如下示例：2. 接口限流在设计接口时，我们应当对接口的负载能力做出评估，尤其是提供给第三方使用时，这样当实际请求流量超过预期流量时，我们便可采取相应的预防策略，以免服务器崩溃。一般来说限流主要是为了防止恶意的Dos攻击或者爬虫等非正常的业务访问，因此一般来说采取的方式都是直接丢弃超出阈值的

1. 如何设计安全可靠的开放接口—之Token2. 如何设计安全可靠的开放接口—之AppId、AppSecret3. 如何设计安全可靠的开放接口—之签名(sign)4. 如何设计安全可靠的开放接口【番外篇】—关于MD5应用的介绍5. 如何设计安全可靠的开放接口—还有哪些安全保护措施对称加密算法是指通过密钥对原始数据（明文），进行特殊的处理后，使其变成密文发送出去，数据接收方收到数据后，再使用同样的密钥进行特殊处理后，再使其还原为原始数据（明文），对称加密算法中密钥只有一个，数据加密与解密方都必须事先

在实际开发中，肯定会经常遇到对参数字段进行校验的场景，虽然大多数情况下前端都会进行校验，但我们知道前端并不可信，所以后台也需要进行校验，通常我们只能写大量的来完成校验工作，而如果使用则可以轻松的通过注解来完成。引入Jar包使用示例注意：请求时，参数必须加上才能生效分组有些时候，同一个参数在不能场景下校验的规则可能不一样，这时候我们就可以通过分组的方式来实现实体类属性设置了两种校验，分别针对为A和B的生效只要在相对应的接口上选择A或者B即可...

文章目录【如何设计安全可靠的开放接口】系列前言AES加解密代码实现【如何设计安全可靠的开放接口】系列1. 如何设计安全可靠的开放接口—之Token2. 如何设计安全可靠的开放接口—之AppId、AppSecret3. 如何设计安全可靠的开放接口—之签名(sign)4. 如何设计安全可靠的开放接口【番外篇】—关于MD5应用的介绍5. 如何设计安全可靠的开放接口—还有哪些安全保护措施前言前面提到过，到目前为止我们已经基本上实现了一个安全可靠的开放接口设计，本节我们再来完善最后一块拼图：对业务参数

文章目录【如何设计安全可靠的开放接口】系列【如何设计安全可靠的开放接口】系列1. 如何设计安全可靠的开放接口—之Token2. 如何设计安全可靠的开放接口—之AppId、AppSecret3. 如何设计安全可靠的开放接口—之签名(sign)4. 如何设计安全可靠的开放接口【番外篇】—关于MD5应用的介绍......

前言在提到对于开放接口的安全设计时，一定少不了对于摘要算法的应用（MD5算法是其实现方式之一），在接口设计方面它可以帮助我们完成数据签名的功能，也就是说用来防止请求或者返回的数据被他人篡改。本文我们单从安全的角度出发，看看到底哪些场景下的需求可以借助MD5的方式来实现。密码存储在一开始的时候，大多数服务端对于用户密码的存储肯定都是明文的，这就导致了一旦存储密码的地方被发现，无论是黑客还是服务端维护人员自己，都可以轻松的得到用户的账号、密码，并且其实很多用户的账号、密码在各种网站上都是一样的，也就是说

文章目录【如何设计安全可靠的开放接口】系列前言前置知识【如何设计安全可靠的开放接口】系列1. 如何设计安全可靠的开放接口—之Token2. 如何设计安全可靠的开放接口—之AppId、AppSecret前言本节内容可以说是开放接口设计的关键所在，上一节在最后也提到了appId、appSecret如果没有接下来的这一步签名，将变的毫无意义，所以本节我们就来正式看看应该如何进行签名。前置知识首先，在介绍签名方式之前，我们必须先了解2个概念，分别是：非对称加密（比如：RSA）、摘要算法（比如：MD5）

文章目录前言前言前面我们介绍过了Token机制，它可以解决单点登陆、跨域等问题，避免每次都需要用户登陆，不过并不是每个对外开放的接口都是需要用户登陆的，如果是这样，那我们就要想其他的方式来对用户身份进行验证了，一般我们会使用AppId的方式，实际上你也可以认为它是一种Token机制，只不过换一个名字而已。AppId的生成......

前言Open API是会暴露到公网被访问的接口，那与内网接口最重要的区别就是如何做好安全的问题，常见的安全问题有：合法身份判别、数据防窥、数据防篡改、请求防重放、Dos攻击等等，本文针对这些安全问题整理了一些常见的应对措施。合法身份判别首先，我们先来看看如何解决身份判别的问题，身份判别最简单的方式就是让用户自己注册账号、密码，然后使用账号、密码登陆成功后再进行接口请求，但是对于Open API来说一般是没有登陆这一步操作的，所以我们就需要通过另一种方式来间接的让请求用户实现登陆。TokenToke

文章目录前言1. 一道测试题2. 如何判断null值3. Null不要进行算术运算4. 使用GROUP BY、ORDER BY5. COUNT()、 MIN()和 SUM()忽略 NULL值前言从概念上看，MySQL对Null的定义是a missing unknown value，它与空字符串''并不是一回事，MySQL对于它的处理方式也有些不同，对于初学者来说经常会把这二者混淆，本文就结合一些案例来具体看看。1. 一道测试题先从一道简单的测试题看起表名：customer，表中数据如下：mysq

文章目录前言创建一个流过滤map转换flatMap 先展开再转换distinct 去重sort 排序limit+skip 可实现分页peek 用于执行结果前后查看，方便调试collect 收集，是流的一种终止操作grouping 分组partitioning 分区reduce 使用累计函数进行归约前言Stream流式操作，针对集合、数组、函数、I/O流等提供了映射、转换、过滤、排序、聚合等一系列API，一些原本非常复杂的查询，使用Stream只需要几行代码就可以搞定，大大简化了代码的复杂度。创建一个流

文章目录1. 引入jar包2. properties配置3. 分别配置两个数据源4. Dao目录5. Entity6. Mapper文件7. Controller测试8. 结果验证1. 引入jar包pom.xml文件<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-in

【Prometheus+SpringBoot+Grafana】快速入门教程

线程池是我们平时开发中使用较多的一种组件，其主要监控点在于池中的线程和阻塞队列中的任务情况。构建一个线程池先构建一个基本的线程池，并看看有哪些参数我们可以直接获取到public class ThreadPoolMonitor { private final static Logger log = LoggerFactory.getLogger(ThreadPoolMonitor.class); private static final ThreadPoolExecutor thre

前言我相信你应该用过uptime命令查询系统负载的情况，或者在各种监控终端上看到过系统load这一项，但是每次问别人到底什么是系统load？系统load到达多少算过高？又有哪些原因会造成系统load过载？我发现很少有人能回答清楚，大多数都觉得系统load过载就表示CPU使用率过载、然而实际上并不完全这样的，本文就来仔细分析一下到底有哪些原因会造成系统load过载！uptime命令还是先来看看uptime命令，...

前言我相信你一定遇到过软件上线后出现问题，可以说每次上线应该是软件最容易出现问题的时候，所以也有各种各样预防的措施，比如充分的测试、灰度发布、上线监控、回滚方案等等，这一切都是为了尽量减少版本上线后出问题所造成的损失，一个成熟有经验的团队会非常高效的解决上线后的故障，而缺乏经验的团队遇到问题后则可能无法第一时间做出正确的判断，现在我们来对比一下，看看有哪些可以借鉴学习的地方。核心步骤1、评估影响范围2、根据影响范围确认解决方式3、复盘、持续优化评估影响范围一般而言，当上线出现问题后，作为开发人

前言在阿里开发手册中，对于线程池的使用有这样两点要求：正确的使用线程池可以减少在创建和销毁线程上所消耗的时间，所以大家都知道在使用线程时，应该构建一个线程池，然后从线程池中取线程，尽管JDK已经为我们提供了线程池，不必我们重复造轮子，但项目中还是会因为在构建线程池时，因为参数设置不正确导致生产上出现问题，本文就来分析一下JDK为我们提供的线程池中每个参数的含义以及应该如何决定设置什么样的值。JDK中线程池的核心参数定义corePoolSize核心线程数，即线程池始终保持着corePoolSize