ARTS Week 11

ARTS Week 11

桐人现在正要把自己所说的话付诸行动，能够做到这一点，并不是因为桐人很强，而是他愿意接受自己的懦弱，烦恼、痛苦但即便如此依旧继续向前。

---

Algoithm

奇偶链表

概述

给定一个单链表，把所有的奇数节点和偶数节点分别排在一起。请注意，这里的奇数节点和偶数节点指的是节点编号的奇偶性，而不是节点的值的奇偶性。

请尝试使用原地算法完成。你的算法的空间复杂度应为 O(1)，时间复杂度应为 O(nodes)，nodes 为节点总数。

示例 1:

输入: 1->2->3->4->5->NULL
输出: 1->3->5->2->4->NULL
示例 2:

输入: 2->1->3->5->6->4->7->NULL
输出: 2->3->6->7->1->5->4->NULL
说明:

应当保持奇数节点和偶数节点的相对顺序。
链表的第一个节点视为奇数节点，第二个节点视为偶数节点，以此类推。

分析

1. 通过位置，而不是通过里面的数值判断。

2. 画出来

代码

# Definition for singly-linked list.
class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next


class Solution:
    def oddEvenList(self, head: ListNode) -> ListNode:
        if not head:
            return head
        # 使用指针进行同步，注意，这里是通过位置判断是否为奇偶，而不是通过判断里面的位置来进行判断。
        odd = head
        even = head.next
        even_start = even

        while even and even.next:
            odd.next = even.next
            odd = odd.next

            even.next = odd.next
            even = even.next

        odd.next = even_start
        return head

总结

链表的问题都可以通过画图的形式展示出来，然后通过多指针，或者递归的方式同步

---

Review

How To Become A True Keyboard Warrior (And Stop Using Your Mouse)

概述

推崇使用键盘来提高工作效率。

文本

1. Control-Backspace / Control-Delete will eradicate the left/right word without the need to individually backspace each letter.
2. Shift plus your arrow keys lets you select text with the keyboard, add control in there and you can select whole words. Use shift and Home/End to select a whole line, use them without shift to jump to the end or start of a line. This way you can press Home-Shift-End-Backspace and a whole line is gone in a second.
3. Control-UpArrow will jump up a Paragraph in many text editors, something that I don’t use much but it’s a little faster than using just the UpArrow.
4. Control-F allows you to find words, it also allows to quickly jump down to a specific part of a website or long document when you know what you are searching for. Control-H lets you open the same window and replace words / phrases in most pograms.
5. Control-Home/End allow you to jump to the beginning/end of the document which is very useful if you went back to correct a sentence or something and then want to continue writing at the end of the document.

browser

1. Control-T will open a new tab
2. Control-W will close the current tab.
3. Control-1 through 8 will cycle through open tabs, control-9 will always jump to the last open tab to the very right.
4. Control-PageUp/Down will cycle through your open tabs, just PageUp/Down will allow you to scroll the page.
5. Speaking of scrolling the page: You can scroll down by just pressing the space bar which is easily the most convenient way to scroll down while your other hand is busy…holding the water bottle that you use to hydrate well enough and be more responsible than your peers.
6. Control-R reloads the page and is a little easier to reach than F5 which does the same thing.
7. Your URL bar is also your search bar, if you type www.google.com into your search bar to then reach for the mouse, click the already open search bar, then type the word you were actually looking for please just stop doing that.

---

Tip

redis RDB
redis 数据同步，主从一致

概述

1. 高可用：

   1. 数据尽量减少丢失
   2. 服务尽量减少中断

2. 读写分离:
   

3. 同步过程:
   

4. 网络中断后 slave_repl_offset 记录偏移量:
   

5. 常用架构 主-从-从 降低系统压力:
   

思考

引用大神 Kaito 的回答：

2核CPU、4GB内存、500G磁盘，Redis实例占用2GB，写读比例为8:2，此时做RDB持久化，产生的风险主要在于 CPU资源 和 内存资源 这2方面：

