cab5的博客

磁盘空间不足导致服务无法访问，docker导致磁盘空间不足，docker system prune 清理空间

对OAuth2.0中的四种模式以及涉及到的四种角色进行梳理

为了能够更方便、更直观的让Boss，让同伴，让自己了解到自己近期的工作情况，我拉了一个小队，利用农闲的时间，结合已有的项目管理系统中的数据，开发了一个新系统，名叫 “鹿蜀”。所谓行动就是版本迭代，每个版本迭代都会有一个负责人和一个行动代号。用来展示行动中的开发任务，测试任务，以及出现的Bug。用来展示行动中的每个人的开发任务，以及产出的Bug数量。按月/季度统计，这个月/季度所有的开发任务，测试任务，以及产出了多少个Bug。按月/季度统计，每个开发在这个时间段内，所有的开发任务以及产出的Bug。基于

int 整数相乘溢出问题

最近在将 fastjson 用 jackson 进行替换的过程当中，出现了 “com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException, message: Unrecognized” 的问题。该问题出现的原因是由于 JSON 里面包含了实体没有的字段而导致了反序列化的失败，如下图：如果我们把 content 中的 gender 字段去掉，就能正常运行了，如下图：这里有两个解决方案，如下：将 ObjectMapper 的 Deseria

如上图，最终总结为以下 3 点：与（&）都为 1 结果为 1，其他都为 0或（|）只有存在 1 个 1则结果为 1，其他都为 0异或（^）相同则结果为 0，不同则结果为 1

一、前言起初的想法是基于自己制定的规则整一套的状态码体系，可是后来发现，因为这套规则是自己制定的，应用范围非常有限，不具有通用性，会对新接触的人产生一定的理解和学习成本。而后，得到网上一些建议的启发，想到可以结合已得到大众认可且都熟悉的「HTTP状态码」来建立状态码体系。二、设计方案该状态码体系，主要分为以下两个部分组成：HTTP状态码（HTTP Status Code）这部分就是 Http Response 中的 status。主要用来标识与业务无关的情况，例如：参数校验错误（400）、请求

清除无用的importoption + commod + o

前言最近由于 log4j2 的漏洞问题，让我对 log4j 和 log4j2 的区别有了一些认识，这里做个简单的记录。首先引用官网的一段原文，如下：End of Life On August 5, 2015 the Logging Services Project ManagementCommittee announced that Log4j 1.x had reached end of life. Forcomplete text of the announcement please see

问题产生的原因是 JDK 版本太低，我们可以通过以下三个步骤来检查 JDK 的版本并进行调整，如下：检查 IDEA 中 JDK 的设置检查项目中 JDK 的设置检查模块中 JDK 的设置

TPS（Transactions Per Second）中文翻译“每秒事务处理量”，即服务器每秒处理的事务数。TPS 中的 T 包含 「消息接收」、「消息处理（例如：数据库操作）」、「响应」 三个步骤，即一个完整事务。QPS（Query Per Second）是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应...

一、screw 是什么screw 是一个简洁好用的数据库表结构文档的生成工具，支持 MySQL、Oracle、PostgreSQL 等主流的关系数据库。仓库地址是：https://github.com/pingfangushi/screwscrew 生成的文档有 HTML、Word、Markdown 三种格式，如下：HTML：Word：Markdown：二、screw 快速入门本文的内容是基于 screw 的 maven 插件（screw-maven-plugin）来生成数据库

一、前提本方案是基于 「微信非付款码支付」 进行设计的。二、业务场景首先，大家先大概了解下「预约」和「取消预约」两个流程。预约取消预约三、遇到的问题试想如下场景：用户预约，拉起微信支付后选择支付，但是在支付回调通知前，用户又发起了取消。此时该如何实现取消逻辑呢？此时，订单的状态处于 “待支付”，是允许取消还是不允许取消呢？首先，说下 “不允许取消” 这种情况在业务上是不可能成立的，为什么这么说呢？因为，只有那些处于 “支付中” 状态的订单不允许取消才合理，而我们只有 “待支付”、

BFF，即 Backend For Frontend（服务于前端的后端），我的理解是为了某个特定的前端提供针对性的API 接口，并在服务端直接进行业务逻辑的处理，又称为用户体验适配器。BFF 只是一种逻辑分层，而非一种技术，如下图：...

一、概念PO【persistant object】持久对象，对应数据库的表。BO【persistant object】业务对象，将业务逻辑封装成一个对象。可以理解为 PO 的组合，例如：我们可以以教育经历、工作经验、社会关系作为 PO，将这三者封装成一个简历（BO）。DTO【Data Transfer Object】数据传输对象，用在需要跨进程或远程传输时，不包含业务逻辑。DTO 可以隐藏 server 端的表结构，例如：一个 PO 100 个属性，DTO 只返回其中的 10 个属性。客户端如

