木炭車行駛速度慢，載重能力差，主要承擔客運。當時，由市區發往百多公里以外鄰縣的班線，每天只能行使一個單程。由於車輛老舊，汽車中途拋錨現象時常發生。特別是遇上坡路段，汽車還經常熄火，需旅客幫助推車。有時木炭燒完，還要發動旅客下車揀柴禾、樹枝充做燃料。

現在說到新能源，一般會想到電動車，如果了解得多的可能還知道燃料電池或者氫動力之類，但是再早一點，國內還有另外一種不用新能源的“新能源”汽車—木炭車。

當你在想木炭車怎麼驅動車的時候是不是以為大力出奇迹？其實這裏的木炭不是直接當做發動機的燃料來產生動力，整個工作原理大致如下圖。

利用木炭在一個特殊的發生爐經過一系列程序後生成煤氣，然後讓發動機燃燒煤氣驅動車輛。聽着就很蛋疼啊，除了讓車看起來更丑，開起來更慢，可能還有更多的pM2.5（那會應該還沒有這個概念）為什麼要搞這種事情呢？

上世紀五十年代初，國家經濟處在恢復時期又遇抗美援朝戰爭，各西方國家對我國實施禁運政策，國家汽油短缺，燒汽油的車就紛紛改裝成燒木炭的車。（所以木炭車的本質還是活塞發動機的原理，只是燃料從石油變成了煤氣。）

由於木炭車的結構，每天發車前，駕駛員需要用油棉引燃木炭，先燒上１０分鐘左右，然後搖動鼓風機才能啟動。上部的木炭淋有少量的水分，由於頂部的鍋爐蓋在正常工作時是密封着的，高溫密封加少量的氧，反應成一氧化碳氣體，經罐內生鐵造的爐膽管道，進入儲氣罐再送到發動機里和適量的空氣混合，形成可燃混合氣（也就是煤氣），然後導入發動機工作。（讓我們看下木炭車的動力系統是怎麼工作的）

木炭車一般從點爐到啟動需40-50分鐘。行駛中，還要添料、捅爐、掌握木炭燃燒程度，司機和助手每天工作相當辛苦。木炭車行駛速度慢，載重能力差，主要承擔客運。當時，由市區發往百多公里以外鄰縣的班線，每天只能行使一個單程。由於車輛老舊，汽車中途拋錨現象時常發生。

特別是遇上坡路段，汽車還經常熄火，需旅客幫助推車。有時木炭燒完，還要發動旅客下車揀柴禾、樹枝充做燃料。

一趟行程下來司機乘客都是灰頭土臉，但是在當時的情況下，有車就已經很滿足了，顯然這裏的“新能源”並不是所謂的綠色新能源，所以木炭車隨着我國的油田發展也就漸漸消失了。

看到上面的工程師以為木炭車中國才有嗎？其實二戰的時候有些國家也因為石油問題，甚至期間的坦克也採用“木炭車”的技術，屁股上背着一個大罐。

而在我們的鄰國朝鮮現在還有機會能看到。

雖然我們國家現在有了自己的油田，現在卻是世界最大石油進口國。不管是因為真的消耗如此巨大還是戰略上的貯備，木炭車的歷史都讓我們明白了一個道理，一定要有自己的核心技術。如果當時我們連木炭車都搗鼓不出來就真的只能幹瞪眼。現在的自主品牌中有些確實腳踏實地在潛心研發自己的技術，但是也有些品牌像寄生蟲一樣，總是想着鑽空子，鬧個大新聞，希望自主品牌越來越好的贊一個！本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

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

前置后驅載貨也是一流的，但1。6L動力剛好夠用而已。想動力強加錢上1。5T吧”東風風光580指導價：7。29-9。99萬“又一款7座中型SUV，價格也與長安CX70相似，硬抗的節奏。不過衝著配置以及顏值，我選風光580”東風風神AX3指導價：6。

在留言中，小編總是會遇到很多很多的留言，都是詢問某某車型是怎樣的。那麼今天小編就來一個超大的集合，簡單但客觀地評論6-8萬區間的SUV熱門車型。這樣的評論小編真擔心自己的飯碗吶~

寶駿560

指導價：6.98-10.58萬

“寶駿神車物美價廉，空間大油耗低配置高，但就是底盤表現沒有那麼的SUV。”

北汽幻速S2

指導價：5.18-6.08萬

“價格非常低的SUV車型滿足你的SUV夢，空間還是可以的，但底盤以及操控還是別想着太SUV”

北汽幻速S3

指導價：5.38-6.68萬

“就問你，五萬多的7座緊湊型SUV還想着怎樣？不過小編覺得要是出五座版本的話，空間表現絕對是逆天的”

紳寶X35

指導價：6.58-8.88萬

“總體中規中矩沒有太多亮點，但是來自北汽紳寶讓它可靠性更高，內飾也挺對年輕人口味”

比速T3

指導價：7.49-8.69萬

“配置水平極高，使用的還是1.3T渦輪增壓發動機，就是比速的4S店在哪裡？”

比亞迪元

指導價：7.49-8.69萬

“國產中最愛堆配置的品牌，顏值頗高，背着小書包非常個性，但就看合不合你胃口”

長安CX70

指導價：6.89-10.99萬

“不到7萬買到中型7座SUV，還能有誰？前置后驅載貨也是一流的，但1.6L動力剛好夠用而已。想動力強加錢上1.5T吧”

東風風光580

指導價：7.29-9.99萬

“又一款7座中型SUV，價格也與長安CX70相似，硬抗的節奏？不過衝著配置以及顏值，我選風光580”

東風風神AX3

指導價：6.97-8.77萬

“啊？原來這貨是SUV，我還以為是旅行車呢？顏值不錯，但性價比比較一般”

東南DX3

指導價：6.79-10.09萬

“要顏值有顏值，要操控有操控，年輕人的最愛，後輪還是多連桿式獨立懸架。”

哈弗H1

指導價：5.49-7.89萬

“別以為長城M2換了一個馬甲我就不認得你，ESp配置率較高值得推薦，但其餘都是中規中矩”。

大邁X5

指導價：6.99-12.19萬

“你覺得它外觀像誰呢？配置外觀表現優秀，但就是做工方面以及質感方面需要加強”

小編總結：

對這個價位的車型而言，成本的原因它們是無法做到盡善盡美的，要配置還是要動力？兩者都要做到的話，駕駛品質以及做工精細水平能保證嗎？所以小編覺得的是選擇滿足自己最大需求的車型就好了。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準

題外話：本來不想解釋、可是看完評論，有點服氣。沒想到居然這麼多人能曲解題意。這篇文章明顯是在說，不要寫一大堆if-else，一大堆是啥意思很難懂嗎？我沒有一句話說了不要寫if-else。開頭也給出了具體需求，在這種需求的前提下不要寫if-else，沒毛病吧？？

代碼潔癖狂們！看到一個類中有幾十個if-else是不是很抓狂？
設計模式學了用不上嗎？面試的時候問你，你只能回答最簡單的單例模式，問你有沒有用過反射之類的高級特性，回答也是否嗎？
這次就讓設計模式(模板方法模式+工廠模式)和反射助你消滅if-else！
真的是開發中超超超超超超有用的乾貨啊！

那個坑貨

某日，碼農胖滾豬接到上級一個需求，這個需求牛逼了，一站式智能報表查詢平台，支持mysql、pgxl、tidb、hive、presto、mongo等眾多數據源，想要啥數據都能通通給你查出來展示，對於業務人員數據分析有重大意義！

雖然各個數據源的參數校驗、查詢引擎和查詢邏輯都不一樣，但是胖滾豬對這些框架都很熟悉，這個難不倒她，她只花了一天時間就都寫完了。

領導胖滾熊也對胖滾豬的效率表示了肯定。可是好景不長，第三天，領導閑着沒事，準備做一下code review，可把胖滾熊驚呆了，一個類裏面有近30個if-else代碼，我滴個媽呀，這可讓代碼潔癖狂崩潰了。

// 檢驗入參合法性
Boolean check = false;
if(DataSourceEnum.hive.equals(dataSource)){
    check = checkHiveParams(params);
} else if(DataSourceEnum.tidb.equals(dataSource)){
    check = checkTidbParams(params);
} else if(DataSourceEnum.mysql.equals(dataSource)){
    check = checkMysqlParams(params);
} // else if ....... 省略pgxl、presto等
if(check){
    if(DataSourceEnum.hive.equals(dataSource)){
        list = queryHive(params);
    } else if(DataSourceEnum.tidb.equals(dataSource)){
        list = queryTidb(params);
    } else if(DataSourceEnum.mysql.equals(dataSource)){
        list = queryMysql(params);
    } // else if ....... 省略pgxl、presto等
}
//記錄日誌
log.info("用戶={} 查詢數據源={} 結果size={}",params.getUserName(),params.getDataSource(),list.size());

模板模式來救場

