ARTS第六周
ARTS是什么？
Algorithm：每周至少做一个leetcode的算法题；
Review：阅读并点评至少一篇英文技术文章；
Tip/Techni：学习至少一个技术技巧；
Share：分享一篇有观点和思考的技术文章。
Algorithm
题目：141. Linked List Cycle
解题思路
本题是链表相关的一道题，题目给出一个链表，问我们这个链表中是否有环。题目中给出了三个例子来帮助我们分析是否有环，我们可以简单理解为，判断链表中是否有节点被超过两个节点的next指针指向，如果有就存在环，如果没有就无环。
第一种方法
我们一次遍历链表中的各个节点，并把遍历过节点存到一个set中，每次遍历下一个节点的时候先判断是否它是否存在于set中，如果存在则表示此链表存在环，如果遍历完整个链表都没有发现重复节点，则表示此链表不存在环。
第二种方法
设置两个快慢指针，一个指向第一个节点取名为slow，另一个指向第二个节点，取名为fast，slow指针每次走一步，即slow = slow.next，fast指针每次走两步，即fast = fast.next.next，遍历过程中判断slow和fast的值是否相等，如果有环，fast指针会追上slow指针，如果没环，最终fast或fast.next的值会是null。
代码
第一种方法
public boolean hasCycle(ListNode head) {
Set<ListNode> nodes = new HashSet<>();
if (head == null || head.next == null){
return false;
}
while (head.next != null){
if (nodes.contains(head)) {
return true;
}else{
nodes.add(head);
head = head.next;
}
}
return false;
}
第二种方法
public boolean hasCycle(ListNode head) {
if (head == null || head.next == null){
return false;
}
ListNode quick = head.next;
ListNode slow = head;
while (quick != slow){
if (quick == null || quick.next == null){
return false;
}
quick = quick.next.next;
slow = slow.next;
}
return true;
}
Review
这周在medium上看了一篇文章How to work optimally with relational databases,意思就是“如何更好地使用关系型数据库”。下面我就对这篇文章中的主要内容进行翻译（如有错误，敬请指正），完整原文请点击前文链接前往阅读。
理解关系型数据库
存储
MySQL是一种关系型数据库，它的数据是由一行行tuple表示，所有tuple组成一个relation，每行tuple用它的属性来表示。关系如下图所示：
假设我们有一个借书的应用，我们需要存储所有图书的借阅记录，为了存储它们，我们用下面的sql语句创建一个简单的关系表：
> CREATE TABLE book_transactions ( id INTEGER NOT NULL AUTO_INCREMENT, book_id INTEGER, borrower_id INTEGER, lender_id INTEGER, return_date DATE, PRIMARY KEY (id));
这个表看起来就像这样：
book_transactions
------------------------------------------------
id borrower_id lender_id book_id return_date
这里的** id **是主键， borrower_id, lender_id, book_id都是外键，在我们使用我们的应用之后会生成几条记录：
book_transactions
------------------------------------------------
id borrower_id lender_id book_id return_date
------------------------------------------------
1 1 1 1 2018-01-13
2 2 3 2 2018-01-13
3 1 2 1 2018-01-13
获取数据
我们的应用有一个dashboard页允许用户去查看他们借阅图书的记录，那么让我们来获取某个用户的借阅记录：
> SELECT * FROM book_transactions WHERE borrower_id = 1;
book_transactions
------------------------------------------------
id borrower_id lender_id book_id return_date
------------------------------------------------
1 1 1 1 2018-01-13
2 1 2 1 2018-01-13
这会顺序扫描关系表并把这个用户的数据返回给我们。这看起来很快，因为我们的关系表数据很少。为了能看到精确的查询时间，我们通过下面的命令把** set profiling **设置成true：
> set profiling=1;
一旦设置了profiling参数，再此运行查询语句的时候，使用下面的命令就能看到执行时间：
> show profiles;
这将返回我们执行的查询命所花费的时间。
Query_ID | Duration | Query
1 | 0.00254000 | SELECT * FROM book_transactions ...
执行速度似乎很快。
慢慢地，book_transactions表数据越来越多，因为会一直产生很多的记录。
问题
这在我们的关系表中增加了tuples的数量，接着，用户获取借阅记录的时间开始变得更长。MySQL需要遍历所有的tuples去找到结果。
为了插入很多数据到这个表，我写了下面的存储过程：
DELIMITER //
CREATE PROCEDURE InsertALot()
BEGIN
DECLARE i INT DEFAULT 1;
WHILE (i <= 100000) DO
INSERT INTO book_transactions (borrower_id, lender_id, book_id, return_date) VALUES ((FLOOR(1 + RAND() * 60)), (FLOOR(1 + RAND() * 60)), (FLOOR(1 + RAND() * 60)), CURDATE());
SET i = i+1;
END WHILE;
END //
DELIMITER ;
* It took around 7 minutes to insert 1.5 million data
这个存储过程插入了100000条随机数据到我们的book_transactions表，在运行完这个存储过程以后，分析器显示运行时间有略微增长：
Query_ID | Duration | Query
1 | 0.07151000 | SELECT * FROM book_transactions ...
让我们多加一点数据，运行上面的存储过程，然后看看会发生什么。随着加入越来越多的数据，查询时长也在随之增加。当有1.5百万数据插入到这张表的时候，查询的响应时间已经明显加长了。
Query_ID | Duration | Query
1 | 0.36795200 | SELECT * FROM book_transactions ...
这只是一个简单的涉及整数字段的查询。
随着更多的复合查询，排序查询和计数查询，执行时间将变得更长。
对于单个查询，这似乎不是一个很长的时间，但当我们每分钟运行数千甚至上百万的查询的时候，就会有很大的不同。
将有更长的等待时间，这会降低整个应用的性能。同样的一个查询，执行时间会从2ms增加到370ms。
加速
索引
MySQL和其他数据库提供了索引，一种有助于更快获取数据的数据结构。
在MySQL中，有不同类型的索引：
- 主键索引 -- 加在主键上的索引。默认情况下，主键都是加了索引的。它确保任意两行数据不会出现同一个主键值。
- 唯一索引 -- 唯一索引可以确保没有两行数据会有同一个值，可以使用唯一索引存储多个NULL值。
- 普通索引 -- 可以加在除主键以外的任何字段上。
- 全文索引 -- 全文索引可以帮助针对字符串数据的查询
索引存储的方式主要有两种：
Hash -- 这种方式主要用于精确匹配，不适用于比较。
B-Tree -- 这是存储上面提到的索引类型最常用的方式。
MySQL适用B-Tree作为它的默认索引格式，数据存储在一颗二叉树中，这样能快速检索数据。
用B-Tree组织数据有助于跳过关系表中所有tuples的全表扫描。
上面图中的B-Tree一共有16个节点，假设我们需要找到数字6，我们总共只需要遍历3次就能找到这个数，这有助于提高搜索性能。
所以要提高book_transactions表的性能，让我们在lender_id字段上添加索引。
> CREATE INDEX lenderId ON book_transactions(lender_id)
----------------------------------------------------
* It took around 6.18sec Adding this index
上面的命令在lender_id字段上添加了一个索引。重新运行之前的查询语句，让我们来看看它如何影响我们拥有的1.5百万数据的性能。
> SELECT * FROM book_transactions WHERE lender_id = 1;
Query_ID | Duration | Query
1 | 0.00787600 | SELECT * FROM book_transactions ...
哇，又像之前那么快了！
现在和只有3条记录的时候一样快，通过正确的索引添加，我们能看到显著的性能提升。
复合索引和单一索引
刚才我们添加的是单一索引，索引也能加到复合字段上。
如果我们的查询包含多个字段，一个复合索引将帮助我们，我们可以使用下面的命令来添加一个复合索引：
> CREATE INDEX lenderReturnDate ON book_transactions(lender_id, return_date);
索引的其他用法###
查询不是索引唯一的用途，它们也能被用在ORDER BY条件上，让我们根据lender_id字段对所有记录排序。
> SELECT * FROM book_transactions ORDER BY lender_id;
1517185 rows in set (4.08 sec)
4.08 秒，太长了！出了什么问题吗？我们明明加了索引。让我们借助EXPLAIN语句深入研究看看这个查询语句是怎么被执行的。
使用ExPlain####
我们添加一个explain语句来看这个查询在我们当前的数据集中究竟是怎么执行的。
> EXPLAIN SELECT * FROM book_transactions ORDER BY lender_id;
输出如下：
explain语句返回了几个字段，让我们看看上图中的表格来找到问题所在。
rows：被扫描的行数
filtered:获取数据时被扫描行所占的百分比
type:如果使用索引则给出，ALL表示没有使用索引
possible_keys, key, key_len 都是NULL，表示没有使用索引
那么为什么这个查询没有用索引？
这是因为我们在查询语句使用了select *，意味着我们会查询表中的所有字段。
索引只有那些加了索引的字段的信息，不包含其他字段，这意味着MySQL需要去主表再次获取数据。
那么我们应该如何写我们的查询语句？
只查需要的字段####
要删除转到主表的查询，我们需要只查索引表中存在的值。让我们修改一下查询语句：
> SELECT lender_id FROM book_transactions ORDER BY lender_id;
这将在0.46秒内返回结果，哪个更快？但还是有提高的余地。
当这个查询是在1.5百万条记录上完成的，它需要花费更多的时间去加载数据到内存。
使用Limit
我们或许不需要一次性获取1.5百万条数据。使用LIMIT批量获取数据代替获取全量数据是一种更好的方式。
> SELECT lender_id
FROM book_transactions
ORDER BY lender_id LIMIT 1000;
有了LIMIT，响应时间大大提升，只需要0.0025秒。我们能使用OFFSET获取下一批数据。
> SELECT lender_id
FROM book_transactions
ORDER BY lender_id LIMIT 1000 OFFSET 1000;
这会获取下一批1000条数据，用这种方式我们可以增加offset和limit获取所有数据。但是有一个陷阱，随着offset的增加，查询性能也会下降。
这是因为MySQL会扫描全表数据去到达offset点，因此最好不要使用很高的offset。
计数查询怎么样？####
InnoDB引擎有并发写的能力。这使其具有高扩展性并提高了每秒的吞吐量。
但这是有代价的，InnoDB无法为任意表记录数添加缓存计数器。所以，计数器必须通过遍历所有过滤数据完成实时计数，这使得COUNT查询比较慢。
所以推荐在应用逻辑里为大数据量的数据计算总计数。
为什么不给所有字段都加索引
增加索引能提高性能，但它也有代价。应该有效地使用，给更多的字段增加索引会有下面的问题：
- 占用大量的内存，需要更大的机器
- 当我们做删除操作的时候，会重建索引（CPU密集型操作，慢删除）
- 当我们做插入操作的时候，会重建索引（CPU密集型操作，慢插入）
- 更新不会做全局重建索引，所以更新操作时更快的，cpu效率更高
我们知道添加索引很有帮助，但我们不能在所有数据上都添加索引除非它能提升性能。
分区
当我们构建索引的时候，我们只有索引字段的信息，没有索引中不存在的字段数据。
那么，就如前文说的，MySQL需要回表获取别的字段数据，这会减慢执行时间。
我们可以使用分区来解决这个问题。
分区是一种技术，MySQL将一张表的数据拆分成多张表，但还是当一张表来管理。
在表中执行任何类型的操作时，我们需要指定正在使用的分区。随着数据被分解，MySQL有一个较小的数据集可供查询，根据需要确定正确的分区是高性能的关键。
但如果我们一直用同一台机器，它能扩展吗？
分片
当面对庞大的数据集，将所有数据存储在同一台机器上可能会很麻烦。
特定分区可能很重，需要更多查询，而其他分区则较少。所以一个会影响另一个。它们无法单独扩展。
假设最近三个月的数据是最常用的，而较旧的数据使用较少。也许最近的数据大多是更新/创建的，而旧的数据大多只是被读过。
要解决此问题，我们可以将最近三个月的分区移动到另一台计算机。
分片是一种将大数据集分成较小块的方式，然后转移到单独的RDBMS。换句话说，分片也可以称为“水平分区”。
关系数据库能够随着应用程序的增长而扩展。找出正确的索引并根据需要调整基础架构是必要的。
Tip/Techni
本周分享一个cpu占用100%问题的解决方法，主要用到两个命令top和perf，top用来确认引发 CPU 性能问题的来源；perf用来排查出引起性能问题的具体函数。
具体示例
使用top命令查看当前cpu使用率，按下数字1，切换到每个cpu的使用率：
$ top
...
%Cpu0 : 98.7 us, 1.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 99.3 us, 0.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21514 daemon 20 0 336696 16384 8712 R 41.9 0.2 0:06.00 php-fpm
21513 daemon 20 0 336696 13244 5572 R 40.2 0.2 0:06.08 php-fpm
21515 daemon 20 0 336696 16384 8712 R 40.2 0.2 0:05.67 php-fpm
21512 daemon 20 0 336696 13244 5572 R 39.9 0.2 0:05.87 php-fpm
21516 daemon 20 0 336696 16384 8712 R 35.9 0.2 0:05.61 php-fpm
这里有多个使用率在40%左右的进程，我们找其中一个使用 perf 分析下:
# -g 开启调用关系分析，-p 指定 php-fpm 的进程号 21515
$ perf top -g -p 21515
按方向键切换到 php-fpm，再按下回车键展开 php-fpm 的调用关系，调用关系最终到了 sqrt 和 add_function。
然后我们需要去源码中寻找这两个方法的踪迹，问题就藏在使用到这两个方法的地方。
Share
今天分享一则轻松一点的讯息Mozilla 抱怨谷歌偏心! 火狐/Edge 加载 YouTube 缓慢，看到这则新闻的时候我瞬间联想到了最近美国和中国的贸易战，两者何其相似，都是强者无理欺负弱者而弱者只能抱怨的案例，自古以来亘古不变的真理就是强者才有话语权，实力说话，不然就要“挨打”，不仅仅是商场、外交是这样，生活中处处都是这个道理的鲜活例子，作为个人也要努力变强，这样才有话语权，才能有更多的自由做你想做的事，过你想过的生活。