Hikari 线程参数和数据库连接池参数对业务吞吐率的影响分析 场景 本例中我们使用 Undertow 作为 Web 容器，使用 Hikari 作为数据库连接池， 并通过 spring.datasource.hikari.maximum-pool-size 和 server.undertow.threads.worker 两个参数的调整，看看对于业务的性能影响有多大 为此我准备了一个简单的 DEMO，并且执行 1000 次请求，并发 100，每次请求执行一个 SLEEP(5) 的 SQL模拟单笔耗时。并在一个 2C 的服务器上测试。应用默认参数如下 spring.datasource.hikari.connection-timeout=30000 spring.datasource.hikari.minimum-idle=10 spring.datasource.hikari.maximum-pool-size=10 server.undertow.threads.worker(默认是 2C*8) 默认参数 $ ab -c 100 -n 1000 http://localhost:6060/test This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Server Hostname: localhost Server Port: 6060 Document Path: /test Document Length: 14 bytes Concurrency Level: 100 Time taken for tests: 510.

在 REDIS 中一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素，但实际上中如果下面两种情况，我就会认为它是 bigkeys。 字符串类型：单个 value 超过5MB 哈希、列表、集合、有序集合元素可数超过 10000 因为 REDIS 是单进程处理，所以对 BIGKEY 的访问会产生阻塞，如果你获取 100 次单体大小为 5MB 的 KEY，那么这些数据（500MB）传输到客户端就需要一定的时间，这期间其他命令都要排队等待。 查找 BIGKEY 使用 bigkeys 命令可以统计大对象（建议在从结点执行），为了方式阻塞，我们设置一个休眠参数 -i 0.1 redis-cli -h <ip> -p <port> -a <password> --bigkeys -i 0.1 结果如下： $ redis-cli -h 192.168.51.207 -p 9015 --bigkeys Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type.

我们在使用 Github、Gitlab 或者 JetBrains Space 时通常使用 SSH 密钥可以连接 Git 服务，而无需在每次访问时都提供用户名和个人访问令牌。 另外现在大量平台启用账户登录多次验证，也促进我们避免使用账号密码登录。 为了便于管理我们通常会为每个 Git 平台配置不同的 SSH KEY，然后通过 ~/.ssh/config 配置每个平台对应的 SSH KEY。 创建多个 SSH KEY 使用如下命令创建 id_github，注意提示输入文件名时请修改成 id_github ssh-keygen -t ed25519 -C "coolbeevip@github.com" 使用同样的方法我们分别创建 id_gitlab 和 id_github，这时在的本地的 ~/.ssh 目录下会得到如下文件 id_github(私钥)、id_github.pub(公钥) id_gitlab(私钥)、id_gitlab.pub(公钥) 将 *.pub 文件内容分别导入到 Git 服务中，详细方式请参考 Github and SSH keys 、 GitLab and SSH keys 或 JetBrains Space and SSH keys 配置 SSH 编辑 ~/.ssh/config 文件为每个 Git 地址配置不同的私钥 Host github.com ServerAliveInterval 60 UseKeychain yes IdentityFile ~/.

