標籤: 台中電動車

2020-11-27

【設計模式】如何用組合替代繼承

Post By admin 網路資訊 , , , , , ,

如果問面向對象的三大特性是什麼，多數人都能回答出來：封裝、繼承、多態。

繼承 作為三大特性之一，近來卻越來越不推薦使用，更有極端的語言，直接語法中就不支持繼承，例如 Go。這又是為什麼呢？

為什麼不推薦使用繼承？

假設我們要設計一個關於鳥的類。

我們將“鳥類”定義為一個抽象類 AbstractBird。所有更細分的鳥，比如麻雀、鴿子、烏鴉等，都繼承這個抽象類。

大部分鳥都會飛，那我們可不可以在 AbstractBird 抽象類中，定義一個 Fly() 方法呢？

答案是否定的。儘管大部分鳥都會飛，但也有特例，比如鴕鳥就不會飛。鴕鳥繼承具有 Fly() 方法的父類，那鴕鳥就具有“飛”這樣的行為，這顯然不符合我們對現實世界中事物的認識。

解決方案一

在鴕鳥這個子類中重寫 Fly() 方法，讓它拋出異常。

public class AbstractBird
{
    public virtual void Fly()
    {
        Console.WriteLine("I'm flying.");
    }
}

//鴕鳥
public class Ostrich : AbstractBird
{
    public override void Fly()
    {
        throw new NotImplementedException("I can't fly.");
    }
}

這種設計思路雖然可以解決問題，但不夠優美。因為除了鴕鳥之外，不會飛的鳥還有很多，比如企鵝。對於這些不會飛的鳥來說，我們都需要重寫 Fly() 方法，拋出異常。

這違背了迪米特法則（也叫最少知識原則），暴露不該暴露的接口給外部，增加了類使用過程中被誤用的概率。

解決方案二

通過 AbstractBird 類派生出兩個更加細分的抽象類：會飛的鳥類 AbstractFlyableBird 和不會飛的鳥類 AbstractUnFlyableBird，讓麻雀、烏鴉這些會飛的鳥都繼承 AbstractFlyableBird，讓鴕鳥、企鵝這些不會飛的鳥，都繼承 AbstractUnFlyableBird 類。

此時，繼承關係變成了三層，還行得通。

如果要再添加一個游泳 Swim() 的方法，那情況就複雜了，要分為四中情況：

  • 會飛會游泳
  • 會飛不會游泳
  • 不會飛會游泳
  • 不會飛不會游泳

如果再有其他行為加入，抽象類的數量就會幾何級數增長。

我們要搞清楚某個類具有哪些方法、屬性，必須閱讀父類的代碼、父類的父類的代碼……一直追溯到最頂層父類的代碼。

使用組合

針對“會飛”這樣一個行為特性，我們可以定義一個 Flyable 接口，只讓會飛的鳥去實現這個接口。針對會游泳，定義一個 Swimable 接口，會叫定義一個 Tweetable 接口。

public interface Flyable
{
    void Fly();
}

public interface Swimable
{
    void Swim();
}

public interface Tweetable
{
    void Tweet();
}

//麻雀
public class Sparrow : Flyable, Tweetable
{
    public void Fly() => Console.WriteLine("I am flying.");

    public void Tweet() => Console.WriteLine("!@#$%^&*……");
}

//企鵝
public class Penguin : Swimable, Tweetable
{
    public void Swim() => Console.WriteLine("I am swimming.");

    public void Tweet() => Console.WriteLine("!@#$%^&*……");
}

麻雀和企鵝都會叫，Tweet 實現了兩遍，這是壞味道。我們可以用組合來消除這個壞味道。

public interface Flyable
{
    void Fly();
}

public interface Swimable
{
    void Swim();
}

public interface Tweetable
{
    void Tweet();
}

public class FlyAbility : Flyable
{
    public void Fly() => Console.WriteLine("I am flying.");
}

public class SwimAbility : Swimable
{
    public void Swim() => Console.WriteLine("I am swimming.");
}

public class TweetAbility : Tweetable
{
    public void Tweet() => Console.WriteLine("!@#$%^&*……");
}

//麻雀
public class Sparrow : Flyable, Tweetable
{
    FlyAbility flyAbility = new FlyAbility();
    TweetAbility tweetAbility = new TweetAbility();

    public void Fly() => flyAbility.Fly();

    public void Tweet() => tweetAbility.Tweet();
}

//企鵝
public class Penguin : Swimable, Tweetable
{
    SwimAbility swimAbility = new SwimAbility();
    TweetAbility tweetAbility = new TweetAbility();

    public void Swim() => swimAbility.Swim();

    public void Tweet() => tweetAbility.Tweet();
}

雖然現在主流的思想都是多用組合少用繼承，但是從上面的例子可以看出，繼承改寫成組合意味着要做更細粒度的類的拆分，要定義更多的類和接口。類和接口的增多也就或多或少地增加代碼的複雜程度和維護成本。所以，在實際的項目開發中，我們還是要根據具體的情況，來具體選擇該用繼承還是組合。

本文出自極客時間 王爭 老師的課程《設計模式之美》。原文示例為 java，因為我是做 C# 的，所以本文示例代碼我改成了 C# 。

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-26

分析ThreadLocal的弱引用與內存泄漏問題-Java8,利用線性探測法解決hash衝突

Post By admin 網路資訊 , , , , , ,

目錄

一.介紹

二.問題提出

　　2.1內存原理圖

　　2.2幾個問題

三.回答問題

　　3.1為什麼會出現內存泄漏

　　3.2若Entry使用弱引用

　　3.3弱引用配合自動回收

四.總結　　

 

 

 

一.介紹

　　之前使用ThreadLocal的時候，就聽過ThreadLocal怎麼怎麼的可能會出現內存泄漏，具體原因也沒去深究，就是一種不清不楚的狀態。最近在看JDK的源碼，其中就包含ThreadLocal，在對ThreadLocal的使用場景介紹以及源碼的分析后，對於ThreadLocal中可能存在的內存泄漏問題也搞清楚了，所以這裏專門寫一篇博客分析一下。

　　在分析內存泄漏之前，先了解2個概念，就是內存泄漏和內存溢出：

　　內存溢出（memory overflow）：是指不能申請到足夠的內存進行使用，就會發生內存溢出，比如出現的OOM（Out Of Memory）

　　內存泄漏（memory lack）：內存泄露是指在程序中已經動態分配的堆內存由於某種原因未釋放或者無法釋放（已經沒有用處了，但是沒有釋放），造成系統內存的浪費，這種現象叫“內存泄露”。

　　當內存泄露到達一定規模后，造成系統能申請的內存較少，甚至無法申請內存，最終導致內存溢出，所以內存泄露是導致內存溢出的一個原因。

 

二.問題提出

2.1內存原理圖

　　下圖是程序運行中的內存分布圖，簡要介紹一下這種圖：當前線程有一個threadLocals屬性（ThreadLocalMap屬性），該map的底層是數組，每個數組元素時Entry類型，Entry類型的key是ThreadLocal類型（也就是創建的ThreadLocal對象），而value是則是ThreadLocal.set()方法設置的value。

　　

　　需要注意的是ThreadLocalMap的Entry，繼承自弱引用，定義如下，關於Java的引用介紹，可以參考：Java-強引用、軟引用、弱引用、虛引用

/**
 * ThreadLocalMap中存放的元素類型，繼承了弱引用類
 */