a、内存资源风险：Redis fork子进程做RDB持久化，由于写的比例为80%，那么在持久化过程中，“写实复制”会重新分配整个实例80%的内存副本，大约需要重新分配1.6GB内存空间，这样整个系统的内存使用接近饱和，如果此时父进程又有大量新key写入，很快机器内存就会被吃光，如果机器开启了Swap机制，那么Redis会有一部分数据被换到磁盘上，当Redis访问这部分在磁盘上的数据时，性能会急剧下降，已经达不到高性能的标准（可以理解为武功被废）。如果机器没有开启Swap，会直接触发OOM，父子进程会面临被系统kill掉的风险。

b、CPU资源风险：虽然子进程在做RDB持久化，但生成RDB快照过程会消耗大量的CPU资源，虽然Redis处理处理请求是单线程的，但Redis Server还有其他线程在后台工作，例如AOF每秒刷盘、异步关闭文件描述符这些操作。由于机器只有2核CPU，这也就意味着父进程占用了超过一半的CPU资源，此时子进程做RDB持久化，可能会产生CPU竞争，导致的结果就是父进程处理请求延迟增大，子进程生成RDB快照的时间也会变长，整个Redis Server性能下降。

c、另外，可以再延伸一下，老师的问题没有提到Redis进程是否绑定了CPU，如果绑定了CPU，那么子进程会继承父进程的CPU亲和性属性，子进程必然会与父进程争夺同一个CPU资源，整个Redis Server的性能必然会受到影响！所以如果Redis需要开启定时RDB和AOF重写，进程一定不要绑定CPU。

主从全量同步使用RDB而不使用AOF的原因：

1、RDB文件内容是经过压缩的二进制数据（不同数据类型数据做了针对性优化），文件很小。而AOF文件记录的是每一次写操作的命令，写操作越多文件会变得很大，其中还包括很多对同一个key的多次冗余操作。在主从全量数据同步时，传输RDB文件可以尽量降低对主库机器网络带宽的消耗，从库在加载RDB文件时，一是文件小，读取整个文件的速度会很快，二是因为RDB文件存储的都是二进制数据，从库直接按照RDB协议解析还原数据即可，速度会非常快，而AOF需要依次重放每个写命令，这个过程会经历冗长的处理逻辑，恢复速度相比RDB会慢得多，所以使用RDB进行主从全量同步的成本最低。

2、假设要使用AOF做全量同步，意味着必须打开AOF功能，打开AOF就要选择文件刷盘的策略，选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量同步数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景，其实是不需要开启AOF的。

另外，需要指出老师文章的错误：“当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。”

1、主从库连接都断开了，哪里来replication buffer呢？

2、应该不是“主从库断连后”主库才把写操作写入repl_backlog_buffer，只要有从库存在，这个repl_backlog_buffer就会存在。主库的所有写命令除了传播给从库之外，都会在这个repl_backlog_buffer中记录一份，缓存起来，只有预先缓存了这些命令，当从库断连后，从库重新发送psync $master_runid $offset，主库才能通过$offset在repl_backlog_buffer中找到从库断开的位置，只发送$offset之后的增量数据给从库即可。

有同学对repl_backlog_buffer和replication buffer理解比较混淆，我大概解释一下：

1、repl_backlog_buffer：就是上面我解释到的，它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量同步带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量同步，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量同步的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。

2、replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个 内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。

3、再延伸一下，既然有这个内存buffer存在，那么这个buffer有没有限制呢？如果主从在传播命令时，因为某些原因从库处理得非常慢，那么主库上的这个buffer就会持续增长，消耗大量的内存资源，甚至OOM。所以Redis提供了client-output-buffer-limit参数限制这个buffer的大小，如果超过限制，主库会强制断开这个client的连接，也就是说从库处理慢导致主库内存buffer的积压达到限制后，主库会强制断开从库的连接，此时主从复制会中断，中断后如果从库再次发起复制请求，那么此时可能会导致恶性循环，引发复制风暴，这种情况需要格外注意。

---

Share

ubuntu apt lock err

概述

测试环境中安装 apt-get install python3-pip ，显示lock。

按照教程 kill 进程后，依然还是不能下载，显示没有办法获取锁，这里其实已经是因为 进程 kill 后，没有释放锁，所以需要手动将相关的文档，删除后，在进行下载。