这是一个 Morris 计数器（近似计数算法）的 Java 实现，用很小的数据结构准确估计具有几十亿数据量的数据计数。 我们通常会定义一个 Long 类型对象，通过累加的方式实现计数。每个 Long 类型占用 8 byte (64bit) 空间，如果你有 30 亿个要记录的对象，那么你就需要 22GB 的空间存储这些计数器，这还不不包括在哈希中的对象ID。 背景 近似计数算法是允许我们使用非常少量的内存对大量事件进行计数的技术。它由 Robert Morris 于 1977 年发明。 该算法使用概率技术来增加计数器，尽管它不能保证准确性，但它确实提供了对真实值的相当好的估计，同时引入了最小但相当恒定的相对误差。 在这篇文章中，我们详细介绍了 Morris 算法及其背后的数学原理。 Morris 在贝尔实验室工作时遇到了一个问题。他应该编写一段代码来计算大量事件，而他只有一个 8 位计数器。 由于事件的数量很容易超过 256，使用普通方法计算它们是不可行的，这种限制导致他构建了这个近似计数器，它不是提供精确计数，而是提供一个近似计数。 计数和投硬币 构建近似计数器的一个简单方案是对每次事件变换进行计数。每收到一个新事件，我们抛一次硬币，如果正面朝上，我们增加计数，否则不增加。 这样计数器中的值平均下来将代表总事件的一半（因为抛硬币的获得正面并的概率是 0.5）。当我们将计数乘以 2 时，我们将得到近似实际数量的计数。 CoinFlipsCounter.java 这种基于抛硬币的计数技术是参数为 (n, p) 的二项分布，其中 n 是所见事件的总数，p 是成功概率，即在抛硬币过程中出现正面的概率。对真实事件数 n 的计数值 v 由下式给出 $$ \large 估算值v = 实际值n * 概率p = 实际值n/2 $$ 这种二项式的正态分布标准偏差将帮助我们找到估算中的误差，对于正态分布平均值两侧标准差的两倍覆盖了分布的 95%；我们使用它来查找计数器值中的相对和绝对误差。 $$ \large 误差 = \sqrt{实际值n * 概率p(1-概率p)} = \sqrt{估算值v/2} $$

SYSTEM MacBook Pro 16G JVM -Xmx4g -Xms4g -Xss256k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -Xnoclassgc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=12 -XX:MaxTenuringThreshold=15 -XX:+ExplicitGCInvokesConcurrent -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:CMSInitiatingOccupancyFraction=65 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 CPU Flame Graph GrpaphQL Schema Parser Slow Method

安装 在 macOS 基于源代码自己编译发布版本 安装 Etcd 启动 apisix-etcd.yml version: '3.2' services: etcd-1: image: docker.io/bitnami/etcd:3.4.16 hostname: etcd container_name: apisix-etcd ports: - '2380:2380' - '2379:2379' environment: - ALLOW_NONE_AUTHENTICATION=yes - ETCD_NAME=etcd-1 - ETCD_LISTEN_PEER_URLS=http://0.0.0.0:2380 - ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 - ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 volumes: - ./volume/apisix/etcd/data:/bitnami/etcd/data - ./volume/apisix/etcd/conf:/opt/bitnami/etcd/conf docker-compose -f docker-compose-apisix-etcd.yml up -d 验证 $ curl -L http://127.0.0.1:2379/health {"health":"true"} 安装编译环境 安装 Node 10.23.0+ $ node -v v12.18.3 安装 Yarn $ npm install -g yarn $ yarn -v 1.22.10 安装 openresty 、luarocks、lua、curl、 git brew install openresty/brew/openresty luarocks lua@5.

场景描述 我有两个 UPSTREAM 服务: UPSTREAM 1 $ curl -i -X GET http://192.168.51.234:5005/nc-tools/actuator/health HTTP/1.1 200 OK Connection: keep-alive Transfer-Encoding: chunked Content-Type: application/vnd.spring-boot.actuator.v3+json Date: Sat, 22 May 2021 09:09:29 GMT {"status":"UP","components":{...}} UPSTREAM 2 $ curl -i -X GET http://10.19.88.60:5005/nc-tools/actuator/health HTTP/1.1 200 OK Connection: keep-alive Transfer-Encoding: chunked Content-Type: application/vnd.spring-boot.actuator.v3+json Date: Sat, 22 May 2021 09:08:12 GMT {"status":"UP","components":{...}} 我希望通过 APISIX 将请求流量路由到两个不同的 UPSTREAM 服务上，参考插件 traffic-split 的样例，可以实现此功能 配置路由 & traffic-split 本例中并没有单独定义 UPSTREAM，而是在 traffic-split 中直接定义了 UPSTREAM 的地址