static class Entry extends WeakReference<ThreadLocal<?>> {
    // key對應的value，注意key是ThreadLocal類型
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

 

2.2問題提出

　　在看了上面ThreadLocal和ThreadLocalMap相關的內存分佈以及關聯后，提出這樣幾個問題：

　　1.ThreadLocal為什麼會出現內存溢出？

　　2.Entry的key為什麼要用弱引用？

　　3.使用弱引用是否就能解決內存溢出？

　　為了回答上面這3個問題，我寫了一段代碼，後面根據這段代碼進行分析：

public void step1() {
    // some action
    
    step2();
    step3();
    
    // other action
}

// 在stepX中都會創建threadLocal對象
public void step2() {
    ThreadLocal<String> tl = new ThreadLocal<>();
    tl.set("this is value");
}
public void step3() {
    ThreadLocal<Integer> tl = new ThreadLocal<>();
    tl.set(99);
}

　　在step1中會調用step2和step3，step2和step3都會創建ThreadLocal對象，當step2和step3執行完畢后，其中的棧內存中ThreadLocal引用就會被清除。

 

三.回答問題

 

　　

　　現在針對這個圖，一步一步的分析問題，中途會得出一些臨時的結論，但是最終的結論才是正確的。

 

3.1為什麼會出現內存泄露

　　現在有2點假設，本小節的分析都是基於這兩個假設之上的：

　　1.Entry的key使用強引用，key對ThreadLocal對象使用強引用，也就是上面圖中連線5是強引用（key強引用ThreadLocal對象）；

　　2.ThreadLocalMap中不會對過期的Entry進行清理。

　　上面代碼中，如果ThreadLocalMap的key使用強引用，那麼即使棧內存的ThreadLocal引用被清除，但是堆中的ThreadLocal對象卻並不會被清除，這是因為ThreadLocalMap中Entry的key對ThreadLocal對象是強引用。

　　如果當前線程不結束，那麼堆中的ThreadLocal對象將會一直存在，對應的內存就不會被回收，與之關聯的Entry也不會被回收（Entry對應的value也不會被回收），當這種情況出現數量比較多的時候，未釋放的內存就會上升，就可能出現內存泄漏的問題。

　　上面的結論是暫時的，有前提假設！！！最終結論還需要看後面分析。

 

3.2若Entry使用弱引用

　　

　　仍舊有1個假設，就是ThreadLocalMap中不會對過期的Entry進行清理，陳舊的Entry是指Entry的key為null。

　　按照源碼，Entry繼承弱引用，其Key對ThreadLocal是弱引用，也就是上圖中連線5是弱引用，連線6仍為強引用。

　　同樣以上面代碼為例，step2和step3創建了ThreadLocal對象，step2和step3執行完后，棧中的ThreadLocal引用被清除了；由於堆內存中ThreadLocalMap的Entry key弱引用ThreadLocal對象，根據垃圾收集器對弱引用對象的處理：

當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象。

　　此時堆中ThreadLocal對象會被gc回收（因為現在沒有對ThreadLocal的強引用，只有一個弱引用ThreadLocal對象），Entry的key為null，但是value不為null，且value也是強引用（連線6），所以Entry仍舊不能回收，只能釋放ThreadLocal的內存，仍舊可能導致內存泄漏。

　　在沒有自動清理陳舊Entry的前提下，即使Entry使用弱引用，仍可能出現內存泄漏。

 

3.3弱引用配合自動回收

　　通過3.2的分析，其實只要陳舊的Entry能自動被回收，就能解決內存泄漏的問題，其實JDK就是這麼做的。

　　如果看過源碼，就知道，ThreadLocalMap底層使用數組來保存元素，使用“線性探測法”來解決hash衝突，關於線性探測法的介紹可以查看：利用線性探測法解決hash衝突

　　在每次調用ThreadLocal類的get、set、remove這些方法的時候，內部其實都是對ThreadLocalMap進行操作，對應ThreadLocalMap的get、set、remove操作。

　　重點來了！重點來了！重點來了！

　　ThreadLocalMap的每次get、set、remove，都會清理過期的Entry，下面以get操作解釋，其他操作也是一個意思，大致如下：

　　1.ThreadLocalMap底層用數組保存元素，當get一個Entry時，根據key的hash值（非hashCode）計算出該Entry應該出在什麼位置；

　　2.計算出的位置可能會有衝突，比如預期位置是position=5，但是position=5的位置已經有其他Entry了；

　　3.出現衝突后，會使用線性探測法，找position=6位置上的Entry是否匹配（匹配是指hash相同），如果匹配，則返回position=6的Entry。

　　4.在這個過程中，如果position=5位置上的Entry已經是陳舊的Entry（Entry的key為null），此時position=5的key就應該被清理；

　　5.光清理position=5的Entry還不夠，為了保證線性探測法的規則，需要判斷數組中的其他元素是否需要調整位置（如果需要，則調整位置），在這個過程中，也會進行清理陳舊Entry的操作。

　　上面這5個步驟就保證了每次get都會清理數組中（map）的陳舊Entry，清理一個陳舊的Entry，就是下面這三行代碼：

Entry.value = null; // 將Entry的value設為null
table[index] = null;// 將數組中該Entry的位置設置null
size--;	// map的size減一

　　對於ThreadLocal的set、remove也類似這個原理。

　　有了自動回收陳舊Entry的操作，需要注意的是，在這個時候，key使用弱引用就是至關重要的一點！！！

　　因為key使用弱引用后，當弱引用的ThreadLocal對象被會回收后，該key的引用為null，則該Entry在下一次get、set、remove的時候就才會被清理，從未避免內存泄漏的問題。

　　

四.總結

　　在上面的分析中，看到ThreadLocal基本不會出現內存泄漏的問題了，因為ThreadLocalMap中會在get、set、remove的時候清理陳舊的Entry，與Entry的key使用弱引用密不可分。

　　當然我們也可以在代碼中手動調用ThreadLocal的remove方法進行清除map中key為該threadLocal對象的Entry，同時清理過期的Entry。

　　

 

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-25

又要到處浪又要省油，有這種好事？這5款車就行

Post By admin 網路資訊 , , , , , ,

以不到30萬的價格買到一輛混動的大7座SUV，還要什麼入門BBA。再來看看同樣換新顏、尺寸大一號的全新秦pro，新車搭載一套由BYD476ZQA型1。5T發動機、電動機和鋰電池組構成的插電式混動系統后，工信部申報綜合油耗僅為1升/百公里。

前幾天正巧試駕了朋友剛提不久的雷克薩斯CT200h，除了非常不錯的操控感和車身動態表現之外，讓我印象最深刻的就是油耗，在一頓猛踩和駕駛模式來回切換之後，平均油耗也不過7L/百公里，我相信還有其他車主做出了更漂亮的數據。

雖然當初一早就布局混動車型市場的CT200h並沒有因此而大賣，但發展到今天，隨着混動技術的不斷成熟和國內市場政策的風雲變幻，已經有越來越多的消費者被混動車型的諸多優勢所打動，比如省油、安靜、駕駛體驗等等。所以今天就給大家盤點一下，北京車展之後都有哪些混動車型是值得消費者密切關注的。

1、卡羅拉/雷凌pHEV插電混動版

卡羅拉和雷凌可以說是豐田的兩個“開掛”車型，從燃油版到HEV油電混動版（雙擎）從來都不愁賣，而此次北京車展上豐田終於兌現了兩年前的承諾，在國內正式發布了卡羅拉/雷凌pHEV插電混動版車型。

這兩款新車可以說是含着金鑰匙出生的“富二代”，畢竟豐田多年以來經營的品牌形象、技術實力和市場口碑為這二者打下了堅實的銷量基礎，所以目測上市后月銷1萬輛是基本操作，想要入手的朋友們可要盯緊了。

在外形上兩款新車與普通版的差別並不大，僅針對細節進行了微調，比如車頭和車尾部分都加入了藍色元素。此外，由於插電混動版搭載了更大容量的電池組，所以內部空間與普通版車型稍有差異。

值得一提的是，這兩款車屬於中國特供車，意味着自帶銷量BUG，並且其搭載了1.8L自然吸氣發動機+電動機組，同時還配備容量為9-13kWh的鋰離子電池組，純電動條件下的續航里程可超過100km。

這是神馬概念？起碼就目前我國市場上銷售的插電混動車型，大部分純電動續航里程都只在50-80km以內，並且考慮到緊湊級車推出pHEV版本的多是自主品牌車型，而它們的老對手軒逸、朗逸等還沒加入這個市場，所以此次亮相的卡羅拉和雷凌pHEV版本只要定價合適，銷量應該不成問題，別忘了它們還可獲得一部分政策補貼哦（雙擎版本沒有）。

2、領克01 pHEV插電混動版

說領克01 pHEV版之前必先提一提燃油版領克01，這款車型自去年11月上市以來便憑藉優秀的做工和沃爾沃技術的加持迅速圈粉，獲得市場的好評如潮。本以為領克會按部就班、穩紮穩打地推出新能源產品，不過眼看WEY氣勢洶洶地推出了p8之後，領克怕也是坐不太住了，於是便適時地推出了領克01 pHEV版。

在外觀和內飾方面，該車和之前的燃油版車型基本相同，只是在前進氣格柵以及前翼子板處增加了藍色元素進行點綴，表明其新能源型的身份。而尾部右下側還貼有“01 pHEV”的字樣。

動力方面，領克01 pHEV則搭載了1.5T發動機和電動機所組成的插電式混合動力系統，發動機最大凈功率約180馬力，動力電池為鎳鈷錳三元鋰離子電池，官方宣稱該車的百公里油耗僅為1.8L，同時其純電動模式下最大行駛里程為51km。如果想要入手朋友，其量產車型最快會在今年年內上市，所以準備好鈔票就是了。

3、比亞迪唐DM/秦pro

我們都知道，自從前奧迪設計師艾格入主比亞迪之後，旗下打頭陣車型瞬間秒變高富帥，就連之前被人嫌棄的“BYD”都多了一個洋氣的註釋–Build Your Dream！如果你還沒什麼畫面感的話，在此貢獻兩張圖讓大家感受一下：

了解更多點擊視頻：

全新一代唐从里裡外外都整了個遍，多了幾分國際范。首先在外觀上採用了家族最新的Dragon Face設計語言，整體大氣而又十分吸睛；

內飾同樣話題性十足，其中最搶眼的部分當屬中控可90°旋轉的超級大屏，同時全液晶儀錶和藍色氛圍燈增加了車內的科技感。

動力方面，其將搭載2.0T發動機與電動機組成的插電式混動系統，系統綜合最大功率超過500馬力，而高配車型百公里加速僅需4.5秒，咳咳划重點了–奔馳GLC43 AMG的成績為4.9秒。

值得一提的是，新一代唐標配7座布局，其長寬高分別為4870/1940/1720mm，軸距為2820mm，相比上一代車型在軸距和寬度上有所增加，所以能帶來更寬敞的乘坐體驗。另外在此次北京車展，新一代唐公布預售價–補貼后25萬起步。港真！以不到30萬的價格買到一輛混動的大7座SUV，還要什麼入門BBA！

再來看看同樣換新顏、尺寸大一號的全新秦pro，新車搭載一套由BYD476ZQA型1.5T發動機、電動機和鋰電池組構成的插電式混動系統后，工信部申報綜合油耗僅為1升/百公里！並且根據車尾標判斷，新車的官方百公里加速時間或為5.9秒，看來是充分體現了什麼叫“雨露均沾”了。

4、廣汽謳歌CDX混動版

每每提到謳歌這個品牌，總有兩道跨不過的坎，一個是跟長安LOGO抹不去的姻緣，另一個就是跟隔壁家的雷克薩斯比境遇，很顯然以上兩項都是招黑的。不過也必須承認，痛定思痛的謳歌如今似乎也有點重新步入正軌的意思了。

在此次北京車展，廣汽謳歌就帶來了CDX的混動版本，並且從售價上看還是蠻有誠意的。新車共推出了三款車型，售價區間為29.98-35.28萬元，同時新車外觀顏色增加磨砂皓灰和混動版專屬的藍紫色車漆，內飾則增加了紅色內飾可選，而頂配版車型還將增配Acura Watch。

畢竟謳歌也是“本田大法”的受益者，所以混動版車型相比同級別對手的較大優勢就體現在動力系統上。新車將搭載本田的i-MMD混合動力系統，其由一台2.0L的阿特金森循環自然吸氣發動機、由驅動電機和發電機組成的“電動CVT”直驅傳動機構、動力控制單元及鋰電池組等組成。

這套系統可以根據負載和使用條件的不同，在純電動、混合動力和發動機直驅三種模式之間無縫切換。參數方面，2.0L發動機最大功率146馬力，混動系統綜合最大功率215馬力，而官方公布的綜合油耗為5.0L/百公里。所以三十萬買一台省油的豪華SUV，好像很不錯的樣子！

5、雷克薩斯ES混動版

此次北京車展雷克薩斯的展台只放了兩台車，沒錯！只有兩台！在大多數人看來這就是典型的“寒酸”，而在雷粉眼裡這就叫“傲嬌”，因為雷克薩斯選擇把ES混動版的全球首發放在了中國，雖說一直不願意國產，雖說看展的觀眾不一定get到這樣做的用心良苦，但足以說明其對中國市場的看重。

雷克薩斯全新一代ES基於TNGA平台打造，除搭載全新2.0L發動機外，還配有2.5L多級混合動力系統，也就是全新凱美瑞上用的那一套，沒錯，就是傳說中41%熱效率的那一款名機。同時它還搭載了結構更緊湊的全新一代E-CVT电子無極變速系統，以及布局更為合理的鎳氫電池組。另外，最高純電巡航時速由前一代的75km/h提升到120km/h。

如想了解更多，點擊下方視頻：

結語

從當初雷克薩斯CT200h的“天生異質”，到如今各家廠商混合動力車型的日漸成熟，可以說能活下來的、能在市場上銷售的技術都是好技術。不管是自主品牌的比亞迪、長城、吉利，還是合資品牌的兩田，甚至是進口品牌，都在加緊布局新能源戰線，所以這對我們消費者來說無疑是個大利好。至於混動車型值不值得買這樣俗套的話題，我想就不用多糾結了，畢竟買車從來都是按需購買的。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-24

隨機抽樣一致性（RANSAC）算法詳解

Post By admin 網路資訊 , , , , , ,

隨機抽樣一致性（RANSAC）算法能夠有效的剔除特徵匹配中的錯誤匹配點。

實際上，RANSAC能夠有效擬合存在噪聲模型下的擬合函數。實際上，RANSAC算法的核心在於將點劃分為“內點”和“外點”。在一組包含“外點”的數據集中，採用不斷迭代的方法，尋找最優參數模型，不符合最優模型的點，被定義為“外點”。這就是RANSAC的核心思想。

RANSAC原理

OpenCV中濾除誤匹配對採用RANSAC算法尋找一個最佳單應性矩陣H，矩陣大小為3×3。RANSAC目的是找到最優的參數矩陣使得滿足該矩陣的數據點個數最多，通常令h33=1來歸一化矩陣。由於單應性矩陣有8個未知參數，至少需要8個線性方程求解，對應到點位置信息上，一組點對可以列出兩個方程，則至少包含4組匹配點對。

 

 

