零、背景

近一年，看了几本书感觉对我更深入理解 CS，工作更顺畅了，也促使我更关注底层原理。
《计算机网络：自顶向下方法》、《操作系统精髓与设计原理》
《Java性能优化权威指南》、《性能之巅》、《Redis运维与开发》

所以想着再在底层相关的主题上继续深入学习
于是误打误撞，来到了之前在 GitHub 关注的一个『自学计算机科学』仓库，很赞同下面这个观点

软件工程师分为两种：

1. 一种充分理解了计算机科学，从而有能力应对充满挑战的创造性工作；
2. 另一种仅仅凭着对一些高级工具的熟悉而勉强应付。

这两种人都自称软件工程师，都能在职业生涯早期挣到差不多的工资。
然而，随着时间流逝，第一种工程师不断成长，所做的事情将会越来越有意义且更为高薪，
不论是有价值的商业工作、突破性的开源项目、技术上的领导力或者高质量的个人贡献。

一、资源

1.1 摘要

零、摘要

响应国家就地过年的号召，今年第一次在外过年。
弹指一挥间，12 天的假期已经成为过去。
期间还是有不少的收获，最主要的是看了 4 本书。
以及在微博上面看到了不少的任何事，甚是触动。

找到自己的兴趣，追求精进，坚持做对的事情。

一、阅读

1.1 《 UML 和模式应用》0113~0207

这本书是 leader 推荐给大家的
基于职责去做设计的理念确实很棒，值得观摩实践。

零、背景

本文灵感来自《人人都是产品经理 2.0》
位置：7.4.2 如何做一个让 Ta 们讨厌的人

作为一个研发，工作过程中如果能及时发现如下场景，
及时给对方负反馈，否则受伤的是整个团队。
看了这本书之后，感觉对产品有新的认知，
知道他们在做什么，怎么做，后续可以更好的与他们沟通。
而且里面的内容对于研发来讲也是适用的。

一、开始实施之前

1.1 不说清需求价值

技术问”为什么要做”时：
1、时支支吾吾
2、这是老板(XXX)要的，假装自己是个传话筒
3、我接的是二手需求，什么都不知道
随说：其实正确的做法是追溯这个需求的初衷，有利于评估 ROI (投入产出比)，以及排优先级，以及增进对业务的理解。

1.2 不去想细节功能

一、背景

由于某种原因，需要手工处理错误日志提取某些信息。
下载下来的日志文件是压缩包

1.1 文件信息

1
2
3
4

system_error.log.2020-11-01.20201105200433.zip
system_error.log.2020-11-01.20201105195953.zip
system_error.log.2020-11-01.20201105200830.zip
...省略

1.2 压缩包信息

1
2
3
4
5
6
7

$ unzip -v system_error.log.2020-11-01.20201105200830.zip
Archive:  system_error.log.2020-11-01.20201105200830.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
 4495560  Defl:N    78526  98% 11-01-2020 23:43 504551c6  system_error.log.2020-11-01
--------          -------  ---                            -------
 4495560            78526  98%                            1 file

压缩包文件名不一样，但是压缩包中的文件有一样的名字。
例如：system_error.log.2020-11-01

尝试使用如下方式，提示有重复，需要挨个选择如何处理，极度不便。
于是想使用 shell 来解决（ 之前没写过 shell ）

1.2 尝试过程

一、常见单位

进制除了 Byte 与 bit 之间是 8，其它的都是 1024，但是目前很多时候习惯用 1000，比如 1T ≈ 1000G;

二、带宽/网速

2.1 带宽

运营商(ISP)带宽宣传常见的有：50M、100M、500M、1000M…
注意：这是传输速率，而不是下载速度。

零、背景

最近做压力测试，不同的系统的机器监控数据差异明显
A 系统：CPU 高 load 低
B 系统：CPU 低 load 高

那么是什么导致 A B 系统出现这种情况？
CPU 高了系统肯定跑不动了，那么 load 多高代表系统跑不动呢？

一、解释

1. A 系统的原因
   CPU 很忙，没有等待其它资源，瓶颈在 CPU。
2. B 系统的原因
   等待磁盘 I/O 完成的进程过多，导致进程队列长度过大，
   但是 CPU 运行的进程却很少，这样就导致负载过大，但 CPU 使用率低，瓶颈不在 CPU，可能在 I/O。

二、load averages 知识

1. Linux 系统下代表的是 system load averages。

2. Linux load averages track not just runnable tasks, but also tasks in the uninterruptible sleep state.
   Linux 平均负载不仅跟踪可运行的任务，还跟踪处于不可中断睡眠状态的任务。

3. On Linux, load averages are (or try to be) “system load averages”, for the system as a whole, measuring the number of threads that are working and waiting to work (CPU, disk, uninterruptible locks). Put differently, it measures the number of threads that aren’t completely idle. Advantage: includes demand for different resources.
   在 Linux 上，负载平均值是(或试图是)“系统负载平均值” ，对于整个系统来说，测量正在工作和等待工作的线程数(CPU、磁盘、不可中断锁)。换句话说，它测量的是没有完全空闲的线程数量。优势: 包括对不同资源的需求。

