據外媒報導，特斯拉將推出Model S P100D車型，新車的綜合性能更強，最大續航里程可達530公里。

Model S P90D與Model S P85D相同，都採用了前後雙電動馬達的配置，但前者進一步強化了電動馬達的馬力輸出表現，安置於前輪的電動馬達可輸出190千瓦的最大功率，後輪的電動馬達則可提供高達370千瓦的最大功率，使得Model S P90D的最大綜合輸出馬力達到驚人的560千瓦。在Model S P90D車型上，特斯拉還新增了動力更加強勁的Ludicrous競速模式，它可讓車輛百公里加速秒數縮短10%，僅需2.8秒即可完成，極速則可達到250公里/小時。

在動力系統方面，Model S P100D車型將搭載功率為100千瓦時的電池里程套件，並搭載雙電機，以及四驅系統。新車的百公里加速時間為2.7秒，最大續航里程可能超過530公里。相較於特斯拉旗下的現款最強車型Model S P90D增加了40公里的續航里程，並縮短了0.6秒的百公里加速時間。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

目錄

今天我們來聊聊“鏈表（Linked list）”這個數據結構。

在我們上一章中棧與隊列底層都是採用順序存儲的這種方式的，而今天要聊的鏈表則是採用鏈式存儲，鏈表可以說是繼數組之後第二種使用得最廣泛的通用數據結構了,可見其重要性！

相比，鏈表是一種稍微複雜一點的數據結構。對於初學者來說，掌握起來也要比數組稍難一些。這兩個非常基礎、非常常用的數據結構，我們常常將會放到一塊兒來比較。所以我們先來看，這兩者有什麼區別。數組需要一塊連續的內存空間來存儲，對內存的要求比較高。而鏈表恰恰相反，它並不需要一塊連續的內存空間，它通過“指針”將一組零散的內存塊串聯起來使用,鏈表結構五花八門，今天我重點給你介紹三種最常見的鏈表結構，它們分別是：單鏈表、雙向鏈表和循環鏈表。

鏈表通過指針將一組零散的內存塊串聯在一起。其中，我們把內存塊稱為鏈表的“結點”。為了將所有的結點串起來，每個鏈表的結點除了存儲數據之外，還需要記錄鏈上的下一個結點的地址。而尾結點特殊的地方是：指針不是指向下一個結點，而是指向一個空地址NULL，表示這是鏈表上最後一個結點。

@

單鏈表

package demo2;

//一個節點
public class Node {

    //節點內容
    int data;
    //下一個節點
    Node next;
    
    public Node(int data) {
        this.data=data;
    }
    
    //為節點追回節點
    public Node append(Node node) {
        //當前節點
        Node currentNode = this;
        //循環向後找
        while(true) {
            //取出下一個節點
            Node nextNode = currentNode.next;
            //如果下一個節點為null,當前節點已經是最後一個節點
            if(nextNode==null) {
                break;
            }
            //賦給當前節點
            currentNode = nextNode;
        }
        //把需要追回的節點追加為找到的當前節點的下一個節點
        currentNode.next=node;
        return this;
    }
    
    //插入一個節點做為當前節點的下一個節點
    public void after(Node node) {
        //取出下一個節點，作為下下一個節點
        Node nextNext = next;
        //把新節點作為當前節點的下一個節點
        this.next=node;
        //把下下一個節點設置為新節點的下一個節點
        node.next=nextNext;
    }
    
    //显示所有節點信息
    public void show() {
        Node currentNode = this;
        while(true) {
            System.out.print(currentNode.data+" ");
            //取出下一個節點
            currentNode=currentNode.next;
            //如果是最後一個節點
            if(currentNode==null) {
                break;
            }
        }
        System.out.println();
    }
    
    //刪除下一個節點
    public void removeNext() {
        //取出下下一個節點
        Node newNext = next.next;
        //把下下一個節點設置為當前節點的下一個節點。
        this.next=newNext;
    }
    
    //獲取下一個節點
    public Node next() {
        return this.next;
    }
    
    //獲取節點中的數據
    public int getData() {
        return this.data;
    }
    
    //當前節點是否是最後一個節點
    public boolean isLast() {
        return next==null;
    }
    
}

單鏈表測試類

package demo2.test;

import demo2.Node;

public class TestNode {
    
    public static void main(String[] args) {
        //創建節點
        Node n1 = new Node(1);
        Node n2 = new Node(2);
        Node n3 = new Node(3);
        //追加節點
        n1.append(n2).append(n3).append(new Node(4));
        //取出下一個節點的數據
//      System.out.println(n1.next().next().next().getData());
        //判斷節點是否為最後一個節點
//      System.out.println(n1.isLast());
//      System.out.println(n1.next().next().next().isLast());
        
        //显示所有節點內容
        n1.show();
        //刪除一個節點
//      n1.next().removeNext();
        //显示所有節點內容
//      n1.show();
        //插入一個新節點
        Node node = new Node(5);
        n1.next().after(node);
        n1.show();
    }

}

