一、背景

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

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)

二、原因

零、关于面试

面试决定因子：70% 能力、20% 缘分、10% 行情。
软件工程师这条不归路，永远都走不到头，每天进步一点点，早日走上人生巅峰。

一、面经/知识点

仓库中的东西更多是抛砖引玉
提供业界比较通用/关注的技术
还得贴合自身需要深入去学习

基础指引：https://github.com/Snailclimb/JavaGuide
进阶之路：https://github.com/doocs/advanced-java
简历打磨：https://github.com/geekcompany/ResumeSample/blob/master/java.md
编程书籍：https://github.com/jobbole/awesome-programming-books
大厂试题：https://github.com/0voice/interview_internal_reference

后续持续更新，多交流，共同成长。

零、写在前面

早几天在领导 JG 的朋友圈看到这篇文章
简单几个字的标题，让我产生了兴趣
一来这个标题是挺吸引人，典型的自媒体文章
二来JG 之前推过一些书很不错
三来一般领导朋友圈都不会推垃圾信息

全文看来其实感觉还是挺切合我的认知：

1. 人很难认清自己，很难找到方向，成长路上有他人指点会很棒
2. 除了遇到的人合读过的书，十年之后你还是你
3. 多与他人交流，多帮助他人，利人利己
4. 运动、学习、反馈、重塑大脑

离开学校
大部分时间都是围绕着工作
有些人可能觉得当前的工作不满意
然后想着学点什么高大上的东西为以后的工作做准备
极端情况下这种选择是对的，大部分情况会让自己进退两难
正确的选择应该是：过好当下，瞭望远方，持续学习，总结反思，慢慢进步
架构师同事 SGLS 说过：做好当下的事情才是最重要的，不管现在是做什么项目，设计和实现是我们自己可以控制的。

以下为原文

1
2
3

审视是一个特别好的词。当一个人开始审视世界、审视经历、审视自己的时候，更容易做出有担当的选择。
作为美团“二号首长”，王慧文选择在2020年底正式“退休”，这不可分说地成为了焦点——
王慧文，是怎么成为“王慧文”的？

一、“不自我设限”，造就无边界的王慧文

什么是促使人成长的本质原因？
王慧文一直在渴求突破，也一直在探究这个问题。

1. 人要接受变化，有动荡才有进化

王慧文修行的开端，就是校内网。
2006年3月，王慧文、王兴和另外四名同伴绞尽脑汁、黑白颠倒，终于让校内网收获了一百多万用户。
王兴开始四处找投资，但在多数投资人眼里看来，他们仍是群“生瓜蛋子”、“杂牌军”，校内网不过是几个大学生做的小打小闹的玩意儿。
但在这时，千橡集团董事长陈一舟出现了，他愿意拿出一千多万人民币，收购校内网。《九败一胜：美团创始人王兴创业十年》中这样描述

零、分页查询

分页查询一般都会想到 offset limit

问题1

当不停机需要全量同步数据时
有可能会漏掉或者重复处理很多数据
因为中途会有数据改动
每次分页内的数据与预期的会有出入

问题2

offset 会进行全表扫描

一、推荐方案

通过不变的字段进行排序
最好是使用递增的主键索引

1
2
3
4
5

select *
  from hisen
where id > ${lastId}
  order by id
limit ${pageSize};

二、参考