接上回書

書接，分享了Class文件的主要構成，同時也詳細分析了魔數、次版本號、主版本號、常量池集合、訪問標誌的構造，接下來我們就繼續學習。

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

類索引和父類索引

類索引（this_class）和父類索引（super_class）都是一個u2類型的數據，類索引用於確定這個類的全限定名，父類索引用於確定這個類的父類全限定名。由於java語言不允許多重繼承，所以父類索引只有一個。

類索引和父類索引各自指向常量池中類型為CONSTANT_Class_info的類描述符，再通過類描述符中的索引值找到常量池中類型為CONSTANT_Utf8_info的字符串。再來看一下之前的Class文件例子：

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

結合之前javap分析出來的常量池內容：

   #3 = Class         #17        // OneMoreStudy
   #4 = Class         #18        // java/lang/Object
  #17 = Utf8          OneMoreStudy
  #18 = Utf8          java/lang/Object

類索引為0x0003，去常量池裡找索引為3的類描述符，類描述符中的索引為17，再去找索引為17的字符串，就是“OneMoreStudy”。

父類索引為0x0004，去常量池裡找索引為4的類描述符，類描述符中的索引為18，再去常量池裡找索引為18的字符串，就是“java/lang/Object”。

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

接口索引集合

接口索引集合（interface）是一組u2類型的數據的集合，由於java語言允許實現多個接口，所以接口索引也有多個，它們按照implements語句后的接口順序從左到右依次排列在接口索引集合中。接口索引集合的第一項數據是接口集合計數值（interfaces_count），表示有多少接口索引。如果該類沒有實現任何接口，那麼該計數值為0，後面的接口索引表不佔任何字節。之前的例子OneMoreStudy類沒有實現任何接口，所以接口集合計數值就是0，如下圖：

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

字段表集合

字段表（field_info）是用來描述接口或類中聲明的變量。包括類級變量（靜態變量）和實例級變量（成員變量），但是不包括在方法內部聲明的局部變量。具體結構如下錶：

類型	名稱	數量	描述
u2	access_flags	1	字段的訪問標誌
u2	name_index	1	字段的簡單名稱索引
u2	descriptor_index	1	字段的描述符索引
u2	attributes_count	1	字段的屬性計數值
attribute_info	attributes	attributes_count	字段的屬性

字段表中的access_flags，和類的access_flags是非常類似的，但是標識和含義是不一樣的。具體如下錶：

標誌名稱	標誌值	含義
ACC_PUBLIC	0x0001	字段是否public
ACC_PRIVATE	0x0002	字段是否private
ACC_PROTECTED	0x0004	字段是否protected
ACC_STATIC	0x0008	字段是否static
ACC_FINAL	0x0010	字段是否為final
ACC_VOLATILE	0x0040	字段是否volatile
ACC_TRANSIENT	0x0080	字段是否transient
ACC_SYNTHETIC	0x1000	字段是否由編譯器自動產生的
ACC_ENUM	0x4000	字段是否enum

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

這裏提到了簡單名稱、描述符，和全限定名有什麼區別呢？稍微說一下。

簡單名稱是沒有類型和參數修飾的方法或字段名稱，比如OneMoreStudy類中的number字段和plusOne()方法的簡單名稱分別是“number”和“plusOne”。

全限定名是把類全名中的“.”替換成“/”就可以了，比如java.lang.Object類的全限定名就是“java/lang/Object”。

描述符是用來描述字段的數據類型、方法的參數列表（包括數量、類型以及順序）和返回值。基礎數據類型和無返回的void類型都有一個大寫字母表示，對象類型用字符L加對象的全限定名來表示，如下錶：

標識字符	含義
B	基本類型byte
C	基本類型char
D	基本類型double
F	基本類型float
I	基本類型int
J	基本類型long
S	基本類型short
Z	基本類型boolean
V	特殊類型void
L	對象類型 如 Ljava/lang/Object