鏈表要想隨機訪問第k個元素，就沒有數組那麼高效了。因為鏈表中的數據並非連續存儲的，所以無法像數組那樣，根據首地址和下標，通過尋址公式就能直接計算出對應的內存地址，而是需要根據指針一個結點一個結點地依次遍歷，直到找到相應的結點。

你可以把鏈表想象成一個隊伍，隊伍中的每個人都只知道自己後面的人是誰，所以當我們希望知道排在第k位的人是誰的時候，我們就需要從第一個人開始，一個一個地往下數。所以，鏈表隨機訪問的性能沒有數組好，需要O(n)的時間複雜度。

雙向鏈表

接下來我們再來看一個稍微複雜的，在實際的軟件開發中，也更加常用的鏈表結構：雙向鏈表。單向鏈表只有一個方向，結點只有一個後繼指針next指向後面的結點。而雙向鏈表，顧名思義，它支持兩個方向，每個結點不止有一個後繼指針next指向後面的結點，還有一個前驅指針prev指向前面的結點。

public class DoubleNode {
    //上一個節點
    DoubleNode pre=this;
    //下一個節點
    DoubleNode next=this;
    //節點數據
    int data;
    
    public DoubleNode(int data) {
        this.data=data;
    }
    
    //增節點
    public void after(DoubleNode node) {
        //原來的下一個節點
        DoubleNode nextNext = next;
        //把新節點做為當前節點的下一個節點
        this.next=node;
        //把當前節點做新節點的前一個節點
        node.pre=this;
        //讓原來的下一個節點作新節點的下一個節點
        node.next=nextNext;
        //讓原來的下一個節點的上一個節點為新節點
        nextNext.pre=node;
    }
    
    //下一個節點
    public DoubleNode next() {
        return this.next;
    }
    
    //上一個節點
    public DoubleNode pre() {
        return this.pre;
    }
    
    //獲取數據
    public int getData() {
        return this.data;
    }
    
}

雙向鏈表測試

import demo2.DoubleNode;

public class TestDoubleNode {

    public static void main(String[] args) {
        //創建節點
        DoubleNode n1 = new DoubleNode(1);
        DoubleNode n2 = new DoubleNode(2);
        DoubleNode n3 = new DoubleNode(3);
        //追加節點
        n1.after(n2);
        n2.after(n3);
        //查看上一個，自己，下一個節點的內容
        System.out.println(n2.pre().getData());
        System.out.println(n2.getData());
        System.out.println(n2.next().getData());
        System.out.println(n3.next().getData());
        System.out.println(n1.pre().getData());
        
    }
    
}

單鏈表VS雙向鏈表

如果我們希望在鏈表的某個指定結點前面插入一個結點或者刪除操作，雙向鏈表比單鏈表有很大的優勢。雙向鏈表可以在O(1)時間複雜度搞定，而單向鏈表需要O(n)的時間複雜度，除了插入、刪除操作有優勢之外，對於一個有序鏈表，雙向鏈表的按值查詢的效率也要比單鏈表高一些。因為，我們可以記錄上次查找的位置p，每次查詢時，根據要查找的值與p的大小關係，決定是往前還是往後查找，所以平均只需要查找一半的數據。

現在，你有沒有覺得雙向鏈表要比單鏈表更加高效呢？這就是為什麼在實際的軟件開發中，雙向鏈表儘管比較費內存，但還是比單鏈表的應用更加廣泛的原因。如果你熟悉Java語言，你肯定用過LinkedHashMap這個容器。如果你深入研究LinkedHashMap的實現原理，就會發現其中就用到了雙向鏈表這種數據結構。實際上，這裡有一個更加重要的知識點需要你掌握，那就是用空間換時間的設計思想。當內存空間充足的時候，如果我們更加追求代碼的執行速度，我們就可以選擇空間複雜度相對較高、但時間複雜度相對很低的算法或者數據結構。相反，如果內存比較緊缺，比如代碼跑在手機或者單片機上，這個時候，就要反過來用時間換空間的設計思路。

循環鏈表

循環鏈表是一種特殊的單鏈表。實際上，循環鏈表也很簡單。它跟單鏈表唯一的區別就在尾結點。我們知道，單鏈表的尾結點指針指向空地址，表示這就是最後的結點了。而循環鏈表的尾結點指針是指向鏈表的頭結點。和單鏈表相比，循環鏈表的優點是從鏈尾到鏈頭比較方便。當要處理的數據具有環型結構特點時，就特別適合採用循環鏈表。比如著名的約瑟夫問題。儘管用單鏈表也可以實現，但是用循環鏈表實現的話，代碼就會簡潔很多。