 RANSAC算法從匹配數據集中隨機抽出4個樣本並保證這4個樣本之間不共線，計算出單應性矩陣，然後利用這個模型測試所有數據，並計算滿足這個模型數據點的個數與投影誤差(即代價函數)，若此模型為最優模型，則對應的代價函數最小。

損失函數：

 

 

 也就是通過隨機抽樣求解得到一個矩陣，然後驗證其他的點是否符合模型，然後符合的點成為“內點”，不符合的點成為“外點”。下次依然從“新的內點集合”中抽取點構造新的矩陣，重新計算誤差。最後誤差最小，點數最多就是最終的模型。

RANSAC算法步驟：

RANSAC算法步驟： 

          1. 隨機從數據集中隨機抽出4個樣本數據 (此4個樣本之間不能共線)，計算出變換矩陣H，記為模型M；

          2. 計算數據集中所有數據與模型M的投影誤差，若誤差小於閾值，加入內點集 I ；

          3. 如果當前內點集 I 元素個數大於最優內點集 I_best , 則更新 I_best = I，同時更新迭代次數k ;

          4. 如果迭代次數大於k,則退出 ; 否則迭代次數加1，並重複上述步驟；

  注：迭代次數k在不大於最大迭代次數的情況下，是在不斷更新而不是固定的；

 

 

 其中，p為置信度，一般取0.995；w為”內點”的比例 ; m為計算模型所需要的最少樣本數=4；
關於RANSAC算法的思想，可以用下圖表示

 

 也就是RANSAC算法的本質是：在存在噪聲的數據中，我們求解一個模型，使得非噪聲數據可以用該模型表示，而噪聲數據被排除在外。

分享三個講解RANSAC算法的網址：

https://www.csdn.net/gather_2d/MtjaMg3sNDAwNS1ibG9n.html

https://www.cnblogs.com/xrwang/archive/2011/03/09/ransac-1.html

https://blog.csdn.net/yanghan742915081/article/details/83005442

 

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-23

微服務技術棧：常見註冊中心組件，對比分析

Post By admin 網路資訊 , , , , , ,

本文源碼：GitHub·點這裏 || GitEE·點這裏

一、註冊中心簡介

1、基礎概念

在分佈式架構的系統中註冊中心這個概念就已經被提出了，最經典的就是Zookeeper中間件。

微服務架構中，註冊中心是最核心的基礎服務之一，註冊中心可以看做是微服務架構中的通信中心，當一個服務去請求另一個服務時，通過註冊中心可以獲取該服務的狀態，地址等核心信息。

服務註冊主要關係到三大角色：服務提供者、服務消費者、註冊中心。

2、流程和原理

基礎流程