首先我們來分析下，不管是什麼數據源，算法結構(流程)都是一樣的，1、校驗參數合法性 2、查詢 3、記錄日誌。這不就是說模板一樣、只不過具體細節不一樣,沒錯吧？

讓我們來看看設計模式中模板方法模式的定義吧：

模板方法模式：定義一個操作中的算法的框架,而將一些步驟延遲到子類中. 使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。通俗的講,就是將子類相同的方法, 都放到其抽象父類中。

我們這需求不就和模板方法模式差不多嗎？因此我們可以把模板抽到父類(抽象類)中。至於特定的步驟實現不一樣，這些特殊步驟，由子類去重寫就好了。

廢話不多說了，我們先把父類模板寫好吧，完全一樣的邏輯是記錄日誌，這步在模板寫死就好。至於檢驗參數和查詢，這兩個方法各不相同，因此需要置為抽象方法，由子類去重寫。

public abstract class AbstractDataSourceProcesser <T extends QueryInputDomain> {
    public List<HashMap> query(T params){
        List<HashMap> list = new ArrayList<>();
        //檢驗參數合法性 不同的引擎sql校驗邏輯不一樣
        Boolean b = checkParam(params);
        if(b){
            //查詢
            list = queryData(params);
        }
        //記錄日誌
        log.info("用戶={} 查詢數據源={} 結果size={}",params.getUserName(),params.getDataSource(),list.size());
        return list;
    }
    //抽象方法 由子類來實現特定邏輯
    abstract Boolean checkParam(T params);
    abstract List<HashMap> queryData(T params);
}

這段代碼非常簡單。但是為了照顧新手，還是想解釋一個東西：

T這個玩意。叫泛型，因為不同數據源的入參不一樣，所以我們使用泛型。但是他們也有公共的參數，比如用戶名。因此為了不重複冗餘，更好的利用公共資源，在泛型的設計上，我們可以有一個泛型上限，<T extends QueryInputDomain>

public class QueryInputDomain<T> {
    public String userName;//查詢用戶名
    public String dataSource;//查詢數據源 比如mysql\tidb等
    public T params;//特定的參數 不同的數據源參數一般不一樣
}
public class MysqlQueryInput extends QueryInputDomain{
    private String database;//數據庫
    public String sql;//sql
}

接下來就輪到子類出場了，通過上面的分析，其實也很簡單了，不過是繼承父類，重寫checkParam()和queryData()方法，下面以mysql數據源為例，其他數據源也都一樣的套路：

@Component("dataSourceProcessor#mysql")
public class MysqlProcesser extends AbstractDataSourceProcesser<MysqlQueryInput>{
    @Override
    public Boolean checkParam(MysqlQueryInput params) {
        System.out.println("檢驗mysql參數是否準確");
        return true;
    }

    @Override
    public List<HashMap> queryData(MysqlQueryInput params) {
        List<HashMap> list = new ArrayList<>();
        System.out.println("開始查詢mysql數據");
        return list;
    }
}

這樣一來，所有的數據源，都自成一體，擁有一個只屬於自己的類，後續要擴展數據源、或者要修改某個數據源的邏輯，都非常方便和清晰了。

說實話，模板方法模式太簡單了，抽象類這東西也太基礎普遍了，一般應屆生都會知道的。但是對於初入職場的新人來說，還真不太能果斷應用在實際生產中。因此提醒各位：一定要有一個抽象思維，避免代碼冗餘重複。

另外，要再啰嗦幾句，即使工作有幾年的工程師也很容易犯一個錯誤。就是把思維局限在今天的需求，比如老闆一開始只給你一個mysql數據源查詢的需求，壓根沒有if-else，可能你就不會放在心上，直接在一個類中寫死，不會考慮到後續的擴展。直到後面越來越多的新需求，你才恍然大悟，要全部重構一番，這樣浪費自己的時間了。因此提醒各位：做需求不要局限於今天，要考慮到未來。 從一開始就做到高擴展性，後續需求變更和維護就非常爽了。

原創聲明：本文為【胖滾豬學編程】原創博文，轉載請註明出處。以漫畫形式讓編程生動有趣！原創不易，求關注！

工廠模式來救場

但是模板模式還是沒有完全解決胖滾豬的if-else，因為需要根據傳進來的dataSource參數，判斷由哪個service來實現查詢邏輯，現在是這麼寫的：

  if(DataSourceEnum.hive.equals(dataSource)){
        list = queryHive(params);
    } else if(DataSourceEnum.tidb.equals(dataSource)){
        list = queryTidb(params);
    }

那麼這種if-else應該怎麼去幹掉呢？我想先跟你講講工廠模式的那些故事。

工廠模式：工廠方法模式是一種創建對象的模式，它被廣泛應用在jdk中以及Spring和Struts框架中。它將創建對象的工作轉移到了工廠類。

為了呼應一下工廠兩字，我特意舉一個代工廠的例子讓你理解，這樣你應該會有更深刻的印象。

以手機製造業為例。我們知道有蘋果手機、小米手機等等，每種品牌的手機製造方法必然不相同，我們可以先定義好一個手機標準接口，這個接口有make()方法,然後不同型號的手機都繼承這個接口:

#Phone類：手機標準規範類(AbstractProduct)
public interface Phone {
    void make();
}
#MiPhone類：製造小米手機（Product1）
public class MiPhone implements Phone {
    public MiPhone() {
        this.make();
    }
    @Override
    public void make() {
        System.out.println("make xiaomi phone!");
    }
}
#IPhone類：製造蘋果手機（Product2）
public class IPhone implements Phone {
    public IPhone() {
        this.make();
    }
    @Override
    public void make() {
        System.out.println("make iphone!");
    }
}

現在有某手機代工廠：【天霸手機代工廠】。客戶只會告訴該工廠手機型號，就要匹配到不同型號的製作方案，那麼代工廠是怎麼實現的呢？其實也很簡單，簡單工廠模式(還有抽象工廠模式和工廠方法模式,有興趣可以了解下)是這麼實現的：

#PhoneFactory類：手機代工廠（Factory）
public class PhoneFactory {
    public Phone makePhone(String phoneType) {
        if(phoneType.equalsIgnoreCase("MiPhone")){
            return new MiPhone();
        }
        else if(phoneType.equalsIgnoreCase("iPhone")) {
            return new IPhone();
        }
    }
}

這樣客戶告訴你手機型號，你就可以調用代工廠類的方法去獲取到對應的手機製造類。你會發現其實也不過是if-else，但是把if-else抽到一個工廠類，由工廠類統一創建對象，對我們的業務代碼無入侵，不管是維護還是美觀上都會好很多。

首先，我們應該在每個特定的dataSourceProcessor(數據源執行器)，比如MysqlProcesser、TidbProcesser中添加spring容器註解@Component。該註解我想應該不用多解釋了吧~重點是:我們可以把不同數據源都搞成類似的bean name,形如dataSourceProcessor#數據源名稱,如下兩段代碼：

@Component("dataSourceProcessor#mysql")
public class MysqlProcesser extends AbstractDataSourceProcesser<MysqlQueryInput>{
@Component("dataSourceProcessor#tidb")
public class TidbProcesser extends AbstractDataSourceProcesser<TidbQueryInput>{

這樣有什麼好處呢？我可以利用Spring幫我們一次性加載出所有繼承於AbstractDataSourceProcesser的Bean ，形如Map<String, AbstractDataSourceProcesser>,Key是Bean的名稱、而Value則是對應的Bean:

@Service
public class QueryDataServiceImpl implements QueryDataService {
    @Resource
    public Map<String, AbstractDataSourceProcesser> dataSourceProcesserMap;
    public static String beanPrefix = "dataSourceProcessor#";
    @Override
    public List<HashMap> queryData(QueryInputDomain domain) {
        AbstractDataSourceProcesser dataSourceProcesser = dataSourceProcesserMap.get(beanPrefix + domain.getDataSource());
        //省略query代碼
    }
}

可能你還是不太理解，我們直接看一下運行效果：

1、dataSourceProcesserMap內容如下所示，存儲了所有數據源Bean，Key是Bean的名稱、而Value則是對應的Bean:

2、我只需要通過key(即前綴+數據源名稱=beanName)，就能匹配到對應的執行器了。比如當參數dataSource為tidb的時候，key為dataSourceProcessor#tidb，根據key可以直接從dataSourceProcesserMap中獲取到TidbProcesser

public static String classPrefix = "com.lyl.java.advance.service.";

AbstractDataSourceProcesser sourceGenerator = 
(AbstractDataSourceProcesser) Class.forName
(classPrefix+DataSourceEnum.getClasszByCode(domain.getDataSource()))
.newInstance();

需要注意的是，該種方法是通過className來獲取到類的實例，而前端傳參肯定是不會傳className過來的。因此可以用到枚舉類，去定義好不同數據源的類名：

public enum DataSourceEnum {
    mysql("mysql", "MysqlProcesser"),
    tidb("tidb", "TidbProcesser");
    private String code;
    private String classz;

原創聲明：本文為【胖滾豬學編程】原創博文，轉載請註明出處。以漫畫形式讓編程生動有趣！原創不易，求關注！

總結

有些童鞋總覺得設計模式用不上，因為平時寫代碼除了CRUD還是CRUD，面試的時候問你設計模式，你只能回答最簡單的單例模式,問你有沒有用過反射之類的高級特性，回答也是否。

其實不然，JAVA這23種設計模式，每一個都是經典。今天我們就用模板方法模式+工廠模式(或者反射)解決了讓人崩潰的if-else。後續對於設計模式的學習，也應該多去實踐，從真實的項目中找到用武之地，你才算真正把知識佔為己有了。

本篇文章的內容和技術點雖然很簡單，但旨在告訴大家應該要有一個很好的代碼抽象思維。杜絕在代碼中出現一大摞if-else或者其他爛代碼。

即使你有很好的代碼抽象思維，做需求開發的時候，也不要局限於當下，只考慮現在，要多想想未來的擴展性。

就像你談戀愛一樣，只考慮當下的是渣男，考慮到未來的，才算是一個負責任的人

“願世界沒有渣男”

原創聲明：本文為【胖滾豬學編程】原創博文，轉載請註明出處。以漫畫形式讓編程生動有趣！原創不易，求關注！

本文來源於公眾號：【胖滾豬學編程】。一枚集顏值與才華於一身，不算聰明卻足夠努力的女程序媛。用漫畫形式讓編程so easy and interesting！求關注！

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

【其他文章推薦】

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

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

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

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

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

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

最近測試team在測試過程中反饋部分接口需要做一定的限流措施，剛好我也回顧了下限流相關的算法。常見限流相關的算法有四種：計數器算法, 滑動窗口算法, 漏桶算法, 令牌桶算法

1.計數器算法(固定窗口)