package demo2;

//一個節點
public class LoopNode {

    //節點內容
    int data;
    //下一個節點
    LoopNode next=this;
    
    public LoopNode(int data) {
        this.data=data;
    }
    
    //插入一個節點做為當前節點的下一個節點
    public void after(LoopNode node) {
        //取出下一個節點，作為下下一個節點
        LoopNode nextNext = next;
        //把新節點作為當前節點的下一個節點
        this.next=node;
        //把下下一個節點設置為新節點的下一個節點
        node.next=nextNext;
    }
    
    //刪除下一個節點
    public void removeNext() {
        //取出下下一個節點
        LoopNode newNext = next.next;
        //把下下一個節點設置為當前節點的下一個節點。
        this.next=newNext;
    }
    
    //獲取下一個節點
    public LoopNode next() {
        return this.next;
    }
    
    //獲取節點中的數據
    public int getData() {
        return this.data;
    }
    
}

循環鏈表測試

package demo2.test;

import demo2.LoopNode;

public class TestLoopNode {

    public static void main(String[] args) {
        LoopNode n1 = new LoopNode(1);
        LoopNode n2 = new LoopNode(2);
        LoopNode n3 = new LoopNode(3);
        LoopNode n4 = new LoopNode(4);
        //增加節點
        n1.after(n2);
        n2.after(n3);
        n3.after(n4);
        System.out.println(n1.next().getData());
        System.out.println(n2.next().getData());
        System.out.println(n3.next().getData());
        System.out.println(n4.next().getData());
    }

}

最後，我們再對比一下數組，數組的缺點是大小固定，一經聲明就要佔用整塊連續內存空間。如果聲明的數組過大，系統可能沒有足夠的連續內存空間分配給它，導致“內存不足（out of memory）”。如果聲明的數組過小，則可能出現不夠用的情況。這時只能再申請一個更大的內存空間，把原數組拷貝進去，非常費時。鏈表本身沒有大小的限制，天然地支持動態擴容，我覺得這也是它與數組最大的區別。

你可能會說，我們Java中的ArrayList容器，也可以支持動態擴容啊？事實上當我們往支持動態擴容的數組中插入一個數據時，如果數組中沒有空閑空間了，就會申請一個更大的空間，將數據拷貝過去，而數據拷貝的操作是非常耗時的。

我舉一個稍微極端的例子。如果我們用ArrayList存儲了了1GB大小的數據，這個時候已經沒有空閑空間了，當我們再插入數據的時候，ArrayList會申請一個1.5GB大小的存儲空間，並且把原來那1GB的數據拷貝到新申請的空間上。聽起來是不是就很耗時？

除此之外，如果你的代碼對內存的使用非常苛刻，那數組就更適合你。因為鏈表中的每個結點都需要消耗額外的存儲空間去存儲一份指向下一個結點的指針，所以內存消耗會翻倍。而且，對鏈表進行頻繁的插入、刪除操作，還會導致頻繁的內存申請和釋放，容易造成內存碎片，如果是Java語言，就有可能會導致頻繁的GC（Garbage Collection，垃圾回收）。

所以，在我們實際的開發中，針對不同類型的項目，要根據具體情況，權衡究竟是選擇數組還是鏈表！

如果本文對你有一點點幫助，那麼請點個讚唄，謝謝~

最後，若有不足或者不正之處，歡迎指正批評，感激不盡！如果有疑問歡迎留言，絕對第一時間回復！

歡迎各位關注我的公眾號，一起探討技術，嚮往技術，追求技術，說好了來了就是盆友喔…

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

據悉，寶馬高層最新證實，i品牌的第三款車型i5將會是一台電動車，而非之前所傳聞的燃料電池車或者是插電式混合動力車。不過他也表示，i5除了純電動版本，也會像i3那樣擁有一款增程車型。

寶馬全新i5假想圖

至於i5的車身形式目前仍然是一個迷，但從各方消息以及寶馬高層的暗示來看，這是一台家庭定位的車型，所以它選擇SUV造型的可能性應該是最大的。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

普通相機抖動腳本較易實現，但在使用cinemachine相機下，其Transform組件不可被代碼修改，那麼Cinemachine的相機抖動如何實現呢？本文結合實際項目，對實現相機抖動的三大步驟進行系統講解：

• 項目地址：

配置流程

項目背景：一款2D像素動作遊戲，我們操控着Player（必須帶有Collider組件），遊戲相機為Cinemachine 2DCamera（關於其配置方法此處不做贅述，推薦文章在末尾參考處）