  • 服務啟動時，將自身的網絡地址等信息註冊到註冊中心，註冊中心記錄服務註冊數據。
  • 服務消費者從註冊中心獲取服務提供者的地址，並通過地址和基於特定的方式調用服務提供者的接口。
  • 各個服務與註冊中心使用一定機制通信。如果註冊中心與服務長時間無法通信，就會註銷該實例，這也稱為服務下線，當服務重新連接之後，會基於一定的策略在線上線。
  • 服務地址相關信息發生變化時，會重新註冊到註冊中心。這樣，服務消費者就無需手工維護提供者的相關配置。

核心功能

通過上面的基本流程，不難發現一個註冊中心需要具備哪些核心功能：

  • 服務發現

服務發現是指服務在啟動后，註冊到註冊中心，服務方提供自身的元數據，比如IP地址、端口、運行狀況指標的Uri 、主頁地址等信息。

  • 服務記錄

記錄註冊中心的服務的信息，例如服務名稱、IP地址、端口等。服務消費方基於查詢獲取可用的服務實例列表。

  • 動態管理服務

註冊中心基於特定的機制定時測試已註冊的服務，例如：默認的情況下會每隔30秒發送一次心跳來進行服務續約。通過服務續約來告知Server該Client仍然可用。正常情況下，如果Server在90 秒內沒有收到Client 的心跳，Server會將Client 實例從註冊列表中刪除。

二、基礎組件對比

1、Zookeeper組件

1.1基礎描述

ZooKeeper是非常經典的服務註冊中心中間件，在國內環境下，由於受到Dubbo框架的影響，大部分情況下認為Zookeeper是RPC服務框架下註冊中心最好選擇，隨着Dubbo框架的不斷開發優化，和各種註冊中心組件的誕生，即使是RPC框架，現在的註冊中心也逐步放棄了ZooKeeper。在常用的開發集群環境中，ZooKeeper依然起到十分重要的作用，Java體系中，大部分的集群環境都是依賴ZooKeeper管理服務的各個節點。

1.2組件特點

從Zookeeper的數據結構特點看，並不是基於服務註冊而設計的，ZooKeeper提供的命名空間與文件系統的名稱空間非常相似，在數據結構上高度抽象為K-V格式，十分通用，說到這裏不得不提一下Redis，也可以作為註冊中心使用，只是用的不多。

ZooKeeper組件支持節點短暫存在，只要創建znode的會話處於活動狀態，這些znode就會存在，會話結束時，將刪除znode。Dubbo框架正是基於這個特點，服務啟動往Zookeeper註冊的就是臨時節點，需要定時發心跳到Zookeeper來續約節點，並允許服務下線時，將Zookeeper上相應的節點刪除，同時Zookeeper使用ZAB協議雖然保證了數據的強一致性。

2、Eureka組件

2.1基礎描述

SpringCloud框架生態中最原生的深度結合組件，Eureka是Netflix開發的服務發現框架，基於REST的服務，主要用於服務註冊，管理，負載均衡和服務故障轉移。但是官方聲明在Eureka2.0版本停止維護，不建議使用。

2.2組件特點

Eureka包含兩個組件：EurekaServer和EurekaClient。

EurekaServer提供服務註冊服務，各個節點啟動后，會在EurekaServer中進行註冊，這樣EurekaServer中的服務註冊表中將會存儲所有可用服務節點的信息，服務節點的信息可以在界面中直觀的看到。Eureka允許在註冊服務的時候，自定義實現檢查自身狀態的是否健康的方法，這在服務實例能夠保持心跳上報的場景下，是一種比較好的體驗。

EurekaClient是一個java客戶端，用於簡化與EurekaServer的交互，客戶端同時也就是一個內置的、使用輪詢(round-robin)負載算法的負載均衡器。

3、Consul組件

3.1基礎描述

Consul是用於服務發現和配置的工具。Consul是分佈式的，高度可用的，並且具有極高的可伸縮性，而且開發使用都很簡便。它提供了一個功能齊全的控制面板，主要特點是：服務發現、健康檢查、鍵值存儲、安全服務通信、多數據中心、ServiceMesh。Consul在設計上把很多分佈式服務治理上要用到的功能都包含在內了。

3.2組件特點

Consul提供多個數據中心的支持，基於Fabio做負載均衡，每個數據中心內，都有客戶端和服務端的混合構成。預計有三到五台服務端。可以在失敗和性能的可用性之間取得良好的平衡。數據中心中的所有節點都參与八卦協議。這意味着有一個八卦池，其中包含給定數據中心的所有節點。這有幾個目的：首先，不需要為客戶端配置服務器的地址;發現是自動完成的。其次，檢測節點故障的工作不是放在服務器上，而是分佈式的。這使得故障檢測比天真的心跳方案更具可擴展性。第三，它被用作消息傳遞層，用於在諸如領導者選舉等重要事件發生時進行通知。

4、Nacos組件

4.1基礎描述

Nacos致力於發現、配置和管理微服務。Nacos提供了一組簡單易用的特性集，幫助您實現動態服務發現、服務配置管理、服務及流量管理。Nacos更敏捷和容易地構建、交付和管理微服務平台。 Nacos 是構建以“服務”為中心的現代應用架構(例如微服務範式、雲原生範式)的服務基礎設施。Nacos支持作為RPC註冊中心，例如：支持Dubbo框架；也具備微服務註冊中心的能力，例如：SpringCloud框架。

4.2組件特點

Nacos在經過多年生產經驗后提煉出的數據模型，則是一種服務-集群-實例的三層模型。如上文所說，這樣基本可以滿足服務在所有場景下的數據存儲和管理,數據模型雖然相對複雜，但是並不強制使用數據結構的風格，大多數應用場景下，和Eureka數據模型是類似的。

Nacos提供數據邏輯隔離模型，用戶賬號可以新建多個命名空間，每個命名空間對應一個客戶端實例，這個命名空間對應的註冊中心物理集群是可以根據規則進行路由的，這樣可以讓註冊中心內部的升級和遷移對用戶是無感知的。

三、組件選擇

如下註冊中心對比圖。

綜合上述幾種註冊中心對比，再從現在SpringCloud框架流行趨勢看，個人推薦後續微服務架構體系選擇Nacos組件，大致原因如下，社區活躍，經過大規模業務驗證，不但可以作為微服務註冊中心，也支持作RPC框架Dubbo的註冊中心，且有完善的中文文檔，總結下來就一句話：通用中間件，省時；文檔詳細，省心。

四、源代碼地址

GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud

推薦文章：微服務基礎系列

序號 文章標題
01 微服務基礎：Eureka組件，管理服務註冊發現
02 微服務基礎：Ribbon和Feign組件，實現請求負載均衡
03 微服務基礎：Hystrix組件，實現服務熔斷
04 微服務基礎：Turbine組件，實現微服務集群監控
05 微服務基礎：Zuul組件，實現路由網關控制
06 微服務基礎：Config組件，實現配置統一管理
07 微服務基礎：Zipkin組件，實現請求鏈路追蹤
08 微服務基礎：與Dubbo框架、Boot框架對比分析
09 微服務基礎：Nacos組件，服務和配置管理
10 微服務基礎：Sentinel組件，服務限流和降級
11 微服務應用：分庫分表模式下，數據庫擴容方案
12 微服務應用：Shard-Jdbc分庫分表，擴容方案實現

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-20

同級最便宜，這款20多萬的超帥氣SUV車主卻說……

Post By admin 網路資訊 , , , , , ,

0L混動最大馬力（pS）：182/發動機:146 電動機:184最大扭矩（Nm）：240/發動機:175 電動機:315變速箱：8DCT/E-CVT百公里加速（s）：8。35/8。6百公里油耗（L）：6。8/5車主百公里油耗（L）：8。71/暫

謳歌CDX肩負着在國內為謳歌品牌打開市場的重任，它具備極其前衛的設計風格，而且看到實車時你就會感受到其設計的精緻感！

寬敞的空間，前衛設計讓它具有不錯的競爭力。而且它搭載一款1.5T高功率發動機，匹配一副8擋雙離合變速箱，動力系統匹配是高效的，它換擋平順，降擋的速度也相當快，動力表現可圈可點！下面我們就來看看這款豪華SUV車型的各方面表現怎麼樣吧！

長寬高：4496*1840*1615mm

軸距：2660mm

定位：緊湊型SUV

設計激進的謳歌CDX可謂是同級車型中的一股清流，前臉造型極其激進，鑽石形中網造型顯得相當有個性。同時車身線條緊湊，但車內卻能營造出足夠的乘坐空間。

內飾方面它在細節處富有創意，造型類似“如意”的旋鈕擋把設計科技感強，而內飾的用料也是到位的。值得一提的是這套內飾的按鍵布局簡約、合理，方向盤上的按鍵也具備不錯手感，在行車過程中操作便利！

發動機：1.5T/2.0L混動

最大馬力（pS）：182/發動機:146 電動機:184

最大扭矩（Nm）：240/發動機:175 電動機:315

變速箱：8DCT/E-CVT

百公里加速（s）：8.35/8.6

百公里油耗（L）：6.8/5

車主百公里油耗（L）：8.71/暫本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

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

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

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

2020-11-19

UniRx精講（二）：獨立的 Update &UniRx 的基本語法格式

Post By admin 網路資訊 , , , , , ,

獨立的 Update

在 UniRx 簡介的時候，筆者講了一種比較麻煩的情況：就是在 MonoBehaviour 的 Update 中摻雜了大量互相無關的邏輯，導致代碼非常不容易閱讀。

這種情況我們平時在項目開發中非常常見，代碼如下:

private void Update()
{
	if (A)
	{
		...
	}

	if (B)
	{
		...
		if (D)
		{
			...
		}
		else {}
	}

	switch (C)
	{
		...
	}

	if (Input.GetMouseButtonUp(0))
	{
		...
	}
}

Update 方法中代碼冗長，而且干擾視線，非常影響閱讀。

而使用 UniRx 則可以改善這個問題。

void Start()
{
	// A 邏輯,實現了 xx
	Observable.EveryUpdate()
			.Subscribe(_ => 
			{
				if (A)
				{
					...
				}
			}).AddTo(this);
	

	// B 邏輯,實現了 xx
	Observable.EveryUpdate()
			.Subscribe(_ =>
			{
				if (B)
				{
					...
					if (D)
					{
						...
					}
				else {}
				}
			}).AddTo(this);

	// C 邏輯，實現了 xx
	Observable.EveryUpdate()
			.Subscribe(_ =>
			{
				switch (C)
				{
					...
				}
			}).AddTo(this);

	// 鼠標點擊檢測邏輯
	Observable.EveryUpdate()
			.Subscribe(_ => {
			{
				if (Input.GetMouseButtonUp(0))
				{
					...
				}
			}).AddTo(this);
}

雖然在代碼長度上沒有任何改善，但是最起碼，這些 Update 邏輯互相之間獨立了。
狀態跳轉、延時等等這些經常在 Update 里實現的邏輯，都可以使用以上這種方式獨立。

使用 UniRx 可以對我們工程中的代碼進行了改善，而筆者接觸 UniRx 之後，就再也沒有使用過 Update 方法了。

不過以上的這種 UniRx 使用方式，是比較初級的，而這種使用方式，隨着對 UniRx 的深入學習，也會漸漸淘汰，因為等我們入門之後，會學習更好的實現方式。

今天的內容就這些。

知識地圖

UniRx 的基本語法格式

在之前的兩篇文章中，我們學習了 UniRx 的 Timer 和 Update 這兩個 API，但是對代碼的工作原理還沒有進行過介紹。在這篇文章中，我們就來試着理解一下 UniRx 的代碼工作原理及 UniRx 的基本語法格式。

先搬出來第一篇文章中 Delay 的實現代碼:

/****************************************************************************
 * http://liangxiegame.com liangxie
 ****************************************************************************/
 
using System;
using UniRx;
using UnityEngine;

namespace UniRxLesson
{
	public class DelayExample : MonoBehaviour
	{
		private void Start()
		{
			Observable.Timer(TimeSpan.FromSeconds(2.0f)).Subscribe(_ =>
			{
				Debug.Log("延時兩秒"); 
				
			}).AddTo(this);
		}
	}
}

代碼中的 Observable.XXX().Subscribe() 是非常經典的 UniRx 格式。只要理解了這種格式就可以看懂大部分的 UniRx 的用法了。

首先解決代碼中的詞彙問題：

  • Observable：可觀察的，是形容詞，它形容後邊的詞（Timer）是可觀察的，我們可以直接把 Observable 後邊的詞理解成發布者。
  • Timer：定時器，名詞，被 Observable 修飾，所以是發布者，是事件的發送方。
  • Subscribe：訂閱，是動詞，它訂閱誰呢？當然是前邊的 Timer，這裏可以理解成訂閱者，也就是事件的接收方。
  • AddTo：添加到，這個我們暫時不用理解得太深刻，只需要知道它是與 MonoBehaviour 進行生命周期綁定即可。

以上的代碼，連起來則是：可被觀察（監聽）的.Timer().訂閱()
理順了之後應該是：訂閱可被觀察的定時器。

其概念關係很容易理解。

  • Timer 是可觀察的。
  • 可觀察的才能被訂閱。
Observable.XXX().Subscribe();

這行代碼我們可以理解為：可被觀察（監聽）的 XX，註冊。

以上筆者從發布者和訂閱者這個角度進行了簡單的介紹，以便大家理解。
但是 UniRx 的側重點，不是發布者和訂閱者這兩個概念如何使用，而是事件從發布者到訂閱者之間的過程如何處理。
所以這兩個點不重要，重要的是兩點之間的線，也就是事件的傳遞過程。

這裏先不說得太深入，在入門之後，會用很大的篇幅去深入介紹這些概念的。

今天的 UniRx 的基本語法格式的介紹就到這裏，我們下一篇再見，拜拜~

知識地圖

更多內容
QFramework 地址：https://github.com/liangxiegame/QFramework
QQ 交流群：623597263
涼鞋的主頁：https://liangxiegame.com/zhuanlan
關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-18

日本香川縣養雞場爆禽流感 將撲殺33萬隻雞

Post By admin 網路資訊 , , , , , ,

摘錄自2020年11月5日中央社報導

日本香川縣三豊市的一處養雞場從11月1日到4日突然有約3800隻雞死亡，經檢驗後驗出H5型禽流感病毒，該養雞場將撲殺約33萬隻雞。

香川縣政府今天上午召開對策本部會議，決定養雞場飼養的約33萬隻雞將進行撲殺。

日本的養雞場上次發生禽流感疫情，是2018年1月香川縣讚岐市的養雞場驗出H5型禽流感病毒。

日本首相菅義偉今天上午聽取報告後，指示相關單位要提醒家禽業者對此高度警戒，並輔導與支援業者預防、收集現場情報；農林水產省與相關部會緊密合作，迅速進行防疫措施，以及對國民盡速提供正確的防疫資訊。

國際新聞
日本
禽流感

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-17

最低5.48萬起，這些車代表了國產車最高水準？

Post By admin 網路資訊 , , , , , ,

相比較其它車企來說，寶駿就簡單粗暴多了，價格就是寶駿最大的優勢，因此寶駿也有價格屠夫的稱號，早期寶駿推出寶駿樂馳和寶駿630的時候其實價格優勢並不明顯，而從寶駿730和560開始，寶駿的高性價比稱號便越打越響，而310和510的上市也直接讓其坐穩了家轎市場的頭把交椅。

俗話說，沒有兩把刷子，怎麼能出來混社會；做人如此，造車也是這樣，對於各家車企來說，它們的產品雖然都各有優缺，但是那些賣的好混的不錯的車企卻往往有它們的看家本領。中國汽車品牌的繁榮發展雖然不過短短20年，但是卻也有不少的車企做得越來越大，在中國汽車市場上呼聲較高，除了自主車向來的高性價比之外，這些自主品牌都有什麼看家本領呢？

長安這些年來混得是順風順水，相當不錯；說起長安，可能很多人想到的是長安車型漂亮的外觀內飾，長安最新的睿騁CC和逸動就十分帥氣。

不過長安在自主車型中優勢最大的其實還是底盤，長安的車型底盤的厚實感和懸挂的濾震處理、側傾抑制都是相當出色的。長安的車型在底盤的質感上有一種歐系車的感覺，這是很多自主車型望塵莫及的。

代表車型：長安CS95

作為長安目前產品序列中最高級也是最碩大的車型，CS95代表了長安的產品高度，而實際上這款車的表現也是可圈可點，厚實的底盤不錯的隔音以及較高的性價比都是CS95的競爭力所在。

在自主車型中如果要問誰的發動機最好的話，那麼一定是榮威和MG的車型，目前榮威和MG產品序列中有兩款發動機堪稱強悍，那就是1.5T和2.0T的兩款渦輪增壓發動機，前者擁有169馬力/250牛米的動力，後者輸出更是高達220馬力/350牛米。

這樣的兩台發動機加持使得榮威MG的車型動力十分強悍，我們實測的1.5T名爵6百公里加速時間僅需7.09秒，可以說相當厲害了。除此之外搭載這兩台發動機的車型油耗也普遍比同規格的自主車型更低，實力可見一斑。

代表車型：名爵6

作為名爵榮威最有代表的車型，名爵6的動力十分強悍，1.5T的發動機加持下實測百公里加速僅需7.09秒，而且混合動力版本的名爵6加速還更加恐怖；除了強大的動力之外，名爵6在科技感上也相當出色，加上不錯的外觀，名爵6銷量也比較不錯了。

相比較其它車企來說，寶駿就簡單粗暴多了，價格就是寶駿最大的優勢，因此寶駿也有價格屠夫的稱號，早期寶駿推出寶駿樂馳和寶駿630的時候其實價格優勢並不明顯，而從寶駿730和560開始，寶駿的高性價比稱號便越打越響，而310和510的上市也直接讓其坐穩了家轎市場的頭把交椅。

寶駿的車型在保證品質的基礎上，價格卻總是比同規格的哈弗等車型便宜不少，因此也獲得了市場的熱捧，我們老闆就因為看中了寶駿的低價高質，買了台寶駿730給我們做公務用車呢~

代表車型：寶駿510

自從哈弗H6誕生以來，連續幾年的時間霸佔銷量榜首位，不過510發力之後完成了對哈弗H6的超越，憑藉超高的性價比以及靚麗的外觀，寶駿510為寶駿品牌的形象以及銷量立下了汗馬功勞，可以說510成就了如今的寶駿。

寶馬7系的遙控泊車可以說是一個創舉，但是第一個做遙控泊車的卻並非寶馬，而是咱們的比亞迪，並且比亞迪的遙控泊車不僅可以控制前後行駛，還能轉向，這就是比亞迪在科技配置上創新的體現，而諸如此類的电子配置很多，比如說全景影像、綠凈系統、可以自動切換內外循環的空調以及自帶記錄儀等功能都是比亞迪率先涉足的，在科技配置方面比亞迪說第二，傳統車企里估計沒人敢認第一。

代表車型：宋MAX

雖說宋MAX並非是比亞迪最高端的車型，但確實是比亞迪目前最受市場歡迎的車型了，除了那個漂亮的外觀和內飾之外，宋MAX的配置也是非常誇張，前後雷達、全景影像、電動尾門、前排座椅通風加熱、12.8英寸大屏、全LED大燈等配置出現在這麼一台十萬級的MpV也是十分誇張了。

從前有這麼一個段子，長城的老闆公布年度預算：“研發部門500萬，設計部門10億”，雖然是車友編出來的一個段子，但是也能看得出公眾對於長城車型的印象。而這一個設計花十億的印象也是直接來自於長城現有的車型。

在自主車型中長城的外觀內飾精緻度確實非常高，除了最近哈弗車系大面積推廣的电子手剎之外，在車輛的鈑金噴漆水平、內飾的用料做工甚至按鍵的手感質感上哈弗都在不遺餘力地做好，而這樣帶來的好處就是哈弗的車型與廉價感這一詞已經完全脫離關係了，無論是視覺感受還是觸感都十分出色，讓人愛不釋手。

代表車型：哈弗H7

目前哈弗產品中定位最高的並不是哈弗H7，但是在內飾外觀精緻度上認為哈弗H7是最出色的，尤其是擋桿後方的按鈕分佈，看起來用起來都有幾分奧迪的精緻感，加上車內不錯的做工用料，這個內飾的品質感絕對不輸30萬的合資車。

雖然長安車型的底盤質感不錯，但是長安為了迎合年輕人而做了很多運動化調校，因此多數長安車型的底盤濾振不算徹底，要說自主車型中哪個品牌的車濾振最能給人好感，虎哥覺得一定是東南。

東南車型雖然外觀足夠靚麗，但是並非是普通貨色，在濾振水平上東南可謂相當出色，比如說東南DX3和東南DX7的濾振就足夠徹底，路面上大大小小的振動都能被過濾得十分到位，即使是快速軋過井蓋也不會有單薄感和突兀感，感覺有一種貼地飛行的質感，濾振水平完全不遜色於別克。

代表車型：東南DX3

在試駕DX3就對DX3的濾震水平十分震驚，激烈駕駛時底盤的安穩感很好、經過大大小小的坑窪時車內感覺都相當淡定，懸挂的濾振表現值得表揚，底盤的厚實感也是比較到位了，超過同價位的多數自主車。

2010年前後，中國市場掀起了一股合資自主品牌的風潮，當時許多諸如理念、啟辰、朗世之類的合資自主品牌誕生，但是大潮褪去才知道誰在裸泳，如今完整活下來並且混得還不錯的也就剩下啟辰了。

而說起啟辰最厲害的地方，那就是啟辰的車型基本就是換殼的日產，比如說T70實際上就是海外的7座版老款逍客、D60就是軒逸、D50/R50也就是老款的日產騏達，因此在三大件和造車水準上啟辰也原封不動地繼承了日產的基因，但是在價格上啟辰比哈弗之類的自主車有過之而無不及，因此賣得好也不足為奇了。

代表車型：啟辰T70

啟辰T70實際上就是海外7座版逍客的底盤，加上日產那套成熟的2.0L+CVT動力總成，雖然動力不算強悍，但是勝在可靠性和燃油經濟性好，這也是選擇啟辰的一大重要原因，在性價比上T70也超過了大多數的自主車，比如說11.78萬的T70 2.0L CVT睿享版就有定速巡航、胎壓監測、一鍵啟動無鑰匙進入、主駕駛電動座椅等高端裝備。

有神似奧迪Q3的SR7、跟保時捷macan傻傻分不清的SR9、撞臉大眾概念SUV的大邁X7、有奧迪A6L內涵的眾泰Z700以及神似奧迪Q5的眾泰T600，花五分之一的錢買一輛豪車，誰能不心動？

代表車型：幾乎全系車型~本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案

2020-11-16

[源碼解析] GroupReduce，GroupCombine 和 Flink SQL group by

Post By admin 網路資訊 , , , , , ,

[源碼解析] GroupReduce，GroupCombine和Flink SQL group by

目錄

  • [源碼解析] GroupReduce，GroupCombine和Flink SQL group by
    • 0x00 摘要
    • 0x01 緣由
    • 0x02 概念
      • 2.1 GroupReduce
      • 2.2 GroupCombine
      • 2.3 例子
    • 0x03 代碼
    • 0x04 Flink SQL內部翻譯
    • 0x05 JobGraph
    • 0x06 Runtime
      • 6.1 ChainedFlatMapDriver
      • 6.2 GroupReduceCombineDriver
      • 6.3 GroupReduceDriver & ChainedFlatMapDriver
    • 0x07 總結
    • 0x08 參考

0x00 摘要

本文從源碼和實例入手，為大家解析 Flink 中 GroupReduce 和 GroupCombine 的用途。也涉及到了 Flink SQL group by 的內部實現。

0x01 緣由

在前文[源碼解析] Flink的Groupby和reduce究竟做了什麼中，我們剖析了Group和reduce都做了些什麼，也對combine有了一些了解。但是總感覺意猶未盡，因為在Flink還提出了若干新算子，比如GroupReduce和GroupCombine。這幾個算子不搞定，總覺得如鯁在喉，但沒有找到一個良好的例子來進行剖析說明。

本文是筆者在探究Flink SQL UDF問題的一個副產品。起初是為了調試一段sql代碼，結果發現Flink本身給出了一個GroupReduce和GroupCombine使用的完美例子。於是就拿出來和大家共享，一起分析看看究竟如何使用這兩個算子。

請注意：這個例子是Flink SQL，所以本文中將涉及Flink SQL goup by內部實現的知識。

0x02 概念

Flink官方對於這兩個算子的使用說明如下：

2.1 GroupReduce

GroupReduce算子應用在一個已經分組了的DataSet上，其會對每個分組都調用到用戶定義的group-reduce函數。它與Reduce的區別在於用戶定義的函數會立即獲得整個組。

Flink將在組的所有元素上使用Iterable調用用戶自定義函數，並且可以返回任意數量的結果元素。

2.2 GroupCombine

GroupCombine轉換是可組合GroupReduceFunction中組合步驟的通用形式。它在某種意義上被概括為允許將輸入類型 I 組合到任意輸出類型O。與此相對的是，GroupReduce中的組合步驟僅允許從輸入類型 I 到輸出類型 I 的組合。這是因為GroupReduceFunction的 “reduce步驟” 期望自己的輸入類型為 I。

在一些應用中，我們期望在執行附加變換（例如，減小數據大小）之前將DataSet組合成中間格式。這可以通過CombineGroup轉換能以非常低的成本實現。

注意：分組數據集上的GroupCombine在內存中使用貪婪策略執行，該策略可能不會一次處理所有數據，而是以多個步驟處理。它也可以在各個分區上執行，而無需像GroupReduce轉換那樣進行數據交換。這可能會導致輸出的是部分結果，所以GroupCombine是不能替代GroupReduce操作的，儘管它們的操作內容可能看起來都一樣。

2.3 例子

是不是有點暈？還是直接讓代碼來說話吧。以下官方示例演示了如何將CombineGroup和GroupReduce轉換用於WordCount實現。即通過combine操作先對單詞數目進行初步排序，然後通過reduceGroup對combine產生的結果進行最終排序。因為combine進行了初步排序，所以在算子之間傳輸的數據量就少多了。

DataSet<String> input = [..] // The words received as input

// 這裏通過combine操作先對單詞數目進行初步排序，其優勢在於用戶定義的combine函數只調用一次，因為runtime已經把輸入數據一次性都提供給了自定義函數。  
DataSet<Tuple2<String, Integer>> combinedWords = input
  .groupBy(0) // group identical words
  .combineGroup(new GroupCombineFunction<String, Tuple2<String, Integer>() {

    public void combine(Iterable<String> words, Collector<Tuple2<String, Integer>>) { // combine
        String key = null;
        int count = 0;

        for (String word : words) {
            key = word;
            count++;
        }
        // emit tuple with word and count
        out.collect(new Tuple2(key, count));
    }
});

// 這裏對combine的結果進行第二次排序，其優勢在於用戶定義的reduce函數只調用一次，因為runtime已經把輸入數據一次性都提供給了自定義函數。  
DataSet<Tuple2<String, Integer>> output = combinedWords
  .groupBy(0)                              // group by words again
  .reduceGroup(new GroupReduceFunction() { // group reduce with full data exchange

    public void reduce(Iterable<Tuple2<String, Integer>>, Collector<Tuple2<String, Integer>>) {
        String key = null;
        int count = 0;

        for (Tuple2<String, Integer> word : words) {
            key = word;
            count++;
        }
        // emit tuple with word and count
        out.collect(new Tuple2(key, count));
    }
});

看到這裏，有的兄弟已經明白了，這和mapPartition很類似啊，都是runtime做了大量工作。為了讓大家這兩個算子的使用情形有深刻的認識，我們再通過一個sql的例子，向大家展示Flink內部是怎麼應用這兩個算子的，也能看出來他們的強大之處。

0x03 代碼

下面代碼主要參考自 flink 使用問題匯總。我們可以看到這裏通過groupby進行了聚合操作。其中collect方法，類似於mysql的group_concat。

public class UdfExample {
    public static class MapToString extends ScalarFunction {

        public String eval(Map<String, Integer> map) {
            if(map==null || map.size()==0) {
                return "";
            }
            StringBuffer sb=new StringBuffer();
            for(Map.Entry<String, Integer> entity : map.entrySet()) {
                sb.append(entity.getKey()+",");
            }
            String result=sb.toString();
            return result.substring(0, result.length()-1);
        }
    }

    public static void main(String[] args) throws Exception {
        MemSourceBatchOp src = new MemSourceBatchOp(new Object[][]{
                new Object[]{"1", "a", 1L},
                new Object[]{"2", "b33", 2L},
                new Object[]{"2", "CCC", 2L},
                new Object[]{"2", "xyz", 2L},
                new Object[]{"1", "u", 1L}
        }, new String[]{"f0", "f1", "f2"});

        BatchTableEnvironment environment = MLEnvironmentFactory.getDefault().getBatchTableEnvironment();
        Table table = environment.fromDataSet(src.getDataSet());
        environment.registerTable("myTable", table);
        BatchOperator.registerFunction("MapToString",  new MapToString());
        BatchOperator.sqlQuery("select f0, mapToString(collect(f1)) as type from myTable group by f0").print();
    }
}

程序輸出是

f0|type
--|----
1|a,u
2|CCC,b33,xyz

0x04 Flink SQL內部翻譯

這個SQL語句的重點是group by。這個是程序猿經常使用的操作。但是大家有沒有想過這個group by在真實運行起來時候是怎麼操作的呢？針對大數據環境有沒有做了什麼優化呢？其實，Flink正是使用了GroupReduce和GroupCombine來實現並且優化了group by的功能。優化之處在於：

  • GroupReduce和GroupCombine的函數調用次數要遠低於正常的reduce算子，如果reduce操作中涉及到頻繁創建額外的對象或者外部資源操作，則會相當省時間。
  • 因為combine進行了初步排序，所以在算子之間傳輸的數據量就少多了。

SQL生成Flink的過程十分錯綜複雜，所以我們只能找最關鍵處。其是在 DataSetAggregate.translateToPlan 完成的。我們可以看到，對於SQL語句 “select f0, mapToString(collect(f1)) as type from myTable group by f0”，Flink系統把它翻譯成如下階段，即

  • pre-aggregation ：排序 + combine；
  • final aggregation ：排序 + reduce；

從之前的文章我們可以知道，groupBy這個其實不是一個算子，它只是排序過程中的一個輔助步驟而已，所以我們重點還是要看combineGroup和reduceGroup。這恰恰是我們想要的完美例子。

input ----> (groupBy + combineGroup) ----> (groupBy + reduceGroup) ----> output

SQL生成的Scala代碼如下，其中 combineGroup在後續中將生成GroupCombineOperator，reduceGroup將生成GroupReduceOperator。

  override def translateToPlan(
      tableEnv: BatchTableEnvImpl,
      queryConfig: BatchQueryConfig): DataSet[Row] = {

    if (grouping.length > 0) {
      // grouped aggregation
      ...... 
      if (preAgg.isDefined) { // 我們的例子是在這裏
        inputDS          
          // pre-aggregation
          .groupBy(grouping: _*)
          .combineGroup(preAgg.get) // 將生成GroupCombineOperator算子
          .returns(preAggType.get)
          .name(aggOpName)
          // final aggregation
          .groupBy(grouping.indices: _*) //將生成GroupReduceOperator算子。
          .reduceGroup(finalAgg.right.get)
          .returns(rowTypeInfo)
          .name(aggOpName)
      } else {
        ......
      }
    }
    else {
      ......
    }
  }
}

// 程序變量打印如下
this = {DataSetAggregate@5207} "Aggregate(groupBy: (f0), select: (f0, COLLECT(f1) AS $f1))"
 cluster = {RelOptCluster@5220}

0x05 JobGraph

LocalExecutor.execute中會生成JobGraph。JobGraph是提交給 JobManager 的數據結構，是唯一被Flink的數據流引擎所識別的表述作業的數據結構，也正是這一共同的抽象體現了流處理和批處理在運行時的統一。

在生成JobGraph時候，系統得到如下JobVertex。

jobGraph = {JobGraph@5652} "JobGraph(jobId: 6aae8b5e5ad32f588136bef26f8b65f6)"
 taskVertices = {LinkedHashMap@5655}  size = 4

{JobVertexID@5677} "c625209bb7fb9a098807551840aeaa99" -> {InputOutputFormatVertex@5678} "CHAIN DataSource (at initializeDataSource(MemSourceBatchOp.java:98) (org.apache.flink.api.java.io.CollectionInputFormat)) -> FlatMap (select: (f0, f1)) (org.apache.flink.runtime.operators.DataSourceTask)"

{JobVertexID@5679} "b56ace4acd7a2f69ea110a9f262ff80a" -> {JobVertex@5680} "CHAIN GroupReduce (groupBy: (f0), select: (f0, COLLECT(f1) AS $f1)) -> FlatMap (select: (f0, mapToString($f1) AS type)) -> Map (Map at linkFrom(MapBatchOp.java:35)) (org.apache.flink.runtime.operators.BatchTask)"
 
{JobVertexID@5681} "3f5e2a0f700421d80ce85e02a6d9db73" -> {InputOutputFormatVertex@5682} "DataSink (collect()) (org.apache.flink.runtime.operators.DataSinkTask)"
 
{JobVertexID@5683} "ad29dc5b2e0a39ad2cd1d164b6f859f7" -> {JobVertex@5684} "GroupCombine (groupBy: (f0), select: (f0, COLLECT(f1) AS $f1)) (org.apache.flink.runtime.operators.BatchTask)"

我們可以看到，在JobGraph中就生成了對應的兩個算子。其中這裏的FlatMap就是用戶的UDF函數MapToString的映射生成。

GroupCombine (groupBy: (f0), select: (f0, COLLECT(f1) AS $f1))  
  
CHAIN GroupReduce (groupBy: (f0), select: (f0, COLLECT(f1) AS $f1)) -> FlatMap (select: (f0, mapToString($f1) AS type)) -> Map

0x06 Runtime

最後，讓我們看看runtime會如何處理這兩個算子。

6.1 ChainedFlatMapDriver

首先，Flink會在ChainedFlatMapDriver.collect中對record進行處理，這是從Table中提取數據所必須經歷的，與後續的group by關係不大。

@Override
public void collect(IT record) {
   try {
      this.numRecordsIn.inc();
      this.mapper.flatMap(record, this.outputCollector);
   } catch (Exception ex) {
      throw new ExceptionInChainedStubException(this.taskName, ex);
   }
}

// 這裡能夠看出來，我們獲取了第一列記錄
record = {Row@9317} "1,a,1"
 fields = {Object[3]@9330} 
this.taskName = "FlatMap (select: (f0, f1))"

// 程序堆棧打印如下
collect:80, ChainedFlatMapDriver (org.apache.flink.runtime.operators.chaining)
collect:35, CountingCollector (org.apache.flink.runtime.operators.util.metrics)
invoke:196, DataSourceTask (org.apache.flink.runtime.operators)
doRun:707, Task (org.apache.flink.runtime.taskmanager)
run:532, Task (org.apache.flink.runtime.taskmanager)
run:748, Thread (java.lang)

6.2 GroupReduceCombineDriver

其次，GroupReduceCombineDriver.run()中會進行combine操作。