一、概述TCP 协议与 UDP 协议同属于传输层的协议。二、TCP 数据包的大小我们通过下图来进行说明：通过上图我们可以知道TCP数据包（Header+Data）总长度为1480字节。三、TCP 数据包的编号一个 TCP 数据包大概 1400 多个字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送 7100 多个包。发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收方按照顺序还原（万一发生丢包，也可以知道丢失的是哪

一、概述对于日志的提交一直都没有形成一个很好的规范（每次提交都比较随意：<），最近看到一篇文章，里边有一章节介绍了一种写法规范（感觉还不错:>），从该文得知当前业界比较广泛应用的是 Angular Git Commit Guidelineshttps://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines二、具体格式<type>: <subject>&l

OSI参考模型OSI（Open System Interconnect），即开放式系统互联。TA 是 ISO（国际标准化组织）组织在1985年研究的网络互连模型, 一般叫 OSI 参考模型。OSI 的推出主要是为了更好的使网络应用更为普及，通过推荐所有公司使用 OSI 参考模型来控制网络，这样，所有公司就可以依据相同的规范，来实现互联了。OSI 定义了七层网络互联的架构（如下表格），每一层都有自己负责实现的功能和协议OSI层功能协议设备描述第七层应用层文件传输、电子邮件

经常会听到 “标准HTTP协议是无状态的、无连接的” ，这里有几个关键词“标准 HTTP 协议”、“无状态的”、“无连接”，既然有“标准HTTP协议”，那“非标准HTTP协议”又是啥呢？“无状态的”、“无连接的”又该怎么理解呢？首先标准的 http 协议指的是不包括 cookies, session，application 的 http 协议，也就是说 cookies, session，application 不属于标准协议。那“无状态的”、“无连接的”又该怎么说呢？标准HTTP协议标准HTTP协

首先要告诉大家的是，Idea 本身没有提供删除自定义 Archetype 的功能。而我们要是想删除那些已不用的自定义 Archetype，就只能通过操作配置文件（UserArchetypes.xml）了：(下面，我来讲一下如何删除自定义 Archetype。其实也很简单，只要找到 UserArchetypes.xml 文件，然后将该文件中不用的 Archetype 删除，重启 Idea 就好了。我用的是 MAC，Idea 是 IntelliJIdea2019.3，UserArchetypes.xml 的路

对于日志输出我们使用的是 logback，日志写入的方式采用的是比较常用的同步写入文件（即 RollingFileAppender），logback-spring.xml 配置如下：<?xml version="1.0" encoding="UTF-8"?><configuration> <!-- 日志保存路径为/logs --> <substitutionProperty name="log.base" value="logs"/>

场景在实际工作当中，我们偶尔会碰到一个方法要返回1个以上返回值的情况，例如：一个方法要同时返回name=“kaka”,age=18。这该怎么解决呢？解决方案通常有以下几种解决方案：将返回值放入List中，List作为方法的返回值返回将返回值放入Object数组中，数组作为方法的返回值返回将返回值放入Map中，Map作为方法的返回值返回定义一个Class，返回值作为该Class的属性，该Class作为方法的返回值返回可能大部分人都跳不出以上 4 种解决方案吧？其实还有另外一种方式，那就是采

现象上周线上出了一个问题，现象如下：前端的出现了很多的访问超时后台服务（3个节点）没有任何报错信息后台日志偶尔还是会看到进来的前端请求日志（说明服务端还是会接受请求，并处理请求，就是很慢）后台服务容器内资源的使用情况都处于正常状态由于其他业务产生了大量消费不了的消息循环请求后台服务（3个节点）重启服务（3个节点），开始的时候问题貌似被解决了，前端能够正常接收到后台的返回，但是过了一段儿时间，就用不行了现象分析通过不停的有大量日志刷入（消费不掉的消息不停的请求后台造成的），怀疑是否因为

背景上周线上出了一个问题，现象如下：前端的出现了部分请求访问超时后台服务（3个节点）没有任何报错信息处理通过查看 3 个节点上后台服务的日志，发现由于定时调度策略的问题致使所有的任务都被调度到了同 1 个节点上，而另外 2 个节点则无定时任务运行。针对这个现象，猜测是这个运行定时任务的节点出现了问题，致使被分发到该节点上的请求无法正常返回。为了快速解决线上的问题，抱着试一试的心态重启了该节点上的服务。感谢上帝爸爸，一切回归正常了（长舒了一口气~~）。分析表面上问题貌似被解决了，但是真的是解