Skip to content

Commit 0f5b24c

Browse files
authored and
committed
two arts
1 parent 9dedcf9 commit 0f5b24c

File tree

4 files changed

+330
-0
lines changed

4 files changed

+330
-0
lines changed

‎_posts/arts/2019-04-13-arts_week_2.md

Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
---
2+
title: ARTS(第2周)
3+
category: ARTS
4+
tags: arts
5+
---
6+
7+
> **本周提纲：**
8+
>
9+
> 1. Algorithm: 最长公共前缀
10+
> 2. Review: 预示你在编程方面很逊的10件事
11+
> 3. Tip: 阿里巴巴开源数据迁移框架DataX
12+
> 4. Share: 缓存架构，一篇足够(58沈剑)
13+
14+
<!-- more -->
15+
16+
## Algorithm
17+
18+
[14.最长公共前缀](https://leetcode-cn.com/problems/longest-common-prefix/)
19+
20+
### 描述
21+
22+
> 编写一个函数来查找字符串数组中的最长公共前缀。
23+
>
24+
> 如果不存在公共前缀，返回空字符串 ""。
25+
> 示例 1:
26+
>
27+
> 输入: ["flower","flow","flight"]
28+
> 输出: "fl"
29+
>
30+
> 示例 2:
31+
>
32+
> 输入: ["dog","racecar","car"]
33+
> 输出: ""
34+
> 解释: 输入不存在公共前缀。
35+
> 说明:
36+
>
37+
> 所有输入只包含小写字母 a-z 。
38+
39+
### CODE
40+
41+
```python
42+
class Solution:
43+
def longestCommonPrefix(self, strs: List[str]) -> str:
44+
"""
45+
:type strs :List[str]
46+
:rtype str
47+
"""
48+
if len(strs) == 0: return ""
49+
# 按照字母表顺序获取最大值和最小值（进行了简单的排序）
50+
s1, s2 = min(strs), max(strs)
51+
zobj = zip(s1,s2)
52+
rstr = ""
53+
for i,j in list(zobj):
54+
if i != j:
55+
return rstr
56+
rstr += i
57+
return rstr
58+
```
59+
60+
## Review
61+
62+
[10 Signs You Will Suck at Programming](https://blog.usejournal.com/10-signs-you-will-suck-at-programming-5497a6a52c5c) [预示你在编程方面很逊的10件事]
63+
64+
> 作者是一个编程的教育工作者，总结的10件事我觉得是可以套用到大多数的行业的
65+
66+
1. 缺少好奇心
67+
68+
> 好奇心（兴趣）是干好一件事情的基础，有了好奇心才能是不那么折磨的过程。
69+
> 干一件事情首先要问自己“这是我感兴趣的事情吗？”如果答案是“否”那就别在这件事情上浪费时间了，如果答案是“是”那就全情投入的去展现自己的好奇心吧！
70+
71+
2. 缺少自主性和工具包
72+
73+
> 遇到问题要积极主动的思考，自主的寻找答案或者接近答案，在解决问题的过程中丰富自己的工具包
74+
75+
3. 面对问题缺少坚持
76+
77+
> 程序世界就是一个接一个的问题，思考问题解决问题，才能更快更好的解决新的问题
78+
79+
4. 缺少解决问题的成就感
80+
81+
> 苦海无边，苦中作乐（要不怎么面对接踵而至的Bug）
82+
83+
5. 缺少学习和理解的耐心
84+
85+
> 技术之门深似海，没有学习的耐性怎么行
86+
87+
6. 对于思考这件事感到乏味或者感到累
88+
89+
> 思考就像锻炼身体，越练越强壮
90+
91+
7. 无法独立思考
92+
93+
> 多看，多学，多想
94+
95+
8. 死板，狭隘，混乱的思想
96+
97+
> OPEN YOUR MIND
98+
99+
9. 只追求结果正确而不关注不同的解决方法之间的好与坏
100+
101+
> 关注错误才能避免错误
102+
103+
10. 不关注细节
104+
105+
> 细节有时候是决定性的
106+
107+
## Tip
108+
109+
DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步功能。
110+
111+
GitHub地址：[https://github.com/alibaba/DataX](https://github.com/alibaba/DataX)
112+
113+
## Share
114+
115+
[缓存架构，一篇足够](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961368&idx=1&sn=82a59f41332e11a29c5759248bc1ba17&chksm=bd2d0dc48a5a84d293f5999760b994cee9b7e20e240c04d0ed442e139f84ebacf608d51f4342&scene=21#wechat_redirect)
116+
117+
来自`58沈剑`的公众号`架构师之路`
118+
119+
本文提到了选择缓存的一些参考点：
120+
121+
1. 介绍进程内缓存（常见的redis/memcache等为进程外缓存服务）
122+
2. redis和memcache怎么选
123+
3. 缓存的误用
124+
4. 究竟是淘汰缓存还是修改缓存
125+
5. 先操作数据库，还是先操作缓存（考虑具体的应用场景灵活应用）
126+
6. 缓存与数据库不一致（主从数据库导致，通过订阅binlog触发缓存淘汰策略）
127+
7. 主从数据库不一致

‎_posts/arts/2019-04-19-arts_week_3.md

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
---
2+
title: ARTS(第3周)
3+
category: ARTS
4+
tags: arts
5+
---
6+
7+
> **本周提纲：**
8+
>
9+
> 1. Algorithm: 删除排序数组中的重复项
10+
> 2. Review: 一个谷歌工程师编码解决问题的过程
11+
> 3. Tip: Jenkins REST API 触发任务执行
12+
> 4. Share: 关于负载均衡的一切(58沈剑)
13+
14+
<!-- more -->
15+
16+
## Algorithm
17+
18+
[26. 删除排序数组中的重复项](https://leetcode-cn.com/problems/remove-duplicates-from-sorted-array/)
19+
20+
### 描述
21+
22+
> 给定一个排序数组，你需要在原地删除重复出现的元素，使得每个元素只出现一次，返回移除后数组的新长度。
23+
> 不要使用额外的数组空间，你必须在原地修改输入数组并在使用 O(1) 额外空间的条件下完成。
24+
>
25+
>> 示例 1:
26+
>>
27+
>> 给定数组 nums = [1,1,2],函数应该返回新的长度 2, 并且原数组 nums 的前两个元素被修改为 [1,2]。
28+
>>
29+
>> 你不需要考虑数组中超出新长度后面的元素。
30+
>>
31+
>> 示例 2:
32+
>>
33+
>> 给定 nums = [0,0,1,1,1,2,2,3,3,4],函数应该返回新的长度 5, 并且原数组 nums 的前五个元素被修改为 [0,1,2,3,4]。
34+
>>
35+
>> 你不需要考虑数组中超出新长度后面的元素。
36+
37+
### CODE
38+
39+
```python
40+
class Solution:
41+
def removeDuplicates(self, nums: List[int]) -> int:
42+
"""
43+
:type nums :List[int]
44+
:rtype int
45+
"""
46+
if len(nums) <= 1:
47+
return len(nums)
48+
i = 0
49+
for j in range(1, len(nums)):
50+
if nums[i] != nums[j]:
51+
i += 1
52+
nums[i] = nums[j]
53+
return i+1
54+
```
55+
56+
## Review
57+
58+
[TDD Changed My Life](https://medium.com/javascript-scene/tdd-changed-my-life-5af0ce099f80) [测试驱动开发改变我的人生]
59+
60+
## Tip
61+
62+
## Share
63+

‎_posts/db/2019-01-10-db_isolation.md

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
---
2+
title: 数据库隔离级别
3+
category: db
4+
tags: db isolation
5+
---
6+
7+
## 数据库隔离级别
8+
9+
事务之间对于数据的可见性
10+
11+
隔离级别 |脏读（Dirty Read） |不可重复读（NonRepeatable Read） |幻读（Phantom Read）
12+
|-----------------------------|------|-------|----
13+
未提交读（Read uncommitted，RU）|可能 |可能 |可能
14+
已提交读（Read committed，RC） |不可能 |可能 |可能
15+
可重复读（Repeatable read，RR） |不可能 |不可能 |可能
16+
可串行化（SERIALIZABLE） |不可能 |不可能 |不可能
17+
18+
<!-- more -->
19+
20+
### 未提交读（Read uncommitted，RU）
21+
22+
是最低的隔离级别。允许“脏读”（dirty reads），事务可以看到其他事务“尚未提交”的修改。
23+
24+
### 已提交读（Read committed，RC）
25+
26+
基于锁机制并发控制的DBMS需要对选定对象的写锁一直保持到事务结束，但是读锁在SELECT操作完成后马上释放（因此“不可重复读”现象可能会发生，见下面描述）。和可重复读（Repeatable read，RR）隔离级别一样，也不要求“范围锁”。
27+
28+
### 可重复读（Repeatable read，RR）
29+
30+
基于锁机制并发控制的DBMS需要对选定对象的读锁（read locks）和写锁（write locks）一直保持到事务结束，但不要求“范围锁”，因此可能会发生“幻影读”。
31+
32+
### 可串行化（SERIALIZABLE）
33+
34+
最高的隔离级别。
35+
36+
在基于锁机制并发控制的DBMS实现可串行化，要求在选定对象上的读锁和写锁保持直到事务结束后才能释放。在SELECT 的查询中使用一个“WHERE”子句来描述一个范围时应该获得一个*范围锁（range-locks）*。这种机制可以避免“幻读”（phantom reads）现象。
37+
38+
[MySQL Gap Lock问题](https://www.cnblogs.com/diegodu/p/9239200.html)
39+
[事务隔离](https://en.wikipedia.org/wiki/Isolation_(database_systems))
40+
[innodb locking transaction model](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-transaction-model.html)

‎_posts/db/mysql/2019-01-21-InnoDB_Locking.md

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
---
2+
title: InnoDB 锁分类
3+
category: db
4+
tags: MySQL lock
5+
---
6+
7+
## 共享/排它锁（Shared and Exclusive Locks）
8+
9+
InnoDB实现了标准的行级锁：shared(S) lock 和 exclucive(X) lock
10+
11+
1. 事务获得某一行的共享S锁才可以读取这一行，允许多个事务持有某一行的共享S锁（读读可以并行）
12+
2. 事务获取某一行的排它X锁可以对这一行尽心`修改`或`删除`，不允许多个事务同时持有某一行的排它X锁（读写，写写不可以并行）
13+
14+
> 注意： 如果事务T1已经获取了某一行的共享S锁，此时如果T2想要获取改行的排它X锁是不能立即获取的
15+
16+
## 意向锁(Intention Locks)
17+
18+
意向锁是一种`表锁`，支持多粒度锁定（multiple granularity locking），允许行锁和表锁共存。
19+
20+
1. 意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁
21+
2. 意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁
22+
23+
> 举个例子：
24+
>
25+
> SELECT ... FOR SHARE 设置的是意向共享锁（IS锁）
26+
> SELECT ... FOR UPDATE 设置的是意向排它锁（IX锁）
27+
28+
意向锁的协议如下：
29+
30+
1. 一个事务在获取共享S锁之前，需要获取意向共享锁（IS锁）或者更强的锁；
31+
2. 一个事务在获取排它X锁之前，需要获取意向排它锁（IX锁）。
32+
33+
| | X |IX |S |IS
34+
--|-----------|---------|-----------|--
35+
X | Conflict |Conflict | Conflict |Conflict
36+
IX| Conflict |Compatible| Conflict|Compatible
37+
S | Conflict |Conflict |Compatible |Compatible
38+
IS| Conflict |Compatible| Compatible|Compatible
39+
40+
## 记录锁(Record Locks)
41+
42+
锁住`索引记录`。
43+
44+
例如： `select * from t where id = 10 for update` 对于id=10的记录的修改，插入，删除操作都会失败。（而普通的`select * from t where id = 10` 在RR隔离级别下只是`快照读`(SnapShot Read)，并不加锁）
45+
46+
## 间隙锁(Gap Locks)
47+
48+
间隙锁是在索引的间隙加的锁，主要目的是为了防止其他事务在间隔中插入数据，以导致`不可重复读`。
49+
50+
如果事务隔离级别降低为读提交（Read Commited, RC）则间隙锁会失效。
51+
52+
例如，`SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;`将阻止其他事务将值15插入到列t.c1中，无论列中是否已存在任何此类值，因为该范围内所有现有值之间的间隔都被锁定。但是可以进行范围内的值的UPDATE操作。
53+
54+
## 临键锁(Next-key Locks)
55+
56+
临键锁，是记录锁与间隙锁的组合，它的封锁范围，既包含索引记录，又包含索引区间。
57+
58+
临键锁的主要目的，是为了避免幻读(Phantom Read)
59+
60+
## 插入意向锁(Insert Intention Locks)
61+
62+
多个事务，在同一个索引，同一个范围区间插入记录时，如果插入的位置不冲突，不会阻塞彼此。
63+
64+
## 自增锁(Auto-inc Locks)
65+
66+
自增锁是一种特殊的表级别锁（table-level lock），专门针对事务插入AUTO_INCREMENT类型的列。最简单的情况，如果一个事务正在往表中插入记录，所有其他事务的插入必须等待，以便第一个事务插入的行，是连续的主键值。
67+
68+
使用[innodb_autoinc_lock_mode](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_autoinc_lock_mode)可以配置自增锁的行为，它允许你选择如何在可预测的自动增量值序列和插入操作的最大并发之间进行权衡。
69+
70+
```SQL
71+
-- 数据库状态
72+
SHOW ENGINE INNODB STATUS;
73+
74+
-- 数据库事务锁的状态
75+
USE INFORMATION_SCHEMA
76+
SELECT * FROM INNODB_LOCK_WAITS;
77+
78+
-- 事务详情
79+
SELECT * FROM INNODB_LOCKS
80+
WHERE LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM INNODB_LOCK_WAITS);
81+
OR
82+
SELECT INNODB_LOCKS.*
83+
FROM INNODB_LOCKS
84+
JOIN INNODB_LOCK_WAITS
85+
ON (INNODB_LOCKS.LOCK_TRX_ID = INNODB_LOCK_WAITS.BLOCKING_TRX_ID);
86+
87+
-- 具体表的锁情况
88+
SELECT * FROM INNODB_LOCKS
89+
WHERE LOCK_TABLE = db_name.table_name;
90+
A list of transactions waiting for locks:
91+
92+
--事务状态
93+
SELECT TRX_ID, TRX_REQUESTED_LOCK_ID, TRX_MYSQL_THREAD_ID, TRX_QUERY
94+
FROM INNODB_TRX
95+
WHERE TRX_STATE = 'LOCK WAIT';
96+
97+
[事务隔离级别]({{ site.blog_url }}/2019/01/10/db_isolation.html)
98+
[InnoDB并发插入，居然使用意向锁](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961461&idx=1&sn=b73293c71d8718256e162be6240797ef&chksm=bd2d0da98a5a84bfe23f0327694dbda2f96677aa91fcfc1c8a5b96c8a6701bccf2995725899a&scene=21#wechat_redirect)
99+
[InnoDB，select为啥会阻塞insert](https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961471&idx=1&sn=da257b4f77ac464d5119b915b409ba9c&chksm=bd2d0da38a5a84b5fc1417667fe123f2fbd2d7610b89ace8e97e3b9f28b794ad147c1290ceea&scene=21#wechat_redirect)
100+
[innnodb consistent read](https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html)

0 commit comments

Comments
 (0)