對於數組類型，每一維度使用一個前置的“[”字符來描述，比如java.lang.Object[][]的二維數據，就是“[[Ljava/lang/Object”。在描述方法時，按照先參數列表，后返回值的順序描述，參數列表按照嚴格順序放在“()”值中，比如boolean equals(Object anObject)，就是“(Ljava/lang/Object)B”。

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

再來看一下之前的Class文件例子：

OneMoreStudy類中只有一個字段number，所以字段計數值為0x0001。字段number只被private修飾，沒有其他修飾，所以字段的訪問標誌位為0x0002。字段的簡單名稱索引是0x0005，去常量池中找索引為5的字符串，為“number”。字段的描述符索引為0x0006，去常量池中找索引為6的字符串，為“I”，是基本類型int。以下是常量池相關內容：

   #5 = Utf8          number
   #6 = Utf8          I

字段number的屬性計數值為0x0000，也就是沒有需要額外描述的信息。

字段表集合中不會列出從父類或者父接口中繼承而來的字段，但有可能列出原版Java代碼中沒有的字段，比如在內部類中為了保持對外部類的訪問性，會自動添加指向外部類實例的字段。

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

方法表集合

方法表的結構和字段表的是一樣的，也是依次包括了訪問標誌（access_flags）、名稱索引（name_index）、描述符索引（descriptor_index）和屬性表集合（attributes）。具體如下錶：

類型	名稱	數量	描述
u2	access_flags	1	方法的訪問標誌
u2	name_index	1	方法的簡單名稱索引
u2	descriptor_index	1	方法的描述符索引
u2	attributes_count	1	方法的屬性計數值
attribute_info	attributes	attributes_count	方法的屬性

對於方法的訪問標誌，所有標誌位和取值如下錶：

標誌名稱	標誌值	含義
ACC_PUBLIC	0x0001	方法是否public
ACC_PRIVATE	0x0002	方法是否private
ACC_PROTECTED	0x0004	方法是否protected
ACC_STATIC	0x0008	方法是否static
ACC_FINAL	0x0010	方法是否為final
ACC_SYNCHRONIZED	0x0020	方法是否sychronized
ACC_BRIDGE	0x0040	方法是否是由編譯器產生的橋接方法
ACC_VARARGS	0x0080	方法是否接受不定參數
ACC_NATIVE	0x0100	方法是否為native
ACC_ABSTRACT	0x0400	方法是否為abstract
ACC_STRICT	0x0800	方法是否為strictfp
ACC_SYNTHETIC	0x1000	方法是否由編譯器自動產生

方法中的Java代碼，經過編譯器編程成字節碼指令后，放在方法屬性表集合中一個名為“Code”的屬性里，後面會有更多分享。

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

再來看一下之前的Class文件例子：

方法計算值為0x0003，表示集合中有兩個方法（編譯器自動添加的無參構造方法和源碼中的plusOne方法）。第一個方法的訪問標誌是0x0001，表示只有ACC_PUBLIC標誌為true。

名稱索引為0x0007，在常量池中為索引為7的字符串為“ ”，這就是編譯器自動添加的無參構造方法。描述符索引為0x0008，在常量池中為索引為7的字符串為“()V”，方法的屬性計數值為0x0001，表示該方法有1個屬性，屬性名稱索引為0x0009，在常量池中為索引為7的字符串為“Code”。以下是常量池相關內容：

   #7 = Utf8          <init>
   #8 = Utf8          ()V
   #9 = Utf8          Code

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

屬性表集合

屬性表（attribute_info）在前面的分享中出現了幾次，在Class文件、字段表、方法表都可以有自己的屬性表集合，用來描述某些場景下特有的信息。

屬性表不在要求具有嚴格的順序，並且只要不與已有的屬性名重複，任何人實現的編譯器都可以寫入自己定義的屬性信息，Java虛擬機在運行時會忽略掉它不認識的屬性。

我總結了一些比較常見的屬性，如下錶：

屬性名稱	使用位置	含義
Code	方法表	Java代碼編譯成的字節碼指令
ConstantValue	字段表	final關鍵字定義的常量值
Exceptions	方法表	方法拋出的異常
InnerClasses	類文件	內部類列表
LineNumberTable	Code屬性	Java源碼的行號與字節碼指定的對應關係
LocalVariableTable	Code屬性	方法的局部變量描述
SourceFile	類文件	記錄源文件名稱

對於每個屬性，它的名稱都從常量池中引用一個CONSTANT_Utf8_info類型的常量，而屬性值的結構則是完全自定義的，只需要用一個u4類型來說明屬性值所佔的位數就可以了。具體結構如下：

類型	名稱	數量	含義
u2	attribute_name_index	1	屬性名稱索引
u2	attribute_length	1	屬性值所佔的位數
u1	info	attribute_length	屬性值

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

總結

Class文件主要由魔數、次版本號、主版本號、常量池集合、訪問標誌、類索引、父類索引、接口索引集合、字段表集合、方法表集合和屬性表集合組成。隨着JDK版本的不斷升級，Class文件結構也在不斷更新，學習之路,永不止步。

歡迎關注微信公眾號：萬貓學社，每周一分享Java技術乾貨。

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

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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

介紹了高效科技組織的特點及管理經驗，指出科技團隊的定位和使命在於支持業務、賦能業務、最終引領業務，同時，還介紹了面向未來的科技組織的特點及對管理者提出的能力要求。

內容來源 | LeaTech全球CTO領導力峰會宜信公司CTO 高級副總裁向江旭分享《大型科技團隊的管理》

主講人 | 宜信公司CTO 高級副總裁向江旭

實錄整理 | 宜信技術學院成芳

引言：11月16日，由51CTO旗下CTO訓練營品牌精心打造的LeaTech全球CTO領導力峰會在北京粵財JW萬豪酒店拉開序幕。作為CTO、技術VP、技術總監等技術管理者人群的高端社交圈，本屆峰會現場聚集了CTO訓練營歷屆校友、CTO導師，以及行業中的資深技術管理者。600多位與會嘉賓在現場充分交流了有關技術性視野、技術領導力、技術團隊組織建設等精彩話題的觀點與思考，藉助峰會這個線下平台，技術管理者們积極探索了更多商業可能，開拓管理視野，令自身領導力再上新台階。

本次峰會邀請到宜信公司CTO 高級副總裁向江旭先生，帶來主題為《大型科技團隊的管理》的分享，向江旭先生在分享中提到科技團隊的定位和使命在於支持業務、賦能業務、最終引領業務，同時，他還介紹了面向未來的科技組織的特點及對管理者提出的能力要求。

以下為本次演講的分享實錄。

各位朋友下午好，今天我分享的主題是《大型科技團隊的管理》，非常高興能跟大家分享一些關於大型科技團隊管理的經驗和觀察。

去年12月，我在另一個峰會的分享中提到經濟寒冬、金融寒冬，今年這個時候也開始進入冬季，但是不管外面的大環境如何，技術人/技術圈都非常幸運，在科技賦能的市場中，技術人總是被需要的，技術圈也總是熱情高漲的。我認為，關於技術團隊的管理經驗非常值得與大家一起分享和交流。

一、大型科技團隊的特點及定位

大型科技團隊一般都有以下幾個特點：

• 一定規模。顧名思義，談到大型科技團隊首先想到的特點肯定是團隊成員眾多。
• 地域分佈廣。科技團隊的成員可能分佈在不同的地方。
• 團隊背景多元。這種多元包括兩個層面的含義：一是角色背景多元，有的成員甚至不是做技術（這裏特指軟件研發）的，而是從其他行業轉過來的，比如行業數據分析師等角色。二是團隊成員的種族、國家背景多元。

一定規模、團隊背景多元化、分佈在不同地域等特點，使得大型科技團隊在管理上面臨着非常大的挑戰。

1.1 大型科技公司的科技團隊組織架構

上圖是一些大家耳熟能詳的漫畫，介紹了幾種典型的科技公司的科技團隊架構形式。

• “Google式團隊架構”：最上面是兩個創始人和一個CEO，下面是部門負責人，其特點是下一級有多個彙報對象，這是谷歌的內部架構和管理方式，從一個層面代表了某個歷史階段科技組織的團隊構造。
• “Amazon式團隊架構”：典型的層級式管理，逐級彙報。
• “Oracle式團隊架構”：特點是有一個專門的法務團隊，因為Oracle收購了很多公司，某種程度上它是一個法務或銷售導向的公司。
• “Facebook式團隊架構”：Facebook的團隊結構和它的業務一樣，是社交網絡形式的網狀結構。
• “Apple式團隊架構”：（這是一張比較早期的圖）其特點是最核心的靈魂人物的觸角深入到公司的方方面面，事無巨細都是他在親自主導。
• “Microsoft式團隊結構”：最後這張也是之前的圖，代表的是我服務過的公司-微軟。三大版塊部門沒有交集，很深的部門牆，互相之間存在比較激烈的內部鬥爭。

由此可見，大型科技公司的文化基因決定了其科技團隊的組織架構形式，而科技組織架構的設計和管理很大程度上決定了組織的效能。

1.2 科技團隊的使命和定位

在討論科技團隊的管理之前，有一個很重要的前提，要知道科技團隊的使命和定位是什麼。

很多非科技驅動的公司，比如銀行、保險公司、地產公司等，都在計劃或嘗試轉型成為一家科技公司。我認為在這樣的背景下，科技從業人員反而應該更清楚自己的定位。

1）支持業務

首先我們是支持業務的，要把業務放在最核心的位置，如果公司是靠產品和服務生存的，業務沒做好，科技也不一定能做好。當然公司類型不一樣，不能一概而論。比如純科技公司微軟，產品和服務本身就是技術，技術的好壞決定了公司業務的好壞。

2）賦能業務

科技團隊通過開發一些工具，幫助業務、銷售等部門實現業務流程信息化、智能化，使得業務流轉的過程更為暢通和友好。甚至更進一步，開發一個好的技術平台，使得生態圈、合作夥伴、第三方公司能夠在平台上發展業務、共建生態，這時科技團隊就起到了賦能業務的作用。

3）引領業務

科技團隊還可以通過技術創新、產品創新來拓展新的業務領域，催生新的業務模式，增加新的收入來源，成為引領業務的力量。

這三點是相輔相成的，支持業務、賦能業務，最後引領業務，不論是在技術驅動的公司，還是在業務驅動的公司，技術團隊的使命和定位都是如此。

1.3 技術和業務的關係

定位決定地位，業務發展是終極目標，當面臨整體技術戰略與商業戰略衝突、技術實施節點選擇、技術與業務路徑匹配等問題時，技術管理者可以從以下方面進行思考。

1）解決技術戰略與商業戰略的衝突。

技術和業務除了相輔相成的關係外，還存在一定的衝突。其實技術和業務的衝突在大家平時的工作中經常見到，比如業務同事着急上線一個功能來做活動；而技術覺得要達到同樣的目的，我們可能需要好的設計和架構，而不是簡單做一個臨時補丁式的功能，這就是很常見的技術和業務的衝突。

雖然技術負責人要對未來中長期的戰略布局保持持續思考，但這取決於公司的大小、規模和階段。如果是初創公司，首要任務是生存，那麼業務需求是最高優先級，首先要考慮解決系統不穩定、安全或其他問題；但對於有一定體量的企業，公司業務已經發展到一定階段，技術團隊也有一定的規模，當存在業務需求和技術戰略的衝突時，在滿足最緊迫的業務需求的同時，將一定精力投入到基礎技術研發中去，必須要做中長期的項目預研，做一些底層、甚至風險較高的研究。

2）技術變革的實施節點

我們永遠在高速公路上奔跑，一邊行駛一邊換輪子或換部件的事情一直在發生。技術重構、技術變革、技術債務償還的時機和節點和對業務產生的影響，是我們面臨的又一個挑戰，也是需要我們長期考慮的問題。

什麼節點選擇什麼樣的技術？技術負責人具體把握新技術引入節點，其實難度很大。如果新技術距離實現商用價值僅有一年時間，那麼必須要進行布局，申請預算，建立團隊推進；如果新技術商業化已經迫在眉睫，競爭對手已經在布局了，那麼採取的措施就不是從頭做起，更好的應對方式可能是進行併購或資本運作。

3）技術與業務路徑匹配

新技術來臨，對業務的影響和衝擊會分短、中、長期，有的技術在短期內對新的業態有幫助，有的技術需要一個比較長的周期才會對業務產生影響。這時技術領導人要評估技術本身，並將其與業務的戰略路徑進行匹配，如果對長期業務有幫助，新技術仍然要引入，只是選擇時間點、投入範圍等可能會不一樣。

同時，在引入新技術進行技術創新時，還要注意新技術對當前業務產生的影響。舉個例子，宜信是一家金融科技公司，有自己的催收部門，我們一方面通過規範催收人員的行為來進行催收，一方面自己研發催收機器人。催收機器人的出現意味着部分催收人員的工作將會被替代，同時，機器人的特點之一是沒有情緒，它會按照程序設定禮貌地和用戶溝通，這就會在一定程度對催收效果和業務產生影響。因此我們還要考慮在哪個環節使用機器人這個技術，帶來的效果會更好。這也是技術和業務相輔相成又存在矛盾衝突關係的體現。

1.4 科技戰略

對於大型科技團隊而言，科技戰略思維也非常重要。舉幾個例子。

舉例提到的是我工作過的幾家公司，它們在不同的時間點做了一些不同的戰略調整。

很多年以前，在中國90%的Windows都不是正版的，於是微軟內部提出一個計劃，希望Windows在中國免費。這個計劃現在看起來非常簡單，也很容易理解，正版Windows免費帶來的好處顯而易見：它是一個非常好的終端用戶觸點、可以獲取更多用戶，可以基於這些用戶數據做數據分析和精準營銷等。但是當時微軟Windows的老大極力反對這件事，他認為這會影響Windows的營收，因此這個計劃最終沒有實行。這就是戰略思維的問題，如果不是在中國本地親身體驗這個環境和市場，可能做出的戰略決策就不一定是準確的，帶來的結果可能是痛失更大的發展機會。

微軟後來的雲戰略轉型是成功的，而移動轉型卻是失敗的。移動轉型時期，微軟收購諾基亞旗下的大部分手機業務，並基於Windows自研出一個Windows操作系統放在手機硬件上。因為微軟覺得沒有推出自己的手機這是一個缺憾，還認為佔領移動終端必須基於Windows，因此作出這樣的決策，結果以失敗告終。Windows使微軟一度成為桌面系統垄斷的贏家，也使得微軟在移動轉型失敗，成為下一步發展的絆腳石，可謂是成也Windows，敗也Windows。

再看蘇寧，蘇寧受到阿里巴巴、京東等電商的衝擊，痛下決心必須做電商，它採取的戰略是結合自己線下門店的優勢做O2O智慧門戶，實行線上下單、線下體驗、送貨到家，這種全渠道、全觸點的用戶交互與服務形式，使得蘇寧成為“中國傳統行業数字化轉型互聯網”為數不多的成功案例之一。

現在金融行業正處於嚴監管的環境，金融公司該何去何從？在這裏分享一些我的看法。

縱觀改革開放以來的歷史，每個行業在開始初期都是開放的，任何人都可以參与進來，魚龍混雜，一旦行業出現亂象，就會有監管介入，那些能力不強的、不合規的會被淘汰，等到監管后再開放、行業再成熟時，最後存活下來的才能健康發展。金融行業也是如此。

科技同仁不僅要埋頭做好自己的工作，也要抬頭看看歷史和未來，思考我們身處的這個行業，我們從事的科技工作對公司、對行業的作用是什麼？行業未來的發展趨勢是什麼，這對我們未來的職業發展也有幫助。

二、大型科技團隊的管理實踐

2.1 成功科技組織的特點

無論是前面提到的國際科技巨頭，還是國內優秀的互聯網公司，成功的科技組織都具備一些共同的特點。

1）高效、敏捷

優秀的科技團隊一定是一個高效、敏捷的團隊，能夠快速響應用戶和市場的需求變化，快速上線產品、得到反饋、不斷迭代更新，滿足或超過用戶的預期。

2）商業思維

科技團隊一定要有商業頭腦、商業思維，因為無論是搭建系統，還是做APP，一定有用戶，我們需要真正洞察到用戶的痛點和問題，幫他們及時解決問題，給他們創造價值。

3）數據驅動

如果科技團隊的工作只圍繞產品經理提出的需求，未來的產品路線圖還不夠，一定要基於用戶反饋、市場反饋、日活、月活、留存、轉化等數據來驅動產品走向、技術走向。

4）變革創新

很多公司都在強調變革和創新，我認為這是科技團隊必須要打造的環境和氛圍，方式很多，比如組織各種各樣的黑客馬拉松、團隊之間的交流分享等。我們公司也在組織黑客馬拉松，每個月業務部門都有比較棘手或緊迫的項目，技術團隊與業務團隊聯合把這些業務痛點解決，成果馬上應用到業務環境中去。

2.2 績效管理

績效管理的機制在微軟實行了很多年，其強制5%、10%的淘汰機制，一直被人詬病，因為它使得很多團隊互相指責、互相拆台，有的員工為了績效“寧當雞頭不當鳳尾”，組織內形成不好的文化和結果。後來改成了5%、10%的獎勵，從懲罰後進者變成鼓勵先進者，取得的效果好很多。

2.3 溝通

溝通每天都在進行，比如各種大大小小的會議。我發現不管開多少會，高層領導的想法、思路並不一定能被所有同事理解，因為溝通方式、溝通渠道的原因，信息不能觸達到所有人，需要重複很多遍。

我們可以利用一些非正式場合或社交媒體來進行交流。比如我們公司有每月的CTO午餐會，抽籤的方式，各團隊都有機會可以坐下來跟我一起吃午餐，通過這種面對面的交流，我會向團隊成員提出一些我的看法，或者推薦一本書，他們會向我反饋當時的痛點、想法等。我覺得這是一種非常好的機制，大家能夠在一個寬鬆的環境下面對面地交流。記得以前在思科工作的時候，也有CEO早餐會，每個月過生日的員工可以跟CEO吃早餐，也是一種很好的溝通互動的方式。

2.4 團隊文化

團隊文化包含很多要素，我對這幾點的認同感比較深：主人翁意識、緊迫感、同理心。

2.5 技術決策

商業世界充滿了選擇和決策。作為一個技術決策人，有時很難做決定，難做決定就意味着拖延，這一點對於大型科技團隊的決策人來說是比較忌諱的，很多時候不在於你做的決策是對還是錯，而是在於你做不做決定。如果你是一個不敢做決定的人，帶領的團隊就會缺乏方向感，你做的決定就會受到團隊的質疑和挑戰。

有時候即使你做出了錯誤的決定，但大家一起努力執行的時候，可能可以逐步調整轉變從而達成正確的結果。技術管理人一定要懂得取捨，通過大腦計算，明確目標，了解關聯方，分析可選項和利弊，基於目標、數據和對未來的預期做出決策。

2.6 執行力

執行的時候要不忘初心，一步步地大處着眼、小處着手，小步快跑，快速迭代，及時反饋，及時調整，朝着設定的目標專心致志、心無旁騖。

2.7 終極目標

最後的終極目標是，希望科技團隊能夠做到比業務更懂業務，比用戶更懂用戶，讓技術本身變成公司核心的業務。我認為如果能做到科技團隊在公司起到了核心的作用，這才是永生的價值。

三、面向未來的科技組織

3.1 回顧微軟的3任CEO和3種組織

就微軟而言，同一家公司，文化和技術氛圍在不同階段是不一樣的。

第一個階段，CEO比爾蓋茨，技術為王，認為技術改變世界，代碼可以改變千萬人的生活。這一階段造就了好的產品，同時也存在一些負面影響，比如垄斷等。

第二個階段，CEO鮑爾默，業績為王，要求所有設備，包括手機、電視、車等，都跑到Windows上，還和海爾合作推出基於Windows的智能電視，當時所有跟Windows衝突的想法和計劃基本都被扼殺在搖籃里，這也導致公司錯失了很多發展的機會。

第三個階段，CEO納德拉，公司文化變得更加包容、強調同理心、開放透明，包括技術開源、提供雲服務、和蘋果/谷歌等競爭對手合作。這種開放包容的氛圍，讓微軟得以浴火重生。

3.2 面向未來的科技組織

面向未來的科技組織應該是什麼樣的？

1）跨界融合

不同背景的人，融合到一個跨界的氛圍和組織中，一起發力。

2）数字化轉型

傳統公司也在做数字化轉型，這時會引入很多科技人才，利用科技幫助公司完成轉型，並在行業實現快速發展。

3）全球共享、全球分佈

團隊組成全球化，來自不同國家、不同種族的人組成一個全球化的團隊。東南亞有一個集美團、滴滴、螞蟻金服為一體的公司，解決出行、支付、快遞的問題，這家公司有一個幾千人的科技團隊，團隊成員來自50多個種族，分佈在美國、新加坡、北京、印尼、印度等國家和地區。

4）技術引領

未來科技團隊不僅要做到賦能業務，還要能實現引領業務。

這樣的科技團隊需要跨界、全球化、複合型的領導人，只有既懂科技、又懂管理；既要懂業務，又懂行業的管理人才才能適合於領導面向未來的科技組織。

以上就是今天跟大家分享的全部內容，時間很短，主要介紹了一些在不同公司不同行業的大型科技團隊的管理經驗，希望大家在面向未來的科技組織中找到自己的定位，成為一個優秀的領導者。謝謝大家。

本文根據向江旭老師在LeaTech全球CTO領導力峰會上的分享內容整理所得，轉載請聯繫授權。

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

※3c收購,鏡頭 收購有可能以全新價回收嗎?

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

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

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

※賣IPHONE,iPhone回收,舊換新!教你怎麼賣才划算?

本文由葡萄城技術團隊編撰並首發

轉載請註明出處：，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。

引言

在Web應用發展的初期，那時關係型數據庫受到了較為廣泛的關注和應用，原因是因為那時候Web站點基本上訪問和併發不高、交互也較少。而在後來，隨着訪問量的提升，使用關係型數據庫的Web站點多多少少都開始在性能上出現了一些瓶頸，而瓶頸的源頭一般是在磁盤的I/O上。而隨着互聯網技術的進一步發展，各種類型的應用層出不窮，這導致在當今雲計算、大數據盛行的時代，對性能有了更多的需求，主要體現在以下四個方面：

1. 低延遲的讀寫速度：應用快速地反應能極大地提升用戶的滿意度
2. 支撐海量的數據和流量：對於搜索這樣大型應用而言，需要利用PB級別的數據和能應對百萬級的流量
3. 大規模集群的管理：系統管理員希望分佈式應用能更簡單的部署和管理
4. 龐大運營成本的考量：IT部門希望在硬件成本、軟件成本和人力成本能夠有大幅度地降低

為了克服這一問題，NoSQL應運而生，它同時具備了高性能、可擴展性強、高可用等優點，受到廣泛開發人員和倉庫管理人員的青睞。

Redis是什麼

Redis是現在最受歡迎的NoSQL數據庫之一，Redis是一個使用ANSI C編寫的開源、包含多種數據結構、支持網絡、基於內存、可選持久性的鍵值對存儲數據庫，其具備如下特性：

• 基於內存運行，性能高效
• 支持分佈式，理論上可以無限擴展
• key-value存儲系統
• 開源的使用ANSI C語言編寫、遵守BSD協議、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API

相比於其他數據庫類型，Redis具備的特點是：

• C/S通訊模型
• 單進程單線程模型
• 豐富的數據類型
• 操作具有原子性
• 持久化
• 高併發讀寫
• 支持lua腳本

哪些大廠在使用Redis？

• github
• twitter
• 微博
• Stack Overflow
• 阿里巴巴
• 百度
• 美團
• 搜狐

Redis的應用場景有哪些？

Redis 的應用場景包括：緩存系統（“熱點”數據：高頻讀、低頻寫）、計數器、消息隊列系統、排行榜、社交網絡和實時系統。

 

Redis的數據類型及主要特性

Redis提供的數據類型主要分為5種自有類型和一種自定義類型，這5種自有類型包括：String類型、哈希類型、列表類型、集合類型和順序集合類型。

String類型：

它是一個二進制安全的字符串，意味着它不僅能夠存儲字符串、還能存儲圖片、視頻等多種類型, 最大長度支持512M。

對每種數據類型，Redis都提供了豐富的操作命令，如：

• GET/MGET
• SET/SETEX/MSET/MSETNX
• INCR/DECR
• GETSET
• DEL

哈希類型：

該類型是由field和關聯的value組成的map。其中，field和value都是字符串類型的。

Hash的操作命令如下：

• HGET/HMGET/HGETALL
• HSET/HMSET/HSETNX
• HEXISTS/HLEN
• HKEYS/HDEL
• HVALS

列表類型：

該類型是一個插入順序排序的字符串元素集合, 基於雙鏈表實現。

List的操作命令如下：

• LPUSH/LPUSHX/LPOP/RPUSH/RPUSHX/RPOP/LINSERT/LSET
• LINDEX/LRANGE
• LLEN/LTRIM

集合類型：

Set類型是一種無順序集合, 它和List類型最大的區別是：集合中的元素沒有順序, 且元素是唯一的。

Set類型的底層是通過哈希表實現的，其操作命令為：

• SADD/SPOP/SMOVE/SCARD
• SINTER/SDIFF/SDIFFSTORE/SUNION

Set類型主要應用於：在某些場景，如社交場景中，通過交集、並集和差集運算，通過Set類型可以非常方便地查找共同好友、共同關注和共同偏好等社交關係。

順序集合類型：

ZSet是一種有序集合類型，每個元素都會關聯一個double類型的分數權值，通過這個權值來為集合中的成員進行從小到大的排序。與Set類型一樣，其底層也是通過哈希表實現的。

ZSet命令：

• ZADD/ZPOP/ZMOVE/ZCARD/ZCOUNT
• ZINTER/ZDIFF/ZDIFFSTORE/ZUNION

Redis的數據結構

Redis的數據結構如下圖所示：

關於上表中的部分釋義：

1. 壓縮列表是列表鍵和哈希鍵的底層實現之一。當一個列表鍵只包含少量列表項，並且每個列表項要麼就是小整數，要麼就是長度比較短的字符串，Redis就會使用壓縮列表來做列表鍵的底層實現
2. 整數集合是集合鍵的底層實現之一，當一個集合只包含整數值元素，並且這個集合的元素數量不多時，Redis就會使用整數集合作為集合鍵的底層實現

如下是定義一個Struct數據結構的例子：

 

簡單動態字符串SDS (Simple Dynamic String)

基於C語言中傳統字符串的缺陷，Redis自己構建了一種名為簡單動態字符串的抽象類型，簡稱SDS，其結構如下：

SDS幾乎貫穿了Redis的所有數據結構，應用十分廣泛。

SDS的特點

和C字符串相比，SDS的特點如下：

　　1. 常數複雜度獲取字符串長度

　　　　Redis中利用SDS字符串的len屬性可以直接獲取到所保存的字符串的長
　　　　度，直接將獲取字符串長度所需的複雜度從C字符串的O(N)降低到了O(1)。

　　2. 減少修改字符串時導致的內存重新分配次數

　　　　通過C字符串的特性，我們知道對於一個包含了N個字符的C字符串來說，其底層實現總是N+1個字符長的數組（額外一個空字符結尾）

　　　　那麼如果這個時候需要對字符串進行修改，程序就需要提前對這個C字符串數組進行一次內存重分配（可能是擴展或者釋放）　

　　　　而內存重分配就意味着是一個耗時的操作。

Redis巧妙的使用了SDS避免了C字符串的缺陷。在SDS中，buf數組的長度不一定就是字符串的字符數量加一，buf數組裡面可以包含未使用的字節，而這些未使用的字節由free屬性記錄。

與此同時，SDS採用了空間預分配的策略，避免C字符串每一次修改時都需要進行內存重分配的耗時操作，將內存重分配從原來的每修改N次就分配N次——>降低到了修改N次最多分配N次。

如下是Redis對SDS的簡單定義：

  

Redis特性1：事務

• 命令序列化，按順序執行
• 原子性
• 三階段: 開始事務 – 命令入隊 – 執行事務
• 命令：MULTI/EXEC/DISCARD

Redis特性2：發布訂閱(Pub/Sub)

• Pub/sub是一種消息通訊模式
• Pub發送消息, Sub接受消息
• Redis客戶端可以訂閱任意數量的頻道
• “fire and forgot”, 發送即遺忘
• 命令：Publish/Subscribe/Psubscribe/UnSub

　　

Redis特性3：Stream

• Redis 5.0新增
• 等待消費
• 消費組(組內競爭)
• 消費歷史數據
• FIFO

 

 

 

以上就是Redis的基本概念，下面我們將介紹在開發過程中可能會踩到的“坑”。

Redis常見問題解析：擊穿

概念：在Redis獲取某一key時, 由於key不存在, 而必須向DB發起一次請求的行為, 稱為“Redis擊穿”。

引發擊穿的原因：

• 第一次訪問
• 惡意訪問不存在的key
• Key過期

合理的規避方案：

• 服務器啟動時, 提前寫入
• 規範key的命名, 通過中間件攔截
• 對某些高頻訪問的Key，設置合理的TTL或永不過期

Redis常見問題解析：雪崩

概念：Redis緩存層由於某種原因宕機后，所有的請求會湧向存儲層，短時間內的高併發請求可能會導致存儲層掛機，稱之為“Redis雪崩”。

合理的規避方案：

• 使用Redis集群
• 限流

Redis在產品開發中的應用實踐

為此，我很高興的為大家介紹，葡萄城架構師Jim將在2019-11-27 14：00 為大家帶來一場公開課，其中 Jim除了為大家講解Redis的基礎，同時也會實際演示他所在的項目組使用Redis時碰到的問題以及解決方案，對於剛接觸Redis的同學來說，更具參考意義和學習價值，歡迎大家屆時參加，公開課地址：。

• 後端採用nodeJS
• 使用Azure的Redis服務
• Redis的使用場景

　　　　-  token緩存, 用於令牌驗證

　　　　-  IP白名單

碰到的問題

• “網絡抖動”或者Redis服務異常導致Redis訪問超時
• Redis客戶端驅動穩定性問題

　　　　-  連接池 “Broken connection” 問題

　　　　-  JS的Promise引出的Redis重置問題

下面我們來簡單了解一下Redis的進階知識。

進階之Redis協議簡介

Redis客戶端通訊協議：RESP(Redis Serialization Protocol)，其特點是：

• 簡單
• 解析速度快
• 可讀性好

Redis集群內部通訊協議：RECP(Redis Cluster Protocol ) ，其特點是：

• 每一個node兩個tcp 連接
• 一個負責client-server通訊(P: 6379)
• 一個負責node之間通訊(P: 10000 + 6379)

 

Redis協議支持的數據類型：

• 簡單字符(首字節: “+”)

      　　“+OK\r\n”

• 錯誤(首字節: “-”)

      　　“-error msg\r\n”

• 数字(首字節: “:”)

      　　“:123\r\n”

• 批量字符(首字節: “$”)

      　　“&hello\r\nWhoa re you\r\n”

• 數組(首字節: “*”)

      　　“*0\r\n”

      　　“*-1\r\n”

除了Redis，還有什麼NoSQL型數據庫

市面上類似於Redis，同樣是NoSQL型的數據庫有很多，如下圖所示，除了Redis，還有MemCache、Cassadra和Mongo。下面，我們就分別對這幾個數據庫做一下簡要的介紹：

 

 

Memcache：這是一個和Redis非常相似的數據庫，但是它的數據類型沒有Redis豐富。Memcache由LiveJournal的Brad Fitzpatrick開發，作為一套分佈式的高速緩存系統，被許多網站使用以提升網站的訪問速度，對於一些大型的、需要頻繁訪問數據庫的網站訪問速度的提升效果十分顯著。

Apache Cassandra：（社區內一般簡稱為C*）這是一套開源分佈式NoSQL數據庫系統。它最初由Facebook開發，用於儲存收件箱等簡單格式數據，集Google BigTable的數據模型與Amazon Dynamo的完全分佈式架構於一身。Facebook於2008將 Cassandra 開源，由於其良好的可擴展性和性能，被 Apple、Comcast、Instagram、Spotify、eBay、Rackspace、Netflix等知名網站所採用，成為了一種流行的分佈式結構化數據存儲方案。

MongoDB：是一個基於分佈式文件存儲、面向文檔的NoSQL數據庫，由C++編寫，旨在為WEB應用提供可擴展的高性能數據存儲解決方案。MongoDB是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係型數據庫的，它支持的數據結構非常鬆散，是一種類似json的BSON格式。

總結

以上就是Redis入門介紹教程，如果各位還想了解更多，歡迎通過評論和私信的方式告訴我。

 

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

※3c收購,鏡頭 收購有可能以全新價回收嗎?

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

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

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

※賣IPHONE,iPhone回收,舊換新!教你怎麼賣才划算?

 

   

       在上一篇 文章中我們學習了TreeGrid的一些基礎知識，接下我們來創建我們開發組織管理功能用到的一些類。關於如何創建類我們之前的文章中已經寫了很多了，這裡會有些簡略。

 

四、定義應用服務接口需要用到的DTO類

      為了在進行查詢時使用, PagedOrgResultRequestDto被用來將模塊數據傳遞到基礎設施層.

       1. 在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊“ABP.TPLMS.Application”項目，在彈出菜單中選擇“添加” > “新建文件夾”，並重命名為“Orgs”

      2. 使用鼠標右鍵單擊我們剛才創建的“Orgs”文件夾，在彈出菜單中選擇“添加” > “新建文件夾”，並重命名為“Dto”。

      3．右鍵單擊“Dto”文件夾，然後選擇“添加” > “類”。 將類命名為 Paged OrgResultRequestDto，然後選擇“添加”。代碼如下。

using Abp.Application.Services.Dto;
using Abp.Application.Services.Dto;
using System;
using System.Collections.Generic;
using System.Text;
 

namespace ABP.TPLMS.Orgs.Dto
{

public class PagedOrgResultRequestDto : PagedResultRequestDto
    {
        public string Keyword { get; set; }
    }
}

      4．右鍵單擊“Dto”文件夾，然後選擇“添加” > “類”。 將類命名為 OrgDto，然後選擇“添加”。代碼如下。

using Abp.Application.Services.Dto;
using Abp.AutoMapper;
using ABP.TPLMS.Entitys;
using System;
using System.Collections.Generic;
using System.Text;
 

namespace ABP.TPLMS.Orgs.Dto
{

    [AutoMapFrom(typeof(Org))]
    public class OrgDto : EntityDto<int>
    {

        int m_parentId = 0;
        public string Name { get; set; }       

        public string HotKey { get; set; }
        public int ParentId { get { return m_parentId; } set { m_parentId = value; } }       

        public string ParentName { get; set; }
        public bool IsLeaf { get; set; }
        public bool IsAutoExpand { get; set; }       

        public string IconName { get; set; }
        public int Status { get; set; }
        public int Type { get; set; }      
        public string BizCode { get; set; }       

        public string CustomCode { get; set; }
        public DateTime CreationTime { get; set; }
        public DateTime UpdateTime { get; set; }

        public int CreateId { get; set; }
        public int SortNo { get; set; }
        public int _parentId {
            get { return m_parentId; }          

        }
    }
}

 

      5．右鍵單擊“Dto”文件夾，然後選擇“添加” > “類”。 將類命名為 CreateUpdateOrgDto，然後選擇“添加”。代碼如下。

using Abp.Application.Services.Dto;
using Abp.AutoMapper;
using ABP.TPLMS.Entitys;
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Text;

 
namespace ABP.TPLMS.Orgs.Dto
{

    [AutoMapTo(typeof(Org))]
    public class CreateUpdateOrgDto : EntityDto<int>
    {

        public string Name { get; set; }
        [StringLength(255)]
        public string HotKey { get; set; }

        public int ParentId { get; set; }

        [Required]
        [StringLength(255)]
        public string ParentName { get; set; }

        public bool IsLeaf { get; set; }
        public bool IsAutoExpand { get; set; }

        [StringLength(255)]
        public string IconName { get; set; }

        public int Status { get; set; }
        public int Type { get; set; }

        [StringLength(255)]
        public string BizCode { get; set; }

        [StringLength(100)]
        public string CustomCode { get; set; }
        public DateTime CreationTime { get; set; }
        public DateTime UpdateTime { get; set; }

        public int CreateId { get; set; }
        public int SortNo { get; set; } 

    }
}

 

 

 

 

五、定義IOrgAppService接口

        6． 在Visual Studio 2017的“解決方案資源管理器”中，鼠標右鍵單擊“Org”文件夾，然後選擇“添加” > “新建項”，在彈出對話框中選擇“接口”。為應用服務定義一個名為 IOrgAppService 的接口。代碼如下。

using System;
using System.Collections.Generic;
using System.Text;
using Abp.Application.Services;
using ABP.TPLMS.Orgs.Dto; 

 

namespace ABP.TPLMS.Orgs
{
  public  interface IOrgAppService : IAsyncCrudAppService<//定義了CRUD方法

             OrgDto, //用來展示組織信息
             int, //Org實體的主鍵
             PagedOrgResultRequestDto, //獲取組織信息的時候用於分頁
             CreateUpdateOrgDto, //用於創建組織信息
             CreateUpdateOrgDto> //用於更新組織信息

    {
    }
}

 

      六、實現IOrgAppService

       7．在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊“Org”文件夾，然後選擇“添加” > “新建項”，在彈出對話框中選擇“類”。為應用服務定義一個名為 OrgAppService 的服務類。代碼如下。

using Abp.Application.Services;
using Abp.Domain.Repositories;
using ABP.TPLMS.Entitys;
using ABP.TPLMS.Orgs.Dto;
using System;
using System.Collections.Generic;
using System.Text;
 

namespace ABP.TPLMS.Orgs
{

    public class OrgAppService : AsyncCrudAppService<Org, OrgDto, int, PagedOrgResultRequestDto,
                            CreateUpdateOrgDto, CreateUpdateOrgDto>, IOrgAppService 

    {
        public OrgAppService(IRepository<Org, int> repository)

            : base(repository)

        { 

        }
    }
}

七 創建OrgController繼承自TPLMSControllerBase

      1. 在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊在領域層“ABP.TPLMS.Web.Mvc”項目中的Controller目錄。 選擇“添加” > “新建項…”。如下圖。

 

     2. 在彈出對話框“添加新項-ABP.TPLMS.Web.Mvc”中選擇“控制器類”，然後在名稱輸入框中輸入“OrgsController”，然後點擊“添加”按鈕。

     3.在OrgsController.cs文件中輸入如下代碼，通過構造函數注入對應用服務的依賴。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Abp.AspNetCore.Mvc.Authorization;
using Abp.Web.Models;
using ABP.TPLMS.Controllers;
using ABP.TPLMS.Orgs;
using ABP.TPLMS.Orgs.Dto;
using ABP.TPLMS.Web.Models.Orgs;
using Microsoft.AspNetCore.Mvc;


namespace ABP.TPLMS.Web.Controllers
{
    [AbpMvcAuthorize]
    public class OrgsController : TPLMSControllerBase
    {
        private readonly IOrgAppService _orgAppService;
        private const int MAX_COUNT= 1000;
        
        public OrgsController(IOrgAppService orgAppService)
        {
            _orgAppService = orgAppService;
        }
        [HttpGet]
        // GET: /<controller>/
        public IActionResult Index()
        {
            return View();
        }
        [DontWrapResult]
        [HttpPost]
        public string List()
        {         
            PagedOrgResultRequestDto paged = new PagedOrgResultRequestDto();
            paged.MaxResultCount = MAX_COUNT;
           var userList = _orgAppService.GetAll(paged).GetAwaiter().GetResult().Items;
            int total = userList.Count;
            var json = JsonEasyUI(userList, total);
            return json;
        }       
    }
}

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

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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

中油從 107 年起，依據經濟部智慧電動機車能源補充設施普及計畫(公建計畫)於加油站建置電動機車充電、換電設備，去年僅睿能 Gogoro 參與設 144 站，今年增加光陽 Ionex，兩家採公開競標方式，由光陽 Ionex 獲得 3 標共 146 站，睿能 Gogoro 得到 1 標 48 站；其中，睿能 Gogoro 扣除合約到期站數，再加上先前自建設站，在台灣中油加油站中有 285 站可為消費者服務。

經濟部工業局委託台灣銀行辦理共同供應契約設備系統招標，其中電池交換設備系統得標廠商都需符合安全規範審核，108 年換電設備系統之得標廠商共有睿能 Gogoro 及光陽 Ionex 兩家，中油考量消費者的便利性及設備使用公平性兩大原則，於採購系統設備前即採取公開方式辦理合作經營招標。

中油表示，北部地區有 52 站與睿能 Gogoro 合作的換電站，今年合約陸續到期，睿能 Gogoro 依據契約與決標結果遷移設備，為執行公建計畫，中油將此52站列入今年建置194站換電站的地點，公建換電站依各縣市站點打散，再平均分4案開標，讓每一標案站點均涵蓋各縣市，投標結果為光陽 Ionex 獲得 3 標（146 站）、睿能 Gogoro 得 1 標（48 站），原先台灣中油與睿能 Gogoro 合約到期的52站中，有38站改由光陽Ionex得標。

中油指出，上述政府電動機車充、換電站公建計畫，於 107 年已執行 161 站，其中 144 座換電站均為睿能 Gogoro 所有，另有充電 17 站，今年預計建置 216 座充換電站，其中 194 座為換電站，光陽 Ionex 有 146 站、睿能 Gogoro 48 站，另有充電 22 站，以總數來說，再加上睿能 Gogoro 之前的自建站 79 站，其仍在台灣中油有 285 站，光陽 Ionex 有 146 站為消費者服務，明年亦將配合政府預算持續建置更多站點，協助政府綠能政策推動。

（本文內容由 授權使用。首圖來源：Gogoro）

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

【其他文章推薦】

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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

我們在提到了對Win10 API的調用，但仍存在無法在WPF中使用UWP控件的問題，雖然都是XAML控件，但卻是兩套命名空間下的同名類型，無法混用。
人總會被現實打敗，強大如某軟也得向生活低頭，UWP一直沒有起色，某軟的老大又一心去搞Azure。Windows平台的重振，似乎想走回頭路，從1903版本開始，支持在.NET Framwork的WPF和WinForm工程中，直接使用部分的UWP控件了。首當其沖的，就是有點騷包的InkToolbar和InkCanvas。

接下來我們就來試試如何在WPF工程中，使用UWP的InkToolbar和InkCanvas。
首先創建一個空的WPF工程，完成后，在Nuget的搜索界面填入 Microsoft.Toolkit.Wpf.UI.Controls ，選中第一個進行安裝。

完成安裝后，打開MainWindow.xaml，添加對命名空間的引用xmlns:Controls=”clr-namespace:Microsoft.Toolkit.Wpf.UI.Controls;assembly=Microsoft.Toolkit.Wpf.UI.Controls”。接着就可以在<Grid>節點中添加UWP版本的InkToolbar和InkCanvas控件了。

<Window x:Class="WPFInkSample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:WPFInkSample"
        xmlns:Controls="clr-namespace:Microsoft.Toolkit.Wpf.UI.Controls;assembly=Microsoft.Toolkit.Wpf.UI.Controls"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800">
    <Grid >
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>
        <Controls:InkToolbar TargetInkCanvas="{x:Reference myInkCanvas}" Grid.Row="0" />
        <Controls:InkCanvas x:Name="myInkCanvas" Grid.Row="1" />
    </Grid>
</Window>

同時我們還需要在MainWindow.xaml.cs中設置InputDeviceTypes。

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            this.myInkCanvas.InkPresenter.InputDeviceTypes = CoreInputDeviceTypes.Mouse | CoreInputDeviceTypes.Pen;
        }
    }

然後按下F5運行，某軟的騷操作來了……因為僅在1903以後的版本才支持這種騷操作（10.0.18226是稍早的preview版），所以需要做額外的處理才可以。

我們這裡有兩種選擇，一是通過來打包這個WPF程序，然後在Packaging工程的屬性里，將Target version和Minimum version同時設置為Windows 10, version 1903 (10.0.18362) 。這是MSDN上推薦的標準做法，這樣做的好處在於，打包好的程序可以直接上傳MS Store。
如果我們想保持exe的可執行文件形式，還有另一種做法，在Project文件上右鍵點擊Add->New Item，添加一個manifest文件。
在這個文件中，找到<!–Windows 10–>，然後做如下編輯：

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- A list of the Windows versions that this application has been tested on
           and is designed to work with. Uncomment the appropriate elements
           and Windows will automatically select the most compatible environment. -->
  
      <!-- Windows Vista -->
      <!--<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />-->
  
      <!-- Windows 7 -->
      <!--<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />-->
  
      <!-- Windows 8 -->
      <!--<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />-->
  
      <!-- Windows 8.1 -->
      <!--<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />-->
  
      <!-- Windows 10 -->
      <maxversiontested Id="10.0.18362.0"/>
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
  
    </application>
  </compatibility>

保存后，再通過F5運行，即發現一切正常，不在出現之前的運行時錯誤了。
本篇我們介紹了如何在WPF工程中使用UWP InkToolbar和InkCavas。因為這個功能僅在1903后的版本支持，所以下一篇我們會介紹如何簡單地判斷Win10 API 版本，在運行時判斷是否執行對應版本的代碼。
Github：

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

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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

一、背景

地圖App的功能可以簡單概括為定位，搜索，導航三部分，分別解決在哪裡，去哪裡，和怎麼去的問題。高德地圖的搜索場景下，輸入的是，地理相關的檢索query，用戶位置，App圖面等信息，輸出的是，用戶想要的POI。如何能夠更加精準地找到用戶想要的POI，提高滿意度，是評價搜索效果的最關鍵指標。

一個搜索引擎通常可以拆分成query分析、召回、排序三個部分，query分析主要是嘗試理解query表達的含義，為召回和排序給予指導。

地圖搜索的query分析不僅包括通用搜索下的分詞，成分分析，同義詞，糾錯等通用NLP技術，還包括城市分析，wherewhat分析，路徑規劃分析等特定的意圖理解方式。

常見的一些地圖場景下的query意圖表達如下：

query分析是搜索引擎中策略密集的場景，通常會應用NLP領域的各種技術。地圖場景下的query分析，只需要處理地理相關的文本，多樣性不如網頁搜索，看起來會簡單一些。但是，地理文本通常比較短，並且用戶大部分的需求是唯一少量結果，要求精準度非常高，如何能夠做好地圖場景下的文本分析，並提升搜索結果的質量，是充滿挑戰的。

二、整體技術架構

搜索架構

類似於通用檢索的架構，地圖的檢索架構包括query分析，召回，排序三個主要部分。先驗的，用戶的輸入信息可以理解為多種意圖的表達，同時下發請求嘗試獲取檢索結果。后驗的，拿到每種意圖的檢索結果時，進行綜合判斷，選擇效果最好的那個。

query分析流程

具體的意圖理解可分為基礎query分析和應用query分析兩部分，基礎query分析主要是使用一些通用的NLP技術對query進行理解，包括分析，成分分析，省略，同義詞，糾錯等。應用query分析主要是針對地圖場景里的特定問題，包括分析用戶目標城市，是否是where+what表達，是否是從A到B的路徑規劃需求表達等。

整體技術演進

在地里文本處理上整體的技術演進經歷了規則為主，到逐步引入機器學習，到機器學習全面應用的過程。由於搜索模塊是一個高併發的線上服務，對於深度模型的引入有比較苛刻的條件，但隨着性能問題逐漸被解決，我們從各個子方向逐步引入深度學習的技術，進行新一輪的效果提升。

NLP領域技術在最近幾年取得了日新月異的發展，bert，XLNet等模型相繼霸榜，我們逐步統一化各個query分析子任務，使用統一的向量表示對進行用戶需求進行表達，同時進行seq2seq的多任務學習，在效果進一步提升的基礎上，也能夠保證系統不會過於臃腫。

本文就高德地圖搜索的地理文本處理，介紹相關的技術在過去幾年的演進。我們將選取一些點分上下兩篇進行介紹，上篇主要介紹搜索引擎中一些通用的query分析技術，包括糾錯，改寫和省略。下篇着重介紹地圖場景中特有query分析技術，包括城市分析，wherewhat分析，路徑規劃。

三、通用query分析技術演進

3.1 糾錯

在搜索引擎中，用戶輸入的檢索詞（query）經常會出現拼寫錯誤。如果直接對錯誤的query進行檢索，往往不會得到用戶想要的結果。因此不管是通用搜索引擎還是垂直搜索引擎，都會對用戶的query進行糾錯，最大概率獲得用戶想搜的query。

在目前的地圖搜索中，約有6%-10%的用戶請求會輸入錯誤，所以query糾錯在地圖搜索中是一個很重要的模塊，能夠極大的提升用戶搜索體驗。

在搜索引擎中，低頻和中長尾問題往往比較難解決，也是糾錯模塊面臨的主要問題。另外，地圖搜索和通用搜索，存在一個明顯的差異，地圖搜索query結構化比較突出，query中的片段往往包含一定的位置信息，如何利用好query中的結構化信息，更好地識別用戶意圖，是地圖糾錯獨有的挑戰。

常見錯誤分類

(1) 拼音相同或者相近，例如: 盤橋物流園-潘橋物流園
(2) 字形相近，例如: 河北冒黎-河北昌黎
(3) 多字或者漏字，例如: 泉州州頂街-泉州頂街

糾錯現狀

原始糾錯模塊包括多種召回方式，如：

拼音糾錯：主要解決短query的拼音糾錯問題，拼音完全相同或者模糊音作為糾錯候選。
拼寫糾錯：也叫形近字糾錯，通過遍歷替換形近字，用query熱度過濾，加入候選。
組合糾錯：通過翻譯模型進行糾錯替換，資源主要是通過query對齊挖掘的各種替換資源。

組合糾錯翻譯模型計算公式：

其中p(f)是語言模型，p(f|e)是替換模型。

問題1：召回方式存在缺陷。目前query糾錯模塊主要召回策略包括拼音召回、形近字召回，以及替換資源召回。對於低頻case，解決能力有限。

問題2：排序方式不合理。糾錯按照召回方式分為幾個獨立的模塊，分別完成相應的召回和排序，不合理。

技術改造

改造1：基於空間關係的實體糾錯
原始的糾錯主要是基於用戶session挖掘片段替換資源，所以對於低頻問題解決能力有限。但是長尾問題往往集中在低頻，所以低頻問題是當前的痛點。

地圖搜索與通用搜索引擎有個很大的區別在於，地圖搜索query比較結構化，例如北京市朝陽區阜榮街10號首開廣場。我們可以對query進行結構化切分（也就是地圖中成分分析的工作），得到這樣一種帶有類別的結構化描述，北京市【城市】朝陽區【區縣】阜榮街【道路】10號【門址後綴】首開廣場【通用實體】。

同時，我們擁有權威的地理知識數據，利用權威化的地理實體庫進行前綴樹+後綴樹的索引建庫，提取疑似糾錯的部分在索引庫中進行拉鏈召回，同時利用實體庫中的邏輯隸屬關係對糾錯結果進行過濾。實踐表明，這種方式對低頻的區劃或者實體的錯誤有着明顯的作用。

基於字根的字形相似度計算

上文提到的排序策略裏面通過字形的編輯距離作為排序的重要特徵，這裏我們開發了一個基於字根的字形相似度計算策略，對於編輯距離的計算更為細化和準確。漢字信息有漢字的字根拆分詞表和漢字的筆畫數。

將一個漢字拆分成多個字根，尋找兩個字的公共字根，根據公共字根筆畫數來計算連個字的相似度。

改造2：排序策略重構

原始的策略召回和排序策略耦合，導致不同的召回鏈路，存在顧此失彼的情況。為了能夠充分發揮各種召回方式的優勢，急需要對召回和排序進行解耦並進行全局排序優化。為此我們增加了排序模塊，將流程分為召回和排序兩階段。

模型選擇

對於這個排序問題，這裏我們參考業界的實踐，使用了基於pair-wise的gbrank進行模型訓練。

樣本建設

通過線上輸出結合人工review的方式構造樣本。

特徵建設
(1) 語義特徵。如統計語言模型。
(2) 熱度特徵。pv，點擊等。
(3) 基礎特徵。編輯距離，切詞和成分特徵，累積分佈特徵等。

這裏解決了糾錯模塊兩個痛點問題，一個是在地圖場景下的大部分低頻糾錯問題。另一個是重構了模塊流程，將召回和排序解耦，充分發揮各個召回鏈路的作用，召回方式更新后只需要重訓排序模型即可，使得模塊更加合理，為後面的深度模型升級打下良好的基礎。後面在這個框架下，我們通過深度模型進行seq2seq的糾錯召回，取得了進一步的收益。

3.2 改寫

糾錯作為query變換的一種方式的召回策略存在諸多限制，對於一些非典型的query變換表達，存在策略的空白。比如query=永城市新農合辦，目標POI是永城市新農合服務大廳。用戶的低頻query，往往得不到較好搜索效果，但其實用戶描述的語義與主poi的高頻query是相似的。

這裏我們提出一種query改寫的思路，可以將低頻query改寫成語義相似的高頻query，以更好地滿足用戶需求多樣性的表達。

這是一個從無到有的實現。用戶表達的query是多樣的，使用規則表達顯然是難以窮盡的，直觀的思路是通過向量的方式召回，但是向量召回的方式很可能出現泛化過多，不適應地圖場景的檢索的問題，這些都是要在實踐過程中需要考慮的問題。

方案

整體看，方案包括召回，排序，過濾，三個階段。

召回階段

我們調研了句子向量表示的幾種方法，選擇了算法簡單，效果和性能可以和CNN，RNN媲美的SIF（Smooth Inverse Frequency）。向量召回可以使用開源的Faiss向量搜索引擎，這裏我們使用了阿里內部的性能更好的的向量檢索引擎。

排序階段
樣本構建
原query與高頻query候選集合，計算語義相似度，選取語義相似度的TOPK，人工標註的訓練樣本。

特徵建設

1.基礎文本特徵
2.編輯距離
3.組合特徵

模型選擇

使用xgboost進行分數回歸

過濾階段
通過向量召回的query過度泛化非常嚴重，為了能夠在地圖場景下進行應用，增加了對齊模型。使用了兩種統計對齊模型giza和fastalign，實驗證明二者效果幾乎一致，但fastalign在性能上好於giza，所以選擇fastalign。

通過對齊概率和非對齊概率，對召回的結果進行進一步過濾，得到精度比較高的結果。

query改寫填補了原始query分析模塊中一些低頻表達無法滿足的空白，區別於同義詞或者糾錯的顯式query變換表達，句子的向量表示是相似query的一種隱式的表達，有其相應的優勢。

向量表示和召回也是深度學習模型逐步開始應用的嘗試。同義詞，改寫，糾錯，作為地圖中query變換主要的三種方式，以往在地圖模塊里比較分散，各司其職，也會有互相重疊的部分。在後續的迭代升級中，我們引入了統一的query變換模型進行改造，在取得收益的同時，也擺脫掉了過去很多規則以及模型耦合造成的歷史包袱。

3.2 省略

在地圖搜索場景里，有很多query包含無效詞，如果用全部query嘗試去召回很可能不能召回有效結果。如廈門市搜”湖裡區縣后高新技術園新捷創運營中心11樓1101室 縣后brt站”。這就需要一種檢索意圖，在不明顯轉義下，使用核心term進行召回目標poi候選集合，當搜索結果無果或者召回較差時起到補充召回的作用。

在省略判斷的過程中存在先驗后驗平衡的問題。省略意圖是一個先驗的判斷，但是期望的結果是能夠進行POI有效召回，和POI的召回字段的現狀密切相關。如何能夠在策略設計的過程中保持先驗的一致性，同時能夠在後驗POI中拿到相對好的效果，是做好省略模塊比較困難的地方。

原始的省略模塊主要是基於規則進行的，規則依賴的主要特徵是上游的成分分析特徵。由於基於規則擬合，模型效果存在比較大的優化空間。另外，由於強依賴成分分析，模型的魯棒性並不好。

技術改造

省略模塊的改造主要完成了規則到crf模型的升級，其中也離線應用了深度學習模型輔助樣本生成。

模型選擇

識別出來query哪些部分是核心哪些部分是可以省略的，是一個序列標註問題。在淺層模型的選型中，顯而易見地，我們使用了crf模型。

特徵建設

term特徵。使用了賦權特徵，詞性，先驗詞典特徵等。
成分特徵。仍然使用成分分析的特徵。
統計特徵。統計片段的左右邊界熵，城市分佈熵等，通過分箱進行離散化。

樣本建設

項目一期我們使用了使用線上策略粗標，外包細標的方式，構造了萬級的樣本供crf模型訓練。

但是省略query的多樣性很高，使用萬級的樣本是不夠的，在線上模型無法快速應用深度模型的情況下，我們使用了boostraping的方式，藉助深度模型的泛化能力，離線構造了大量樣本。

使用了這種方式，樣本從萬級很容易擴充到百萬級，我們仍然使用crf模型進行訓練和線上應用。

在省略模塊，我們完成了規則到機器學習的升級，引入了成分以外的其他特徵，提升了模型的魯棒性。同時並且利用離線深度學習的方式進行樣本構造的循環，提升了樣本的多樣性，使得模型能夠更加接近crf的天花板。

在後續深度模型的建模中，我們逐步擺脫了對成分分析特徵的依賴，對query到命中poi核心直接進行建模，構建大量樣本，取得了進一步的收益。

 

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

※3c收購,鏡頭 收購有可能以全新價回收嗎?

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

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

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

※賣IPHONE,iPhone回收,舊換新!教你怎麼賣才划算?

介紹

生產者-消費者模型用於解耦生產者與消費者，平衡兩者之間的能力不平衡，該模型廣泛應用於各個系統中，Hudi也使用了該模型控制對記錄的處理，即記錄會被生產者生產至隊列中，然後由消費者從隊列中消費，更具體一點，對於更新操作，生產者會將文件中老的記錄放入隊列中等待消費者消費，消費后交由HoodieMergeHandle處理；對於插入操作，生產者會將新記錄放入隊列中等待消費者消費，消費后交由HandleCreateHandle處理。

入口

前面的文章中提到過無論是HoodieCopyOnWriteTable#handleUpdate處理更新時直接生成了一個SparkBoundedInMemoryExecutor對象，還是HoodieCopyOnWriteTable#handleInsert處理插入時生成了一個CopyOnWriteLazyInsertIterable對象，再迭代時調用該對象的CopyOnWriteLazyInsertIterable#computeNext方法生成SparkBoundedInMemoryExecutor對象。最後兩者均會調用SparkBoundedInMemoryExecutor#execute開始記錄的處理，該方法核心代碼如下

  public E execute() {
    try {
      ExecutorCompletionService<Boolean> producerService = startProducers();
      Future<E> future = startConsumer();
      // Wait for consumer to be done
      return future.get();
    } catch (Exception e) {
      throw new HoodieException(e);
    }
  }

該方法會啟動所有生產者和單個消費者進行處理。

Hudi定義了BoundedInMemoryQueueProducer接口表示生產者，其子類實現如下

• FunctionBasedQueueProducer，基於Function來生產記錄，在合併日誌log文件和數據parquet文件時使用，以便提供RealTimeView。
• IteratorBasedQueueProducer，基於迭代器來生產記錄，在插入更新時使用。

定義了BoundedInMemoryQueueConsumer類表示消費者，其主要子類實現如下

• CopyOnWriteLazyInsertIterable$CopyOnWriteInsertHandler，主要處理CopyOnWrite表類型時的插入。
  • MergeOnReadLazyInsertIterable$MergeOnReadInsertHandler，主要處理MergeOnRead

表類型時的插入，其為CopyOnWriteInsertHandler的子類。

• CopyOnWriteLazyInsertIterable$UpdateHandler，主要處理CopyOnWrite表類型時的更新。

整個生產消費相關的類繼承結構非常清晰。

對於生產者的啟動，startProducers方法核心代碼如下

  public ExecutorCompletionService<Boolean> startProducers() {
    // Latch to control when and which producer thread will close the queue
    final CountDownLatch latch = new CountDownLatch(producers.size());
    final ExecutorCompletionService<Boolean> completionService =
        new ExecutorCompletionService<Boolean>(executorService);
    producers.stream().map(producer -> {
      return completionService.submit(() -> {
        try {
          preExecute();
          producer.produce(queue);
        } catch (Exception e) {
          logger.error("error producing records", e);
          queue.markAsFailed(e);
          throw e;
        } finally {
          synchronized (latch) {
            latch.countDown();
            if (latch.getCount() == 0) {
              // Mark production as done so that consumer will be able to exit
              queue.close();
            }
          }
        }
        return true;
      });
    }).collect(Collectors.toList());
    return completionService;
  }

該方法使用CountDownLatch來協調生產者線程與消費者線程的退出動作，然後調用produce方法開始生產，對於插入更新時的IteratorBasedQueueProducer而言，其核心代碼如下

  public void produce(BoundedInMemoryQueue<I, ?> queue) throws Exception {
    ...
    while (inputIterator.hasNext()) {
      queue.insertRecord(inputIterator.next());
    }
    ...
  }

可以看到只要迭代器還有記錄（可能為插入時的新記錄或者更新時的舊記錄），就會往隊列中不斷寫入。

對於消費者的啟動，startConsumer方法的核心代碼如下

  private Future<E> startConsumer() {
    return consumer.map(consumer -> {
      return executorService.submit(() -> {
        ...
        preExecute();
        try {
          E result = consumer.consume(queue);
          return result;
        } catch (Exception e) {
          queue.markAsFailed(e);
          throw e;
        }
      });
    }).orElse(CompletableFuture.completedFuture(null));
  }

消費時會先進行執行前的準備，然後開始消費，其中consume方法的核心代碼如下

  public O consume(BoundedInMemoryQueue<?, I> queue) throws Exception {
    Iterator<I> iterator = queue.iterator();

    while (iterator.hasNext()) {
      consumeOneRecord(iterator.next());
    }

    // Notifies done
    finish();

    return getResult();
  }

可以看到只要隊列中還有記錄，就可以獲取該記錄，然後調用不同BoundedInMemoryQueueConsumer子類的consumeOneRecord進行更新插入處理。

值得一提的是Hudi對隊列進行了流控，生產者不能無限制地將記錄寫入隊列中，隊列緩存的大小由用戶配置，隊列能放入記錄的條數由採樣的記錄大小和隊列緩存大小控制。

在生產時，會調用BoundedInMemoryQueue#insertRecord將記錄寫入隊列，其核心代碼如下

  public void insertRecord(I t) throws Exception {
    ...
    rateLimiter.acquire();
    // We are retrieving insert value in the record queueing thread to offload computation
    // around schema validation
    // and record creation to it.
    final O payload = transformFunction.apply(t);
    adjustBufferSizeIfNeeded(payload);
    queue.put(Option.of(payload));
  }

首先獲取一個許可(Semaphore)，未成功獲取會被阻塞直至成功獲取，然後獲取記錄的負載以便調整隊列，然後放入內部隊列（LinkedBlockingQueue）中，其中adjustBufferSizeIfNeeded方法的核心代碼如下

  private void adjustBufferSizeIfNeeded(final O payload) throws InterruptedException {
    if (this.samplingRecordCounter.incrementAndGet() % RECORD_SAMPLING_RATE != 0) {
      return;
    }

    final long recordSizeInBytes = payloadSizeEstimator.sizeEstimate(payload);
    final long newAvgRecordSizeInBytes =
        Math.max(1, (avgRecordSizeInBytes * numSamples + recordSizeInBytes) / (numSamples + 1));
    final int newRateLimit =
        (int) Math.min(RECORD_CACHING_LIMIT, Math.max(1, this.memoryLimit / newAvgRecordSizeInBytes));

    // If there is any change in number of records to cache then we will either release (if it increased) or acquire
    // (if it decreased) to adjust rate limiting to newly computed value.
    if (newRateLimit > currentRateLimit) {
      rateLimiter.release(newRateLimit - currentRateLimit);
    } else if (newRateLimit < currentRateLimit) {
      rateLimiter.acquire(currentRateLimit - newRateLimit);
    }
    currentRateLimit = newRateLimit;
    avgRecordSizeInBytes = newAvgRecordSizeInBytes;
    numSamples++;
  }

首先看是否已經達到採樣頻率，然後計算新的記錄平均大小和限流速率，如果新的限流速率大於當前速率，則可釋放一些許可（供阻塞的生產者獲取後繼續生產），否則需要獲取（回收）一些許可（許可變少後生產速率自然就降低了）。該操作可根據採樣的記錄大小動態調節速率，不至於在記錄負載太大和記錄負載太小時，放入同等個數，從而起到動態調節作用。

在消費時，會調用BoundedInMemoryQueue#readNextRecord讀取記錄，其核心代碼如下

  private Option<O> readNextRecord() {
    ...
    rateLimiter.release();
    Option<O> newRecord = Option.empty();
    while (expectMoreRecords()) {
      try {
        throwExceptionIfFailed();
        newRecord = queue.poll(RECORD_POLL_INTERVAL_SEC, TimeUnit.SECONDS);
        if (newRecord != null) {
          break;
        }
      } catch (InterruptedException e) {
        throw new HoodieException(e);
      }
    }
    ...

    if (newRecord != null && newRecord.isPresent()) {
      return newRecord;
    } else {
      // We are done reading all the records from internal iterator.
      this.isReadDone.set(true);
      return Option.empty();
    }
  }

可以看到首先會釋放一個許可，然後判斷是否還可以讀取記錄（還在生產或者停止生產但隊列不為空都可讀取），然後從內部隊列獲取記錄或返回。

上述便是生產者-消費者在Hudi中應用的分析。

總結

Hudi採用了生產者-消費者模型來控制記錄的處理，與傳統多生產者-多消費者模型不同的是，Hudi現在只支持多生產者-單消費者模型，單消費者意味着Hudi暫時不支持文件的併發寫入。而對於生產消費的隊列的實現，Hudi並未僅僅只是基於LinkedBlockingQueue，而是採用了更精細化的速率控制，保證速率會隨着記錄負載大小的變化和配置的隊列緩存大小而動態變化，這也降低了系統發生OOM的概率。

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

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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