1. 在相機上添加監聽腳本

在我們使用的虛擬相機 CM vcam1 上添加組件：AddComponent->CinemachineImpulse Listener

• CinemachineImpulse Listener：監聽腳本內震動信號（方法調用），使得抖動在此相機上發生
  • Channel Mask：通道遮罩，此處最好默認為EveryThing
  • Gain：可獲得震動信號的數目，0為屏蔽，1表示某時段僅能進行一個抖動運動
  • Use 2D Distance：用於2D遊戲，忽略相機Z軸的抖動

2. 在震動信號發生物體上添加腳本

震動信號發生物體（調用震動函數的物體）為Player，因此需要在Player上添加組件：AddComponent->Cinemachine Collision Impulse Source（注：必須掛到含Collider的物體上），然後在Raw Signal右側齒輪->New Noise Settings 添加震動配置器，默認名CM vcam1 Raw Signal

• Cinemachine Collision Impulse Source：含有抖動函數、震動配置器的關鍵腳本
  • Raw Signal：震動配置器，配置震動參數的關鍵部件，我們打開剛上面新建的CM vcam1 Raw Signal，可看到震動方式的各類參數。我們以Position Y，即上下抖動為例，添加Components后可設置其Frequency震頻及Amplitude震幅，並且勾選右側方框可將其設置為正弦波
  • Attack：抖動開始的變化曲線及時間
  • Sustain Time：抖動的持續時間
  • Decay：抖動衰退的變化曲線及時間

3. 調用震動方法：

在Player內引用震動核心腳本，並在合適位置調用震動方法

private Cinemachine.CinemachineCollisionImpulseSource MyInpulse;

private void Start()
{
    MyInpulse = GetComponent<Cinemachine.CinemachineCollisionImpulseSource>();
}

private void Update()
{
    //按下右鍵產生相機抖動，抖動方式依照上面CM vcam1 Raw Signal內配置信息
    if (Input.GetMouseButtonDown(1))
        MyInpulse.GenerateImpulse();       
}

至此，我們在遊戲內操控Player，按下右鍵即可實現相機抖動。當然除了上面無參的GenerateImpulse()方法，還有兩個帶參的方法：

//假若使用傳遞velocity的方法，其震動方式為velocity和CM vcam1 Raw Signal的混合
public void GenerateImpulse(Vector3 velocity);
public void GenerateImpulse(Vector3 position, Vector3 velocity);

此外，還有可能出現bug：還尚未調用震動函數，遊戲開始時就自動產生抖動。其產生原因博主尚未在對應腳本內發現，但解決方式為關閉Player上的Cinemachine Collision Impulse Source腳本

總述

Cinemachine中實現相機抖動的基本流程：

• 在虛擬相機上添加監聽腳本 CinemachineImpulse Listener
• 在Player上添加震動核心腳本Cinemachine Collision Impulse Source，並添加、設置震動配置器
• Player腳本合適位置調用震動函數

本例僅介紹了單Position方向上的抖動，讀者可按需配置抖動的Position、Rotation、發生時間、維持時間、衰退時間等，實現自己想要的效果

參考

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

今天周末，和大家聊聊學習這件事情。

在如今這個社會，我們的時間被各類 APP 撕的粉碎。

刷知乎、刷微博、刷朋友圈；

看論壇、看博客、看公號；

等等形形色色的信息和知識獲取方式一個都不錯過。

貌似學了很多，但是卻感覺沒什麼用。

要解決上面這些問題，首先要分清楚一點，什麼是信息，什麼是知識。

• 那什麼是信息呢？

你一切聽到的、看到的，都是信息，比如微博上的明星出軌、微信中的表情大戰、抖音上的段子視頻。

• 那什麼是知識呢？

就是指那些被驗證過的、正確的、被人們相信的概念、規律、方法論。

概念是什麼很好理解，我們上學的時候做的最多的一件事情就是背概念。

規律是事物背後的運行法則，例如當市場上某一種貨物供應量減少后，就會導致價格的上升。

方法論俗稱【套路】，解決某一類問題的時候，有效的解決方案。

信息有真假，有時效，而知識有積累、有迭代。我們要學習的是知識，而不是信息。

時間複利

再說一個概念，複利。

這個大家都應該知道，比較多的應該是在銀行存錢或者是購買理財產品的時候，比如下圖的銀行複利增長曲線：

或者是下面這個公式：

1.01^365 = 37.8

隨公式還附贈一句雞湯：

如果一個人每天都能進步 1%，一年之後他的能力會提升 38 倍。

這句話雖然聽起來很雞湯，但是卻想不到有什麼問題，對吧？

