一卓的博客

怕什么真理无穷，
进一寸有一寸的欢喜。

0%

发表于 阅读次数： 4.6k 4 分钟

大规模的数据库存储系统中，数据的生命周期管理是很有必要的；从业务角度发现过期数据，数据归档和数据碎片整理等。以 MySQL 为例，1 个运行很久的 TB 级 MySQL 实例中，极有可能数百 GB 的数据，对业务来说是”过期数据”可直接归档后清理。如果不能发现和及时清理，这部分“过期数据”对生产数据库备份资源消耗，占用工作集数据内存 (过期数据行可能分散 InnoDB 的 page 中)，影响数据还原的 RTO 等。从成本和运维的角度看，代价都是很大的。针对 MySQL 这类”过期数据”问题，通过 MySQL 巡检系统发现问题，使用 MySQL 归档系统备份和删除数据等。

Redis 死键的定义

本文简单聊下 Redis ”死键”的问题，从业务角度对”死键”的 2 个定义:

  • 设置有生存时间 Time to live:TTL 的键，已经过期”死亡”，但因 Redis 主动清理不及时，导致这类键堆积.(这里可能不清晰，后文会详解)
  • 未设置有 TTL 键，使用这批键的程序功能已下线，导致这类键在集群中堆积，无人管理；有的键长达 6 个月访问过一次。
阅读全文 »

发表于 阅读次数： 907 1 分钟

1、 没有 WHERE 子句
2、 使用 IS NULL 和 IS NOT NULL , 以下语句 comm 列的索引会失效

1
SELECT * FROM emp WHERE comm IS NULL;

3、 WHERE 子句中使用函数
如果没有使用基于函数的索引，那么 where 子句中对存在索引的列使用函数时，会使优化器忽略掉这些索引。例如：

1
select * from staff where trunc(birthdate) = '01-MAY-82';
阅读全文 »

发表于 阅读次数： 6.6k 6 分钟

1562835150704

之前上学的时候有这个一个梗，说在食堂里吃饭，吃完把餐盘端走清理的，是 C++ 程序员，吃完直接就走的，是 Java 程序员。

确实，在 Java 的世界里，似乎我们不用对垃圾回收那么的专注，很多初学者不懂 GC，也依然能写出一个能用甚至还不错的程序或系统。但其实这并不代表 Java 的 GC 就不重要。相反，它是那么的重要和复杂，以至于出了问题，那些初学者除了打开 GC 日志，看着一堆 0101 的天文，啥也做不了。

今天我们就从头到尾完整地聊一聊 Java 的垃圾回收。

阅读全文 »

发表于 阅读次数： 6.2k 6 分钟

本文将介绍如何把自己开发出来的 jar 包发布到 Maven 中央仓库，以便将好用的工具共享给其他需要的人.

第一步 注册 jira 账号，将 jira 账号名密码 配置到 maven 的 settings.xml 文件中

JIRA 注册地址

修改 mavan 配置文件 settings.xml ，加入以下配置

1
2
3
4
5
6
7
8
9
10
11
12
<servers>
   <server>
     <id>sonatype-nexus-snapshots</id>
     <username>刚才注册的账号</username>
     <password>刚才注册的密码</password>
   </server>
   <server>
     <id>sonatype-nexus-staging</id>
     <username>刚才注册的账号</username>
     <password>刚才注册的密码</password>
   </server>
 </servers>

构件第一次发布需要创建 ISSUE，可以参考我之前创建的 ISSUE

登录 JIRA，点击 Create ，如图：
1560743125851

阅读全文 »

发表于 阅读次数： 2.2k 2 分钟

Maven 可以根据已有的项目模板来快速构建项目，避免重复的搭建相同的项目开发环境。

首先确保本地正确安装了 JDK 及 Maven

自定义 archetype

1、首先需要创建一个 Maven 项目，或者使用现有 Maven 项目，在项目根目录下执行以下命令

1
mvn archetype:create-from-project
阅读全文 »

发表于 阅读次数： 736 1 分钟

作为一个开发者，通常会拥有公司与 github/gitlab 等多个账户，在不同项目下开发时，commit 的用户名和邮箱是不同的，例如公司项目中，使用的是本名+公司邮箱，而 github 项目中使用的是个人邮箱和昵称。

首先，我们需要了解一下 Git 配置文件生效的优先级。对于一个 Git 仓库来说，配置优先级为 仓库 > 全局 > 系统。操作 Git 时，首先会查找/etc/gitconfig (系统)，然后查找用户的全局配置~/.gitconfig，最后查找每个仓库的 .git/config 配置。所有的配置项，从低优先级开始加载，出现冲突时，较高优先级的配置项会覆盖前面的配置。

阅读全文 »

发表于 阅读次数： 4.1k 4 分钟

一般来说，下图这些命令已经足够日常使用。但是有些时候，我们还需要使用其它的一些不太常用的命令。

bg2015120901

下面是我整理的常用 Git 命令。

阅读全文 »

发表于 阅读次数： 2.5k 2 分钟

版本号命名规则

本文根据 Semantic Versionning 2.0.0 和 Semantic Versioning 3.0.0 选择性的整理出版本号命名规则指南。

版本号的格式为 X.Y.Z(又称 Major.Minor.Patch)，递增的规则为：

1
2
3
X 表示主版本号，当 API 的兼容性变化时，X 需递增，Y 和 Z 同时设置为 0。
Y 表示次版本号，当增加功能(不影响 API 的兼容性) 或者 API 被标记为 Deprecated 时，Y 需递增，同时 Z 设置为 0。
Z 表示修订号，当做 Bug 修复时(不影响 API 的兼容性)，Z 需递增。

详细的规则如下：

1
2
3
4
5
6
7
X, Y, Z 必须为非负整数，且不得包含前导零，必须按数值递增，如 1.9.0 -> 1.10.0 -> 1.11.0
0.Y.Z 的版本号表明软件处于初始开发阶段，意味着 API 可能不稳定；1.0.0 表明版本已有稳定的 API。
先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为：X.Y.Z.[a-c][正整数]，如1.0.0.a1，1.0.0.b99，1.0.0.c1000。
开发版本号常用于 CI-CD，格式为 X.Y.Z.dev[正整数]，如 1.0.1.dev4。
版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0；
对于先行版本号和开发版本号，有：1.0.0.a100 < 1.0.0， 2.1.0.dev3 < 2.1.0；
当存在字母时，以 ASCII 的排序来比较，如 1.0.0.a1 < 1.0.0.b1。

注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！

阅读全文 »