一、標準的netty線程模型

雙池合璧：

1、連接線程池：

連接線程池專門負責監聽客戶端連接請求，並完成連接的建立（包括諸如握手、安全認證等過程）。

連接的建立本身是一個極其複雜、損耗性能的過程，此處使用線程池，能夠極大的增加處理客戶端連接的能力。

2、I/O線程池：

連接線程池會將成功建立的連接註冊到後端I/O線程池，由I/O線程池負責對相應連接的網絡數據進行讀寫、編解碼處理。

在實際應用中，我們通常會定義相應的業務消息協議，並選擇合適的序列化機制，netty I/O線程池部分根據預設的規則進行數據的編解碼。

二、延伸的業務線程池

 

其實我們這裏說的業務線程池不在網絡層處理邏輯里。處理到I/O線程池部分，所需要的請求數據已經處理完畢，涉及具體的業務處理邏輯，比較複雜的，或者時間、性能消耗特別大的，通常我們會單獨設置相應的線程池來處理。

三、netty的極致性能設計

1、無鎖化設計

I/O線程的內部串行化：

局部無鎖化串行處理，避免多線程切換帶來的複雜性及性能損耗（鎖競爭、CPU資源分配）。至於對於處理能力的考慮，可以通過調整I/O線程池容量來平衡。

盡量避免I/O線程和業務線程混淆及切換。

2、直接內存使用

TCP接收和發送使用直接內存代替堆內存，避免了數據在堆內存和主內存之間的複製消耗，提升了I/O讀取和寫入的性能。

 3、transferTo

依賴於操作系統零拷貝特性直接將緩衝區數據發送到相應的通道。

傳統的方式，先將源文件拷貝到內存，然後由內存寫到目的文件。

netty 利用 NIO FileChannel transferTo方法，通道對通道寫數據。

4、CompositeByteBuf

組合緩存使用可以像操作單個緩存一樣操作多個緩存，避免了傳統的操作方式帶來的內存複製性能消耗。

5、內存池使用

netty支持通過內存池的方式循環利用ByteBuf，避免了頻繁的創建，銷毀ByteBuf帶來的資源及性能損耗。

ByteBuf byte數據緩衝區，是NIO編程的主要對象。高負載情景下，ByteBuf內存池使用，可以有效降低GC頻率。

PoolArena netty的內存池實現類。PoolArena 是由多個Chunk組成的大塊內存區域，每個Chunk由一個多個Page組成。

Chunk：組織管理Page的內存分配和釋放，Page被構建為二叉樹形式：

PoolSubpage：對於小於Page的內存使用，直接在Page中完成分配，每個Page切分為大小相同的多個存儲塊兒，存儲塊兒的大小由第一次申請的內存塊兒大小決定。

回收：netty使用狀態位標識Chunk及Page內存可用性，Chunk標識二叉樹Page節點使用狀態；Page標識內部內存塊兒的使用狀態。

6、線程安全優化

合理的使用線程安全容器、原子類等，提升系統的併發處理能力，

7、引用計數器

通過引用計數器及時的申請釋放不再引用的對象，細粒度的內存管理降低了GC的頻率，減少GC帶來的時延增大和CPU損耗。

Netty 4中 ByteBuf 和 ByteBufHolder 引入引用計數器功能（實現ReferenceCounted接口），在特定的對象上跟蹤引用的數目。

引用計數器初始為1。如果對象活動的引用計數器大於0，則不會被釋放。當引用計數減少到0，實例將會被釋放。這也是 PooledByteBufAllocator 內存池應用的核心特性。

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

※別再煩惱如何寫文案,掌握八大原則!

目錄

• 簡介
• Buffer是什麼
• Buffer進階
• 創建Buffer
• Direct VS non-Direct
• Buffer的日常操作
  • 向Buffer寫數據
  • 從Buffer讀數據
  • rewind Buffer
  • Compact Buffer
  • duplicate Buffer
• 總結

簡介

小師妹在學習NIO的路上越走越遠，唯一能夠幫到她的就是在她需要的時候給她以全力的支持。什麼都不說了，今天介紹的是NIO的基礎Buffer。老鐵給我上個Buff。

Buffer是什麼

小師妹：F師兄，這個Buffer是我們縱橫王者峽谷中那句：老鐵給我加個Buff的意思嗎？

當然不是了，此Buffer非彼Buff，Buffer是NIO的基礎，沒有Buffer就沒有NIO，沒有Buffer就沒有今天的java。

因為NIO是按Block來讀取數據的，這個一個Block就可以看做是一個Buffer。我們在Buffer中存儲要讀取的數據和要寫入的數據，通過Buffer來提高讀取和寫入的效率。

更多精彩內容且看：

• 區塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續更新
• Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續更新
• Spring 5.X系列教程:滿足你對Spring5的一切想象-持續更新
• java程序員從小工到專家成神之路（2020版）-持續更新中,附詳細文章教程

更多內容請訪問www.flydean.com

還記得java對象的底層存儲單位是什麼嗎？

小師妹：這個我知道，java對象的底層存儲單位是字節Byte。

對，我們看下Buffer的繼承圖：

Buffer是一個接口，它下面有諸多實現，包括最基本的ByteBuffer和其他的基本類型封裝的其他Buffer。

小師妹：F師兄，有ByteBuffer不就夠了嗎？還要其他的類型Buffer做什麼？

小師妹，山珍再好，也有吃膩的時候，偶爾也要換個蘿蔔白菜啥的，你以為乾隆下江南都幹了些啥？

ByteBuffer雖然好用，但是它畢竟是最小的單位，在它之上我們還有Char，int，Double，Short等等基礎類型，為了簡單起見，我們也給他們都搞一套Buffer。

Buffer進階

小師妹：F師兄，既然Buffer是這些基礎類型的集合，為什麼不直接用結合來表示呢？給他們封裝成一個對象，好像有點多餘。

我們既然在面向對象的世界，從表面來看自然是使用Object比較合乎情理，從底層的本質上看，這些封裝的Buffer包含了一些額外的元數據信息，並且還提供了一些意想不到的功能。

上圖列出了Buffer中的幾個關鍵的概念，分別是Capacity，Limit，Position和Mark。Buffer底層的本質是數組，我們以ByteBuffer為例，它的底層是：

final byte[] hb; 

• Capacity表示的是該Buffer能夠承載元素的最大數目，這個是在Buffer創建初期就設置的，不可以被改變。
• Limit表示的Buffer中可以被訪問的元素個數，也就是說Buffer中存活的元素個數。
• Position表示的是下一個可以被訪問元素的index，可以通過put和get方法進行自動更新。
• Mark表示的是歷史index，當我們調用mark方法的時候，會把設置Mark為當前的position，通過調用reset方法把Mark的值恢復到position中。

創建Buffer

小師妹：F師兄呀，這麼多Buffer創建起來是不是很麻煩？有沒有什麼快捷的使用辦法？

一般來說創建Buffer有兩種方法，一種叫做allocate，一種叫做wrap。

public void createBuffer(){
        IntBuffer intBuffer= IntBuffer.allocate(10);
        log.info("{}",intBuffer);
        log.info("{}",intBuffer.hasArray());
        int[] intArray=new int[10];
        IntBuffer intBuffer2= IntBuffer.wrap(intArray);
        log.info("{}",intBuffer2);
        IntBuffer intBuffer3= IntBuffer.wrap(intArray,2,5);
        log.info("{}",intBuffer3);
        intBuffer3.clear();
        log.info("{}",intBuffer3);
        log.info("{}",intBuffer3.hasArray());
    }

allocate可以為Buffer分配一個空間，wrap同樣為Buffer分配一個空間，不同的是這個空間背後的數組是自定義的，wrap還支持三個參數的方法，後面兩個參數分別是offset和length。

INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=0 lim=10 cap=10]
INFO com.flydean.BufferUsage - true
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=0 lim=10 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=2 lim=7 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=0 lim=10 cap=10]
INFO com.flydean.BufferUsage - true

hasArray用來判斷該Buffer的底層是不是數組實現的，可以看到，不管是wrap還是allocate，其底層都是數組。

需要注意的一點，最後，我們調用了clear方法，clear方法調用之後，我們發現Buffer的position和limit都被重置了。這說明wrap的三個參數方法設定的只是初始值，可以被重置。

Direct VS non-Direct

小師妹：F師兄，你說了兩種創建Buffer的方法，但是兩種Buffer的後台都是數組，難道還有非數組的Buffer嗎？

自然是有的,但是只有ByteBuffer有。ByteBuffer有一個allocateDirect方法，可以分配Direct Buffer。

小師妹：Direct和非Direct有什麼區別呢？