4. In 1993, a Linux engineer found a nonintuitive case with load averages, and with a three-line patch changed them forever from “CPU load averages” to what one might call “system load averages.” His change included tasks in the uninterruptible state, so that load averages reflected demand for disk resources and not just CPUs.
   1993年，一位 Linux 工程师发现了一个与平均负载不直观的案例，一个三行补丁永远地将它们从“ CPU 负载平均值”改变为人们可能称之为“系统负载平均值”他的更改包括处于不可中断状态的任务，因此平均负载反映了对磁盘资源的需求，而不仅仅是 cpu。

三、总结

1. linux load averages 数字大，代表系统压力大;
   阅读全文 »

零、背景说明

目前测试机器为 4C8G
两台机器完全处理一样的工作
大部分时间对象朝生夕死，很少进入老年代
CMS 指定了新生代最大 1536M，略微有点浪费
于是设置 G1 自动调节各个区域大小能否有所改善
也因为最近看了两本 JVM 相关的书籍，拿着锤子锤两下看看

一、G1 设置

1
2
3
4
5
6
7
8
9
10
11
12
13
14

-Xms4096M
-Xmx4096M
-XX:+UseG1GC
-XX:+UnlockDiagnosticVMOptions
-XX:SurvivorRatio=8
-XX:+ParallelRefProcEnabled
-XX:MaxTenuringThreshold=6
-XX:ParGCCardsPerStrideChunk=4096
-XX:MaxGCPauseMillis=100
-XX:MaxMetaspaceSize=256M
-XX:MetaspaceSize=256M
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:/home/hisen/gc.log

二、CMS 设置

当初这个文档应该是在『科技爱好者周刊』上还是哪里发现的
看这个文档本来的目的是每天坚持阅读英文文档
技术文档一般都比较简洁易懂，英语是一个长期的过程，还得继续坚持阅读~

看的过程中发现，结合一定的场景，和示例
和官方文档相比，没有那么枯燥，也更好理解
甚至有一些之前未曾关注的用法让我感到惊艳

所以推荐一下

下载地址：how-to-manage-a-redis-database.pdf

零、背景

很多时候我们调用接口并不是需要接口返回的所有信息;
就像查询数据库很少使用 select * from table; 一样;

为了使现有的存储结构以及代码逻辑改动最少
想办法在最外层的接口对返回的对象进行精简

目的使为了提高接口性能：减少 RPC 传输时间、节省网络带宽、节省序列化开销

一、方案

1. 直接创建一个对象，根据入参传入的所需字段，写一堆 if else 进行 get set;
2. 使用序列化工具，转为类似 Map 结构，取值拼装;
3. 使用 BeanWrapper 操作对象;

前面两种比较呆板，属于定制化开发;

二、实践

Spring BeanWrapper 方案处理非集合对象比较完美，输出对象小不少;
基本数据类型有默认值，无法去除，不过这种对大小影响不大;
完整代码：github.com

1
2
3
4
5
6
7
8
9
10
11
12
13

public static void main(String[] args) {
    Order order = getOrder();
    Order smallerOrder = new Order();
    List<String> keepFields = Lists.newArrayList();
    keepFields.add("orderId");
    keepFields.add("address.province");
    // i want get all names, not only index 1, how to do ?
    keepFields.add("productInfos[1].name");
    copyLimitedProperties(order, smallerOrder, keepFields);
    Gson gson = new Gson();
    System.out.println("src:" + gson.toJson(order));
    System.out.println("des" + gson.toJson(smallerOrder));
}

零、本文背景

有个朋友抛出一个问题，明显不符合最左匹配原则的 SQL，居然走索引了
兜兜转转，嘀咕了好几天，期间也和几个朋友讨论了一下
都没有结果，最后还是在 MySQL 的官方文档中找到了原因
记录下，也算是一次不错的探索。

一、问题描述

1.1 表结构

1
2
3
4
5
6
7
8

CREATE TABLE `people_new` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `last_name` varchar(255) NOT NULL,
  `first_name` varchar(255) NOT NULL,
  `bob` date NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index_union` (`last_name`,`first_name`,`bob`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COMMENT='人员-新'

1.2 数据

1
2
3
4
5
6
7

mysql> select * from people_new;
+----+-----------+------------+------------+
| id | last_name | first_name | bob        |
+----+-----------+------------+------------+
|  1 |  hisen    | yuan       | 2008-08-08 |
+----+-----------+------------+------------+
1 row in set (0.00 sec)

1.3 SQL 分析

可以看到 Using index
但是 possible_keys null 而 key 显示 index_union

1
2
3
4
5
6
7

mysql> explain select * from people_new  where bob = '2008-08-08' and first_name = 'yuan';
+----+-------------+------------+------------+-------+---------------+-------------+---------+------+------+----------+--------------------------+
| id | select_type | table      | partitions | type  | possible_keys | key         | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+------------+------------+-------+---------------+-------------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | people_new | NULL       | index | NULL          | index_union | 1537    | NULL |    1 |   100.00 | Using where; Using index |
+----+-------------+------------+------------+-------+---------------+-------------+---------+------+------+----------+--------------------------+
1 row in set, 1 warning (0.00 sec)

二、原因