 計數器算法是使用計數器在周期內累加訪問次數，當達到設定的閾值時就會觸發限流策略。下一個周期開始時，清零重新開始計數。此算法在單機和分佈式環境下實現都非常簡單，可以使用Redis的incr原子自增和線程安全即可以實現

 這個算法常用於QPS限流和統計訪問總量，對於秒級以上周期來說會存在非常嚴重的問題，那就是臨界問題，如下圖：

 假設我們設置的限流策略時1分鐘限制計數100，在第一個周期最後5秒和第二個周期的開始5秒，分別計數都是88，即在10秒時間內計數達到了176次，已經遠遠超過之前設置的閾值，由此可見，計數器算法（固定窗口）限流方式對於周期比較長的限流存在很大弊端。

 Java 實現計數器（固定窗口）：

package com.brian.limit;

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

import lombok.extern.slf4j.Slf4j;

/**
 * 固定窗口
 */
@Slf4j
public class FixWindow {

    private final ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(5);

    private final int limit = 100;

    private AtomicInteger currentCircleRequestCount = new AtomicInteger(0);

    private AtomicInteger timeCircle = new AtomicInteger(0);

    private void doFixWindow() {
        scheduledExecutorService.scheduleWithFixedDelay(() -> {
            log.info(" 當前時間窗口，第 {} 秒 ", timeCircle.get());
            if(timeCircle.get() >= 60) {
                timeCircle.set(0);
                currentCircleRequestCount.set(0);
                log.info(" =====進入新的時間窗口===== ");
            }
            if(currentCircleRequestCount.get() > limit) {
                log.info("觸發限流策略，當前窗口累計請求數 : {}", currentCircleRequestCount);
            } else {
                final int requestCount = (int) ((Math.random() * 5) + 1);
                log.info("當前發出的 ==requestCount== : {}", requestCount);
                currentCircleRequestCount.addAndGet(requestCount);
            }
           timeCircle.incrementAndGet();
        }, 0, 1, TimeUnit.SECONDS);
    }

    public static void main(String[] args) {
        new FixWindow().doFixWindow();
    }
    
}

2.滑動窗口算法

 滑動窗口算法是將時間周期拆分成N個小的時間周期，分別記錄小周期裏面的訪問次數，並且根據時間的滑動刪除過期的小周期。如下圖，假設時間周期為1分鐘，將1分鐘再分為2個小周期，統計每個小周期的訪問數量，則可以看到，第一個時間周期內，訪問數量為92，第二個時間周期內，訪問數量為104，超過100的訪問則被限流掉了。

 由此可見，當滑動窗口的格子劃分的越多，那麼滑動窗口的滾動就越平滑，限流的統計就會越精確。此算法可以很好的解決固定窗口算法的臨界問題。

  Java實現滑動窗口：

package com.brian.limit;

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;
import lombok.extern.slf4j.Slf4j;

/**
 * 滑動窗口
 * 
 * 60s限流100次請求
 */
@Slf4j
public class RollingWindow {

    private final ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(5);

    // 窗口跨度時間60s
    private int timeWindow = 60;

    // 限流100個請求
    private final int limit = 100;

    // 當前窗口請求數
    private AtomicInteger currentWindowRequestCount = new AtomicInteger(0);

    // 時間片段滾動次數
    private AtomicInteger timeCircle = new AtomicInteger(0);

    // 觸發了限流策略后等待的時間
    private AtomicInteger waitTime = new AtomicInteger(0);

    // 在下一個窗口時，需要減去的請求數
    private int expiredRequest = 0;

    // 時間片段為5秒，每5秒統計下過去60秒的請求次數
    private final int slidingTime = 5;

    private ArrayBlockingQueue<Integer> slidingTimeValues = new ArrayBlockingQueue<>(11);

    public void rollingWindow() {
        scheduledExecutorService.scheduleWithFixedDelay(() -> {

            if (waitTime.get() > 0) {
                waitTime.compareAndExchange(waitTime.get(), waitTime.get() - slidingTime);
                log.info("=====當前滑動窗口===== 限流等待下一個時間窗口倒計時: {}s", waitTime.get());
                if (currentWindowRequestCount.get() > 0) {
                    currentWindowRequestCount.set(0);
                }
            } else {
                final int requestCount = (int) ((Math.random() * 10) + 7);
                if (timeCircle.get() < 12) {
                    timeCircle.incrementAndGet();
                }
                
            log.info("當前時間片段5秒內的請求數: {} ", requestCount);
            currentWindowRequestCount.addAndGet(requestCount);
            log.info("=====當前滑動窗口===== {}s 內請求數: {} ", timeCircle.get()*slidingTime , currentWindowRequestCount.get());

            if(!slidingTimeValues.offer(requestCount)){
                expiredRequest =  slidingTimeValues.poll();
                slidingTimeValues.offer(requestCount);
            } 

            if(currentWindowRequestCount.get() > limit) {
                // 觸發限流
                log.info("=====當前滑動窗口===== 請求數超過100, 觸發限流,等待下一個時間窗口 ");
                waitTime.set(timeWindow);
                timeCircle.set(0);
                slidingTimeValues.clear();
            } else {
                // 沒有觸發限流，滑動下一個窗口需要,移除相應的:在下一個窗口時，需要減去的請求數
                log.info("=====當前滑動窗口===== 請求數 <100, 未觸發限流，當前窗口請求總數: {},即將過期的請求數：{}"
                        ,currentWindowRequestCount.get(), expiredRequest);
                currentWindowRequestCount.compareAndExchange(currentWindowRequestCount.get(), currentWindowRequestCount.get() - expiredRequest);
            }
        }   
        }, 5, 5, TimeUnit.SECONDS);
    }

    public static void main(String[] args) {
        new RollingWindow().rollingWindow();
    }
    

}

計數器（固定窗口）和滑動窗口區別：

計數器算法是最簡單的算法，可以看成是滑動窗口的低精度實現。滑動窗口由於需要存儲多份的計數器（每一個格子存一份），所以滑動窗口在實現上需要更多的存儲空間。也就是說，如果滑動窗口的精度越高，需要的存儲空間就越大。

3.漏桶算法

 漏桶算法是訪問請求到達時直接放入漏桶，如當前容量已達到上限（限流值），則進行丟棄（觸發限流策略）。漏桶以固定的速率進行釋放訪問請求（即請求通過），直到漏桶為空。

 Java實現漏桶：

package com.brian.limit;

import java.util.concurrent.*;

import lombok.extern.slf4j.Slf4j;

/**
 * 漏桶算法
 */
@Slf4j
public class LeakyBucket {
    private final ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(5);

    // 桶容量
    public  int capacity = 1000;
    
    // 當前桶中請求數
    public int curretRequest = 0;

    // 每秒恆定處理的請求數
    private final int handleRequest = 100;

