有的时候我们那需要分析多模块 Maven 项目的依赖使用情况，并希望能够分析出这些依赖的 LICENSE 信息。使用 io.github.coolbeevip:license-maven-plugin 插件 可以生成 TXT 或者 CSV 格式的分析报告 youtube bilibili CSV 格式的报告 NOTICE.CSV NOTICE-LICENSE.CSV TXT 格式的报告 NOTICE.TXT NOTICE-LICENSE.TXT 插件 LICENSE-MAVEN-PLUGIN format 导出格式，支持 csv、txt； license 是否分析 LICENSE 信息，默认 false； ignoreGroupIds 忽略 groupId 列表, 多个用逗号分割; timeout 分析 LICENSE 的超时时间，默认 5 秒; 导出报告 在 Maven 项目的根目录执行如下命令 导出 CSV mvn io.github.coolbeevip:license-maven-plugin:1.5.0:dependency-license-export -Dformat=csv 导出 TXT mvn io.github.coolbeevip:license-maven-plugin:1.5.0:dependency-license-export -Dformat=txt 提示： 导出的报告位置在 ./target/distribute 目录下 导出报告(忽略部分依赖) mvn io.github.coolbeevip:license-maven-plugin:1.5.0:dependency-license-export -Dformat=csv -DignoreGroupIds=org.apache.servicecomb,com.github.seanyinx 导出报告(分析LICENSE) 此功能使用 selenium 从 Maven Central Repository 分析依赖的 License 信息

从源镜像仓库批量拉取镜像，并将这些镜像推送到目标镜像仓库的批量脚本 #!/bin/bash ################################################# # 使用方式 # 从源仓库拉取镜像到本机 # sh docker-images-pulling-pushing.sh pull # # 将本机镜像推送到目的仓库 # sh docker-images-pulling-pushing.sh push # # 清理本机的镜像 # sh docker-images-pulling-pushing.sh clean ################################################# # 源仓库地址 DOCKER_REPO_FROM= # 目标仓库地址 DOCKER_REPO_TO=192.168.2.2:8888/ DOCKER_REPO_TO_USER=test DOCKER_REPO_TO_PASS=Test123456 # 镜像定义 DOCKER_IMAGES=() DOCKER_IMAGES+=(postgres:9.6) DOCKER_IMAGES+=(elasticsearch:6.6.2) DOCKER_IMAGES+=(coolbeevip/servicecomb-pack) # 从源仓库地址拉取镜像到本机仓库 function pull(){ echo "Pull images from $DOCKER_REPO_FROM" for image in ${DOCKER_IMAGES[@]}; do docker pull $DOCKER_REPO_FROM$image done } # 本机镜像推送到目的仓库 function push(){ docker login http://$DOCKER_REPO_TO -u $DOCKER_REPO_TO_USER -p $DOCKER_REPO_TO_PASS echo "Push $DOCKER_REPO_FROM to $DOCKER_REPO_TO" for image in ${DOCKER_IMAGES[@]}; do docker image tag $DOCKER_REPO_FROM$image $DOCKER_REPO_TO$image docker push $DOCKER_REPO_TO$image done } # 清理本机拉取后的镜像 function clean(){ echo "Remove images" docker rmi -f $(docker images | grep $DOCKER_REPO_FROM | awk '{print $3}') docker rmi -f $(docker images | grep $DOCKER_REPO_TO | awk '{print $3}') } case "${@: -1}" in pull ) pull ;; clean ) clean ;; push ) push ;; esac

查看本机 JDK 版本 命令行输入 /usr/libexec/java_home -V 可以看到多个 JDK 版本 $ /usr/libexec/java_home -V Matching Java Virtual Machines (2): 11.0.10, x86_64: "OpenJDK 11.0.10" /Users/zhanglei/Library/Java/JavaVirtualMachines/adopt-openj9-11.0.10/Contents/Home 1.8.0_201, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home /Users/zhanglei/Library/Java/JavaVirtualMachines/adopt-openj9-11.0.10/Contents/Home 查看当前使用的 JDK 版本 $ java -version java version "1.8.0_201" Java(TM) SE Runtime Environment (build 1.8.0_201-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode) 切换 JDK 切换到 JDK 11.0.10 版本，并查看切换后的 JDK 版本 $ export JAVA_HOME=`/usr/libexec/java_home -v 11.0.10` $ java -version openjdk version "11.