Direct Buffer就是說，不需要在用戶空間再複製拷貝一份數據，直接在虛擬地址映射空間中進行操作。這叫Direct。這樣做的好處就是快。缺點就是在分配和銷毀的時候會佔用更多的資源，並且因為Direct Buffer不在用戶空間之內，所以也不受垃圾回收機制的管轄。

所以通常來說只有在數據量比較大，生命周期比較長的數據來使用Direct Buffer。

看下代碼：

public void createByteBuffer() throws IOException {
        ByteBuffer byteBuffer= ByteBuffer.allocateDirect(10);
        log.info("{}",byteBuffer);
        log.info("{}",byteBuffer.hasArray());
        log.info("{}",byteBuffer.isDirect());

        try (RandomAccessFile aFile = new RandomAccessFile("src/main/resources/www.flydean.com", "r");
             FileChannel inChannel = aFile.getChannel()) {
            MappedByteBuffer buffer = inChannel.map(FileChannel.MapMode.READ_ONLY, 0, inChannel.size());
            log.info("{}",buffer);
            log.info("{}",buffer.hasArray());
            log.info("{}",buffer.isDirect());
        }
    }

除了allocateDirect,使用FileChannel的map方法也可以得到一個Direct的MappedByteBuffer。

上面的例子輸出結果：

INFO com.flydean.BufferUsage - java.nio.DirectByteBuffer[pos=0 lim=10 cap=10]
INFO com.flydean.BufferUsage - false
INFO com.flydean.BufferUsage - true
INFO com.flydean.BufferUsage - java.nio.DirectByteBufferR[pos=0 lim=0 cap=0]
INFO com.flydean.BufferUsage - false
INFO com.flydean.BufferUsage - true

Buffer的日常操作

小師妹:F師兄，看起來Buffer確實有那麼一點複雜，那麼Buffer都有哪些操作呢？

Buffer的操作有很多，下面我們一一來講解。

向Buffer寫數據

向Buffer寫數據可以調用Buffer的put方法：

public void putBuffer(){
        IntBuffer intBuffer= IntBuffer.allocate(10);
        intBuffer.put(1).put(2).put(3);
        log.info("{}",intBuffer.array());
        intBuffer.put(0,4);
        log.info("{}",intBuffer.array());
    }

因為put方法返回的還是一個IntBuffer類，所以Buffer的put方法可以像Stream那樣連寫。

同時，我們還可以指定put在什麼位置。上面的代碼輸出：

INFO com.flydean.BufferUsage - [1, 2, 3, 0, 0, 0, 0, 0, 0, 0]
INFO com.flydean.BufferUsage - [4, 2, 3, 0, 0, 0, 0, 0, 0, 0]

從Buffer讀數據

讀數據使用get方法，但是在get方法之前我們需要調用flip方法。

flip方法是做什麼用的呢？上面講到Buffer有個position和limit字段，position會隨着get或者put的方法自動指向後面一個元素，而limit表示的是該Buffer中有多少可用元素。

如果我們要讀取Buffer的值則會從positon開始到limit結束：

public void getBuffer(){
        IntBuffer intBuffer= IntBuffer.allocate(10);
        intBuffer.put(1).put(2).put(3);
        intBuffer.flip();
        while (intBuffer.hasRemaining()) {
            log.info("{}",intBuffer.get());
        }
        intBuffer.clear();
    }

可以通過hasRemaining來判斷是否還有下一個元素。通過調用clear來清除Buffer，以供下次使用。

rewind Buffer

rewind和flip很類似，不同之處在於rewind不會改變limit的值，只會將position重置為0。

public void rewindBuffer(){
        IntBuffer intBuffer= IntBuffer.allocate(10);
        intBuffer.put(1).put(2).put(3);
        log.info("{}",intBuffer);
        intBuffer.rewind();
        log.info("{}",intBuffer);
    }

上面的結果輸出：

INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=3 lim=10 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=0 lim=10 cap=10]

Compact Buffer

Buffer還有一個compact方法，顧名思義compact就是壓縮的意思，就是把Buffer從當前position到limit的值賦值到position為0的位置：

public void useCompact(){
        IntBuffer intBuffer= IntBuffer.allocate(10);
        intBuffer.put(1).put(2).put(3);
        intBuffer.flip();
        log.info("{}",intBuffer);
        intBuffer.get();
        intBuffer.compact();
        log.info("{}",intBuffer);
        log.info("{}",intBuffer.array());
    }

上面代碼輸出：

INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=0 lim=3 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=2 lim=10 cap=10]
INFO com.flydean.BufferUsage - [2, 3, 3, 0, 0, 0, 0, 0, 0, 0]

duplicate Buffer

最後我們講一下複製Buffer，有三種方法，duplicate，asReadOnlyBuffer，和slice。

duplicate就是拷貝原Buffer的position，limit和mark，它和原Buffer是共享原始數據的。所以修改了duplicate之後的Buffer也會同時修改原Buffer。

如果用asReadOnlyBuffer就不允許拷貝之後的Buffer進行修改。

slice也是readOnly的，不過它拷貝的是從原Buffer的position到limit-position之間的部分。

public void duplicateBuffer(){
        IntBuffer intBuffer= IntBuffer.allocate(10);
        intBuffer.put(1).put(2).put(3);
        log.info("{}",intBuffer);
        IntBuffer duplicateBuffer=intBuffer.duplicate();
        log.info("{}",duplicateBuffer);
        IntBuffer readOnlyBuffer=intBuffer.asReadOnlyBuffer();
        log.info("{}",readOnlyBuffer);
        IntBuffer sliceBuffer=intBuffer.slice();
        log.info("{}",sliceBuffer);
    }

輸出結果：

INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=3 lim=10 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=3 lim=10 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBufferR[pos=3 lim=10 cap=10]
INFO com.flydean.BufferUsage - java.nio.HeapIntBuffer[pos=0 lim=7 cap=7]

總結

今天給小師妹介紹了Buffer的原理和基本操作。

本文的例子https://github.com/ddean2009/learn-java-io-nio

本文作者：flydean程序那些事

本文鏈接：http://www.flydean.com/java-io-nio-buffer/

本文來源：flydean的博客

歡迎關注我的公眾號:程序那些事，更多精彩等着您！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

※網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

Redis持久化是面試中經常會問到的問題，這裏主要通過對以下幾個問題進行分析，幫助大家了解Redis持久化的實現原理。

1.Redis持久化是什麼？

2.Redis持久化有哪些策略？各自的實現原理是怎麼樣的？

3.Redis的數據恢復策略是怎麼樣的？

4.Redis持久化策略該如何進行選擇？

1.Redis持久化是什麼？

因為Redis是一個內存數據庫，數據保存在內存中，一旦發生關機或者重啟，內存中的數據都會丟失，所以為了能夠重啟時恢複數據，Redis提供了持久化的機制，正常運行期間根據策略生成持久化文件。在機器重啟后，可以根據根據持久化文件恢復內存中的數據。Redis還為我們提供了持久化的機制。（雖然有主從同步，主機掛掉之後，可以讓從節點成為主節點，但是如果整個機房都發生停電，那麼主節點和從節點內存中的數據都會丟失，所以這也是持久化存在的意義。）

2.Redis持久化有哪些策略？

Redis持久化的策略主要有AOF持久化，RDB持久化，混合持久化。這是我自己總結的一個圖：

AOF持久化

執行流程

AOF持久化主要是Redis在修改相關的命令后，將命令添加到aof_buf緩存區的末尾，然後在每次事件循環結束時，

根據appendfsync的配置：

• appendfsync = always 每條修改命令都會更新到磁盤上的AOF文件, 最多只會丟失當前正在寫入的命令

• appendfsync = everysec 每秒更新到磁盤上的AOF文件一次, 最多丟失2秒的數據（因為執行fsync命令刷盤也需要時間，下面會解釋）

• appendfsync = no 不自動更新到磁盤上的AOF文件，由操作系統來決定何時刷盤(linux 貌似大部分默認是 30s)。可能會丟失刷盤之前的寫入數據。

（基於性能考慮一般生產環境的配置都是everysec）

（aof_buf是Redis中的SDS結構，可以理解為是一個字符串，只是對C語言的字符串做了一些優化，每次將新執行的更新命令添加到字符串末尾。）

怎麼防止AOF文件越來越大？

為了防止AOF文件越來越大，可以通過執行BGREWRITEAOF命令，會fork子進程出來，讀取當前數據庫的鍵值對信息，生成所需的寫命令，寫入新的AOF文件。在生成期間，父進程繼續正常處理請求，執行修改命令后，不僅會將命令寫入aof_buf緩衝區，還會寫入重寫aof_buf緩衝區。當新的AOF文件生成完畢后，子進程父進程發送信號，父進程將重寫aof_buf緩衝區的修改命令寫入新的AOF文件，寫入完畢后，對新的AOF文件進行改名，原子地（atomic）地替換舊的AOF文件。