    public void doLimit() {
        scheduledExecutorService.scheduleWithFixedDelay(() -> {
            final int requestCount = (int) ((Math.random() * 200) + 50);
            if(capacity > requestCount){
                capacity -= requestCount;
                log.info("<><>當前1秒內的請求數:{}, 桶的容量:{}", requestCount, capacity);
                if(capacity <=0) {
                    log.info(" =====觸發限流策略===== ");
                } else {
                    capacity += handleRequest;
                    log.info("<><><><>當前1秒內處理請求數:{}, 桶的容量:{}", handleRequest, capacity);
                }
            } else {
                log.info("<><><><>當前請求數:{}, 桶的容量:{},丟棄的請求數:{}", requestCount, capacity,requestCount-capacity);
                if(capacity <= requestCount) {
                    capacity = 0;
                }
                capacity += handleRequest;
                log.info("<><><><>當前1秒內處理請求數:{}, 桶的容量:{}", handleRequest, capacity);
            }
        }, 0, 1, TimeUnit.SECONDS);
    }

    public static void main(String[] args) {
        new LeakyBucket().doLimit();
    }
}

 漏桶算法有個缺點：如果桶的容量過大，突發請求時也會對後面請求的接口造成很大的壓力。

4.令牌桶算法

 令牌桶算法是程序以恆定的速度向令牌桶中增加令牌，令牌桶滿了之後會丟棄新進入的令牌，當請求到達時向令牌桶請求令牌，如獲取到令牌則通過請求，否則觸發限流策略。

 Java實現令牌桶：

package com.brian.limit;

import java.util.concurrent.*;

import lombok.extern.slf4j.Slf4j;
/**
 * 令牌桶算法
 */
@Slf4j
public class TokenBucket {
    private final ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(5);

    // 桶容量
    public  int capacity = 1000;
    
    // 當前桶中請求數
    public int curretToken = 0;

    // 恆定的速率放入令牌
    private final int tokenCount = 200;

    public void doLimit() {
        scheduledExecutorService.scheduleWithFixedDelay(() -> {
            
            new Thread( () -> {
                if(curretToken >= capacity) {
                    log.info(" =====桶中的令牌已經滿了===== ");
                    curretToken = capacity;
                } else {
                    if((curretToken+tokenCount) >= capacity){
                      log.info(" 當前桶中的令牌數:{},新進入的令牌將被丟棄的數: {}",curretToken,(curretToken+tokenCount-capacity));
                      curretToken = capacity;
                  } else {
                      curretToken += tokenCount;
                  }
                }
            }).start();

            new Thread( () -> {
                final int requestCount = (int) ((Math.random() * 200) + 50);
                if(requestCount >= curretToken){
                    log.info(" 當前請求數:{},桶中令牌數: {},將被丟棄的請求數:{}",requestCount,curretToken,(requestCount - curretToken));
                    curretToken = 0;
                } else {
                    log.info(" 當前請求數:{},桶中令牌數: {}",requestCount,curretToken);
                    curretToken -= requestCount;
                }
            }).start();
        }, 0, 500, TimeUnit.MILLISECONDS);
    }

    public static void main(String[] args) {
        new TokenBucket().doLimit();
    }
    
}

漏桶算法和令牌桶算法區別：

令牌桶可以用來保護自己，主要用來對調用者頻率進行限流，為的是讓自己不被打垮。所以如果自己本身有處理能力的時候，如果流量突發（實際消費能力強於配置的流量限制），那麼實際處理速率可以超過配置的限制。而漏桶算法，這是用來保護他人，也就是保護他所調用的系統。主要場景是，當調用的第三方系統本身沒有保護機制，或者有流量限制的時候，我們的調用速度不能超過他的限制，由於我們不能更改第三方系統，所以只有在主調方控制。這個時候，即使流量突發，也必須捨棄。因為消費能力是第三方決定的。
總結起來：如果要讓自己的系統不被打垮，用令牌桶。如果保證被別人的系統不被打垮，用漏桶算法

參考博客：https://blog.csdn.net/weixin_41846320/article/details/95941361

　　　　　https://www.cnblogs.com/xuwc/p/9123078.html

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

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準

本文始發於個人公眾號：TechFlow，原創不易，求個關注

set(sorted(arr))

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

【其他文章推薦】

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

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

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

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

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

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

Redis 持久化設計

持久化的功能：Redis是內存數據庫，數據都是存儲在內存中的，為了避免進程退出導致數據的永久丟失，要定期將Redis中的數據以某種形式從內存保存到硬盤，當下次Reids重啟時，利用持久化文件實現數據恢復。

RDB：將當前數據保存到硬盤

AOF：將每次執行的寫命令保存到硬盤（類似MySQL的binlog）

1. RDB持久化

RDB持久化是將當前進程中的數據生成快照保存到硬盤(因此也稱作快照持久化)，保存的文件後綴是rdb；當Redis重新啟動時，可以讀取快照文件恢複數據。

1. 觸發條件

   • 手動觸發 save 命令和bgsave命令都可以生成RDB文件, save命令會阻塞Redis服務進程，知道RDB文件創建完畢，bgsave命令則是創建一個子進程，由子進程來負責創建RDB文件，父進程繼續處理請求，bgsave命令執行過程中，只有fork子進程時會阻塞服務器，而對於save命令，整個過程都會阻塞服務器，因此save已基本被廢棄，線上環境要杜絕save的使用；後文中也將只介紹bgsave命令。此外，在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化

   SAVE 執行期間，AOF 寫入可以在後台線程進行，BGREWRITEAOF 可以在子進程進行，所以這三種操作可以同時進行 ，為了避免性能問題，BGSAVE 和 BGREWRITEAOF 不能同時執行

2. 自動觸發

save m n

在配置文件中通過 save m n 命令，指定當前m秒內發生n次變化時，觸發bgsave。

​ 其中save 900 1的含義是：當時間到900秒時，如果redis數據發生了至少1次變化，則執行bgsave；save 300 10和save 60 10000同理。當三個save條件滿足任意一個時，都會引起bgsave的調用.

Redis的save m n，是通過serverCron函數、dirty計數器、和lastsave時間戳來實現的-

• serverCron函數，是Redis服務器的周期性操作函數，默認每隔100ms執行一次，該函數對服務器的狀態進行維護，其中一項工作就是檢測save m n 配置是否滿足條件，如果滿足就執行bgsave.
• dirty計數器 記錄服務器進行了多少起操作，修改，不是客戶端執行了多少修改數據的命令
• lastsave時間戳也是Reids服務器維持的一個狀態，記錄上一次成功執行bgsave的時間

save m n的原理如下：每隔100ms，執行serverCron函數；在serverCron函數中，遍歷save m n配置的保存條件，只要有一個條件滿足，就進行bgsave。對於每一個save m n條件，只有下面兩條同時滿足時才算滿足：

• 當前時間-lastsave > m

• dirty >= n

在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb文件發送給從節點。

在執行shutdown命令時，自動執行rdb持久化

1.2 RDB文件

設置存儲路徑

- 配置文件：dir配置指定目錄，dbfilename指定文件名。默認是Redis根目錄下的dump.rdb文件
- 動態設置： 

config set dir {newdir} /// config set dbfilename {newFileName}

RDB文件 是經過壓縮的二進制文件，默認採用LZF算法對RDB文件進行壓縮，雖然壓縮耗時，但是可以大大減小文件體積，默認是開啟的，可以通過命令關閉：

config set rdbcompression no

RDB文件的壓縮並不是針對整個文件進行的，而是對數據庫中的字符串進行的，且只有在字符串達到一定長度(20字節)時才會進行

格式:

字段說明：

1. REDIS常量，保存‘REDIS’5個字符

2. db_version RDB文件的版本號

3. SELECTDB 表示一個完整的數據庫(0號數據庫)，同理SELECTDB 3 pairs表示完整的3號數據庫；只有當數據庫中有鍵值對時，RDB文件中才會有該數據庫的信息(上圖所示的Redis中只有0號和3號數據庫有鍵值對)；如果Redis中所有的數據庫都沒有鍵值對，則這一部分直接省略。其中：SELECTDB是一個常量，代表後面跟着的是數據庫號碼；0和3是數據庫號碼；

4. KEY-VALUE-PAIRS: pairs則存儲了具體的鍵值對信息，包括key、value值，及其數據類型、內部編碼、過期時間、壓縮信息等等

1. EOF 標志著數據庫內容的結尾（不是文件的結尾），值為 rdb.h/EDIS_RDB_OPCODE_EOF （255）

2. CHECK-SUM RDB 文件所有內容的校驗和，一個 uint_64t 類型值, REDIS 在寫入 RDB 文件時將校驗和保存在 RDB 文件的末尾，當讀取時，根據它的值對內容進行校驗

。如果這個域的值為 0 ，那麼表示 Redis 關閉了校驗和功能。

1.3 啟動時加載

​ RDB文件的載入工作是在服務器啟動時自動執行的，並沒有專門的命令。但是由於AOF的優先級更高，因此當AOF開啟時，Redis會優先載入AOF文件來恢複數據；只有當AOF關閉時，才會在Redis服務器啟動時檢測RDB文件，並自動載入。服務器載入RDB文件期間處於阻塞狀態，直到載入完成為止

2. AOF持久化

AOF(Append Only File) 則以協議文本的方式，將所有對數據庫進行過寫入的命令（及其參數）記錄到 AOF
文件，以此達到記錄數據庫狀態的目的

2.1 開啟AOF

Redis服務器默認開啟RDB，關閉AOF；要開啟AOF，需要在配置文件中配置：

appendonly yes

2.2 執行流程

2.2.1 命令寫入緩衝區

//緩衝區的定義 是一個SDS, 可以兼容C語言的字符串
struct redisServer {
    // AOF緩衝區， 在進入事件loop之前寫入
    sds aof_buf;
};

1. 命令傳播： Redis將執行完的命令、命令的參數、命令的參數個數等信息發送到 AOF 程序中

2. 緩存追加： AOF程序根據接收到的命令命令數據，將命令轉換為網絡通訊協議的格式，然後將協議內容追加到服務器的 AOF 緩存中。

