背景在上一家公司，订单的状态有很多，都是在需求日益增加的条件下，衍生出来的，待支付，待发货，已发货，用户取消，后台取消，批处理取消，上级审核取消等这些业务其实是破坏了订单状态的初始的设计的，并且在日后的维护中，很难达到一个统一的状态，不知道在哪里就触碰了业务的红线，所以，本着简单就是高效的方式，我这收拢公司这些业务的时候，用到了状态机模式，这里就是标题所示的，cola-statemachine 的

1、生成 GUIDhttps://www.guidgen.com/ 2、拼接地址http://127.0.0.1:8888/%7BGUID%7D 3、下载 winy 运行的插件并运行https://github.com/ilanyu/ReverseProxy/releases/tag/v1.4 4、在 setting 那里找到激活的位置

规则引擎概述 规则引擎，全称为业务规则管理系统，英文名为 BRMS(即 Business Rule Management System)。规则引擎的主要思想是将应用程序中的业务决策部分分离出来，并使用预定义的语义模块编写业务决策（业务规则），由用户或开发者在需要时进行配置、管理。需要注意的是规则引擎并不是一个具体的技术框架，而是指的一类系统，即业务规则管理系统。目前市面上具体的规则引擎产品有：dr

既然在触发 full gc 的时候，年老代和持久代都会被清理，那么为什么还会出现 oom 问题？而且对于强引用，当内存空间不足，java 虚拟机宁愿抛出 oom 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题； 那么 full gc 机制的存在有何意义？还是说 fgc 主要针对的是驻扎在老年的的软引用？ 既然如此，对于四种引用的方式如何抉择？总不能所有对象都创建引用队列使

问题现象 订单服务器链接不上，超时。 没有熔断措施，导致其他上游服务超时。 服务器雪崩，整个环境不可用 项目目标 解决线上问题，排查问题，找到具体代码 分析 JVM 关键事项 使用 Visualvm 分析 下载 dump 文件，分析 dump 文件 基础环境：Java1.8 版本，IDEA， 复现问题 问题的主要就是对象在频繁的申请，频繁的放入，导致堆被撑爆 编写对应的代码，其实对应

1、项目背景 上一家离开的公司，使用的技术是 springcloud 的技术，日志是分散在各处的。当时的技术经理，让我搭建一套属于公司自己的日志系统，我做了相应了调研。有了以下的几个方案。 阿里日志系统，自带，可集成 开源的框架 Plumelog 传统的 ELK 2、方案分析 分析以上的框架和成本，最终决定用 plumelog 日志做就够用 每天线上的日志没有那么多，仅仅在商品大卖的时候

项目背景 快速启动一个注册中心在本地 单机 Nacos 镜像docker run --name nacos-standalone -e MODE=standalone -d -p 8848:8848 -p 9848:9848 -p 9849:9849 nacos/nacos-server:2.0.0 单机 Nacos 镜像-Mysql 启动参考： 注意，这里面会用到.env 这个环境变量，记

项目背景 跑起来一个单体的 Redis 容器 单机 Redis 镜像docker run -itd --name redis -p 6379:6379 redis --requirepass '521521'

项目背景 快速跑起来一个 Mysql 的镜像 单机 Mysql 镜像 5.7 版本 docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=521521 --name mysql -v /app/docker/mysql/my.cnf:/etc/mysql/my.cnf -v /app/docker/mysql/db:/var/lib/mysql m

项目背景 经常要找一些 Docekr 的基础命令，这里面作一个总结 项目目标 了解&熟悉 Docker 的一些命令 具体细节 查看当前 docker 有多少镜像 docker images 查看当前服务有多少容器 docker ps -a docker 容器启动 # 举个例子 docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWOR