安装 官方建议的安装方法是从源代码编译安装，您可以从 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

你在当前分支上开发代码，此时不想 commit，但是又想切换到其他分支完成其他的工作，此时可以用 stash 在当前分支执行 stash 将当前分支未提交的代码隐藏起来 $ git stash Saved working directory and index state WIP on SCB-1577: 2554be3d SCB-1593 Add notice for Boringssl support ciphers (base) bogon:servicecomb-pack zhanglei$ 此时你可以看到已经存储到一个id为 2554be3d 里了，这时你可以用 git status 查看已经没有要提交的内容了 git status On branch SCB-1577 nothing to commit, working tree clean (base) bogon:servicecomb-pack zhanglei$ 这时你就可以切换到其他分支开始新的工作 (base) bogon:servicecomb-pack zhanglei$ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. 返回原来的分支继续工作 git checkout SCB-1577 Switched to branch 'SCB-1577' 查看以前隐藏的修改内容 git stash list stash@{0}: WIP on SCB-1577: 2554be3d SCB-1593 Add notice for Boringssl support ciphers (base) bogon:servicecomb-pack zhanglei$ 恢复隐藏内容继续工作，使用 git stash apply {id} (base) bogon:servicecomb-pack zhanglei$ git stash apply stash@{0} On branch SCB-1577 Changes not staged for commit: (use "git add <file>.

当你 fork 一个仓库后，可以时用此方法使你 fork 后的仓库 master 分支保持和上游 master 分支的同步 使用 rebase 命令同步上游 master 分支到你本地的 master 分支，并推送到你 fork 后的仓库 git fetch upstream git checkout master git rebase upstream/master git push -f origin master 或者你确定放弃你本地所有的修改，则可以简单的重置为上游版本 git fetch upstream git checkout master git reset --hard upstream/master git push -f origin master 如果你也想同步 master 分支的修改到你的功能分支 git checkout <分支名> git rebase master git push -f origin <分支名>

Linux 网络相关命令 可以使用 yum install iperf3 安装这个工具，或者从网站 https://iperf.fr/iperf-download.php 下载 测试 TCP 吞吐量 假设我们要测试 10.1.207.180 和 10.1.207.181 两个服务器之间的带宽 先在其中一台服务器 10.1.207.181 服上启动 iperf3 服务 [root@oss-irms-181 ~]# iperf3 -s -p 5001 ----------------------------------------------------------- Server listening on 5001 ----------------------------------------------------------- 再在另一台机器 10.1.207.180 启动客户端连接服务端 10.1.207.181 测试 [root@oss-irms-180 ~]# iperf3 -c 10.1.207.181 -P 4 -t 30 -i 2 -p 5001 Connecting to host 10.1.207.181, port 5001 [ 4] local 10.1.207.180 port 49244 connected to 10.1.207.181 port 5001 [ 6] local 10.

Git 分支非常有用，您可以根据需要创建一个新分支，合并一个分支或删除一个分支。 您可以使用许多 git 命令来管理 git 中的分支。 当您使用 git checkout 分支时，HEAD会指出最后的提交。 简单来说，您可以说 Git HEAD 是当前分支。 每当您签出一个分支或创建一个新分支时，Git HEAD 都会转移它。 HEAD 是对当前检出分支中最后一次提交的引用。 在存储库中，HEAD 始终指向当前分支的起点。 换句话说，HEAD 是指向下一个提交的父对象或下一个提交将发生的地方的指针。 更具体地说，HEAD 是一个移动指针，它可以引用或可以不引用当前分支，但是它始终引用当前提交。 什么是 HEAD^ 插入符（^）是 Commit 的父级。 什么是 HEAD~ 代字号（〜）是一行几个字符（^）的简写字符。 HEAD〜2 与 HEAD ^^ 的作用相同。 如果写数字，则使用的默认值为1，因此 HEAD〜 等价于 HEAD ^。 如何检查HEAD的状态 您可以使用以下命令查看当前 Git HEAD 指向的位置： $ cat .git/HEAD ref: refs/heads/master 并且，你可以使用以下命令查看指向 HEAD 的 commit 的 Hash ID： $ git rev-parse --short HEAD 6f975a5 Detached HEAD HEAD 是您目前的工作分支。 当您尝试 git checkout 分支时，HEAD 指向该分支的顶部，这样您就可以继续工作而没有任何困难。