下载 HAProxy Docker docker pull haproxy:2.3 创建工作目录 mkdir -p /opt/haproxy-oracle/docker_volume 在 /opt/haproxy-oracle/docker_volume 目录下创建如下 haproxy.cfg 文件，请将文件尾部的 oracle 地址和端口改为你的地址和端口 global daemon log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 4096 tune.ssl.default-dh-param 2048 defaults log global retries 3 maxconn 2000 timeout connect 5s timeout client 50s timeout server 50s listen stats bind *:9090 balance mode http stats enable stats auth admin:admin stats uri /stats listen oracle-proxy log global bind :1521 mode tcp balance roundrobin server oracle-1 10.

安装 官方建议的安装方法是从源代码编译安装，您可以从 redis.io 下载最新稳定版的 TAR 包 wget https://download.redis.io/releases/redis-6.2.5.tar.gz tar xvzf redis-6.2.5.tar.gz cd redis-6.2.5 make 此时，您可以通过键入 make test 来测试您的构建是否正常工作。编译后 redis-6.2.5/src 目录填充了一部分可执行文件。 最好将编译后的 Redis 执行文件都复制到适当的位置，或者使用以下命令手动复制（假设我们的安装路径是 /usr/local/redis）： # 可执行文件 sudo mkdir -p /usr/local/redis/bin sudo cp src/redis-server /usr/local/redis/bin sudo cp src/redis-cli /usr/local/redis/bin sudo cp src/redis-sentinel /usr/local/redis/bin sudo cp src/redis-benchmark /usr/local/redis/bin sudo cp src/redis-check-aof /usr/local/redis/bin sudo cp src/redis-check-rdb /usr/local/redis/bin # 配置文件 sudo mkdir -p /usr/local/redis/conf sudo cp redis.conf /usr/local/redis/conf sudo cp sentinel.conf /usr/local/redis/conf # 数据目录 sudo mkdir -p /usr/local/redis/data sudo mkdir -p /usr/local/redis/log # 创建链接 sudo ln -s /usr/local/redis/bin/redis-server /usr/bin/redis-server sudo ln -s /usr/local/redis/bin/redis-cli /usr/bin/redis-cli 提示： 复制完毕后，您可以删除 redis-6.

当 Redis 用作缓存时，通常可以方便地让它在您添加新数据时自动驱逐旧数据。Redis 支持 6 种驱逐策略，你可以使用 maxmemory-policy 修改驱逐策略。默认是不驱逐，也就是说如果使用的内存超过了 maxmemory 限制，将提示 OOM。 你可以在 redis.conf 通过 maxmemory 2gb 设置，也可以通过 config set maxmemory 2gb 方式动态设置，注意： 在64bit系统下，maxmemory设置为0表示不限制内存使用，在32bit系统下，maxmemory不能超过3GB 驱逐策略 noenviction: 禁止驱逐数据(默认淘汰策略) 当 redis 内存数据达到 maxmemory，在该策略下，直接返回OOM错误； volatile-lru: 驱逐已设置过期时间的内存数据集中最近最少使用的数据； volatile-ttl: 驱逐已设置过期时间的内存数据集中即将过期的数据； volatile-random: 驱逐已设置过期时间的内存数据集中任意挑选数据； allkeys-lru: 驱逐内存数据集中最近最少使用的数据； allkeys-random: 驱逐数据集中任意挑选数据； volatile-lfu 驱逐已设置过期时间的内存数据集中使用频率最少的数据；（since 4.0） allkeys-lfu 驱逐内存数据集中使用频率最少的数据；（since 4.0） 如果 KEY 未设置过期时间，那么 volatile-random、volatile-ttl 和 volatile-lru 等同于 noenviction。 驱逐程序如何运作 重要的是要了解驱逐过程的工作方式如下： 客户端运行新命令，导致添加更多数据。 Redis 检查内存使用情况，如果大于 maxmemory limit ，则根据策略驱逐键。 执行新命令，等等。 所以我们不断地越过内存限制的边界，越过它，然后通过驱逐键返回到限制之下。 如果某个命令导致使用大量内存一段时间，则内存限制可能会明显超出。