什麼是AOF文件追加阻塞？

修改命令添加到aof_buf之後，如果配置是everysec那麼會每秒執行fsync操作，調用write寫入磁盤一次，但是如果硬盤負載過高，fsync操作可能會超過1s，Redis主線程持續高速向aof_buf寫入命令，硬盤的負載可能會越來越大，IO資源消耗更快，所以Redis的處理邏輯是會對比上次fsync成功的時間，如果超過2s，則主線程阻塞直到fsync同步完成，所以最多可能丟失2s的數據，而不是1s。

RDB持久化

RDB持久化指的是在滿足一定的觸發條件時（在一個的時間間隔內執行修改命令達到一定的數量，或者手動執行SAVE和BGSAVE命令），對這個時間點的數據庫所有鍵值對信息生成一個壓縮文件dump.rdb，然後將舊的刪除，進行替換。

執行流程

實現原理是fork一個子進程，然後對鍵值對進行遍歷，生成rdb文件，在生成過程中，父進程會繼續處理客戶端發送的請求，當父進程要對數據進行修改時，會對相關的內存頁進行拷貝，修改的是拷貝后的數據。（也就是COPY ON WRITE，寫時複製技術，就是當多個調用者同時請求同一個資源，如內存或磁盤上的數據存儲，他們會共用同一個指向資源的指針，指向相同的資源，只有當一個調用者試圖修改資源的內容時，系統才會真正複製一份專用副本給這個調用者，其他調用者還是使用最初的資源,在CopyOnWriteArrayList的實現中，也有用到，添加或者插入一個新元素時過程是，加鎖，對原數組進行複製，然後添加新元素，然後替代舊數組，解鎖）

	//CopyOnWriteArrayList的添加元素的方法
public boolean add(E e) {
  final ReentrantLock lock = this.lock;
  lock.lock();
  try {
    Object[] elements = getArray();
    int len = elements.length;
    Object[] newElements = Arrays.copyOf(elements, len + 1);
    newElements[len] = e;
    setArray(newElements);
    return true;
  } finally {
    lock.unlock();
  }
}

混合持久化（Redis4.0+）

執行流程

混合持久化同樣也是通過bgrewriteaof命令完成的，不同的是當開啟混合持久化時，fork出的子進程先將當前內存中的鍵值對信息全量的以RDB方式寫入aof文件，然後在將重寫緩衝區的增量命令以AOF方式寫入到文件，寫入完成后通知主進程更新統計信息，並將新的含有RDB格式和AOF格式的AOF文件替換舊的的AOF文件。簡單的說：新的AOF文件前半段是RDB格式的全量數據後半段是AOF格式的增量數據，如下圖：

3.Redis的數據恢復策略是怎麼樣的？

1.如果配置了混合持久化，那麼根據混合持久化文件進行恢複數據。（Redis4.0+）

2.只配置 AOF ，重啟時加載 AOF 文件恢複數據。

3.同時配置了 RDB 和 AOF ，啟動時只加載 AOF文件恢複數據，如果AOF文件損壞，那麼根據RDB文件恢複數據。

4.只配置 RDB，啟動時加載RDB持久化文件恢複數據。

4.Redis持久化策略該如何進行選擇？

（因為混合持久化是Redis 4.0之後支持的，目前一般生成環境使用的Redis版本可能都還較低，所以這裏的策略選擇主要是針對AOF持久和RDB持久化進行技術選型。）

以下是幾種持久化方案選擇的場景：

1.不需要考慮數據丟失的情況

那麼不需要考慮持久化。

2.單機實例情況下

可以接受丟失十幾分鐘及更長時間的數據，可以選擇RDB持久化，對性能影響小，如果只能接受秒級的數據丟失，只能選擇AOF持久化。

3.在主從環境下

因為主服務器在執行修改命令后，會將命令發送給從服務器，從服務進行執行后，與主服務器保持數據同步，實現數據熱備份，在master宕掉後繼續提供服務。同時也可以進行讀寫分離，分擔Redis的讀請求。

那麼在從服務器進行數據熱備份的情況下，是否還需要持久化呢？

需要持久化，因為不進行持久化，主服務器，從服務器同時出現故障時，會導致數據丟失。（例如：機房全部機器斷電）。如果系統中有自動拉起機制（即檢測到服務停止后重啟該服務）將master自動重啟，由於沒有持久化文件，那麼master重啟后數據是空的，slave同步數據也變成了空的。應盡量避免“自動拉起機制”和“不做持久化”同時出現。

所以一般可以採用以下方案：

主服務器不開啟持久化，使得主服務器性能更好。

從服務器開啟AOF持久化，關閉RDB持久化，並且定時對AOF文件進行備份，以及在凌晨執行bgaofrewrite命令來進行AOF文件重寫，減小AOF文件大小。（當然如果對數據丟失容忍度高也可以開啟RDB持久化，關閉AOF持久化）

4.異地災備

一般性的故障（停電，關機）不會影響到磁盤，但是一些災難性的故障（地震，洪水）會影響到磁盤，所以需要定時把單機上或從服務器上的AOF文件，RDB文件備份到其他地區的機房。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

1.簡介

JMeter配置元件可以用來初始化默認值和變量，讀取文件數據，設置公共請求參數，賦予變量值等，以便後續採樣器使用。將在其作用域的初始化階段處理。配置元件（Config Element）提供對靜態數據配置的支持，可以為取樣器設置默認值和變量。

首先我們來看一下JMeter的配置元件，路徑：添加-配置元件；我們可以清楚地看到JMeter5中共有19個配置元件，如下圖所示：

如果上圖您看得不是很清楚的話，宏哥總結了一個思維導圖，關於JMeter5的配置元件類型，如下圖所示：

 通過以上的了解，我們對配置元件有了一個大致的了解和認識。下面宏哥就給小夥伴或則童鞋們分享講解一些通常在工作中會用到的配置元件。

 2.常用配置元件詳解

　　這一小節，宏哥就由上而下地詳細地講解一下常用的配置元件。

2.1CSV Data Set Config

1、我們先來看看這個CSV Data Set Config長得是啥樣子，如下圖所示：

 2、參數詳解及說明，如下錶所示：

參 數	描 述	是否必填
Name	腳本中显示的這個元件的描述性名稱	是
Filename	待讀取文件的名稱。可以寫入絕對路徑，也可以寫入相對路徑（相對於bin目錄），如果直接寫文件名，則該文件要放在bin目錄中。對於分佈式測試，主機和遠程機中相應目錄下應該有相同的CSV文件	是
File Encoding	文件讀取時的編碼格式，不填則使用操作系統的編碼格式	否
Ignore first line	是否忽略首行，如果csv文件中沒有表頭，則選擇false	是
Variable Names	變量名列表，多個變量名之間必須用分隔符分隔。如果該項為空，則文件首行會被讀取並解析為列名列表	否
Delimiter	參數分隔符，將一行數據分隔成多個變量，默認為逗號，也可以使用“\t”。如果一行數據分隔后的值比Vairable Names中定義的變量少，這些變量將保留以前的值（如果有值的話）	是
Allow quoted data?	是否允許變量使用雙引號，允許的話，變量將可以括在雙引號內，並且這些變量名可以包含分隔符	否
Recycle on EOF?	是否循環讀取csv文件內容，達到文件結尾后，是否從文件開始循環重新讀取；默認為 true	是
Stop thread on EOF?	是否循環讀取csv文件內容，達到文件結尾后，線程是否該終止；默認為 true	是
Recycle on EOF?	當Recycle on EOF為False時，停止線程，當Recycle on EOF為True時，此項無意義，默認為 false	是
Sharing mode	1、All threads（默認）：一個線程組內，各個線程（用戶）唯一順序取值；2、current thread：一個線程組內，各個線程（用戶）各自順序取值；3、線程組各自獨立，但每個線程組內各個線程（用戶）唯一順序取值；	是

 3、Recycle on EOF 和Stop thread on EOF的關係：

當Recycle on EOF 選擇true時，Stop thread on EOF選擇true和false無任何意義，因為既然前面已經設置了文件是不停的循環讀取，後面的控制stop就相當於失效；
當Recycle on EOF 選擇false時，Stop thread on EOF選擇true，則當線程數超過文件里的參數的個數時，實際請求數為參數的個數；
當Recycle on EOF 選擇false時，Stop thread on EOF選擇flase，當線程數超過文件里參數的個數時，實際請求次數為線程數，但當線程數超過參數次數時，由於沒有參數，所以結果仍然是失敗的。
4、Sharing mode：如果希望每個線程擁有自己獨立的值集合，那麼就需要創建一系列數據文件，為每個線程準備一個數據文件，如test1.csv、test2.csv等，使用文件名test${__threadNum}.csv,並將“sharing mode”設置為”Current thread”