反過來想一下這句話的前提，一個人都想要每天都能進步 1% ，這可能么？當然排除一些極端情況，對於看到我文章的大多數人來說，這是一件不可能的事情。

每天會形形色色的事情去阻止我們進步這 1% ，比如：

• 今天上班被領導批了，心情不好，不想學習了
• 今天工作太忙了，下班后時間都比較晚了，想要休息了
• 今天和朋友一起出去玩了，玩的很開心
• …

等等，然後我們看到身邊優秀的人的時候：

• 看到他們隨隨便便就考試考出來好成績
• 看到他們隨手寫的文章就是網絡爆文
• 看到他們對於某一項技術非常精通的時候

是不是會有一種無力感，好像他們平時和我們一樣，該吃吃該喝喝該玩玩，但是人家就是很厲害的樣子。

於是，就產生了強烈的焦慮感，要學習，要提高自己，開始看更多的信息，關注更多的學習圈子，焦慮感加重，負向循環開始了。

但是，如果你肯相信時間複利的效應，就不會焦慮。

Why？

你現在看到身邊的人的成績，看到他輕輕鬆松做到的事情，即使你拼盡全力也不可能做到。

從一開始你就錯了，他們已經完成了自己的原始積累，他們已經到達了這件事情的複利拐點 。

什麼是複利拐點？

圖中這個小人站的位置就是複利拐點，

如果一個人到達複利拐點（圖中小人站的地方），那他的收益，會急劇增長，可能比之前所有時間的收益總和還要多。

這裏的收益可以是錢，是能力，是認知。

知識

上面我們介紹了如何區分信息和知識，這裏再分享一個個人理解，有效知識。

判斷一個知識是否有效，就要看這個知識和你之前的已有的知識是否能產生聯繫。

如果可以產生聯繫，那麼你對這個新的知識理解速度會非常的快。

就好比編程語言，小編的本職工作是一名 Java 軟件工程師，但是當小編去學習 Python 的相關基礎知識的時候，速度是非常快的，用旁人的視角看起來就好像小編的學習效率非常的高效。

當然，我們不可能只學習和自己已有知識相關方向的知識，可能會接觸一些完全陌生的領域，那麼這個時候如何還能保持效率較高的學習？

在進入一個新的領域的時候，所有的知識都是一個點一個點的，好像是散落在沙子里的石頭，中間是毫無關聯的，這個時間段的學習是非常痛苦的，小編一般稱為原始積累階段。

很多人在原始積累的階段因為過程過於痛苦，就慢慢的放棄了。

在痛苦的原始積累階段，很多時候看不到盡頭，之前的學習感覺都學過，但是仔細一想，又好像什麼都沒學。

這時，我們可以藉助工具去加強知識之間的關聯和加深自己的記憶——思維導圖。

這個工具小編也經常在用的，比如很多人可能都見過我的公眾號上小編自己整理的 Java 進階相關的思維導圖。

當學習一個新的領域的時候，每當一些基礎的概念能產生聯繫的時候，就可以去畫這麼一張思維導圖，思維導圖能讓我們更清晰直觀的理解不同的事物之間的內在聯繫。

長時間的原始積累太過痛苦怎麼辦？

這個是所有人都會遇到的問題，做一件事情，尤其是學習，當我們無法取得一些成果的時候，對興趣和自信的打擊都會非常的大。

首先在做這件事情之前，你需要為自己找到足夠開始這件事情的理由，也就是要有強大的內驅力。

就好比考研這件事情，如果是身邊的人要考，所以你也要考，那麼我覺得你到底要不要考研這件事情值得再思考一下。

但如果是說你想通過考研，來改變自己的人生軌跡，想要獲得更高的起點，那麼，我覺得這個事兒十有八九你是能堅持下去的。

好比學習 Python ，好像身邊的人都在學，那我也要了解一下，和那種我想要學 Python 來換一份工作，擺脫目前的工作狀態，獲取更高的薪水。

大家可能看着沒什麼感覺，但是想一想，自己的人生中，到底有沒有過堅持某一件事情，並最終獲得了一個還不錯的結果，最後收穫的這份快感，是不是無與倫比的。

當然，除了強大的內驅力以外，小編還可以友情提供一點小技巧。

獲取階段性的正向反饋。

如果一件事情需要耗費較長的時間，那麼再大的內驅力也可能會被時間的流逝給磨平了。

靜靜思考下放棄的原因，沒有獲得成就感。

還是拿考研舉例子，一般考研需要準備大半年到一年左右的時間，很多人都堅持不過半年時間就放棄掉了，為什麼，因為他們看不到成效，看不到曙光。但是高三的高考很多人還是能堅持下來的，為什麼？