   • 將命令以文本協議格式保存在緩存中
   • 為什麼使用文本協議格式？兼容性，避免二次開銷，可讀性
   • 為什麼寫入緩存？這樣不會受制於磁盤的IO性能，避免每次有寫命令都直接寫入硬盤，導致硬盤IO成為Redis負載的瓶頸

3. 文件寫入和保存：AOF 緩存中的內容被寫入到 AOF 文件末尾，如果設定的 AOF 保存
   條件被滿足的話，fsync 函數或者 fdatasync 函數會被調用，將寫入的內容真正地保存到磁盤中。

   為了提高文件寫入效率，在現代操作系統中，當用戶調用write函數將數據寫入文件時，操作系統通常會將數據暫存到一個內存緩衝區里，當緩衝區被填滿或超過了指定時限后，才真正將緩衝區的數據寫入到硬盤裡。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，內存緩衝區中的數據會丟失；因此系統同時提供了fsync、fdatasync等同步函數，可以強制操作系統立刻將緩衝區中的數據寫入到硬盤裡，從而確保數據的安全性。

   AOF保存模式：

   • AOF_FSYNC_ALWAYS: 命令寫入aof-buf后立即調用系統的fsync操作同步到AOF文件。因為 SAVE 是由 Redis 主進程執行的，所以在 SAVE 執行期間，主進程會被阻塞，不能接受命令請求。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固態硬盤（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
   • AOF_FSYNC_NO: 命令寫入aof_buf后調用系統write操作，不對AOF文件做fsync同步；同步由操作系統負責，通常同步周期為30秒。這種情況下，文件同步的時間不可控，且緩衝區中堆積的數據會很多，數據安全性無法保證。
   • AOF_FSYNC_EVERYSEC: 每一秒鐘保存一次,命令寫入aof_buf后調用系統write操作, write完成后線程返回， fsync同步文件操作由專門線程每秒調用一次

2.2.2. 文件重寫

隨着命令不斷寫入AOF，文件會越來越大，為了解決這個問題，Redis引入AOF重寫機制壓縮文件體積，AOF文件重寫是把Redis進程內的數據轉化為寫命令同步到新AOF文件的過程。

重寫后的AOF文件為什麼可以變小？

1. 進程內已經超時的數據不再寫入文件
2. 舊的AOF文件含有無效命令 ，如有些數據被重複設值(set mykey v1, set mykey v2)、有些數據被刪除了(sadd myset v1, del myset)等等， 新的AOF文件只保留最終的數據寫入命令
3. 多條寫入命令可以合併為一個，如：lpush list a、lpush list b可以轉化為：lpush list a b。為了防止單條命令過大造成客戶端緩衝區溢出，對於list、set、hash等類型操作，以64個元素為邊界拆分為多條

AOF重寫可以手動觸發也可以自動觸發：

• 手動觸發： 直接調用bgrewriteaof命令
• 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數確定自動觸發時機。
  • auto-aof-rewrite-min-size：表示運行AOF重寫時文件最小體積，默認為64MB
  • auto-aof-rewrite-percentage：代表當前AOF文件空間(aof_current_size)和上一次重寫后AOF文件空間(aof_base_size)的比值

流程說明：

1）執行AOF重寫請求。

如果當前進程正在執行AOF重寫，請求不執行。

如果當前進程正在執行bgsave操作，重寫命令延遲到bgsave完成之後再執行。

2）父進程執行fork創建子進程，開銷等同於bgsave過程。

3.1）主進程fork操作完成后，繼續響應其它命令。

　　所有修改命令依然寫入AOF文件緩衝區並根據appendfsync策略同步到磁盤，保證原有AOF機制正確性。

3.2）由於fork操作運用寫時複製技術，子進程只能共享fork操作時的內存數據

　　由於父進程依然響應命令，Redis使用“AOF”重寫緩衝區保存這部分新數據，防止新的AOF文件生成期間丟失這部分數據。

4）子進程依據內存快照，按照命令合併規則寫入到新的AOF文件。

　　每次批量寫入硬盤數據量由配置aof-rewrite-incremental-fsync控制，默認為32MB，防止單次刷盤數據過多造成硬盤阻塞。

5.1）新AOF文件寫入完成后，子進程發送信號給父進程，父進程調用一個信號處理函數，並執行以前操作更新統計信息。

5.2）父進程把AOF重寫緩衝區的數據寫入到新的AOF文件。這時新 AOF 文件所保存的數據庫狀態將和服務器當前的數據庫狀態一致。

5.3）對新的AOF文件進行改名，原子地(atomic)覆蓋現有的AOF文件，完成新舊文件的替換。

在整個 AOF 後台重寫過程中，只有信號處理函數執行時會對服務器進程（父進程）造成阻塞，其他時候，AOF 後台重寫都不會阻塞父進程，這將 AOF 重寫對服務器性能造成的影響降到了最低

參考《Redis-設計與實現：AOF-持久化》

2.2.3 重啟加載

流程說明：

1）AOF持久化開啟且存在AOF文件時，優先加載AOF文件。

2）AOF關閉或者AOF文件不存在時，加載RDB文件。

3）加載AOF/RDB文件成功后，Redis啟動成功。

4）AOF/RDB文件存在錯誤時，Redis啟動失敗並打印錯誤信息。

數據還原的詳細步驟：

1. 創建一個不帶網絡連接的偽客戶端（fake client）: 因為 Redis 的命令只能在客戶端上下文中執行，而載入 AOF 文件時所使用的命令直接來源於 AOF 文件而不是網絡連接，所以服務器使用了一個沒有網絡連接的偽客戶端來執行 AOF 文件保存的寫命令，偽客戶端執行命令的效果和帶網絡連接的客戶端執行命令的效果完全一樣。
2. 從AOF文件中分析並讀取出一條寫命令，使用偽客戶端執行被讀出的寫命令，重複此操作，直到AOF文件中的所有寫命令都被處理完畢為止。

2.2.4 文件校驗

加載損壞的AOF文件會拒絕啟動，並打印錯誤信息。

注意：對於錯誤格式的AOF文件，先進性備份，然後採用redis-check-aof --fix命令進行修復，修復后使用diff -u對比數據差異，找到丟失的數據，有些可以進行人工補全。

AOF文件可能存在結尾不完整的情況，比如機器突然掉電導致AOF尾部文件命令寫入不全。

Redis為我們提高了aof-load-truncated配置來兼容這種情況，默認開啟

3. 了解MySQL中的binlog

mysql binlog應用場景與原理深度剖析

參考博文與書籍：

1. 《redis設計與實現》
2. Redis持久化
3. [徐劉根-Redis實戰和核心原理詳解（8）使用快照RDB和AOF將Redis數據持久化到硬盤中](https://blog.csdn.net/xlgen157387/article/details/61925524

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

【其他文章推薦】

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

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

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

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

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

環境資訊中心外電；姜唯 翻譯；林大利 審校；稿源：ENS

儘管全球為防堵武漢肺炎（COVID-19）而大規模封城，大氣中的溫室氣體濃度卻仍來到300萬年來最高。

氣候變遷沒有因為武漢肺炎而停下腳步。封城和經濟趨緩雖使碳排放出現暫時性下降，整體趨勢仍朝著肺炎爆發前的水準邁進。

2020年二氧化碳排放量將因為疫情關係減少4％至7％。確切能減少多少將取決於疫情控制情況和政府的應對措施。

今年雖然碰上疫情而大規模封城，大氣中的溫室氣體濃度卻仍來到300萬年來最高。照片來源：Tony Webster（CC BY-SA 2.0）

2016至2020年將是有史以來最熱的五年

全球最大、最具權威性的多個科學組織合作發表「2020科學界聯合報告（United in Science 2020）」，彙整出全面性的相關資訊。

這份報告是本系列報告的第二份，由世界氣象組織（World Meteorological Organization﹐WMO）協調，收集來自全球碳計畫（Global Carbon Project）、政府間氣候變遷專門委員會（Intergovernmental Panel on Climate Change）、聯合國教科文組織政府間海洋學委員會（Intergovernmental Oceanographic Commission of UNESCO）、聯合國環境規劃署（UN Environment Programme﹐UNEP）和英國氣象局的專業意見 。

「溫室氣體濃度已經達到300萬年來的最高水準，並持續上升中。同時在2020年上半年，西伯利亞大片地區出現長時間的異常熱浪，若不是人為的氣候變遷，這幾乎不可能發生。2016至2020年將是有史以來最熱的五年。」WMO秘書長塔拉斯（Petteri Taalas）教授警告，「這份報告說明了，儘管我們的生活在2020年多方被打亂，但氣候變遷的影響力並未減弱。」

暖化趨勢很可能會持續 使巴黎協定無法達成

乾旱和熱浪大幅增加了野火風險。有史以來野火造成的三次最大經濟損失都發生在最近四年。2019年和2020年夏季，北極地區發生了前所未有的野火。2019年6月，這些野火向大氣排放了5000萬噸二氧化碳，造成永凍土融化。2019年和2020年，亞馬遜雨林發生了大火，對環境造成了巨大影響。

2020科學界聯合報告引用的「世界天氣歸因」最近的一項研究結果指出，由於人為氣候變遷，2020年1月至2020年6月的高溫可能性至少高出600倍。

報告中記載的暖化趨勢很可能會持續下去，使全世界無法實現2015年巴黎協定設定的氣候目標，全球氣溫上升幅度遠低於工業化前水準2°C或僅比工業化高前1.5°C。

報告提供與氣候變遷相關的最新科學資料和發現，作為全球政策和行動的指引。內容聚焦氣候變遷的影響日益增加且不可逆轉，它影響冰川、海洋、自然、經濟和人類生活條件，人類往往可從乾旱或洪水等與水有關的危害切身感受到。

報告也記載了武漢肺炎如何破壞我們透過全球觀測系統監測這些變化的能力。

有史以來野火造成的三次最大經濟損失都發生在最近四年。照片來源： Ulet Ifansasti／Greenpeace（CC BY-NC-ND 2.0）

2020科學界聯合報告的主要發現

大氣中的溫室氣體濃度（世界氣象組織）

大氣中的二氧化碳濃度沒有要封頂的跡象，一直在打破紀錄。

根據WMO全球大氣監測網水準點的報告，2020年上半年二氧化碳濃度高於410 ppm，夏威夷冒納羅亞和澳洲塔斯馬尼亞格里姆角的觀測值分別為414.38 ppm和410.04 ppm。2020年比2019年7月增加了約3 ppm。

2020年二氧化碳排放量的減少只會輕微影響大氣中濃度的增加速度，因為今日大氣中二氧化碳濃度是過去和當前排放以及二氧化碳超長壽命所致結果。

WMO在其報告中表示：「要使氣候變遷穩定下來，必須將排放量持續減少至零淨值。」

全球化石燃料二氧化碳排放量（全球碳計畫）

由於武肺封鎖，2020年二氧化碳排放量預計將下降4％至7％。確切的下降百分比將取決於疫情控制狀況和政府因應方式。

2020年4月上旬的封城高峰期，全球每日化石燃料二氧化碳排放量與2019年相比下降了前所未有的17％。

但儘管如此，排放量仍與2006年的水準相當，凸顯過去15年來的急劇增長及長期依賴化石能源。

到2020年6月上旬，全球每日化石燃料排放量只比2019年水準低了5％不到，去年達到了367億公噸的新紀錄，比1990年氣候變遷談判開始時高62％。

過去10年間，人類活動產生的全球甲烷排放量也在持續增加。報告警告：「目前的二氧化碳和甲烷排放趨勢均無法達到巴黎協定目標。」

排放差距（聯合國環境規劃署）

聯合國環境規劃署呼籲，要實現巴黎協定目標，轉型行動不能再延。

環境署「2019年排放差距報告」顯示，從2020～2030年，要達到巴黎協定的2°C目標，每年要將全球排放量削減3％，要達到1.5°C目標平均每年要削減7％以上。

根據目前的預估，2030年與2°C目標的排放差距為120～150億公噸二氧化碳當量（CO2e），與1.5°C目標的排放差距為29～32吉噸二氧化碳當量，大約等於六個最大排放國的排放總量。

環境署說：「仍然有可能縮小這個排放差距，但需要所有國家和所有部門立即協調一致的行動……短期來說可以透過擴大現有的有效的政策來實現，例如再生能源和能源效率、低碳運輸以及逐步淘汰煤炭的政策。」

全球氣候狀況（WMO和英國氣象局）

2016～2020年的全球平均溫度將是有記錄以來最高溫，比前工業化時代參考期1850～1900年高出約1.1°C，比2011～2015年的全球平均溫度高出0.24°C。

在2020年至2024年這五年期間，至少有一年比工業化前水準高出1.5°C以上的機率是24％，五年平均值超過該水準的機會很小（3%）。兩家機構在報告中表示：「未來五年內，有70%的機率有一個或多個月的氣溫可能比工業化前高至少1.5°C。」

2016年至2020年間的每一年，北極海冰面積都低於平均水準。

2016至2019年的冰川質量損失均大於1950年以來的每個五年期。

2011至2015年和2016至2020年這兩個五年相比，全球平均海平面上升速度有所提高。

氣候變遷下的海洋和冰凍圈（政府間氣候變遷專門委員會）

人為氣候變遷正在影響從山頂到海洋深處的生命維持系統，導致海平面上升加快，對生態系統和人類安全產生連鎖反應，也對適應和綜合風險管理造成嚴峻挑戰。

全球的冰蓋和冰川正在消失。1979年至2018年間，一年之中每個月的北極海冰範圍都一直在減少。野火增加、永凍土突然融化以及北極和山區水文的變化，已經改變了生態系統擾動的頻率和強度。

1970年以來，全球海洋暖化不停息，並吸收了氣候系統90％以上的多餘熱量。自1993年以來，海洋暖化的速度和所吸收的來自氣候系統的熱量增加了一倍以上。

海洋熱浪的頻率增加了一倍，持續時間更長、強度更大、範圍更廣，導致大規模珊瑚白化。自1980年代以來，海洋吸收了人為二氧化碳總排放量的20％至30％，使海洋進一步酸化。

自大約1950年以來，海洋暖化、海冰變化和氧氣流失，許多海洋物種的分佈範圍和季節性活動發生了變化。

由於格陵蘭和南極冰蓋的冰流失率增加、冰川持續流失和海洋熱膨脹，近幾十年來海平面加速上升。2006至2015年全球平均海平面上升速度為每年3.6±0.5公釐，這在上個世紀前所未見。

全球的冰蓋和冰川正在消失。美國冰河灣國家公園。照片來源：mulf（CC BY-NC-ND 2.0）

氣候與水資源（WMO）

氣候變遷最明顯的影響出現在水文條件的變化，包括冰雪動力學的變化。

到2050年，受洪水威脅的人數將從目前的12億增加到16億。在2010年代初到中期，有19億人（全球人口的27％）生活在可能缺水的地區。到2050年，這個數字將增加到27～32億。

截至2019年，全世界有12％人口的飲用水來自未經改進和不安全的水源。全世界有30％以上的人口（即24億人）沒有任何形式的衛生設施。

氣候變遷將使更多地區缺水，已經缺水的地區將更嚴重。

冰凍圈是山區及其下游地區的重要淡水來源。學界認為，冰川的年徑流最晚將在21世紀末達到全球最高峰。此後全球冰川徑流將減少，影響水的儲存。

據估計，中歐和高加索地區現已達到最高水位，青藏高原地區將在2030年至2050年達到最高水位。隨著積雪融化形成徑流，該地區的永凍土和冰川佔河流總流量的45％，流量減少將影響17億人的用水。

武肺期間的地球系統觀測（教科文組織和WMO政府間海洋學委員會）

武漢肺炎嚴重影響全球觀測工作，進而影響預報以及其他天氣、氣候和海洋相關服務的品質。

3月和4月的飛行器觀測工作平均減少了75％至80％，降低了天氣模型的預報能力。自6月以來僅略有恢復。人工操作的氣象站觀測工作也受到嚴重干擾，尤其在非洲和南美。

諸如河流流量之類的水文觀測情況也類似。自動化系統可以繼續傳遞數據，而人工讀取的測量站受到影響。

2020年3月，幾乎所有海洋學研究船都被召回國籍港口。商用船無法提供重要的海洋和天氣觀測資料，並且無法維護海洋浮標和其他系統。每10年要進行四次的全深度海洋調查，包括碳、溫度、鹽度和水鹼度等變量偵測，都取消了。提供溫室氣體排放資訊的的船舶表面碳測量工作也幾乎停止。

這對氣候變遷監測的影響是長期的，可能會阻礙或限制融冰期結束時進行的冰川質量變化或永凍土厚度的測量活動。觀測活動中斷將使基本氣候變量的歷史時間序列產生斷層，不利監測氣候變動和變遷以及相關影響。

Climate Change Intensifies Despite Pandemic Lockdowns GENEVA, Switzerland, September 10, 2020 (ENS)

Already at their highest levels in three million years, greenhouse gas concentrations in the atmosphere continue to increase, lockdowns around the world to slow the spread of the pandemic coronavirus have forced vehicles to stay parked, making way for clearer skies – temporarily.

But climate change has not stopped for COVID-19. Emissions are heading in the direction of pre-pandemic levels following a temporary decline caused by the lockdown and economic slowdown.

In 2020, emissions of the greenhouse gas carbon dioxide (CO2) are projected to fall by an estimated four to seven percent due to COVID-19 confinement policies. The exact drop in atmospheric CO2 will depend on the trajectory of the pandemic and government responses to address it.

These facts are contained in a new multi-agency report from the world’s largest and most respected scientific organizations, “United in Science 2020.”

The report, the second in a series, was coordinated by the World Meteorological Organization, WMO, with input from the Global Carbon Project, the Intergovernmental Panel on Climate Change, the Intergovernmental Oceanographic Commission of UNESCO, the UN Environment Programme and the UK Met Office.

WMO Secretary-General Professor Petteri Taalas warned, “Greenhouse gas concentrations – which are already at their highest levels in three million years – have continued to rise. Meanwhile, large swathes of Siberia have seen a prolonged and remarkable heatwave during the first half of 2020, which would have been very unlikely without anthropogenic climate change. And now 2016–2020 is set to be the warmest five-year period on record.

“This report shows that whilst many aspects of our lives have been disrupted in 2020, climate change has continued unabated,” Taalas said.

“Major impacts have been caused by extreme weather and climate events. A clear fingerprint of human-induced climate change has been identified on many of these extreme events,” the WMO and UN Met Office say in the report.

Drought and heatwaves substantially increased the risk of wildfires. The three largest economic losses on record from wildfires have all occurred in the last four years. Summer 2019 and 2020 saw unprecedented wildfires in the Arctic region. In June 2019, these fires emitted 50 million tonnes of CO2 into the atmosphere and caused the loss of permafrost. In 2019 and 2020 there were also widespread fires in the Amazon rainforest, with dramatic environmental impacts.

The results of a recent study by World Weather Attribution cited in “United in Science 2020” showed with high confidence that the January to June 2020 heat is at least 600 times more likely as a result of human-induced climate change.

The warming trend documented in this report is likely to continue, and the world is not on track to meet targets set in the 2015 Paris Agreement on climate to keep the global temperature increase well below 2°C or at 1.5°C above pre-industrial levels.

“United in Science 2020” presents the latest scientific data and findings related to climate change to inform global policy and action. It highlights the increasing and irreversible impacts of climate change, which affects glaciers, oceans, nature, economies and human living conditions and is often felt through water-related hazards such as drought or flooding.

It also documents how COVID-19 has impeded our ability to monitor these changes through the global observing system.

“This has been an unprecedented year for people and planet. The COVID-19 pandemic has disrupted lives worldwide. At the same time, the heating of our planet and climate disruption has continued apace,” said UN Secretary-General António Guterres in a foreword to the report.

“Never before has it been so clear that we need long-term, inclusive, clean transitions to tackle the climate crisis and achieve sustainable development. We must turn the recovery from the pandemic into a real opportunity to build a better future,” said Guterres, who presented the report to the UN on Wednesday. “We need science, solidarity and solutions.”

KEY FINDINGS FROM “UNITED IN SCIENCE 2020”

Greenhouse Gas Concentrations in the Atmosphere (World Meteorological Organization)

Atmospheric CO2 concentrations showed no signs of peaking and have continued to increase to new records.

Benchmark stations in the WMO Global Atmosphere Watch network reported CO2 concentrations above 410 parts per million (ppm) during the first half of 2020, with observations from Mauna Loa, Hawaii and Cape Grim, Tasmania at 414.38 ppm and 410.04 ppm, respectively, in July 2020, up about three parts per million from July 2019.

Reductions in emissions of CO2 in 2020 will only slightly impact the rate of increase in the atmospheric concentrations, which are the result of past and current emissions, as well as the very long lifetime of CO2.

“Sustained reductions in emissions to net zero are necessary to stabilize climate change,” the WMO states in its report.

Global Fossil CO2 emissions (Global Carbon Project)

CO2 emissions in 2020 will fall by an estimated four percent to seven percent due to COVID-19 confinement policies. The exact percent of decline will depend on the trajectory of the pandemic and government responses to address it.

During peak lockdown in early April 2020, the daily global fossil CO2 emissions dropped by an unprecedented 17 percent compared to 2019.

But even so, emissions were still equivalent to 2006 levels, highlighting both the steep growth over the past 15 years and the continued dependence on fossil sources for energy.

By early June 2020, global daily fossil CO2 emissions had mostly returned to within five percent below 2019 levels, which reached a new record of 36.7 gigatonnes last year, 62 percent higher than at the start of climate change negotiations in 1990.

Global methane emissions from human activities, too, have continued to increase over the past decade. “Current emissions of both CO2 and methane are not compatible with emissions pathways consistent with the targets of the Paris Agreement,” the report warns.

Emissions Gap (UN Environment Programme)

“Transformational action can no longer be postponed if the Paris Agreement targets are to be met,” urges the UN Environment Programme.

The UNEP Emissions Gap Report 2019 showed that the cuts in global emissions required per year from 2020 to 2030 are close to three percent for a 2°C target and more than seven percent per year on average for the 1.5°C goal of the Paris Agreement.

The Emissions Gap in 2030 is estimated at 12-15 gigatonnes (Gt) of carbon dioxide equivalent (CO2e) to limit global warming to below 2°C. For the 1.5°C goal, the gap is estimated at 29-32 Gt CO2e, roughly equivalent to the combined emissions of the six largest-emitting countries.

“It is still possible to bridge the emissions gap, but this will require urgent and concerted action by all countries and across all sectors,” UNEP said.

“A substantial part of the short-term potential can be realized through scaling up existing, well-proven policies, for instance on renewables and energy efficiency, low carbon transportation means and a phase-out of coal,” the UN agency said.

Technically and economically feasible solutions already exist, said UNEP. Looking beyond the 2030 timeframe, new technological solutions and gradual change in consumption patterns are needed at all levels.

State of Global Climate (WMO and UK’s Met Office)

The average global temperature for 2016–2020 is expected to be the warmest on record, about 1.1°C above 1850-1900, a reference period for temperature change since pre-industrial times and 0.24°C warmer than the global average temperature for 2011-2015.

In the five-year period 2020–2024, the chance of at least one year exceeding 1.5°C above pre-industrial levels is 24 percent, with a very small chance (three percent) of the five-year mean exceeding this level. “It is likely (~70 percent chance) that one or more months during the next five years will be at least 1.5 °C warmer than pre-industrial levels,” the two agencies said in the report.

In every year between 2016 and 2020, the Arctic sea ice extent has been below average.

The years 2016–2019 recorded a greater glacier mass loss than all other past five-year periods since 1950.

The rate of global mean sea-level rise increased between the five-year periods 2011–2015 and 2016–2020.

The Ocean and Cryosphere in a Changing Climate (Intergovernmental Panel on Climate Change)

Human-induced climate change is affecting life-sustaining systems, from the top of the mountains to the depths of the oceans, leading to accelerating sea-level rise, with cascading effects for ecosystems and human security.

This increasingly challenges adaptation and integrated risk management responses.

Ice sheets and glaciers worldwide have lost mass. Between 1979 and 2018, Arctic sea-ice extent has decreased for all months of the year. Increasing wildfire and abrupt permafrost thaw, as well as changes in Arctic and mountain hydrology, have altered the frequency and intensity of ecosystem disturbances.

The global ocean has warmed unabated since 1970 and has taken up more than 90 percent of the excess heat in the climate system. Since 1993 the rate of ocean warming, and thus heat uptake has more than doubled.

Marine heatwaves have doubled in frequency and have become longer-lasting, more intense and more extensive, resulting in large-scale coral bleaching events. The ocean has absorbed between 20 percent to 30 percent of total anthropogenic CO2 emissions since the 1980s causing further ocean acidification.

Since about 1950 many marine species have undergone shifts in geographical range and seasonal activities in response to ocean warming, sea-ice change and oxygen loss.

The global mean sea-level is rising, with acceleration in recent decades due to increasing rates of ice loss from the Greenland and Antarctic ice sheets, as well as continued glacier mass loss and ocean thermal expansion. The rate of global mean sea-level rise for 2006–2015 of 3.6 ±0.5 mm/yr is unprecedented over the last century

Climate and Water Resources (WMO)

Climate change impacts are most felt through changing hydrological conditions including changes in snow and ice dynamics.

By 2050, the number of people at risk of floods will increase from its current level of 1.2 billion to 1.6 billion. In the early to mid-2010s, 1.9 billion people, or 27 percent of the global population, lived in potentially water-scarce areas. In 2050, this number will increase to 2.7 to 3.2 billion people.

As of 2019, 12 percent of the world population drinks water from unimproved and unsafe sources. More than 30 percent of the world population, or 2.4 billion people, live without any form of sanitation.

Climate change is projected to increase the number of water-stressed regions and exacerbate shortages in already water-stressed regions.

The cryosphere is an important source of freshwater in mountains and their downstream regions. There is high confidence that annual runoff from glaciers will reach peak globally at the latest by the end of the 21st century. After that, glacier runoff is projected to decline globally with implications for water storage.

It is estimated that Central Europe and Caucasus have reached peak water now and that the Tibetan Plateau region will reach peak water between 2030 and 2050. As runoff from snow cover, permafrost and glaciers in this region provides up to 45 percent of the total river flow, the flow decrease would affect water availability for 1.7 billion people.

Earth System Observations during COVID-19 (Intergovernmental Oceanographic Commission of UNESCO and WMO)

The COVID-19 pandemic has produced significant impacts on the global observing systems, which in turn have affected the quality of forecasts and other weather, climate and ocean-related services.

The reduction of aircraft-based observations by an average of 75 percent to 80 percent in March and April degraded the forecast skills of weather models. Since June, there has been only a slight recovery. Observations at manually operated weather stations, especially in Africa and South America, have also been badly disrupted.

For hydrological observations like river discharge, the situation is similar to that of atmospheric in situ measurements. Automated systems continue to deliver data whereas gauging stations that depend on manual reading are affected.

In March 2020, nearly all oceanographic research vessels were recalled to home ports. Commercial ships have been unable to contribute vital ocean and weather observations, and ocean buoys and other systems could not be maintained. Four full-depth ocean surveys of variables such as carbon, temperature, salinity, and water alkalinity, completed only once per decade, have been canceled. Surface carbon measurements from ships, which tell us about the evolution of greenhouse gases, also effectively ceased.

The impacts on climate change monitoring are long-term. They are likely to prevent or restrict measurement campaigns for the mass balance of glaciers or the thickness of permafrost, usually conducted at the end of the thawing period. The overall disruption of observations will introduce gaps in the historical time series of Essential Climate Variables needed to monitor climate variability and change and associated impacts.

※ 全文及圖片詳見：ENS

溫室氣體
冰川崩塌
熱浪
極端高溫
山林野火
極圈
疫情看氣候與能源
深度低碳專題
國際新聞
氣候變遷

作者

姜唯

如果有一件事是重要的，如果能為孩子實現一個願望，那就是人類與大自然和諧共存。

林大利

於特有生物研究保育中心服務，小鳥和棲地是主要的研究對象。是龜毛的讀者，認為龜毛是探索世界的美德。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準

0L/2。5L最大馬力（pS）：150/186最大扭矩（Nm）：200/233變速箱：6MT/CVT百公里加速（s）：11。7/10。5百公里油耗（L）：7。1/7。7車主百公里油耗（L）：8。81/9。58驅動方式：前置前驅/前置四驅底盤懸挂：前麥弗遜+橫向穩定桿/后複合多連桿+橫向穩定桿實際體驗（體驗者178cm）：前排頭部1拳/後排頭部1拳/後排腿部2拳3指。

日產奇駿是一款的十分低調，但卻比較重要的車型。它沒有像全新換代的本田CR-V那樣以大量科技來收穫大眾目光，但是奇駿卻憑藉良好品質獲得了很高的銷量，在2017年它在合資緊湊型SUV銷量榜上排行第三！

奇駿車內乘空間很充足，而且還推出了7座車型，第三排座椅用來應急還不錯。而且它的座椅擁有着沙發般的柔軟承托，車身隔音水平不錯，駕駛過程中底盤濾振也頗為徹底，舒適性是相當突出的！

此外，奇駿還搭載一套性能突出的適時四驅系統，越野性能在城市SUV中是突出的。它採用多片離合器式限滑差速器進行前後輪扭矩配比，能夠達到前後各50%的動力配比，實用性不錯！

長寬高：4675*1830*1724mm

軸距：2706mm

定位：緊湊型SUV

在造型方面，奇駿使用了日產V-motion式前臉設計，鍍鉻裝飾件粗壯、中網格柵也比老款更大了，前臉的衝擊感挺強的。而車側和尾部造型依然厚重、飽滿，但是細節的亮點不太多。

內飾方面它採用了中央對稱式設計，並且提供了拼色的設計樣式，視覺上能給人不錯的舒適感。中控台採用了軟性材質包裹，車門的軟包也做得到位。方向盤採用了平底設計，設計更偏向年輕化，整體氛圍較好！

發動機：2.0L/2.5L

最大馬力（pS）：150/186

最大扭矩（Nm）：200/233

變速箱：6MT/CVT

百公里加速（s）：11.7/10.5

百公里油耗（L）：7.1/7.7

車主百公里油耗（L）：8.81/9.58

驅動方式：前置前驅/前置四驅

底盤懸挂：前麥弗遜+橫向穩定桿/后複合多連桿+橫向穩定桿

實際體驗（體驗者178cm）：前排頭部1拳/後排頭部1拳/後排腿部2拳3指。而第三排座椅腿部空間比較一般，適合緊急情況下使用。

感興趣的朋友可以點擊小程序查看詳細口碑，從口碑中可以看到車主們對奇駿的硬朗外形、通過性較好、後排乘坐空間大等優點頗為滿意，但是對腳剎駐車和內飾用料方面有些意見。

咱們發現奇駿幅度還是比較可觀的，在廣州需搭配店內上保險、貸款、上牌、置換等項目，而在北京、武漢、上海、成都等地則為現金優惠，性價比不低！

奇駿這款車型乘坐舒適性和行駛品質都有着不錯的表現！動力系統也省心耐用，是一款稱職的家用車，而且四驅系統也具備不錯的性能，優惠幅度也還不錯，所以銷量方面一直保持強勢。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

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

發動機：1。5T/2。0T最大馬力（pS）：181/245最大扭矩（Nm）：240/350變速箱：6AT百公里加速（s）：9。92/7。1百公里油耗（L）：7。2/8。2車主百公里油耗（L）：9。61/11。9驅動方式：前置前驅/前置四驅底盤懸挂：前麥弗遜/后多連桿前排腿部空間（mm）：870-1085前排高度（mm）：990前排寬度（mm）：1470後排腿部空間（mm）：610-850後排高度（mm）：955後排寬度（mm）：1485實際體驗（體驗者178cm）：前排頭部1拳/後排頭部4指/後排腿部2拳

如果你手持20萬的購車預算，想買一款緊湊型SUV的的話，有非常多的選擇。而如果你對於操控性和動力有較大需求的話，福特的翼虎是一個不錯的選擇！

首先，翼虎懸架的調校帶有的韌性，它對於路面細碎振動的過濾徹底，提供了不錯的舒適性，同時在過彎時支撐性比較充足，尾部隨動性也不錯，駕駛起來頗為靈活！

它搭載的1.5T、2.0T兩台發動機具備強勁功率，與它們匹配的6AT變速箱降擋頗為积極，而且它帶有換擋撥片，可玩性挺高它還帶有S擋，能提升動力響應的靈敏程度。它2.0T四驅車型的破百時間僅為7.1秒，而1.5T兩驅車型百公里加速則在9.92秒內。

長寬高：4524*1838*1701mm

軸距：2690mm

定位：緊湊型SUV

外觀方面，現款的翼虎車身線條設計很凌厲，中網上粗壯的橫向條裝飾富有力量感。而且尾燈加入了黑色描邊細節，時尚感不低。而尾部的下方則採用了讓雙邊共兩出的排氣，運動感頗為出眾！

而內飾方面則為比較保守的設計風格，中控台運用軟質搪塑工藝，手感不錯。細節處加入了鋼琴漆黑色亮面裝飾條點綴，質感表現還不錯。

發動機：1.5T/2.0T

最大馬力（pS）：181/245

最大扭矩（Nm）：240/350

變速箱：6AT

百公里加速（s）：9.92/7.1

百公里油耗（L）：7.2/8.2

車主百公里油耗（L）：9.61/11.9

驅動方式：前置前驅/前置四驅

底盤懸挂：前麥弗遜/后多連桿

前排腿部空間（mm）：870-1085

前排高度（mm）：990

前排寬度（mm）：1470

後排腿部空間（mm）：610-850

後排高度（mm）：955

後排寬度（mm）：1485

實際體驗（體驗者178cm）：前排頭部1拳/後排頭部4指/後排腿部2拳2指。

感興趣的朋友可以點擊小程序查看詳細口碑，從口碑中可以看到車主們對翼虎的乘坐空間、操控性、2.0T發動機的強勁動力頗為滿意，但是對較高的油耗有些不滿。

咱們發現翼虎的優惠幅度中規中矩，在廣州地需搭配店內置換、貸款、上保險、上牌等項目，在北京、武漢地區的一些4S店還需加點裝飾。在成都地區則以現金優惠。

福特翼虎的電動助力轉向手感比較輕盈，精準度較高。懸架的調校帶有一定的韌性，它更多地側重於對震動的過濾，同時在過彎時支撐性比較充足，底盤質感較高！而且2.0T車型的動力表現強勁，當然油耗也較高！本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準