All threads：文件在所有線程間共享。

Identifier：所有線程共享相同的標識，共享相同的文件。如有４個線程組，測試人員可以使用一個通用ＩＤ，以便在兩個或多個線程組之間共享文件。

Current thread：每個文件會針對每個線程單獨打開。

Current thread group：每個文件會針對每個線程組打開一次。

2.2HTTP Header Manager

支持用戶添加或者重寫HTTP請求頭。JMeter支持多個信息頭管理器。多個信息頭條目合併成一個信息頭列表，跟隨http請求一併提交到服務端。

注意：敲黑板，敲腦殼！！！

（1）當有多個信息頭管理器，且不同的管理器內有名稱相同的信息頭條目存在時，順序靠前的管理器的信息頭條目會覆蓋後面的；

（2）當只有一個信息頭管理器，但管理器內有名稱相同的信息頭條目時，會同時生效；

 1、我們先來看看這個HTTP Header Manager長得是啥樣子，如下圖所示：

 2、參數詳解及說明，如下錶所示：

參數	描述	是否必填
Name	請求頭的名稱，比如Content-Type	否
Value	請求頭的值，比如application/json	否

3、常用請求頭，這些一般可以抓包和在瀏覽器中查到，如下錶所示：

2.3HTTP Cookie Manager

主要有兩個功能：

一個功能是：像web瀏覽器一樣存儲和發送Cookie。如果有一個HTTP請求和相應里包含Cookie，Cookie管理器會自動存儲Cookie，那麼接下來針對特定web站點的所有請求中使用該Cookie。可在結果樹中查看。