因為高三有月考啊，每次月考完，都能準確的知道自己的水平提升了多少，自己一個月的努力是沒有白費的，自己一個月的努力是真真實實的化成了卷子上的分數。

所以，做一件需要長時間奮戰的事情，最好能提前為自己設定一些階段性的成果檢驗方式。

時間管理

時間管理是一個繞不開的話題，這裏小編其實也沒資格談這件事情，因為小編本身的時間管理也做的並不好，小編也是人，加完班也會感覺到累，回到家也會只想着休息，人非聖賢，對吧。

還是分享一些經驗吧。

嘗試將自己一天做的事情和耗費的時間列一個表格出來（小編之前列舉過，時間有些久遠，找不到了，這裏就不放圖了）。

當這個表格列出來以後，不管多麼自律的人，肯定會發現，一天之中，有相當部分的時間是被浪費掉的，比如刷朋友圈，刷抖音，刷微博。

在生活中，肯定會經常性的出現這樣事情。

“再玩5分鐘手機就睡覺！”

結果12點了還在玩手機。

周末早晨起來，“先玩一局遊戲，在做xxx”。

結果就是玩到了下午。

相信我，那些墮落的人，並不是一開始就想墮落的。

他們只是在被生活中形形色色的誘惑給誘惑到了，因為現在的社會，各個 APP 在掏空了心思去搶佔用戶的留存時長，它們費勁心力的去討好用戶，讓用戶用最簡單最不需要付出的方式去獲得這種毫無意義的低成本的快樂。

所以，開始記錄自己的時間，是做時間管理的第一步。

當然，並不是要我們完全的放棄娛樂時間，這不可能，人不是機器，不可能是只要有電，就能工作，人也是需要休息的，記錄時間只是為了讓我們在面臨選擇的時候，做出正確的選擇。

第一次寫這種長篇內容分享，有內容不當的地方請各位同學海涵。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?

Redis 提供了兩種持久化方式，一種是基於快照形式的 RDB，另一種是基於日誌形式的 AOF，每種方式都有自己的優缺點，本文將介紹 Redis 這兩種持久化方式，希望閱讀本文後你對 Redis 的這兩種方式有更加全面、清晰的認識。

RDB 快照方式持久化

先從 RDB 快照方式聊起，RDB 是 Redis 默認開啟的持久化方式，並不需要我們單獨開啟，先來看看跟 RDB 相關的配置信息：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#   save ""
# 自動生成快照的觸發機制 中間的是時間，單位秒，後面的是變更數據 60 秒變更 10000 條數據則自動生成快照
save 900 1
save 300 10
save 60 10000

# 生成快照失敗時，主線程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否採用壓縮算法存儲
rdbcompression yes

# 數據恢復時是否檢測 RDB文件有效性
rdbchecksum yes

# The filename where to dump the DB
# RDB 快照生成的文件名稱
dbfilename dump.rdb

# 快照生成的路徑 AOF 也是存放在這個路徑下面
dir .

關於 RDB 相關配置信息不多，需要我們調整的就更少了，我們只需要根據自己的業務量修改生成快照的機制和文件存放路徑即可。

RDB 有兩種持久化方式：手動觸發 和 自動觸發，手動觸發使用以下兩個命令：

• save：會阻塞當前 Redis 服務器響應其他命令，直到 RDB 快照生成完成為止，對於內存 比較大的實例會造成長時間阻塞，所以線上環境不建議使用

• bgsave：Redis 主進程會 fork 一個子進程，RDB 快照生成有子進程來負責，完成之後，子進程自動結束，bgsave 只會在 fork 子進程的時候短暫的阻塞，這個過程是非常短的，所以推薦使用該命令來手動觸發

除了執行命令手動觸發之外，Redis 內部還存在自動觸發 RDB 的持久化機制，在以下幾種情況下 Redis 會自動觸發 RDB 持久化：

• 在配置中配置了 save 相關配置信息，如我們上面配置文件中的 save 60 10000 ，也可以把它歸類為“save m n”格式的配置，表示 m 秒內數據集存在 n 次修改時，會自動觸發 bgsave。

• 在主從情況下，如果從節點執行全量複製操作，主節點自動執行 bgsave 生成 RDB 文件併發送給從節點

• 執行 debug reload 命令重新加載 Redis 時，也會自動觸發 save 操作

• 默認情況下執行 shutdown 命令時，如果沒有開啟 AOF 持久化功能則自動執行 bgsave

上面就是 RDB 持久化的方式，可以看出 save 命令使用的比較少，大多數情況下使用的都是 bgsave 命令，所以這個 bgsave 命令還是有一些東西，那接下來我們就一起看看 bgsave 背後的原理，先從流程圖開始入手：

