小五的个人杂货铺

基于(robfig_cron开发一个小工具)包: https://github.com/robfig/cron123go get github.com/robfig/cron/v3@v3.0.0import "github.com/robfig/cron/v3" util123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104package utilimport ( "github.com/pkg/errors" cron "github.com/robfig/cron/v3" "sync")// Crontab crontab managertype ...

背景 /var/opt/gitlab所在磁盘资源不足，现在希望将其无感迁移到**/data/opt/gitlab** 软链接方案停止 GitLab 服务1sudo gitlab-ctl stop 迁移数据到新盘目录12sudo mkdir -p /data/opt/gitlabsudo rsync -av --progress /var/opt/gitlab/ /data/opt/gitlab/ rsync 会保留文件权限和软链接，比 cp 安全。 rasync执行完后，使用diff指令确认下是否一致，如果不一致，则使用rsync继续进行迁移，直至无差异 备份原目录（以防回滚）1sudo mv /var/opt/gitlab /var/opt/gitlab.bak 建立软链接1sudo ln -s /data/opt/gitlab /var/opt/gitlab 权限检查1sudo chown -R git:git /data/opt/gitlab GitLab 默认用户是 git，如果你有改过...

首先，Optional是一个容器，用于放置可能为空的值，它可以合理而优雅的处理null。 不合适的使用方式 直接使用 isPresent() 进行 if 检查 -- isPresent()一般用于流处理的结尾，用于判断是否符合条件。 在方法参数中使用 Optional public void getUser(long uid, Optional<> userType); -- X 直接使用 Optional.get -- 和不做任何空判断一样，十分危险 使用在 POJO 中 -- 给序列化带来麻烦 记录一些API12345678910111213141516171819202122232425262728291. empty()返回一个Optional容器对象，而不是 null。建议常用⭐⭐⭐⭐2. of(T value)创建一个Optional对象，如果 value 是 null，则抛出 NPE。不建议用⭐⭐3. ofNullable(T value)同上，创建一个Optional对象，但 value 为空时返回Optional.empty()...

问题记录 最后的结果Flux、Mono一定要作为方法返回值，因为响应式编程的异常信息保存在这些结果中（而不是在方法调用时抛出），所以这些结果必须作为方法返回值，否则Spring无法知道方法是否报错 常用api记录 如果要操作数据,并返回一个Mono的时候,使用flatMap 一般如果不操作数据,仅数据转换,使用map 订阅者是由Spring框架去完成,我们(开发)写发布者代码 zipWith方法可以组合两个Mono/Flux，并返回新的Mono/Flux类型 take(x)适合取flux中前x个,而当flux就一个元素的适合,可以使用next()将flux转为mono flatMapMany适合将Mono<数组/集合>转换为Flux 当希望合并多个流操作的时候,可以使用Mono.zip/Flux.zip Mono.zip(memberLevelMono, giftCardMono, couponMono).map... zipWith方法会同时请求待合并的两个Mono数据，而zipWhen方法则会阻塞...

通过打开全局 Operator 堆栈追踪 未开启之前 开启之后 这种方法同等与在方法内部输出以下代码1234//打开Hooks.onOperatorDebug();//关闭Hooks.resetOnOperatorDebug();

在使用mvc编程方式下,全局异常拦截可使用如下方式123456789101112131415/** * @author 小五 */@Slf4j@RestControllerAdvice@RequiredArgsConstructorpublic class DefaultExceptionHandlerConfig { @ExceptionHandler(BeHappyException.class) //@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ResponseEntity beHappyExceptionHandler(BeHappyException e){ log.error("BeHappy Exception: {}",e.getMsg()); return ResponseEntity.internalServerError().body(e); }} 在使用路由...

$GOPATH默认位置 操作系统 默认路径示例 环境变量表示法 macOS /Users/用户名/go $HOME/go Linux /home/用户名/go $HOME/go Windows C:\Users\用户名\go %USERPROFILE%\go not a valid zip filegithub.com/shirou/gopsutil/process: zip: not a valid zip file 此类问题多是因为GOPROXY所导致。 使用https://mirrors.aliyun.com/goproxy/,direct的时候，在进行go build/go mod tidy等指令时就会出现此错误。 换成https://goproxy.cn,direct即可。 123456789101112131415161718192021$ mkdir go-example && cd go-example#GO111MODULE=on，使用go module，不使用GOPATH#GO111MODULE=off，使用GO...

Go性能优化 测试代码: https://github.com/behappy-project/behappy-url-shortener Go语言项目中的性能优化主要有以下几个方面： CPU profile：报告程序的 CPU 使用情况，按照一定频率去采集应用程序在 CPU 和寄存器上面的数据 Memory Profile（Heap Profile）：报告程序的内存使用情况 Block Profiling：报告 goroutines 不在运行状态的情况，可以用来分析和查找死锁等性能瓶颈 Goroutine Profiling：报告 goroutines 的使用情况，有哪些 goroutine，它们的调用关系是怎样的 采集性能数据Go语言内置了获取程序的运行数据的工具，包括以下两个标准库： runtime/pprof：采集工具型应用运行数据进行分析 net/http/pprof：采集服务型应用运行时数据进行分析 pprof开启后，每隔一段时间（10ms）就会收集下当前的堆栈信息，获取各个函数占用的CPU以及内存资源；最后通过对这些采样数据进行分析，形成一个性能分析报告。...

前言开发人员写的常常是“单元测试”，但其实可以细分成 单元测试 和 集成测试 两个。 划分的原因拿常见的 Spring IoC 举例。Spring 不同Bean之间相互依赖，例如某API业务逻辑中会依赖不同模块的 Service，Service 方法中又可能依赖不同的 Dao 层方法，甚至还会通过 RPC、HTTP 调用外部服务方法。这给我们写测试用例带来了难度，本来只想测试某个方法的功能，却要考虑一连串的依赖关系。 单元测试 单元测试：是指对软件中的最小可测试单元进行检查和验证。 通常任何软件都会划分为不同的模块和组件。单独测试一个组件时，我们叫做单元测试。单元测试用于验证相关的一小段代码是否正常工作。单元测试不是用于发现应用程序范围内的 bug，或者回归测试的 bug，而是分别检测每个代码片段。 单元测试不验证应用程序代码是否和外部依赖正常工作。它聚焦与单个组件并且 Mock 所有和它交互的依赖。例如，方法中调用发短信的服务，以及和数据库的交互，我们只需要 Mock 假执行即可，毕竟测试的焦点在当前方法上。 单元测试的特点： 不依赖任何模块。 基于代码的测试，不需要在 A...

Kustomize 现代化使用教程与最佳实践为什么选择 Kustomize？Kustomize 是 Kubernetes 原生的配置管理工具（自 k8s 1.14 起内置于 kubectl）。与 Helm 的模板引擎（Template）不同，Kustomize 采用 Overlay（叠加） 的机制。 无模板（Template-free）：不需要学习复杂的模板语法（如 Go Template），直接操作原生的 YAML。 声明式（Declarative）：所有的修改都通过 YAML 文件声明，非常适合 GitOps 工作流。 基础与覆盖（Base & Overlay）：维护一份基础配置（Base），通过补丁（Overlay）派生出开发、测试、生产等不同环境。 核心概念与目录结构一个符合现代最佳实践的 Kustomize 项目结构如下： 1234567891011121314151617181920212223~/my-project├── base # 【基础层】存放通用的资源定义 ├── app ...