接收到的Cookie可以被保存為變量，須定義屬性”CookieManager.save.cookie=true”。另外，在被存儲前Cookie名稱會加上前綴“COOKIE_”，要恢復早前處理方式，則定義屬性”CookieManager.name.prefix=”(一個或多個空格）。

如果啟動了該功能，那麼名稱為TEST的Cookie,可以通過${COOKIE_TEST}加以引用。手動為Cookie管理器添加一個Cookie（為所有JMeter線程所共享）。

1、我們先來看看這個HTTP Cookie Manager長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示：

參數	描述	是否必填
Name	樹中显示此元件描述的名稱	是
Comments	註釋	否
Clear cookie each Iteration	每次線程組運行前，都會清楚cookie，但是如果是手動添加的cookie，不會被清除	否
Cookie Policy	選擇Cookie的管理策略，建議選擇兼容性，兼容性強	是
User Define cookie	用戶自定義cookie	否

 

2.4HTTP Cache Manager

　　被用來為其作用域內的HTTP請求提供緩存功能，如果“Use Cache-Control/Expires header When …”選中，那麼會根據當前時間來選擇，如果請求是”GET”，而時間指向未來，那麼採樣器就會立即返回，而無須從遠程服務器請求URL,這樣是為了模擬瀏覽器的操作，請注意Cache-Control頭必須是“pulic”的，並且只有”max-age”終結選項會被處理，如果請求文檔自從其被緩存以來沒有發生任何改變，那麼響應包體就會為空。

1、我們先來看看這個HTTP Cache Manager長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示：

參數	描述	是否必填
Name	樹中显示此元件的描述性名稱	是
Comments	註釋	否
Clear Cache each iteration	如果選擇此選項，則在線程開始時清除緩存。	否
Use Cache	如果選擇此選項，則在線程開始時使用緩存。	否
Max Number	如果選擇此選項，則在線程開始時最大緩存。	否

 

2.5HTTP Request Defaults

在實際測試計劃中，我們經常會碰到Http Sampler請求有較多的參數與配置會重複，每一個Http Sampler都單獨設置的話比較浪費時間和精力，為了節省工作量，JMeter提供了HTTP Request Defaults元件，用來把這些重複的部分封裝起來，一次設置多次使用。可以設定一些缺省值，假設有10個請求，訪問域名和端口都是一樣的，那HTTP請求中就不再需要單獨配置了，比較方便（增加腳本的移植性）。

這個元件可以設置HTTP請求控制器使用的默認值。例如，圖中【服務器名稱或IP】項目內填入了【example.com】，後面的HTTP請求如果IP也是example.com的話，那麼只要將【服務器名稱或IP】留空，那麼這個字段將自動繼承HTTP請求默認值中的值。其他諸如【協議】、【端口號】、【路徑】等同此。

1、我們先來看看這個HTTP Request Defaults長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示：

參數	描述	是否必填
Name	用作標識一個取樣器，建議使用一個見名知義的名稱	是
Comments	註釋	否
Protocol	協議，向目標服務器發送HTTP請求時的協議，可以是http或者是Https
IP	HTTP請求發送的目標服務器名稱或者IP地址
Port Number	目標服務器端口
Path	目標URL路徑（不包括服務器地址和端口）
Content encdoing	內容的編碼方式
Parameter	參數
body data	參數

 

2.6Counter

計數器，顧名思義就是在測試執行過程中會記錄迭代次數。可以在線程組任何位置創建，允許用戶配置起點、最大值和增量。配置后，計數器將從起點循環到最大值，然後重新開始，直到線程結束。允許用戶創建一個計數器，可在線程組中任何地方被引用。

1、我們先來看看這個Counter長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示：

參數	描述	是否必填
Name	控制器名稱，可以隨意設置	否
Comments	註釋，可以隨意設置	否
Starting value	啟動，記錄數量起始值
Increment	遞增，記錄迭代次數步長，1后是2，步長就是1
Maximum value	記錄的最大值
Number format	計算器格式，可以是数字，例如000000（6位長度，000,000（6位長度，3位間隔開）；字符加数字，例如CUST_000000（字符加6位数字 ）
Exported Variable Name	引用變量名稱，記數器記錄的值可以存入的此引用名（變量），可供其他元件調用
Track counter independently for each user	與每位用戶獨立的跟蹤計數器，每個線程都有自己的計數器，相互不干擾
Reset counter on each Thread Group Iteration	每次迭代復原計數器

 

2.7DNS Cache Manager

1、我們先來看看這個DNS Cache Manager長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示：

參數	描述	是否必填
Name	樹中显示此元件的描述性名稱
Comments	註釋
Clear cache each iter	清除每個迭代的緩存，如果選擇此選項，則每次啟動新迭代時，都會清除每個線程的DNS緩存。
Use System DNS resolver	使用系統DNS解析器；將使用系統DNS解析器。為了正確工作，請編輯 $ JAVA_HOME / jre / lib / security / java.security並添加networkaddress.cache.ttl = 0
Use custom DNS resolver	使用自定義DNS解析器；將使用自定義DNS解析器（來自dnsjava庫）。

 

2.8FTP Request Defaults

被用於設置FTP請求的默認值

1、我們先來看看這個FTP Request Defaults長得是啥樣子，如下圖所示：

2.9HTTP Authorization Manager

HTTP認證是一種安全機制，在客戶端、瀏覽器或者程序向服務器發起請求時，需要提供用戶名和密碼且驗證通過（拿到憑證）才能繼續發起交互。

1、我們先來看看這個HTTP Authorization Manager長得是啥樣子，如下圖所示： 

2.10JDBC Connection Configuration

1、我們先來看看這個JDBC Connection COnfiguration長得是啥樣子，如下圖所示： 

 2、關於JDBC Connection COnfiguration參數詳細說明，可以參考宏哥的另一篇文章是非常詳細的：傳送門。

2.11Java Request Defaults

1、我們先來看看這個Java Request Defaults長得是啥樣子，如下圖所示： 

2.12Keystore Configuration

1、我們先來看看這個Keystore Configuration長得是啥樣子，如下圖所示： 

2、參數詳細說明，如下錶所示：

參數	描述	是否必填
Name	樹中显示此元件的描述性名稱。可以默認	是
Comments	註釋	否
Preload	預載，是否預加載秘鑰庫，設置為true通常是最佳選擇	是
Variable name holding certificate alias	變量名稱，將包含用於客戶端證書身份驗證的別名。例如，將從CSV數據集中填充變量值。在屏幕截圖中，“ certificat_ssl”也將是CSV數據集中的變量。	否
Alias Start index	從0開始在Keystore中使用的第一個鍵的索引。	是
Alias End index	基於0的密鑰庫中要使用的最後一個密鑰的索引。使用“變量名稱持有證書別名”時，請確保其足夠大，以便在啟動時加載所有密鑰。	是

 2.13LDAP Extended Request Defaults

1、我們先來看看這個LDAP Extended Request Defaults長得是啥樣子，如下圖所示： 

2.14LDAP Request Defaults

1、我們先來看看這個LDAP Request Defaults長得是啥樣子，如下圖所示： 

2.15Login Config Element

1、我們先來看看這個Login Config Element長得是啥樣子，如下圖所示： 

2.16Random Variable

1、我們先來看看這個Random Variable長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示：  

參數	描述	是否必填
Name	樹中显示的此元件的描述性名稱。
Comments	註釋
Variable Name	變量名，存儲隨機字符串的變量的名稱。
Output Format	格式化字符串，要使用的java.text.DecimalFormat格式字符串。例如，“ 000”將生成至少3位数字，或者“ USER_000”將生成USER_nnn形式的輸出。如果未指定，則默認為使用Long.toString（）生成数字。
Minimum Value	最小值；生成的隨機數的最小值（長整數）。
Maximum Value	最大值；生成的隨機數的最大值（長整數）。
Seed for Random function	隨機種子，隨機數生成器的種子。默認值為當前時間，以毫秒為單位。如果在“將每個線程”設置為true的情況下使用相同的種子值，則與“ 隨機” 類一樣，您將為earch線程獲得相同的值
Per Thread(User)?	每個線程，如果為False，則在線程組中的所有線程之間共享生成器。如果為True，則每個線程都有自己的隨機生成器。

2.17Simple Config Element

1、我們先來看看這個Simple Config Element長得是啥樣子，如下圖所示： 

2、參數詳細說明，如下錶所示：  

參數	描述	是否必填
Name	樹中显示此元件的描述名稱	是
Comments	註釋	是
Name	參數名稱
Value	參數值

2.18TCP Sampler Config

TCP採樣器配置為TCP採樣器提供默認數據

1、我們先來看看這個TCP Sampler Config長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示： 

參數	描述	是否必填
Name	樹中显示此元件的描述性名稱
Comments	註釋
TCPClient classname	TCPClient類的名稱，默認屬性tcp.handler,使TCPClientImpl失敗
Sever Name or IP	TCP服務器的名稱或者IP
Port Number	使用的端口
Re-use connection	重用連接，如果選擇，則連接保持打開狀態，否則，在讀取數據后將其關閉
Close connection	關閉連接，如果選擇此項，則在運行採樣器后將連接關閉
Set NoDelay	設置節點布局，應該設置nodelay
SO_LINGER	創建套接字時，以指定的延遲時間（以秒為單位）啟用/禁用SO_LINGER。如果將“SO_LINGER”值設置為0，則則可以防止大量套接字處於TIME_WAT 的狀態
End of line byte value	判斷行結束的byte值，如果你指定的值大於127或者小於-128，則會跳過EOL檢測。比如服務器端返回的字符串都是以回車符結尾，那麼我們可以將該選項設置成10。
Text to send	文字發送，要發送的文字
Connect	連接超時（毫秒。0禁用）
Response	響應超時（毫秒。0禁用）

2.19User Defined Variables

如果您有多個線程組，請確保對不同的值使用不同的名稱，因為UDV在線程組之間共享。同樣，這些變量在處理完元素之後才可用，因此您不能引用在同一元素中定義的變量。您可以引用在早期UDV或測試計劃中定義的變量。

1、我們先來看看這個User Defined Variable長得是啥樣子，如下圖所示：

2、參數詳細說明，如下錶所示： 

參數	描述	是否必填
Name	樹中显示此元件描述的名稱
Comments	註釋
User Define Variables	用戶定義的變量。變量名稱/值對。您需要在$ {…}結構的方括號內放置“名稱”（Name）列下的字符串，以便以後使用變量。然後，整個$ {…}將由“值”列中的字符串替換

3.小結

 好了，今天關於JMeter的配置元件就分享到這裏，其中有些常用的要熟練掌握。

 

您的肯定就是我進步的動力。如果你感覺還不錯，就請鼓勵一下吧！記得隨手點波  推薦  不要忘記哦！！！

別忘了點 推薦 留下您來過的痕迹

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

雷凌的外觀設計要比卡羅拉更顯年輕動感一些，1。2T的發動機最大馬力116匹，峰值扭矩185牛米。國家工信部對於豐田雷凌1。2T的油耗測試結果显示為5。7L/100km，而根據現任車主的反應，綜合油耗也是在6。5-7。0L/100km，比其他車型更具優勢的是，雷凌所使用的1。

基於以上種種的原因還是考慮合資車型，而一款油耗低，售價相對親民的合資轎車肯定更讓人覺得具有吸引力，但就目前來說，還是有不少消費者不太能接受純電動和混合動力車型；本次就推薦幾款油耗低，售價也相對能夠讓人接受的合資家用轎車。

標緻308 230THp

指導價格：10.97-13.37萬

標緻308的外觀更新讓人欣喜，家族式前臉設計更有精神，車身整體線條也更加和諧流暢，採用1.2T的標緻308最大馬力136匹，峰值扭矩230牛米。

工信部油耗显示1.2T的標緻308綜合耗油5.2L/100km左右，根據已經購入標緻308 230THp車型的車主反映，普遍油耗在6.5-7.5L/100km左右，油耗並不顯得太高，基礎排量小為其奠定了根基。

廣汽豐田雷凌1.2T

指導價格：10.98-13.38萬

豐田集團繼混合動力車型推出以後，在雷凌和卡羅拉車型上繼續細分了1.2T的發動機版本以供消費者選擇。雷凌的外觀設計要比卡羅拉更顯年輕動感一些，1.2T的發動機最大馬力116匹，峰值扭矩185牛米。

國家工信部對於豐田雷凌1.2T的油耗測試結果显示為5.7L/100km，而根據現任車主的反應，綜合油耗也是在6.5-7.0L/100km，比其他車型更具優勢的是，雷凌所使用的1.2T是一款4缸發動機，平順性更出色。

一汽大眾高爾夫230TSI

指導價格：14.09-15.79萬

大眾高爾夫是家用車層面銷量非常高的一款緊湊型轎車，市場上曝光率很高，人們對它也非常熟悉，外觀造型顯得大氣簡潔，接受人群的年齡覆蓋面非常廣，230TSI所搭載的1.4T EA211發動機最大馬力131匹，峰值扭矩225牛米。

工信部對高爾夫230TSI車型的油耗測試綜合油耗显示5.9L/100km，根據現任車主普遍的口碑放映，230TSI的自動車型綜合油耗在7.5L/100km左右，高爾夫的優勢在於更符合大眾審美的汽車造型，以及更出色的操控性。

全文總結：以上三款車型都是各自車系中油耗較低的選擇，而標緻308凸顯的是個性，雷凌體現的是平實家用，高爾夫的優點在於紮實的底盤感受以及優良的操控性，基本上可以符合訴求各自不同的消費者。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

觀致汽車 觀致5售價：13。99-19。49萬元作為一個向高端進發的自主品牌，觀致的路走得一般。其中一大部分的原因是其較高的定價與較低的知名度，使得消費者對其認可比較一般。而且較少的4S店使得覆蓋較低也是一個原因。它的外觀不太像SUV車型，更像一款跨界車。

目前的SUV市場，雖然有着合資品牌不斷地進入市場，但在10-15萬這個區間仍是自主品牌佔據着領先的地位。由於這個價格區間是自主品牌的必爭之地，因此各家都在推出實力出眾的車型都與其他品牌一較高下。今天所推薦的這幾款，雖說不是目前市場最火的那幾款，但它們就真的不行么？且聽細細道來。

東風乘用車 東風風神AX7

售價：9.97-14.17萬元

東風乘用車一直都是多生孩子好打架的套路，風神AX7作為一輛原創度很高的車型自從上市以來就受到不少消費者的追捧。不僅由於它親民的定價，還有較大的車身尺寸。

它的前臉採用簡潔的造型設計，美觀耐看。多邊形進氣格柵採用橫向鍍鉻裝飾，整體質感出眾。碩大的X保險桿氣場很足，配以碩大的車身，至少第一印象就很深刻。微微上揚的腰線向後延伸與尾燈相融，流暢自然。車尾同樣採用簡潔的設計與前臉呼應。

相對於它的外觀讓人眼前一亮，AX7的內飾造型則相對比較傳統一些。規整的中控台最大的亮色就是突起的多媒體系統了；其中配以鍍鉻裝飾點綴，內飾整體比較年輕。而且AX7相對較大的車身尺寸，使得它的車內空間比較寬敞，也是它的優勢所在。

東風風神AX7的動力非常豐富，相比競爭對手而已；消費者有更多的選擇空間。除了1.4T車型之外，2.0L/2.3L都是採用了標緻旗下發動機，技術成熟可靠。1.4T的動力相當出色，遺憾的是目前只有手動車型；便利性差了點。2.0L與2.3L的車型則除了手動車型之外還配以6AT，日常行駛動力出色平順。懸挂的調校也相當有功力，整體感很強的底盤駕駛起來比較有信心。

奇瑞汽車 瑞虎7

售價：9.79-15.39萬元

奇瑞汽車作為一個自主品牌而已，這麼多年在合資林立的汽車市場里生存也不容易。能一直活得這麼滋潤，自然是它的產品比較出眾了。但之前的車型的外觀都是中規中矩，這一次瑞虎7可謂是出了一口惡氣。

作為奇瑞新研發平台T1X的首款SUV車型，瑞虎7是一款非常重要的產品。它的外觀原創度非常高；層次感豐富的前臉造型一下子就抓住了年輕人的眼球。凹凸有致的線條設計也時尚感很強。波浪式造型的車身線條很有設計感，而且轉向燈融入車身的設計很少見。

它的內飾造型相比目前最火的車型可能會稍遜一籌，但這是因為瑞虎7是在5年前就開始研發。以今天的目光來看，仍然非常好看，就是設計感差點。層次感較強的中控採用活潑的配色，黑棕布局亮點十足。而且瑞虎7的空間實用性也非常出色，後排配備了空調出風口。

瑞虎7搭載的了2.0L與1.5T的發動機，2.0L的車型動力輸出一般，搭載CVT更多的是為了日常的平順性需求的。1.5T則有兩種調校，動力的輸出更加直接充沛一些。日常行駛，這套動力總成做得很不錯，2.0L平順性很好，能滿足代步需求。1.5T車型則駕駛起來更輕鬆一些，變速箱涵接聰明。配上韌性十足的底盤調校，屬於同級一款很出眾的車型。

觀致汽車 觀致5

售價：13.99-19.49萬元

作為一個向高端進發的自主品牌，觀致的路走得一般。其中一大部分的原因是其較高的定價與較低的知名度，使得消費者對其認可比較一般。而且較少的4S店使得覆蓋較低也是一個原因。

它的外觀不太像SUV車型，更像一款跨界車。敦實圓潤的車身造型很獨特。它的前臉非常具有辨識度，設計感觸手的格柵布滿了中國風的設計語言，很有特色。碩大的鍍鉻裝飾也不會顯得很多餘。流線型的車身線條配上一個大尺寸的輪轂，很吸人眼球。車尾造型則相對簡單一些。

它的內飾造型則採用了簡潔的設計，簡單的線條勾勒出層次感強烈的中控台。平整的中控台看上去比較清爽，很適合年輕人的胃口。而它的乘坐空間與儲物空間都都相當出色，假如價格再降一些，很值得購買。

觀致5全系只搭載了一台1.6T的發動機，156ps的賬面數據表現還是可以。除了手動車型之後搭載是6擋雙離合；日常行駛動力輸出比較平順，只是雙離合變速箱為了更好的平順性，降擋會稍微有所猶豫。韌性的懸挂配以輕盈的轉向，日常開起來很輕鬆。

上汽集團 銳騰

銳騰與RX5同屬上汽旗下的SUV車型，雖然銳騰上市時間早很多，但熱度總體來說比RX5還是差了些。但這款個性前衛的SUV確實很出眾，如今外觀造型變得更加的美觀；不太那麼個性。

相比老款而言，新款銳騰變化不大。雖然變化不多，但整體呈現出來的效果非常出色。前臉的重心下移之後，變得更加美觀。經過重新調整的上下進氣格柵使得前臉更加協調。細節上，銳騰在霧燈區域設計了鋼爪設計，很有特色。車身的線條則變化較少，車尾同樣降低了重心，鋼爪的設計與前臉來了呼應。

銳騰的內飾造型變化很大，相比老款而言，減少了塑料感增加了檔次。造型規整的中控層次感豐富，上層採用鍍鉻裝飾條，接觸較多的區域都採用了皮革包裹，質感很出眾。乘坐空間整體處在主流水準，儲物空間豐富。遺憾的就是座椅較硬，長途乘坐會有點累。

作為改款車型，銳騰的動力則變化不大。依然還是1.5T/2.0T發動機與手動變速箱與雙離合的搭配。前麥弗遜后多連桿獨立懸挂使得銳騰天生就比競爭對手好不少，而銳騰呈現出就是底盤的支撐性很好，運動感會強一些。1.5T/2.0T發動機動力充沛，日常行駛比較輕鬆，變速箱涵接較好。

風神AX7顏值很帥氣，除了主打性價比之外；它寬敞的空間與成熟的動力總成都是它的亮點，相信只要多點宣傳；未來的銷量會更好。瑞虎7作為承載奇瑞汽車重任的一款SUV，如今已經開始展露自己的實力。要在眾多對手當中崛起，不僅品質出眾，未來的宣傳與口碑也有過關。

觀致5作為一個新品牌的SUV車型，外觀就不用多說了；很出眾。整體的配置與空間都在這個級別的主流水準，恰巧價格高了很多；4S覆蓋偏少也是它弱勢；希望未來能在這方面加強一下；價格再有所降低仍是一款好車。最後的銳騰，新款的外觀造型變得更加協調，不再是年輕人的專屬。整體的配置都相當出色，宣傳得好又是一款銷量高的車型。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準

RDB

簡介

RDB持久化方式是通過快照(snapshotting)完成的，當符合一定條件時，redis會自動將內存中所有數據以二進制方式生成一份副本並存儲在硬盤上。當redis重啟時，並且AOF持久化未開啟時，redis會讀取RDB持久化生成的二進制文件(默認名稱dump.rdb，可通過設置dbfilename修改)進行數據恢復，對於持久化信息可以用過命令“info Persistence”查看。

save

該命令會由worker thread 執行，因此會阻塞 redis 的 worker ，期間不會響應任何其他客戶端發來的請求，直到RDB快照文件執行完畢，所以慎用。

測試

info persistence 
# rdb_last_save_time:1570126868
save
info persistence
# rdb_last_save_time:1570126928

bgsave

bgsave“後台保存”。與save 最大的差異為它並不是由 worker thread 執行的，而是由redis fork 齣子進程，交由子進程來完成持久化操作。

redis在fork子進程這個時間段內 redis是阻塞的（此段時間不會響應客戶端請求），當子進程創建完成以後redis才會響應客戶端請求。

並且redis不會在控制台显示完成信息，只會寫入日誌。

流程

客戶端執行bgsave命令，redis主進程收到指令並判斷此時是否在執行bgrewriteaof(AOF文件重新過程，後續會講解)，如果此時正好在執行則bgsave直接返回，不fork子進程，如果沒有執行bgrewriteaof重寫AOF文件，則進入下一個階段；

主進程調用fork方法創建子進程，在創建子進程過程中redis主進程阻塞，所以不能響應客戶端請求；

子進程創建完成以後，bgsave命令返回Background saving started，此時標志著redis可以響應客戶端請求了；

子經常根據主進程的內存副本創建臨時快照文件，當快照文件完成以後對原快照文件進行替換；

子進程發送信號給redis主進程完成快照操作，主進程更新統計信息（info Persistence可查看）,子進程退出；

測試

bgsave
Background saving started  # 子進程創建成功，它會去 完成持久化操作

查看日誌

config get logfile
 11) "logfile"
 12) "/var/log/redis/redis-server.log"