  1. 會通過this.sorter.write(value)把數據寫到排序緩衝區。
  2. 會通過sortAndCombineAndRetryWrite(value)進行實際的排序，合併。

因為是系統實現，所以Combine的用戶自定義函數就是由Table API提供的，比如org.apache.flink.table.functions.aggfunctions.CollectAccumulator.accumulate 。

@Override
public void run() throws Exception {
   final MutableObjectIterator<IN> in = this.taskContext.getInput(0);
   final TypeSerializer<IN> serializer = this.serializer;

   if (objectReuseEnabled) {
    .....
   }
   else {
      IN value;
      while (running && (value = in.next()) != null) {
         // try writing to the sorter first
         if (this.sorter.write(value)) {
            continue;
         }

         // do the actual sorting, combining, and data writing
         sortAndCombineAndRetryWrite(value);
      }
   }

   // sort, combine, and send the final batch
   if (running) {
      sortAndCombine();
   }
}

// 程序變量如下
value = {Row@9494} "1,a"
 fields = {Object[2]@9503}

sortAndCombine是具體排序/合併的過程。

  1. 排序是通過 org.apache.flink.runtime.operators.sort.QuickSort 完成的。
  2. 合併是通過 org.apache.flink.table.functions.aggfunctions.CollectAccumulator.accumulate 完成的。
  3. 給下游是由 org.apache.flink.table.runtime.aggregate.DataSetPreAggFunction.combine 調用 out.collect(output) 完成的。
private void sortAndCombine() throws Exception {
   final InMemorySorter<IN> sorter = this.sorter;
   // 這裏進行實際的排序
   this.sortAlgo.sort(sorter);
   final GroupCombineFunction<IN, OUT> combiner = this.combiner;
   final Collector<OUT> output = this.output;

   // iterate over key groups
   if (objectReuseEnabled) {
			......		
   } else {
      final NonReusingKeyGroupedIterator<IN> keyIter = 
            new NonReusingKeyGroupedIterator<IN>(sorter.getIterator(), this.groupingComparator);
      // 這裡是歸併操作
      while (this.running && keyIter.nextKey()) {
         // combiner.combiner 是用戶定義操作，runtime把某key對應的數據一次性傳給它
         combiner.combine(keyIter.getValues(), output);
      }
   }
}

具體調用棧如下：

accumulate:57, CollectAggFunction (org.apache.flink.table.functions.aggfunctions)
accumulate:-1, DataSetAggregatePrepareMapHelper$5
combine:71, DataSetPreAggFunction (org.apache.flink.table.runtime.aggregate)
sortAndCombine:213, GroupReduceCombineDriver (org.apache.flink.runtime.operators)
run:188, GroupReduceCombineDriver (org.apache.flink.runtime.operators)
run:504, BatchTask (org.apache.flink.runtime.operators)
invoke:369, BatchTask (org.apache.flink.runtime.operators)
doRun:707, Task (org.apache.flink.runtime.taskmanager)
run:532, Task (org.apache.flink.runtime.taskmanager)
run:748, Thread (java.lang)

6.3 GroupReduceDriver & ChainedFlatMapDriver

這兩個放在一起，是因為他們組成了Operator Chain。

GroupReduceDriver.run中完成了reduce。具體reduce 操作是在 org.apache.flink.table.runtime.aggregate.DataSetFinalAggFunction.reduce 完成的，然後在其中直接發送給下游 out.collect(output)。

@Override
public void run() throws Exception {
   // cache references on the stack
   final GroupReduceFunction<IT, OT> stub = this.taskContext.getStub();
 
   if (objectReuseEnabled) {
       ......	
   }
   else {
      final NonReusingKeyGroupedIterator<IT> iter = new NonReusingKeyGroupedIterator<IT>(this.input, this.comparator);
      // run stub implementation
      while (this.running && iter.nextKey()) {
         // stub.reduce 是用戶定義操作，runtime把某key對應的數據一次性傳給它
         stub.reduce(iter.getValues(), output);
      }
   }
}

從前文我們可以，這裏已經配置成了Operator Chain，所以out.collect(output)會調用到CountingCollector。CountingCollector的成員變量collector已經配置成了ChainedFlatMapDriver。

public void collect(OUT record) {
   this.numRecordsOut.inc();
   this.collector.collect(record);
}

this.collector = {ChainedFlatMapDriver@9643} 
 mapper = {FlatMapRunner@9610} 
 config = {TaskConfig@9655} 
 taskName = "FlatMap (select: (f0, mapToString($f1) AS type))"

於是程序就調用到了 ChainedFlatMapDriver.collect。

public void collect(IT record) {
   try {
      this.numRecordsIn.inc();
      this.mapper.flatMap(record, this.outputCollector);
   } catch (Exception ex) {
      throw new ExceptionInChainedStubException(this.taskName, ex);
   }
}

最終調用棧如如下：

eval:21, UdfExample$MapToString (com.alibaba.alink)
flatMap:-1, DataSetCalcRule$14
flatMap:52, FlatMapRunner (org.apache.flink.table.runtime)
flatMap:31, FlatMapRunner (org.apache.flink.table.runtime)
collect:80, ChainedFlatMapDriver (org.apache.flink.runtime.operators.chaining)
collect:35, CountingCollector (org.apache.flink.runtime.operators.util.metrics)
reduce:80, DataSetFinalAggFunction (org.apache.flink.table.runtime.aggregate)
run:131, GroupReduceDriver (org.apache.flink.runtime.operators)
run:504, BatchTask (org.apache.flink.runtime.operators)
invoke:369, BatchTask (org.apache.flink.runtime.operators)
doRun:707, Task (org.apache.flink.runtime.taskmanager)
run:532, Task (org.apache.flink.runtime.taskmanager)
run:748, Thread (java.lang)

0x07 總結

由此我們可以看到：

  • GroupReduce，GroupCombine和mapPartition十分類似，都是從系統層面對算子進行優化，把循環操作放到用戶自定義函數來處理。
  • 對於group by這個SQL語句，Flink將其翻譯成 GroupReduce + GroupCombine，採用兩階段優化的方式來完成了對大數據下的處理。

0x08 參考

flink 使用問題匯總

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

【其他文章推薦】

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

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

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

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

※超省錢租車方案