使用 Docker 启动 定义卷目录 APISIX 目前好像还不支持通过环境变量配置参数，所以需要在宿主机上创建配置文件，并在启动 Docker 时通过 Volume 映射进容器 规划外部卷目录 mkdir apisix_home mkdir -p apisix_home/apisix_volume/apisix/apisix_conf mkdir -p apisix_home/apisix_volume/apisix/dashboard_conf 定义 APISIX Dashboard 配置文件 apisix_home/apisix_volume/apisix/dashboard_conf/conf.yaml conf: listen: # 绑定 IP 地址 host: 0.0.0.0 # 监听端口 port: 9000 etcd: # etcd 用户名 # username: "root" # etcd 密码 # password: "123456" # etcd 地址，支持集群多节点定义 endpoints: - apisix-etcd:2379 log: error_log: # 日志级别 debug, info, warn, error, panic, fatal level: warn # 日志输出路径 file_path: logs/error.

在 APISIX STUDY NOTES (2) PLUGINS TRAFFIC SPLIT 提到，我们可以通过这个插件实现上游服务的导流，但是这个插件只能通过自定义 URL参数 或者 REQUEST HEADER 的方式传递导流变量。如果我们想通过 URL PATH 的方式实现上游业务的到导流，可以使用 Proxy Rewrite 插件 场景描述 我有两个 UPSTREAM 服务: UPSTREAM 1 $ curl -i -X GET http://192.168.51.234:5005/nc-tools/actuator/health HTTP/1.1 200 OK Connection: keep-alive Transfer-Encoding: chunked Content-Type: application/vnd.spring-boot.actuator.v3+json Date: Sat, 22 May 2021 09:09:29 GMT {"status":"UP","components":{...}} UPSTREAM 2 $ curl -i -X GET http://10.19.88.60:5005/nc-tools/actuator/health HTTP/1.1 200 OK Connection: keep-alive Transfer-Encoding: chunked Content-Type: application/vnd.spring-boot.actuator.v3+json Date: Sat, 22 May 2021 09:08:12 GMT {"status":"UP","components":{.

开源项目中我们大多采用主干开发模式管理我们的项目，他基本遵循以下规则 所有的 PR 都默认向主干合并 主干上项目的版本号是 -SNAPSHOT 当主干要发布时，我们会建立与之对应的 X 分支（此分支的目的是为了基于此分支发布补丁版本） 基于当前主干去除版本号中的 -SNAPSHOT 后建立与版本对应的 TAG 将主干上的版本号中的 minor 累加一，并在后边增加 -SNAPSHOT 后缀 此过程繁琐，切容易出错。我制作了一个脚本 maven-project-git-release.sh 用来实现这个过程的规范化和自动化 当然，这并不意味着你不需要掌握正手动发布的过程。 由于某种原因导致自动过程中断后，你依然需要手动去处理，所以在使用这个脚本前，请确保你了解这个脚本帮你做了什么工作，以及如何做的。 如何使用 maven-project-git-release.sh 脚本会帮你自动化以下工作 创建一个编译用的目录 目录会创建在你系统的临时目录下，在我的 Mac 系统系统中看起来像 /var/folders/fd/gqdh88px2fj66tmtcy6ffr580000gn/T 在编译用的目录中 git clone 你的仓库代码 你的仓库地址在使用脚本时通过参数指定，像这样 sh maven-project-git-release.sh git@github.com:coolbeevip/license-maven-plugin.git 编译你的代码确保正确 默认在当前仓库根目录下执行 mvn clean package，如果你需要特殊的方式，可以修改脚本中的 check_source_before_release 函数 计算版本号分支名 根据 pom 中的版本定义，自动计算下一版本号，默认采 maven 的3段式版号方式 major.minor.patch，并以此为基准滚动 minor 版本号，如果你需要特殊的方式，可以修改脚本中的 next_version 函数 输出发布计划 发布计划中会显示你要发布的仓库地址，当前版本号、维护用 X 分支、TAG 名称、下一个版本号等信息 Release Plan: ==================================================================== OS: Darwin GIT_REPO_URL: git@github.com:coolbeevip/license-maven-plugin.git RELEASE WORK DIR: /var/folders/fd/gqdh88px2fj66tmtcy6ffr580000gn/T/release-license-maven-plugin.