cat "/var/log/redis/redis-server.log"
2497:M 04 Oct 2019 10:26:46.764 * Background saving started by pid 28960   # 開始後台 持久化
2497:M 04 Oct 2020 10:26:46.772 * Background saving terminated with success   # 後台持久化完成 

RDB相關配置

查看配置的方法：

1 查看配置文件

2 在redis 中查看當前 redis 的配置

CONFIG get *    # 獲取所有的配置
CONFIG get dir   # 獲取 快照文件 保存的 位置
CONFIG get dbfilename   # 獲取 快照文件 的文件名

快照文件位置

配置文件中 dir 指定

快照文件名

配置文件中 dbfilename

是否壓縮

配置文件中 rdbcompression default:yes

設置存儲至本地數據庫時是否壓縮數據，默認為yes，採用LZF壓縮

yes 會耗費一定的CPU資源，默認是 yes 。

no 會使存儲的文件變大（巨大）

是否校驗

配置文件中 yesrdbchecksumy default: yes

yes 會消耗一部分CPU資源，但是數據相對安全不容易損壞

no 可以節約讀寫性過程約10%時間消耗，但是存儲一定的數據損壞風險

後台持久化報錯

配置文件中 stop-writes-on-bgsave-error default: yes

後台存儲過程中如果出現錯誤線程，是否停止保存操作，默認是停止的

no 則忽略錯誤繼續。

快照檢查

配置文件中 rdbchecksum default: yes
在寫入文件和讀取文件時是否開啟rdb文件檢查，檢查是否有無損壞，如果在啟動是檢查發現損壞，則停止啟動。