常用 Kafka 命令 Topics 查询 topic 列表 ./bin/kafka-topics.sh --bootstrap-server 127.0.0.1:9092 --list 查看 topic 描述 ./bin/kafka-topics.sh --bootstrap-server 127.0.0.1:9092 --describe --topic my-topic Consumer Groups 查询消费组列表 ./bin/kafka-consumer-groups.sh --bootstrap-server 127.0.0.1:9092 --list 查询指定的组各 topic 消息消费情况 ./bin/kafka-consumer-groups.sh --bootstrap-server 127.0.0.1:9092 --describe --group my-group

常用 MySQL 命令 连接数配置 查看允许的最大连接数 show variables like '%max_connection%'; 如果过去曾达到此限制，则可以使用以下方法检查 SHOW GLOBAL STATUS LIKE 'max_use%'; 配置用户的最大并发连接数 GRANT USAGE ON *.* TO 'repl'@'%' WITH MAX_CONNECTIONS_PER_HOUR 100 MAX_USER_CONNECTIONS 10; 查看用户的最大并发连接数 SELECT User, Host, max_connections, max_user_connections FROM mysql.user; 设置最大连接数 set global max_connections=1000; 查看当前连接数 show status like 'Threads%'; Threads_cached 当前线程池中缓存有多少空闲线程 Threads_connected 当前的连接数 ( 也就是线程数 ) Threads_running 已经创建的线程总数 Threads_created 当前激活的线程数 ( Threads_connected 中的线程有些可能处于休眠状态 ) thread_cache_size 值过小会导致频繁创建线程，直接反映就是 show status 查看 Threads_created 值过大。 当 Threads_cached 越来越少 但 Threads_connected 始终不降 且 Threads_created 持续升高 这时可适当增加 thread_cache_size 的大小

本文整理构建Maven项目和模块的最佳实践的关键事项，其中包含依赖、版本、属性、模块划分等关键因素，推荐使用 Maven 3.6.3 及以上版本。 为了便于理解，我们假设有一个 API 网关项目，这个网关项目包含服务端、客户端、通知服务端支持插件。 目标 通过多模块方式组织项目 管理项目版本、依赖，属性 规划模块依赖关系 主项目 POM 每个项目都应该在项目根目录下有一个主 POM 文件，并通过主 POM 文件管理下级子模块。在主 POM 中至少会使用一下标签 properties: 定义字符集编码、JDK 版本、插件版本; modules: 下级子模块; pluginRepositories: 插件仓库地址（非必须，主要解决国内访问慢的问题）; repositories: 定义 Maven 私服地址; distributionManagement: 定义发布用 Maven 私服地址 pluginManagement: 定义管理类插件版本 profiles: (非必须) 例如： <?xml version="1.0" encoding="UTF-8"?> <build xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.coolbeevip.apigateway</groupId> <artifactId>apigateway-parent</artifactId> <version>${revision}</version> <packaging>pom</packaging> <properties> <!-- 使用 revision 管理项目版本 --> <revision>1.0.0-SNAPSHOT</revision> <!-- project --> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncodi ng>UTF-8</project.reporting.outputEncoding> <maven.compiler.encoding>UTF-8</maven.compiler.encoding> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <!-- plugins version --> <maven-compiler-plugin.

压缩合并 Commits，将多个 commit 整理合并的方法，这样可以使提交记录更加清晰 查看提交记录，选择你要合并的范围 git log commit 6d757f70af289b5a90d00bd5e4b93d892d64a258 (HEAD -> SCB-1669) Author: Lei Zhang <zhanglei@apache.org> Date: Thu Dec 19 13:53:26 2019 +0800 SCB-1669 Fixed reverse compensation sort bug in FSM commit 37e0c5d99d0e6dae188cbd78f543ba69433b928f (origin/SCB-1669) Author: Lei Zhang <zhanglei@apache.org> Date: Thu Dec 19 02:00:20 2019 +0800 SCB-1669 Fixed Reverse compensation sort bug in FSM commit b4ea8717a86d1eba1956d21727d05c466ff6d8a2 (upstream/master, origin/master, origin/HEAD, master) Author: Lei Zhang <zhanglei@apache.org> Date: Tue Dec 10 16:25:48 2019 +0800 SCB-1658 Improve encapsulation on txEntityMap of SagaData 可以看到最后两次提交，都是为了修复 SCB-1669 这个问题，此时我想合并最后两次提交 6d757f70af289b5a90d00bd5e4b93d892d64a258 和 37e0c5d99d0e6dae188cbd78f543ba69433b928f