bgsave 命令大概有以下幾個步驟：

• 1、執行 bgsave 命令，Redis 主進程判斷當前是否存在正在執行的 RDB/AOF 子進程，如果存在， bgsave 命令直接返回不在往下執行。
• 2、父進程執行 fork 操作創建子進程，fork 操作過程中父進程會阻塞，fork 完成後父進程將不在阻塞可以接受其他命令。
• 3、子進程創建新的 RDB 文件，基於父進程當前內存數據生成臨時快照文件，完成後用新的 RDB 文件替換原有的 RDB 文件，並且給父進程發送 RDB 快照生成完畢通知

上面就是 bgsave 命令背後的一些內容，RDB 的內容就差不多了，我們一起來總結 RDB 持久化的優缺點，RDB 方式的優點：

• RDB 快照是某一時刻 Redis 節點內存數據，非常適合做備份，上傳到遠程服務器或者文件系統中，用於容災備份
• 數據恢復時 RDB 要遠遠快於 AOF

有優點同樣存在缺點，RDB 的缺點有：

• RDB 持久化方式數據沒辦法做到實時持久化/秒級持久化。我們已經知道了 bgsave 命令每次運行都要執行 fork 操作創建子進程，屬於重量級操作，頻繁執行成本過高。
• RDB 文件使用特定二進制格式保存，Redis 版本演進過程中有多個格式 的 RDB 版本，存在老版本 Redis 服務無法兼容新版 RDB 格式的問題

如果我們對數據要求比較高，每一秒的數據都不能丟，RDB 持久化方式肯定是不能夠滿足要求的，那 Redis 有沒有辦法滿足呢，答案是有的，那就是接下來的 AOF 持久化方式

AOF 持久化方式

Redis 默認並沒有開啟 AOF 持久化方式，需要我們自行開啟，在 redis.conf 配置文件中將 appendonly no 調整為 appendonly yes，這樣就開啟了 AOF 持久化，與 RDB 不同的是 AOF 是以記錄操作命令的形式來持久化數據的，我們可以查看以下 AOF 的持久化文件 appendonly.aof

*2
$6
SELECT
$1
0
*3
$3
set
$6
mykey1
$6
你好
*3
$3
set
$4
key2
$5
hello
*1
$8

大概就是長這樣的，具體的你可以查看你 Redis 服務器上的 appendonly.aof 配置文件，這也意味着我們可以在 appendonly.aof 文件中國修改值，等 Redis 重啟時將會加載修改之後的值。看似一些簡單的操作命令，其實從命令到 appendonly.aof 這個過程中非常有學問的，下面時 AOF 持久化流程圖：

在 AOF 持久化過程中有兩個非常重要的操作：一個是將操作命令追加到 AOF_BUF 緩存區，另一個是 AOF_buf 緩存區數據同步到 AOF 文件，接下來我們詳細聊一聊這兩個操作：

1、為什麼要將命令寫入到 aof_buf 緩存區而不是直接寫入到 aof 文件？

我們知道 Redis 是單線程響應，如果每次寫入 AOF 命令都直接追加到磁盤上的 AOF 文件中，這樣頻繁的 IO 開銷，Redis 的性能就完成取決於你的機器硬件了，為了提升 Redis 的響應效率就添加了一層 aof_buf 緩存層， 利用的是操作系統的 cache 技術，這樣就提升了 Redis 的性能，雖然這樣性能是解決了，但是同時也引入了一個問題，aof_buf 緩存區數據如何同步到 AOF 文件呢？由誰同步呢？這就是我們接下來要聊的一個操作：fsync 操作

2、aof_buf 緩存區數據如何同步到 aof 文件中？

aof_buf 緩存區數據寫入到 aof 文件是有 linux 系統去完成的，由於 Linux 系統調度機制周期比較長，如果系統故障宕機了，意味着一個周期內的數據將全部丟失，這不是我們想要的，所以 Linux 提供了一個 fsync 命令，fsync 是針對單個文件操作（比如這裏的 AOF 文件），做強制硬盤同步，fsync 將阻塞直到寫入硬盤完成后返回，保證了數據持久化，正是由於有這個命令，所以 redis 提供了配置項讓我們自行決定何時進行磁盤同步，redis 在 redis.conf 中提供了appendfsync 配置項，有如下三個選項：

# appendfsync always
appendfsync everysec
# appendfsync no