RDB觸發

自動觸發

配置文件中 save default: yes

save second changes
# 查看默認的配置
config get save
"900 1 300 10 60 10000"
# 900秒內 1次鍵更新了就觸發持久化 或 300秒內 10次更新 持久化 60 秒內 10000次更新 觸發持久化
# 該持久化是 bgsave

手動觸發

手動執行 save 或 bgsave

其他觸發

以下幾種種情況下會觸發執行快照操作，並且默認的使用bgsave

主從複製時，從庫全量複製同步主庫數據，此時主庫會執行bgsave命令進行快照；

客戶端執行數據庫清空命令FLUSHALL時候，觸發快照；

客戶端執行shutdown關閉redis時，觸發快照，也可以 使用 nosave 參數顯式聲明不保存快照

shutdown nosave

故障恢復

當redis意外崩潰或者關閉再次啟動時，此時AOF持久化未開啟時(默認未開啟)，將使用RDB快照文件恢複數據。

# 查看日誌
cat /var/log/redis/redis-server.log
30448:M 04 Oct 2019 10:09:37.145 # Server initialized
30448:M 04 Oct 2019 10:09:37.145 * DB loaded from disk: 0.000 seconds   # 從快照恢復
30448:M 04 Oct 2019 10:09:37.146 * Ready to accept connections

缺點

RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具體較大的可能性丟失數據

bgsave指令每次運行要執行fork操作創建子進程，要犧牲掉一些性能

Redis的眾多版本中未進行RDB文件格式的版本統一，有可能出現個版本服務之間數據格式無法兼容現象

存儲數據量較大，效率較低——基於快照思想，每次讀寫都是全部數據，當數據量巨大時，效率非常低
大數據量下的IO性能較低

AOF

簡介

日誌形式的AOF，將命令追加到文件。AOF可以將Redis執行的每一條寫命令追加到磁盤文件(appendonly.aof)中,在redis啟動時候優先選擇從AOF文件恢複數據。因為要頻繁的將每一個操作記錄到文件中，所以開啟AOF持久化會對性能有一定的影響，但是大部分情況下這個影響是可以接受的。

與RDB持久化相比，AOF持久化數據丟失更少，其消耗內存更少(RDB方式執行bgsve會有內存拷貝)。

AOF持久化過程

redisAOF持久化過程可分為以下階段：

追加寫入

redis將每一條寫命令以redis通訊協議添加至緩衝區aof_buf,這樣的好處在於在大量寫請求情況下，採用緩衝區暫存一部分命令隨後根據策略一次性寫入磁盤，這樣可以減少磁盤的I/O次數，提高性能。

同步三種策略

當寫命令寫入aof_buf緩衝區后，redis會將緩衝區的命令寫入到文件，redis提供了三種同步策略，由配置參數appendfsync決定，下面是每個策略所對應的含義：

no

不使用fsync方法同步，而是交給操作系統write函數去執行同步操作，在linux操作系統中大約每30秒執行一次 sync（man 2 sync 查看）。這種情況下，緩衝區數據同步不可控，並且在大量的寫操作下，aof_buf緩衝區會堆積會越來越嚴重，一旦redis出現故障，數據丟失嚴重，整體不可控。

always

表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由於每次寫命令都寫到了文件中, 雖然數據比較安全，但是因為每次寫操作都會同步到AOF文件中，所以在性能上會有影響，同時由於頻繁的IO操作，硬盤的使用壽命會降低。

everysec

數據將使用調用操作系統write寫入文件，並使用fsync每秒一次從內核刷新到磁盤。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。

文件重寫

當開啟AOF時，隨着時間推移，AOF文件會越來越大，redis提出一種重寫的策略來緩解數據存儲和恢復壓力。

重寫策略

重複或無效的命令不寫入文件

過期的數據不再寫入文件

多條命令合併寫入（當多個命令能合併一條命令時候會對其優化合併作為一個命令寫入，例如“RPUSH list1 a RPUSH list1 b” 合併為“RPUSH list1 a b” ）

觸發條件

AOF文件觸發條件可分為手動觸發和自動觸發：

手動觸發：客戶端執行bgrewriteaof命令。

自動觸發：自動觸發通過以下兩個配置協作生效：

auto-aof-rewrite-min-size

AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫,4.0默認配置64mb。

auto-aof-rewrite-percentage

當前AOF文件大小和最後一次重寫后的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。　

redis在AOF功能開啟的情況下，會維持以下三個變量

aof_current_size ：記錄當前AOF文件大小

aof_rewrite_base_size：記錄最後一次AOF重寫之後，AOF文件大小

aof_rewrite_perc：增長百分比變量

每次當serverCron（服務器周期性操作函數）函數執行時，它會檢查以下條件是否全部滿足，如果全部滿足的話，就觸發自動的AOF重寫操作：

沒有BGSAVE命令（RDB持久化）/AOF持久化在執行；

沒有BGREWRITEAOF在進行；

當前AOF文件大小要大於server.aof_rewrite_min_size的值；

當前AOF文件大小和最後一次重寫后的大小之間的比率等於或者大於指定的增長百分比（auto-aof-rewrite-percentage參數）

重寫過程

　　AOF文件重寫過程與RDB快照bgsave工作過程有點相似，都是通過fork子進程，由子進程完成相應的操作，同樣的在fork子進程簡短的時間內，redis是阻塞的，以下圖文說明其重寫過程：

開始bgrewriteaof，判斷當前有沒有bgsave命令(RDB持久化)/bgrewriteaof在執行，倘若有，則這些命令執行完成以後在執行。

主進程fork齣子進程，在這一個短暫的時間內，redis是阻塞的。

當完成重寫后，將重寫后的aof 文件合併到原有aof緩存文件中。並刪除臨時創建的重寫后的aof文件

AOF實現本質

AOF實現本質是基於redis通訊協議，將命令以純文本的方式寫入到文件中。

redis協議：

首先Redis是以行來劃分，每行以\r\n行結束。每一行都有一個消息頭，消息頭共分為5種分別如下:

(+) 表示一個正確的狀態信息，具體信息是當前行+後面的字符。

(-) 表示一個錯誤信息，具體信息是當前行－後面的字符。

(*) 表示消息體總共有多少行，不包括當前行,*後面是具體的行數。

($) 表示下一行數據長度，不包括換行符長度\r\n,$後面則是對應的長度的數據。

(:) 表示返回一個數值，：後面是相應的数字節符。

我們可以直接查看AOF文件中的格式，如下圖：

數據恢復

之前已經提到當AOF開啟時候，redis數據恢復優先選用AOF進行數據恢復，以下使用停止redis來模擬redis故障,然後在重寫啟動進行恢復。

AOF配置參數

auto-aof-rewrite-min-size

AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫,4.0默認配置64mb。

auto-aof-rewrite-percentage

當前AOF文件大小和最後一次重寫后的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。默認 100

appendfsync

上文中提到的三種策略，默認 everysec

always ｜ everysec ｜ no

aof-load-truncated yes

當redis突然運行崩潰時，會出現aof文件被截斷的情況，Redis可以在發生這種情況時退出並加載錯誤，以下選項控制此行為。
如果aof-load-truncated設置為yes，則加載截斷的AOF文件，Redis服務器啟動發出日誌以通知用戶該事件。
如果該選項設置為no，則服務將中止並显示錯誤並停止啟動。當該選項設置為no時，用戶需要在重啟之前使用redis-check-aof實用程序修復AOF文件在進行啟動。

appendonly no

yes開啟AOF，no關閉AOF 默認 no

appendfilename

指定AOF文件名，4.0無法通過config set 設置，只能通過修改配置文件設置。默認 appendonly.aof

RDB-AOF混合持久化

簡介

redis4.0添加了新的持久化方式混合持久化。

混合持久化默認是關閉的，它採用一種rdb + aof 的方式來實現，文件頭rdb 一個全量的快照，格式為二進制，後面是 aof 格式。這樣恢復會先查看開頭是否為REDIS，rdb開頭必然是REDIS。然後從快照恢復，之後從aof恢復。

這樣做的好處是可以結合 rdb 和 aof 的優點, 快速加載同時避免丟失過多的數據

缺點是 aof 裏面的 rdb 部分就是壓縮格式不再是 aof 格式，可讀性差。

開啟混合持久化

5 版本的redis 默認的開啟了aof-use-rdb-preamble 但是 appendonly 默認是 no 也就是說，只要開啟了aof 默認的會使用混合持久化。如果要使用單純的aof 則需要手動的 將 aof-use-rdb-preamble 設為 no （好坑）

4.0版本的混合持久化默認關閉的，通過aof-use-rdb-preamble配置參數控制，yes則表示開啟，no表示禁用，默認是禁用的，可通過config set修改。

混合持久化過程

創建子進程

生成全量的rdb快照，放在appendonly.aof 文件頭部。然後，接下來將aof緩衝區的增量命令以aof方式寫入文件尾

每次恢複數據時，首先從RDB部分恢復，然後執行aof。

數據恢復

開啟了混合持久化時，啟動redis依然優先加載aof文件，aof文件加載可能有兩種情況如下：

aof文件開頭是rdb的格式, 先加載 rdb內容再加載剩餘的 aof。

aof文件開頭不是rdb的格式，直接以aof格式加載整個文件。

三種持久化方案對比

RDB

優點

RDB 是一個非常緊湊（compact）的文件，體積小，傳輸速度快，適合災備。

RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然後這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤 I/O 操作。

RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快很多。

缺點

RDB 丟數據將會丟掉兩次持久化之間的所有數據～

當redis中數據集比較大時候，RDB由於RDB方式需要對數據進行完成拷貝並生成快照文件，fork的子進程會耗CPU，並且數據越大，RDB快照生成會越耗時。

RDB文件是特定的格式，閱讀性差，由於格式固定，並且多版本之間存在不兼容情況。很難受～

AOF

優點

數據更完整，秒級數據丟失(取決於設置fsync策略)

兼容性較高，由於是基於redis通訊協議而形成的命令追加方式，無論何種版本的redis都兼容，再者aof文件是明文的，可閱讀性較好。

缺點

數據文件體積較大,即使有重寫機制，但是在相同的數據集情況下，AOF文件通常比RDB文件大。

相對RDB方式，AOF速度慢於RDB，並且在數據量大時候，恢復速度AOF速度也是慢於RDB。

由於頻繁地將命令同步到文件中，AOF持久化對性能的影響相對RDB較大，但是對於我們來說是可以接受的。

混合持久化

優點

混合持久化結合了RDB持久化 和 AOF 持久化的優點, 由於絕大部分都是RDB格式，加載速度快，同時結合AOF，增量的數據以AOF方式保存了，數據更少的丟失。

缺點

由於前部分是RDB格式，閱讀性較差，兼容性差，一旦開啟了混合持久化，4.0 版本之前的redis 都不認識這種aof文件～ 。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

T90最大的賣點來了，都說自主品牌的動力系統調教的不好，T90直接使用了日產MR20的2。0L自然吸氣發動機，最大功率144馬力，最大扭矩198牛·米，匹配CVT變速箱（低配為6擋手動）。這套動力系統目前也用在天籟和逍客上面搭載，看到這些，你還會擔心T90的動力系統么。

12月25日晚上，東風日產啟辰中型SUV—T90正式上市，價格區間為10.98-15.48萬元。

T90也是小編比較期待的一款自主中型SUV，因為此車有着時尚的外觀，精緻的內飾，舒適的座椅，同時和日產有着千絲萬縷的聯繫，所以小編一直很關注它，直到看到它的正式售價，心裏的石頭也終於落地了，畢竟在價格上，啟辰沒有“逗我們玩”。

T90定位中型轎跑型SUV，目前是啟辰的旗艦車型。T90的車身尺寸為4793*1865*1592mm（不同車型高度略有差異），軸距為2765mm，身材在同級別車型處於正常水準。T90的外觀和寶馬X6、歌詩圖有點類似，都是有着溜背的造型，再加上車子較長，所以T90的側面看起來非常的修長，惹人喜愛。

T90的設計理念為“風雕美學”，這是啟辰第一次運用這個理念設計出來的車型，所以T90的整體外觀看起來會使人眼前一亮，同時別緻的前進氣格柵也為T90加分不少。

內飾也是很討人喜歡的地方，中控台都採用了軟性材質覆蓋，摸起來很柔軟，手感很好，同時做工也比較精細，看得出裝配工藝還是很嚴格的。中控台採用了分辨率高達1920*768的12.3英寸的大屏幕，不僅大氣，同時畫面也比較清晰，運行很流暢，客戶體驗效果很好。

座椅也是T90的亮點，因為T90的尺寸足夠大，所以它的內部空間還是非常寬敞的，尤其是T90採用了和天籟同級別的人體工程學座椅，而移動大沙發是天籟的綽號，所以T90座椅的舒適程度可想而知了。不過遺憾的就是溜背的造型會犧牲一定的後排頭部空間，那些大個子乘客可能要盡量坐到前排了。

T90最大的賣點來了，都說自主品牌的動力系統調教的不好，T90直接使用了日產MR20的2.0L自然吸氣發動機，最大功率144馬力，最大扭矩198牛·米，匹配CVT變速箱（低配為6擋手動）。這套動力系統目前也用在天籟和逍客上面搭載，看到這些，你還會擔心T90的動力系統么？

說了這麼多，大家一定會說T90哪款車的性價比最高了。除了低配和頂配兩款車，T90的同一級別車型的自動和手動車型差價一萬元，相當於多花10000元買一台CVT變速箱，這個價格在同級別屬於正常水平。

其中最低配手動辰尚版配備了主/副駕氣囊、無鑰匙啟動/進入、剎車輔助、多功能方向盤、中控大屏、藍牙電話、後座出風口，配置比較實用，基本可以滿足日常行車需求。唯一遺憾的就是沒有ESp。

手動風尚版和手動辰尚版差價8000元，但是只是多了這兩個配置，性價比較低。而CVT風尚版比手動風尚版貴10000元，多了CVT變速箱，這也可以得出CVT風尚版的性價比也是比較低的。

智尚版僅僅比風尚版貴8000元，但是卻多了這麼多的配置，不得不說性價比真的很高。

頂配CVT領尚版比次頂配CVT智尚版貴1.9萬元，但是只是多了后駐車雷達、腰部支撐調節、前排座椅加熱、LED近光燈、車內氛圍燈、併線輔助、全景攝像頭和更大的輪轂，總體來看性價比並不高。

如果資金不充足，最低配手動辰尚版性價比非常高，如果想要一些配置，那麼智尚版的性價比非常高。總體來說啟辰的質量口碑很好，在加上T90和日產的關係，所以T90也是一款不錯的車型，不過受制於啟辰的知名度限制，能不能熱銷，還是要看T90的造化了。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

相對於大燈外形的變化，光源的變化是最讓我們吃驚的，因為這次鋒范使用的將是集中在大燈中的LED日間行車燈以及LED大燈，脫離了“蠟燭燈”的稱號，並且該價位該級別唯一使用LED大燈的車型。不過尾燈方面基本保留着原有的造型，並且根據細節可以推斷鋒范依然會使用鹵素燈源，這點稍顯遺憾，若是能使用LED燈束式設計辨識度以及顏值肯定上升不少。

前言

本田在這一年內發力非常猛烈，一輛本田思域以及1.5T發動機就引起了不少人的關注。思域個性的外觀更是讓人慾罷不能，但思域以下的車型多半都是以着中庸為主的，其中就算本田鋒范最為明顯，平淡無奇的外觀看着白開水一般，但卻適合絕大多數的審美。本田不滿於此，給我們帶來小改款的本田鋒范。

從這次的官圖來看，本田鋒范將基本保持原來的造型的，但是保險杠進行了調整，有着稍微突出的前吻，而且大燈造型也進行了改變。

前臉將使用的是家族式設計，黑色蜂巢狀中網並且有着一條延伸到大燈上部的鍍鉻裝飾條。大燈樣式也變得和思域類似，就像是思域大燈的縮小版。

相對於大燈外形的變化，光源的變化是最讓我們吃驚的，因為這次鋒范使用的將是集中在大燈中的LED日間行車燈以及LED大燈，脫離了“蠟燭燈”的稱號，並且該價位該級別唯一使用LED大燈的車型。

不過尾燈方面基本保留着原有的造型，並且根據細節可以推斷鋒范依然會使用鹵素燈源，這點稍顯遺憾，若是能使用LED燈束式設計辨識度以及顏值肯定上升不少。

（上圖為現款本田鋒范）

新款本田鋒范將在2017年1月12日在海外市場上市，相信我國市場進行改款也只是時間的問題，本田能把LED大燈逐漸下放到經濟型轎車看得出LED大燈成本在迅速下降。

競爭對手依然是大眾捷達、桑塔納、日產陽光這些合資對手，當然還有着奇瑞艾瑞澤5、長安悅翔V7這些國產對手，若是這次改款鋒范能儘早進入我國相信能給它們造成不少的打擊。畢竟鋒范原本的油耗表現就相當喜人，而如今則是剛剛換上油耗更低的1.5L發動機的新捷達能與之一戰。

不知道各位網友對這改款后的鋒范又是怎樣的看法呢？是否會因為這個新外觀以及LED大燈所埋單？本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※回頭車貨運收費標準