• always：每次有寫入命令都進行緩存區與磁盤數據同步，這樣保證不會有數據丟失，但是這樣會導致 redis 的吞吐量大大下降，下降到每秒只能支持幾百的 TPS ，這違背了 redis 的設計，所以不推薦使用這種方式
• everysec：這是 redis 默認的同步機制，雖然每秒同步一次數據，看上去時間也很快的，但是它對 redis 的吞吐量沒有任何影響，每秒同步一次的話意味着最壞的情況下我們只會丟失 1 秒的數據， 推薦使用這種同步機制，兼顧性能和數據安全
• no：不做任何處理，緩存區與 aof 文件同步交給系統去調度，操作系統同步調度的周期不固定，最長會有 30 秒的間隔，這樣出故障了就會丟失比較多的數據。

這就是三種磁盤同步策略，但是你有沒有注意到一個問題，AOF 文件都是追加的，隨着服務器的運行 AOF 文件會越來越大，體積過大的 AOF 文件對 redis 服務器甚至是主機都會有影響，而且在 Redis 重啟時加載過大的 AOF 文件需要過多的時間，這些都是不友好的，那 Redis 是如何解決這個問題的呢？Redis 引入了重寫機制來解決 AOF 文件過大的問題。

3、Redis 是如何進行 AOF 文件重寫的？

Redis AOF 文件重寫是把 Redis 進程內的數據轉化為寫命令同步到新 AOF 文件的過程，重寫之後的 AOF 文件會比舊的 AOF 文件占更小的體積，這是由以下幾個原因導致的：

• 進程內已經超時的數據不再寫入文件
• 舊的 AOF 文件含有無效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進程內數據直接生成，這樣新的AOF文件只保 留最終數據的寫入命令
• 多條寫命令可以合併為一個，如：lpush list a、lpush list b、lpush list c可以轉化為：lpush list a b c。為了防止單條命令過大造成客戶端緩衝區溢 出，對於 list、set、hash、zset 等類型操作，以 64 個元素為界拆分為多條。

重寫之後的 AOF 文件體積更小了，不但能夠節約磁盤空間，更重要的是在 Redis 數據恢復時，更小體積的 AOF 文件加載時間更短。AOF 文件重寫跟 RDB 持久化一樣分為手動觸發和自動觸發，手動觸發直接調用 bgrewriteaof 命令就好了，我們後面會詳細聊一聊這個命令，自動觸發就需要我們在 redis.conf 中修改以下幾個配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• auto-aof-rewrite-percentage：代表當前 AOF文件空間 （aof_current_size）和上一次重寫后 AOF 文件空間（aof_base_size）的比值，默認是 100%，也就是一樣大的時候
• auto-aof-rewrite-min-size：表示運行 AOF 重寫時 AOF 文件最小體積，默認為 64MB，也就是說 AOF 文件最小為 64MB 才有可能觸發重寫

滿足了這兩個條件，Redis 就會自動觸發 AOF 文件重寫，AOF 文件重寫的細節跟 RDB 持久化生成快照有點類似，下面是 AOF 文件重寫流程圖：

AOF 文件重寫也是交給子進程來完成，跟 RDB 生成快照很像，AOF 文件重寫在重寫期間建立了一個 aof_rewrite_buf 緩存區來保存重寫期間主進程響應的命令，等新的 AOF 文件重寫完成后，將這部分文件同步到新的 AOF 文件中，最後用新的 AOF 文件替換掉舊的 AOF 文件。需要注意的是在重寫期間，舊的 AOF 文件依然會進行磁盤同步，這樣做的目的是防止重寫失敗導致數據丟失，

Redis 持久化數據恢復

我們知道 Redis 是基於內存的，所有的數據都存放在內存中，由於機器宕機或者其他因素重啟了就會導致我們的數據全部丟失，這也就是要做持久化的原因，當服務器重啟時，Redis 會從持久化文件中加載數據，這樣我們的數據就恢復到了重啟前的數據，在數據恢復這一塊Redis 是如何實現的？我們先來看看數據恢復的流程圖：

Redis 的數據恢複流程比較簡單，優先恢復的是 AOF 文件，如果 AOF 文件不存在時則嘗試加載 RDB 文件，為什麼 RDB 的恢復速度比 AOF 文件快，但是還是會優先加載 AOF 文件呢？我個人認為是 AOF 文件數據更全面並且 AOF 兼容性比 RDB 強，需要注意的是當存在 RDB/AOF 時，如果數據加載不成功，Redis 服務啟動會失敗。

最後

目前互聯網上很多大佬都有 Redis 系列教程，如有雷同，請多多包涵了。原創不易，碼字不易，還希望大家多多支持。若文中有所錯誤之處，還望提出，謝謝。

歡迎掃碼關注微信公眾號：「平頭哥的技術博文」，和平頭哥一起學習，一起進步。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包”嚨底家”

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※小三通海運與一般國際貿易有何不同?

※小三通快遞通關作業有哪些?