新設計的“量子電池”將不會再丟失電荷

  科技日報北京 10 月 28 日電 (記者劉霞)據物理學家組織網近日報道,加拿大科學家為不漏電荷的新型量子電池設計出了“藍圖”,這種量子電池僅依靠量子力學原理工作,有望成為多種量子設備的重要組件,比如為量子計算機供電。

  這項研究主要作者之一、多倫多大學的化學家加布里埃爾·漢納解釋說:“量子電池是一種納米尺寸的電池,旨在用於納米級應用領域。我們更熟悉的電池,例如為智能手機供電的鋰離子電池,依賴經典的電化學原理工作;而量子電池僅依賴量子力學原理工作。”

  他說,這項研究從理論上證明,製造出電荷無損的量子電池是可能的,而此前提出的量子電池被認為是不可能的。

  在最新研究中,為了實現這種電荷無損的量子電池的想法,研究團隊將具有高度結構對稱性的開放式量子網絡模型作為存儲激子能量的平台,激子能量是电子吸收足夠高能的光子時所利用的能量。他們使用這種模型旨在證明,即使在開放環境下,也可以毫無損失地存儲能量。

  漢納說:“關鍵是要使這種量子網絡處於黑暗狀態。在黑暗狀態下,網絡無法與周圍環境交換能量。從本質上講,該系統不受環境影響,意味着電池幾乎不會有什麼能量損失。”

  研究人員還藉助該模型,提出了一種按需從電池中釋放儲能的通用方法。接下來,他們計劃探索對電池進行充放電的可行方法,以及如何擴大尺寸以便用於現實中。

  研究人員表示,這種量子電池有望成為多種量子設備的重要組件,例如為量子計算機供電。而且,科學家可以使用當前的固態技術來製造這種電池。

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

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

平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

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

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

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

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

為了孕育恆星,銀河系正在“變胖”

  眾所周知,如果一個人攝入的能量高於消耗的能量,身體就可能發胖,反之則會消瘦。測量人的體重增減只需一台秤而已。

  而浩瀚宇宙中的星系,特別是人類生存的銀河系,處於怎樣的變化之中,卻是困擾全球天文學家的重大難題。日前,一個由歐洲航天局天文學家安德魯·福克斯博士領銜的國際研究團隊在《天體物理學報》上撰文指出,銀河系吸入的氣體比呼出的氣體質量更大,處於“發胖”的過程中。

  那麼,銀河系的“呼吸”和質量變化背後有怎樣的奧秘?這種“發胖”將給銀河系帶來哪些影響?

  氣體物質交換 激活“一池春水”

  銀河系中不斷有氣體被“吹”出,但這些氣體還會重新被“吸”回,落到銀河繫上。這種“呼吸”意味着什麼?

  “這是恆星的誕生與死亡所帶來的氣體塵埃物質循環。”中國科學院上海天文台副研究員左文文在接受科技日報記者採訪時表示,恆星從銀盤中的氣體分子云中坍縮形成。恆星演化過程中的星風,以及大質量恆星演化到生命晚期發生的超新星爆炸,均會將大部分物質向外拋散,並向周圍的星際物質發射激波,形成一個由膨脹的氣體和塵埃構成的殼狀結構,即超新星遺迹。

  “恆星可視為源於塵埃,死亡時又歸於塵埃。”左文文說。

  恆星從生到死的整個生命周期成就了一次大尺度的搬運——將銀盤中的氣體塵埃物質向銀河系更外圍的銀暈中轉移。而且,恆星的一生積攢了大量的金屬元素。天文學中通常把比氦元素原子數大的元素均稱作金屬元素,這些金屬元素就像是一顆恆星兢兢業業地工作——努力地燃燒自己,奮鬥一輩子攢下的財富。它在日常生活中偶爾會“消費”,即通過星風現象拋出一部分物質;更多的是在大質量恆星走向滅亡的那一刻,它窮極一生積攢的“家當”,拋散四射,豐富了整個星系的元素組成,也點燃了下一代恆星生命起源的星星之火。

  隨着時間的推移,銀暈中的氣體塵埃物質會逐漸聚集在一起,重力將導致這些氣體團塊落回銀盤,開始下一輪恆星形成。

  恆星的死亡造就了新恆星的誕生,終點即是起點。周而復始,“向死而生”。銀河系也在無數個恆星的“獻祭”中完成了與周圍環境的氣體物質交換,就像一個湖泊,裏面是一池活水。

  高速分子云 標記“流動人口”

  那麼,銀河系這個大湖泊是在“漲水”還是在“泄水”?很多研究人員都想找到答案。

  此次研究給出的答案是前者,即氣體入流大於外流。

  該項研究利用哈勃太空望遠鏡的紫外波段數據,研究了 187 個高速分子云,根據吸收線相對於靜止參考系波長的移動,測定出它們在銀河系標準靜止參考系的速度,分類成入流的高速分子云和外流的高速分子云。通過計算,研究人員估計流入率為每年 0.53±0.17 倍太陽質量,流出率為每年 0.16±0.06 倍太陽質量,表明目前銀河系處在入流主導的時期。

  入流的氣體來源於哪裡?左文文指出,銀河系的引力有可能將部分星系際介質拖拽進來,也可能會從它的衛星星系拖拽一些氣體物質過來。

  科技日報記者注意到,該研究的主要對象是高速分子云。銀河系中氣體塵埃無數,為何研究人員單單瞄向了高速分子云?

  左文文提到,恆星與恆星之間有星際介質,星系與星系之間有星系際介質。星系並不是一個有着密閉邊界的系統。

  因此,沒有任何一種氣體會給自己主動貼上“外來者”或“本地人”的標籤。那麼,研究人員如何界定哪些氣體是外流或入流的“流動人口”?哪些又是銀河系內“長居”的“常住人口”?解決這些問題的切入點就是高速分子云。

  通常,銀盤中的“常住”氣體會與銀盤的旋轉速度一致。而高速分子云中氣體的移動速度要快於銀盤的旋轉速度,這意味着它們很可能就是入流或外流氣體的一種。再觀測分子云的速度走向,分析它是向著銀盤移動還是遠離銀盤移動,即可判斷該分子云是銀河系吸入的還是呼出的氣體。

  當然,也有學者指出,該研究忽略了本就存在於銀盤中的高速氣體結構,如費米氣泡等,這些銀盤中已有的結構無疑會給實驗帶來誤差。

  左文文也表示,該研究僅基於溫度較低(約 10000 開爾文)的氣體雲塊,給出的每年入流、外流的氣體質量均是下限,還需要有更多數據才能得到更確切的結果。

  呼吸的意義 調控恆星生命周期

  “恆星的形成會受到氣體入流與外流之間關係的調節。所以研究氣體循環過程,對於研究恆星形成、星系演化有很重要的作用。”左文文表示,銀河系是我們所居住的星系,擁有相對來說更豐富的觀測數據去研究氣體循環問題。

  也許很多人都會好奇,如果銀河系一直處於氣體入流多於外流的狀態,可能會怎樣?

  “內流多於外流,表明星系會累積更多的氣體。銀河系提供了恆星產生所需的原料——氣體、塵埃,有助於後續的恆星形成。”左文文表示,相反,如果星系中氣體外流一直多於內流,總有一天,恆星形成的原材料會損失殆盡,星系中便再沒有新恆星形成了。事實上,雖然入流和外流決定了一個星系是否會有持續的恆星形成,但還要關注兩者差距有多大以及這種情況持續時間有多長。

  2018 年日本東北大學的天文學家在《自然》雜誌撰文指出,銀河系在兩次恆星形成的“嬰兒潮”之間經歷了一個持續了數十億年的休眠期,實際上是在“死亡”后“復活”了,而這一現象與星系的氣體循環密不可分。

  根據這一研究,銀河系早期吸入大量寒冷氣體,開始形成第一代恆星。大約在 70 億年前,恆星坍塌爆炸產生的衝擊波將星系內氣體加熱到高溫。這導致寒冷氣體停止流入銀河系,恆星的形成也隨之停止。隨着時間的推移,銀河系的高溫氣體逐漸輻射冷卻,並在 50 億年前開始吸入新的寒冷氣體。這導致了包括太陽在內的第二代恆星的形成。更重要的是,其他研究表明,銀河系的鄰居“仙女座”星系可能也經歷過類似的歷程。這表明大質量的旋渦星系往往會出現形成恆星的“休眠期”,而較小的星系則不會。

  事實上,星系“呼吸”的概念也適用於恆星甚至行星等宇宙中更小的系統。相比銀河系的“增重”,太陽和地球都在減重。根據美國國家航空航天局(NASA)和麻省理工學院的研究,太陽每年喪失 1324.5 萬億噸的質量,地球每年減輕 1 到 5 萬噸。

  正如今日宇宙(Universe Today)網站所寫:“無論我們談論的是行星、恆星還是星系,它們都在經歷出生、生存和死亡。在這期間,他們或許會增重或減重幾磅。生命的循環,便在宇宙的尺度上展開。”

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

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

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

MSP、CMP 面對“多雲”最大挑戰是:網絡

  新的基於雲的應用程序和 IT 服務迅猛發展,導致市場上的多樣性與日俱增,而多雲早已成為現實。此外,對連接和帶寬的巨大需求常常將現有的網絡基礎設施和運營推向極限。一方面,這給服務提供商帶來了重大挑戰,它們需要及時跟上加快發展的步伐。另一方面,這也提供了獲得競爭優勢的機會。

  然而,服務提供商需要使用業界最佳的創新的業務增強解決方案,以便更靈活地應對市場需求,同時提高效率和安全性。眼下,基於軟件的方法發揮重要作用,讓企業可以基於智能網絡以及分析工具和高度自動化的流程帶來的更佳可見性,迅速高效地應對新的需求,併為複雜、廣泛分佈的基礎設施提供連接性、安全性和可管理性。

  正是在這種背景下,瞻博網絡提供 Tungsten Fabric 開源產品和 Contrail 商業版解決方案,擁有 SDN 功能的管理和控制軟件,以簡化服務交付。

  Contrail 的起源

  早在 2012 年,瞻博網絡收購了 Contrail Systems,在軟件定義網絡(SDN)方面邁出了一大步。Contrail 在 SDN 熱潮的早期階段顛覆了市場,因為它引入了網絡即服務理念,通過面向虛擬環境和物理環境的單一管理平台加以抽取。

  收購 Contrail Systems 一年後的 2013 年底,瞻博網絡將其 Contrail Networking 軟件作為官方商業產品來提供,同時還提供全面的商業支持服務。

  與此同時,瞻博還開源了 Contrail 技術,採用 Apache 2.0 許可證的這項技術名為 OpenContrail。將 Contrail 技術回饋開源社區讓開發人員有機會為該項目做出貢獻,並使服務提供商和企業能夠根據自身的具體要求靈活地調整 Contrail。

  Tungsten Fabric——OpenContrail 遷移到 Linux 基金會

  2018 年 3 月,瞻博網絡向前又邁出了一步,將 OpenContrail(開源項目)遷移到了 Linux 基金會,使其更加“開放”。此舉對該項目來說是根本性變化,因為這意味着 Linux 基金會現在是所有者。在這種背景下,這個開源項目有了一個新名稱:Tungsten Fabric,這還有助於更好地區分開源項目和瞻博網絡的商業產品線。

  在 2019 年 9 月,雲頭條與瞻博網絡中國區企業事業部總經理恭弘=叶 恭弘勇、瞻博網絡中國區創新和架構部架構師李錦勛進行了深入的溝通,探討 Tungsten Fabric。

  面對 IT 行業變化和多雲市場的需求,Tungsten Fabric 的價值是什麼?瞻博網絡中國區企業事業部總經理恭弘=叶 恭弘勇表示:

“在多雲時代,我們看到了眾多合作夥伴的轉型,他們從傳統集成商向新一代集成商(MSP)轉型,最複雜、最難做的是解決雲管平台(CMP)的網絡問題。 這樣的話,正好瞻博網絡在這方面積累了很多經驗。 他們選擇了 Tungsten Fabric 開源解決方案,甚至從開源解決方案認識到了我們的商業產品,並且購買。對於多雲市場需求來講,我們認為它是相當重要的一個組件,而且贏得用戶好評。“

  對此雲頭條提了五個問題,以下為詳細回復,供各位參考~

  Tungsten Fabric 為 CMP、MSP 解決了什麼問題?

  CMP 是 MSP 的核心業務產品,也帶給 MSP 最核心的競爭力。而 CMP 通常體系架構複雜,內容龐雜。在 CMP 的基礎設施管理模塊中,包括了計算、存儲和網絡等部分。相對而言,這幾個部分中最為複雜的是網絡部分。因為,計算和存儲的技術和協議較為統一,頭部廠商相對集中,並且存儲和計算資源在企業長期發展的產品更新過程中,與業務相對獨立。而網絡技術歷史悠久,協議眾多,分支龐雜,並且在實際業務中,與業務緊耦合,技術對業務的運行影響巨大。因此,CMP 中,關於網絡部分的解決方案也最為複雜。Tungsten Fabric 的出現,則可以減輕 MSP 對於網絡部分的研發技術投入,使 CMP 可以集中精力做好業務上層部分,關注業務的服務管理能力。利用 Tungsten Fabric 的開放性,CMP 可以較為容易地實現多廠家的網絡設備的管理和整合。

  簡而言之,Tungsten Fabric 在技術上和商業上為 CMP 和 MSP 解決的問題如下。

  技術:

  • 利用 TF 強大的網絡業務能力,改善 CMP 的網絡業務性能和體驗
  • 利用 TF 支持任意的 Underlay,使 CMP 可以適應任何網絡環境,無需強迫客戶在進行業務雲化或者雲管理時變更網絡的設計,加速了 CMP 的實施。
  • 利用 TF 的開放性為 CMP 的網絡管理帶來開放性,使 CMP 支持多廠家網絡資源管理
  • 利用 TF 提供豐富的網絡安全功能,不僅僅實現 CMP 平台上多租戶的業務隔離,還可以利用 NFV 功能實現傳統網絡和虛擬化網絡之間的安全隔離

  商業:

  • 降低 CMP 的開發成本,利用社區所提供的技術和資源實現快速的 CMP 網絡管理部分開發
  • 加速 CMP 的研發速度,降低 MSP 在網絡層研發投入,使 MSP 可以更多投入到業務管理層
  • 利用 TF 帶來的開放性和開源屬性,增強 CMP 在業務上對客戶的吸引力

  Tungsten Fabric 是瞻博網絡平台與設備解耦的重要一步。與 Tungsten Fabric 的開放和開源相對,市場上目前的其他網絡廠商提供或者參与的 CMP 平台,由於網絡功能部分要深度綁定廠商自己的網絡產品,無法解耦,導致整個 CMP 從開放系統轉換為封閉系統,這種網絡層的封閉的生態鏈對客戶形成綁定,消除客戶的自由選擇機會,實現最大化廠商利益。這類 CMP 通常不提供或者僅提供一小部分接口給第三方開發者,從而使其他 MSP 難以將其集成到自己的 CMP 中,難以形成開放的生態和對第三方產品的支持。

  客戶一旦選擇了這樣的 CMP 或者組件,則會被封閉到廠商自己把控的圈子內,未來難以離開廠商的控制範圍。從這個層面向上看,則可以視為是客戶的自主可控策略的失敗。對於客戶而言,自主可控的本質是可以訪問源代碼、具有自主知識產權和可以獨立服務和開發,一旦選擇了這樣的封閉系統,客戶將失去對自有雲架構的把控,完全受制於人。而 Tungsten Fabric 則通過開源實現了平台和設備的解耦,帶給開放者和客戶自由,使客戶真正可以實現對雲架構的自主可控,這正是 Tungsten Fabric 真正的魅力。

  瞻博網絡一直在倡導網絡設備的軟硬件解耦,近期瞻博網絡在自己的交換機產品線逐步開始支持開放網絡操作系統 SONiC,客戶可以從瞻博網絡購買硬件平台來運行 SONiC 系統。同時,瞻博網絡為 SONiC 系統和服務器環境提供了基於容器技術的商業 cRPD 路由協議棧,實現了 Junos 路由協議棧的跨平台部署。通過這些手段,瞻博網絡提供全棧解耦,從網絡設備的軟硬件解耦,到整個網絡層通過 TF 來實現全面解耦。

  Tungsten Fabric 僅僅是瞻博網絡構建全面開放的多雲架構解決方案的一部分。瞻博網絡的目標是提供多雲環境下,最開放、最強大和最全面的軟件定義網絡解決方案,消除客戶在轉向多雲業務的過程中的疑慮,實現用戶選擇的簡化,實現“精研至簡”的願景。

  Tungsten Fabric 與同類的開源解決方案 OpenDayLight 的區別 ?

  從本質上來說都是開源系統,OpenDayLight 是一個開放的模塊化平台架構,不是指具體某一款產品,一般是基於 OpenDayLight 平台再去開放需要的功能,OpenDayLight 聚焦在網絡和服務等比較寬泛的層面。Tungsten Fabric 則是從網絡一直延伸到業務層面,Tungsten Fabric 更加專註於為複雜的多棧多雲網絡提供統一的網絡和安全架構的解決方案。

  相比 OpenDayLight,Tungsten Fabric 明顯區別如下:

  • 具有廣泛的支持性,支持使用不同編排平台(Kubernetes, Mesos/SMACK, OpenShift, OpenStackand VMware 等)編排不同類型的工作負載(虛擬機、容器、裸機),提供了一致的網絡功能和安全策略。
  • 統一性,具有插件支持 CNI、Neutron 或者 vSphere
  • 具備豐富的網絡和安全功能,改變了原有 SDN 注重軟件和編排,而忽視網絡功能和特性的狀態。在功能上支持 EVPN、VXLAN、ECMP、狀態防火牆、七層負載均衡、BGPaaS,服務鏈、應用層策略、基於標籤的終端分組、流量可視化、下一代防火牆卸載、IPSec 等。
  • 提供高性能的網絡能力。Tungsten Fabric 具有專門優化的 vRouter,具備與硬件路由器相似的數據包轉發機制,提供無與倫比的高轉發性能,滿足現代超大規模雲網絡需求。
  • 可擴展能力,利用分佈式架構支持超大規模數節點的部署,支持雲網絡無限延展海量的 VN 網絡。

  Tungsten Fabric(開源版) 與 CONTRAIL (商業版)的區別?

  Tungsten Fabric 和 Contrail 共享代碼,在網絡和安全方面功能是一致的。Tungsten Fabric 缺乏 CEM 中的 AppFormix 套件。AppFormix 提供服務器、中間件、Openstack 等軟件的性能監控功能。此外,Juniper 為 Contrail 提供專業的軟件服務,而 Tungsten Fabric 只能通過社區獲得服務和支持。

  選擇 Tungsten Fabric 具體案例

  TF/Contrail 推出以來,在全球得到了廣泛的關注和使用。從客戶覆蓋範圍來說,客戶群包括以下幾類:

  • 電信運營商:AT&T、Verizon、NTTCom 等。
  • 雲業務供應商:XON-Wingu、TCP Cloud 等。
  • 大型企業:eBay、Symantec、OrangeBusiness Service、Riot Games、中國某大型金融客戶等。

  這些企業的主要應用場景可以分為以下幾種:

  典型客戶:workday

  • 為 SaaS 提供大規模的網絡安全支持
  • 需求:清晰的租戶隔離;高性能的 OpenStack Neutron 替代;為任意的 Underlay 架構提供 Overlay 業務;不進行廠商鎖定;支持多種部署模式下的 Overlay
  • TF/Contrail 的價值:安全的多租戶隔離;超大規模網絡支持;標準和成熟的協議;支持異構計算環境

  典型客戶:Riot Games

  • 為容器化的 SaaS 提供多租戶雲環境
  • 需求:支持快速發展的雲業務;支持多租戶自服務的開發測試雲;提供容器化網絡的安全、多租戶支持;與客戶定製的編排系統集成;支持多雲環境(本地化和 AWS);支持服務鏈
  • TF/Contrail 的價值:支持容器化網絡、支持多雲、可以作為統一的虛擬化網絡和安全層;;與定製的編排系統集成

  典型客戶:TCP Cloud

  • 為 IaaS 環境的私有雲提供高性能支撐
  • 需求:提供對任意 Underlay 網絡的支持;不進行廠商鎖定;敏捷和靈活;支持對 overlay 和 underlay 的連接;對租戶清晰地隔離
  • TF/Contrail 的價值:標準和成熟度的協議;支持對傳統和虛擬化的環境的連接;大規模改善現有的網關的性能;安全的多租戶支持

  典型客戶:賽門鐵克

  • 敏捷的 IaaS 雲支持
  • 需求:敏捷的 DevOps 環境;降低人工干預/避免錯誤;提供任意 Underlay 下的 Overlay;清晰的租戶隔離
  • TF/Contrail 的價值:提供按需橫向擴展的網絡服務;提供自動化的網絡部署;大規模提高現有網關的 ROI;安全的多租戶隔離

 

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

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

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

PHP 7 的 PHP-FPM 存在遠程代碼執行漏洞

  據外媒 ZDNet 的報道,PHP 7.x 中最近修復的一個遠程代碼執行漏洞正被惡意利用,並會導致攻擊者控制服務器。編號為 CVE-2019-11043 的漏洞允許攻擊者通過向目標服務器發送特製的 URL,即可在存在漏洞的服務器上執行命令。漏洞利用的 PoC 代碼也已在 GitHub 上發布

  一旦確定了易受攻擊的目標,攻擊者便可以通過在 URL 中附加 ‘?a=’ 以發送特製請求到易受攻擊的 Web 服務器。

  僅 NGINX 服務器受影響

  幸運的是,並非所有的 PHP Web 服務器都受到影響。據介紹,僅啟用了 PHP-FPM 的 NGINX 服務器容易受到攻擊。PHP-FPM 代表 FastCGI Process Manager,是具有某些附加功能的 PHP FastCGI 替代實現。它不是 nginx 的標準組件,但部分 Web 託管商仍會將其作為標準 PHP 託管環境的一部分。

  Web 託管商 Nextcloud 就是其中一個例子,該公司於 10 月 24 日向其客戶發出安全警告,督促客戶將 PHP 更新至最新版本 7. 3.11 和 7. 2.24,其中包含針對 CVE-2019-11043 漏洞的修復程序。另外,許多其他虛擬主機供應商也被懷疑正在運行易受攻擊的 nginx + PHP-FPM 組合。

  但是也有一些網站由於技術限制而無法更新 PHP,或無法從 PHP-FPM 切換到另一個 CGI 處理器。

  修復建議

  關於漏洞的詳細分析可查看 https://paper.seebug.org/1063/

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

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

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

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

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

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

中國首家赴美上市的AI和區塊鏈芯片巨頭誕生

  2019 年是比特幣礦機芯片殺戮江湖的世紀分水嶺。經歷 2018 年幣價大崩盤,直到 2019 年第二季價格回升,各方才獲得些許的喘息空間。但刻不容緩地,礦機大廠立刻加入下一輪逐鹿資本市場的戰役,這一役,堪稱是攸關生死。

  2019 年中,陸續傳來多家比特幣礦機芯片巨頭計劃赴美掛牌的消息,雖然官方都未證實,但業界心裏有數,這一波能成功敲開資本市場大門者,不但可以繼續主宰幣界的挖礦世界,更將獲得充沛的資金動能去挖掘另一大金礦:AI 芯片。

  10 月 29 日這一天,嘉楠 Canaan 傳來好消息,已向美國納斯達克遞交招股書,目標是通過公開上市籌資不超過 4 億美元,即將成為中國第一家敲開美納斯達克大門的比特幣礦機大廠,問鼎“比特幣礦機第一股”的頭銜。


圖:DeepTech

  一、入選台積電 7nm 首批戰略合作夥伴 

  自 2015 年初以來,嘉楠就與台積電達成了合作,並形成了可信賴、穩定和互利的合作夥伴關係。嘉楠也被台積電選為 7nm ASIC 的首批合作夥伴之一,显示了嘉楠作為全球頂級 IC 設計公司的地位。如今嘉楠已經成為全球第二大比特幣礦機設計商和製造商,離不開台積電這樣的巨頭合作與支持。 

  在比特幣礦機芯片領域中站穩腳步后,布局 AI 芯片領域,是每一家礦機巨頭必然的下一步轉型,以及技術的延伸。 

  嘉楠也在 2018 年 9 月基於 RISC-V 開放架構設計出第一代的邊緣計算(Edge-Computing)AI 芯片:勘智 K210,是嘉楠第一代內置卷積神經網絡加速器的 SoC 級 AI 芯片產品。 

  嘉楠在招股書中披露,從 2015 年 6 月至今共完成 7 顆礦機 ASIC 芯片,涵蓋台積電的 28nm、16nm、7nm 等歷代最先進的工藝技術,歷年工藝技術的進展如下: 

  2015 年 28nm 的 ASIC 芯片量產,是當時最早使用 28nm 工藝的設計業者之一 

  2016 年第一代 16nm 的 ASIC 量產,是當時在區塊鏈相關 ASIC 領域上,最早使用當時最先進的第一代 16nm 者 

  2017 年第二代 16nm 的 ASIC 的量產 

  2018 年第三代 16nm ASIC 的量產 

  2019 年第四代 16nm ASIC 的量產 

  2018 年 4 月推出第一代 7nm 的 ASIC,2018 年 8 月於台積電 12 寸廠內生產。 

  2019 年 6 月推出 8nm 的 ASIC 在 2019 年 9 月投入量產。 

  2019 年 10 月 25 日嘉楠在美國納斯達克遞交招股書,即將敲開美國資本市場大門,成為中國第一家赴美掛牌的比特幣礦機大廠,而這一步,得來不易。


圖:DeepTech 

  二、幣圈無人不知的“南瓜張” 

  提到嘉楠,就不能不提幣圈界無人不知曉的“南瓜張”,他是嘉楠的董事長兼首席執行官張楠賡。 

  與臉書創辦人馬克·扎克伯格、微軟創辦人比爾·蓋茨一樣,2012 年正在北京航空航天大學攻讀計算機專業博士的張楠賡,為了捍衛自己痴迷的比特幣世界,要專心研發 ASIC 礦機芯片技術,做出了退學的決定。 

  提到比特幣和幣圈,不諱言“比特大陸“、“吳忌寒”的名字非常活躍,且廣受市場熱議。相形之下,嘉楠的公司文化,以及張楠賡的個人形象一直非常低調,圈內人總是以“技術情懷”、“宅男”來形容這個團隊。 

  “阿瓦隆”(Avalon),是全球第一台採用 ASIC 芯片的比特幣礦機,就是南瓜張耗盡心血研發的,因而開啟了 ASIC 百家爭鳴的時代,為了增強算力,芯片工藝從 110nm 、55nm、28nm、16nm、7nm 等一代代演進下去。 

  在 ASIC 芯片問世之前,比特幣挖礦最早是用 CPU,只要用家裡的個人計算機就可以參与這個奇幻的虛擬数字貨幣世界,但隨着礦工數量的快速成長,一般 CPU 逐漸難以追上較複雜的挖礦算法。 

  2010 年開始有人用個人 GPU 挖礦,但沒多久,比特幣價格的瘋狂成長再度推進了挖礦的技術。

  2011 年初比特幣價格首次突破 1 美元,到 6 月份更成長到 30 美元,為了追求更強的算力和挖礦速度,全球第一台用 FPGA 挖礦的產品問世。 

  一直到 2013 年,南瓜張成功推出全球第一台 ASIC 礦機“阿瓦隆” ,由於起初的數量不多,甚至被市場炒高到一台要價 25 萬人民幣,還是很多人捧着現金排隊等售。這也開啟了 ASIC 芯片礦機的風潮,接着,2013 年 4 月“嘉楠”這家公司誕生於世。 

  其實,當時阿瓦隆推出后,很快追上來的是幣圈有名的“烤貓”傳奇。2013 年下半烤貓礦機有多款 ASIC 芯片問世,讓阿瓦隆、烤貓快速成為當時兩大礦機霸主。 只是,烤貓礦機因為下一代的技術研發掉隊,成為快速崛起但也迅速隕落的一代“烤貓傳奇”。 

  且在 2013 年底比特幣監管機制陸續來臨,也帶來一陣產業寒冬導致礦機市場需求迅速降溫,存活下來的大廠以嘉楠和比特大陸為首。長期醉心研發的嘉楠有技術實力做壁壘,成功熬過產業寒冬,但因為較晚進入礦機市場,這塊領域被比特大陸搶了先機。 

  在那之後的比特幣江湖,不斷經歷風雨、寒冬、挑戰、機會、嘗試、轉型,來到了 2019 年,迎面而來的是另一個實力之爭的分水嶺契機,那就是問鼎資本市場。 

  嘉楠即將闖關美國資本市場,雖然對手比特大陸也同樣傳出要在美上市,但比特大陸這一年動蕩劇烈,公司各種傳言紛紛,且礦機芯片新秀四起,產業又將面臨另一番挑戰。 

  10 月 24 日下午,中共中央政治局就區塊鏈技術發展現狀和趨勢進行第十八次集體學習。習近平總書記在主持學習時強調,區塊鏈技術的集成應用在新的技術革新和產業變革中起着重要作用。我們要把區塊鏈作為核心技術自主創新的重要突破口,明確主攻方向,加大投入力度,着力攻克一批關鍵核心技術,加快推動區塊鏈技術和產業創新發展。 

  這意味着區塊鏈技術正式成為國家級產業,也是中央對於整個科技領域自主創新的高度重視。 自從新華社發布消息后,美股、港股、A股等資本市場的區塊鏈概念股被資本熱捧。 

  作為全球第二大礦機廠商,一旦上市成功,嘉楠 Canaan 也將成為真正意義上的“全球區塊鏈第一股”,將引領中國區塊鏈行業佔據創新制高點、取得產業新優勢。


圖:DeepTech

  三、AI 芯片轉型之路 

  比特幣礦機是嘉楠的“根”,為了讓公司營運更為健康,也积極朝 AI 芯片轉型,提供整體 AI 解決方案,包括 AI 芯片、算法開發和優化,一直延伸至硬件模塊,最終產品和軟件服務。 

  2018 年 9 月嘉楠推出基於 RISC-V 架構的商用邊緣計算第一代 AI 芯片:勘智 K210,內置卷積神經網絡加速器的 SoC 級 AI 芯片。 

  嘉楠認為,物聯網技術的飛速發展為 AI 芯片帶來巨大的需求,未來 AI 應用場景中,很多都是交給邊緣設備來進行推理和計算。 

  如果計算推理需求能直接在邊緣設備端執行完成,不用將數據丟回雲端,將大幅減少網絡傳輸的處理時間和帶寬成本,也因此,邊緣設備必須具有足夠的推理計算能力,也就是要更為智能化。 

  當中,商業智能和生活智能會是兩個關鍵領域,有望成為 AI 領域的推動力。根據統計,商業智能和生活智能領域的市場份額分別在 2018 年占 AI 垂直產業的 8.3% 和 19.9%,預計到 2023 年將分別增長到 15.9% 和 26.1%。 商業智能包括智能建築,智能零售、智能工業應用。舉例而言,智能建築是 AI 技術與信息技術的結合,像是門禁控制系統、智能門鎖和智能抄表等。 

  對於智能零售,企業可以將 AI 技術用於分析目的,以實現銷售增長,像是在商店中部署智能傳感器,為消費者客制化針對性的購買信息,或是以 AI 幫助商家識別和跟蹤每個單獨的物品,以實現更好的庫存管理。 

  根據 Frost&Sullivan 的數據,2018 年中國商業智能的市場規模為 9.706 億人民幣,預計 2023 年將增長至人民幣 296 億元,年複合增長率為 98.1%。 另一個關鍵應用領域是生活智能,讓用戶可以遠程和本地控制各種智能設備,例如空調、廚房電器、智能玩具等。 

  根據 Frost&Sullivan 統計,2018 年中國生活智能市場規模為 23 億元人民幣,預計到 2023 年將以 84.1% 的年複合增長率增長至 487 億元人民幣。 嘉楠 2017 年營收為 13.081 億元人民幣,2018 年成長至 27.053 億元人民幣,年增幅達 106.8%。未來比特幣礦機和 AI 會是嘉楠在營運上的兩條腿,齊力並進。 

  在比特幣礦機業務上,經歷 2018 年比特幣價格大幅下跌,從 2019 年第二季度開始出現了一定程度的回升,因為比特幣價格將直接影響到礦機的市場需求和價格,公司看好此一回升趨勢將繼續下去,帶動業績升溫。 

  在 AI 產品線的前景上,會專註於邊緣計算,包括智能零售和智能駕駛領域的應用,並在 2020 年連續推出第二代和第三代的 AI 芯片產品。 

  嘉楠指出,目前正在開發 28nm 工藝的第二代 AI 芯片產品,提升算力和能效,計劃在 2020 年第一季度開始量產。 

  緊接着,2020 年下半年推出第三代的 AI 芯片,將導入 12nm 製程技術,該產品會適用於邊緣和雲計算,長期的計劃是希望比特幣礦機業務和 AI 芯片業務上實現更平衡的組合。 

  再者,嘉楠也計劃利用 AI 芯片作為核心硬件,創建一個 AI SaaS 平台,為終端客戶提供整合硬件、算法和軟件的整體人工智能服務,目標是建立一個完整、開放的生態系統。 

  舉例而言,為了促進智能門鎖的應用,將低成本、高性能的 AI SoC 與不同的算法結合在一起,並提供有條件的訪問服務,客戶不用擔心底層的基礎設施,且通過 AI SaaS 平台也可以提供數據分析。 

  再者,嘉楠也計劃擴大海外業務,在全球多個國家設立海外辦事處,擴大海外的客戶群。

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

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

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

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

※帶您來看台北網站建置台北網頁設計,各種案例分享

中國動力電池技術突破,2025 年電動車成本效益比料勝燃油車

 

21 世紀經濟報導,中國電動汽車百人會理事長陳清泰表示,過去一年,中國電動汽車產業正在向高品質發輾轉型,發展形勢良好;而電動汽車再往前發展要跨越一個臨界點,就是電動車的成本效益比達到和超過燃油車,他預期這個臨界點會可能會在 2025 年前後出現。   中國 2017 年新能源汽車銷量目標 70 萬輛,去年 1 到 11 月累計銷售 60.9 萬輛、年增 51.4%。專家預測,中國去年新能源汽車總銷量可能超過 80 萬輛。中國汽車工業協會秘書長助理許海東日前表示,中國去年新能源汽車 70 萬輛銷量目標應可達成,2018 年新能源車銷量增速仍可保持 40% 至 50%,預期銷量將超過 100 萬輛。   陳清泰指出,電動汽車再往前發展要跨越一個臨界點,就是電動車的成本效益比達到和超過燃油車,如果跨過了這個門檻,電動車就可依託市場力量自主發展了,目前仍需靠政策、靠政府補貼。他亦預期,當財政補貼完全取消後,雙積分政策作為替代政策,新能源汽車積分比例將在 2020 年 12% 的基礎上繼續上調。   對於上述臨界點會出現在什麼時候?陳清泰的判斷是,大約在 2025 年前後。對此,他建議中國車企要在以下幾個方面做好準備,首先是在財政補貼退坡之後,做好可持續發展的保障工作,另外電動車自身要透過輕量化、節能化提高成本效益比;其次,產品技術要雙線作戰,其中一條戰線是完善汽車的行駛功能,另一條戰線則是將車聯網和共享化應用到新能源汽車上;第三,自動駕駛是爭奪未來的一個重點;第四,在有限的時間要加緊做品牌建設。   中國電動汽車百人會執行副理事長歐陽明高表示,2017 年中國動力電池技術已取得實質性進展,動力電池系統能量密度已達到 150 瓦時/公斤甚至以上,鋰離子動力電池單體比能量有望於 2020 年前實現 300 瓦時/公斤目標。   他進一步指出,2025 年,具備一般成本效益比的純電動轎車合理的里程是 300 到 400 公里;但 2030 年,最大的技術突破將體現在電解質上,固態電池會規模產業化,電池單體比能量可望觸及 500 瓦時/公斤;2030 年常規的成本效益比車型,續航里程應該可達到 500 公里以上。   (本文內容由授權使用。首圖來源:)

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

【其他文章推薦】

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

平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

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

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

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

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

一文帶你深入了解 redis 複製技術及主從架構

主從架構可以說是互聯網必備的架構了,第一是為了保證服務的高可用,第二是為了實現讀寫分離,你可能熟悉我們常用的 MySQL 數據庫的主從架構,對於我們 redis 來說也不意外,redis 數據庫也有各種各樣的主從架構方式,在主從架構中會涉及到主節點與從節點之間的數據同步,這個數據同步的過程在 redis 中叫做複製,這在篇文章中,我們詳細的聊一聊 redis 的複製技術和主從架構 ,本文主要有以下內容:

  • 主從架構環境搭建
    • 主從架構的建立方式
    • 主從架構的斷開
  • 複製技術的原理
    • 數據同步過程
    • 心跳檢測
  • 主從拓撲架構
    • 一主一從
    • 一主多從
    • 樹狀結構

主從環境搭建

redis 的實例在默認的情況下都是主節點,所以我們需要修改一些配置來搭建主從架構,redis 的主從架構搭建還是比較簡單的,redis 提供了三種方式來搭建主從架構,在後面我們將就介紹,在介紹之前我們要先了解主從架構的特性:在主從架構中有一個主節點(master)和最少一個從節點(slave),並且數據複製是單向的,只能從主節點複製到從節點,不能由從節點到主節點。

主從架構的建立方式

主從架構的建立有以下三種方式:

  • 在 Redis.conf 配置文件中加入 slaveof {masterHost} {masterPort} 命令,隨 Redis 實例的啟動生效
  • 在 redis-server 啟動命令后加入 –slaveof {masterHost} {masterPort} 參數
  • 在 redis-cli 交互窗口下直接使用命令:slaveof {masterHost} {masterPort}

上面三種方式都可以搭建 Redis 主從架構,我們以第一種方式來演示,其他兩種方式自行嘗試,由於是演示,所以就在本地啟動兩個 Redis 實例,並不在多台機器上啟動 redis 的實例了,我們準備一個端口 6379 的主節點實例,準備一個端口 6480 從節點的實例,端口 6480 的 redis 實例配置文件取名為 6480.conf 並且在裏面添加 slaveof 語句,在配置文件最後加入如下一條語句

slaveof 127.0.0.1 6379

分別啟動兩個 redis 實例,啟動之後他們會自動建立主從關係,關於這背後的原理,我們後面在詳細的聊一聊,先來驗證一下我們的主從架構是否搭建成功,我們先在 6379 master 節點上新增一條數據:

然後再 6480 slave 節點上獲取該數據:

可以看出我們在 slave 節點上已經成功的獲取到了在 master 節點新增的值,說明主從架構已經搭建成功了,我們使用 info replication 命令來查看兩個節點的信息,先來看看主節點的信息

可以看出 6379 端口的實例 role 為 master,有一個正在連接的實例,還有其他運行的信息,我們再來看看 6480 端口的 redis 實例信息

可以看出兩個節點之間相互記錄著對象的信息,這些信息在數據複製時候將會用到。在這裡有一點需要說明一下,默認情況下 slave 節點是只讀的,並不支持寫入,也不建議開啟寫入,我們可以驗證一下,在 6480 實例上寫入一條數據

127.0.0.1:6480> set x 3
(error) READONLY You can't write against a read only replica.
127.0.0.1:6480> 

提示只讀,並不支持寫入操作,當然我們也可以修改該配置,在配置文件中 replica-read-only yes 配置項就是用來控制從服務器只讀的,為什麼只能只讀?因為我們知道複製是單向的,數據只能由 master 到 slave 節點,如果在 salve 節點上開啟寫入的話,那麼修改了 slave 節點的數據, master 節點是感知不到的,slave 節點的數據並不能複製到 master 節點上,這樣就會造成數據不一致的情況,所以建議 slave 節點只讀

主從架構的斷開

主從架構的斷開同樣是 slaveof 命令,在從節點上執行 slaveof no one 命令就可以與主節點斷開追隨關係,我們在 6480 節點上執行 slaveof no one 命令

127.0.0.1:6480> slaveof no one
OK
127.0.0.1:6480> info replication
# Replication
role:master
connected_slaves:0
master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0
master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27
master_repl_offset:4367
second_repl_offset:4368
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:4367
127.0.0.1:6480> 

執行完 slaveof no one 命令之後,6480 節點的角色立馬恢復成了 master ,我們再來看看時候還和 6379 實例連接在一起,我們在 6379 節點上新增一個 key-value

127.0.0.1:6379> set y 3
OK

在 6480 節點上 get y

127.0.0.1:6480> get y
(nil)
127.0.0.1:6480> 

在 6480 節點上獲取不到 y ,因為 6480 節點已經跟 6379 節點斷開的聯繫,不存在主從關係了,slaveof 命令不僅能夠斷開連接,還能切換主服務器,使用命令為 slaveof {newMasterIp} {newMasterPort},我們讓 6379 成為 6480 的從節點, 在 6379 節點上執行 slaveof 127.0.0.1 6480 命令,我們在來看看 6379 的 info replication

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6480
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:4367
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:4367
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:4368
repl_backlog_histlen:0
127.0.0.1:6379> 

6379 節點的角色已經是 slave 了,並且主節點的是 6480 ,我們可以再看看 6480 節點的 info replication

127.0.0.1:6480> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=4479,lag=1
master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea
master_replid2:a54f3ba841c67762d6c1e33456c97b94c62f6ac0
master_repl_offset:4479
second_repl_offset:4368
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:4479
127.0.0.1:6480> 

在 6480 節點上有 6379 從節點的信息,可以看出 slaveof 命令已經幫我們完成了主服務器的切換。

複製技術的原理

redis 的主從架構好像很簡單一樣,我們就執行了一條命令就成功搭建了主從架構,並且數據複製也沒有問題,使用起來確實簡單,但是這背後 redis 還是幫我們做了很多的事情,比如主從服務器之間的數據同步、主從服務器的狀態檢測等,這背後 redis 是如何實現的呢?接下來我們就一起看看

數據複製原理

我們執行完 slaveof 命令之後,我們的主從關係就建立好了,在這個過程中, master 服務器與 slave 服務器之間需要經歷多個步驟,如下圖所示:

slaveof 命令背後,主從服務器大致經歷了七步,其中權限驗證這一步不是必須的,為了能夠更好的理解這些步驟,就以我們上面搭建的 redis 實例為例來詳細聊一聊各步驟。

1、保存主節點信息

在 6480 的客戶端向 6480 節點服務器發送 slaveof 127.0.0.1 6379 命令時,我們會立馬得到一個 OK

127.0.0.1:6480> slaveof 127.0.0.1 6379
OK
127.0.0.1:6480> 

這時候數據複製工作並沒有開始,數據複製工作是在返回 OK 之後才開始執行的,這時候 6480 從節點做的事情是將給定的主服務器 IP 地址 127.0.0.1 以及端口 6379 保存到服務器狀態的 masterhost 屬性和 masterport 屬性裏面

2、建立 socket 連接

在 slaveof 命令執行完之後,從服務器會根據命令設置的 IP 地址和端口,跟主服務器創建套接字連接, 如果從服務器能夠跟主服務器成功的建立 socket 連接,那麼從服務器將會為這個 socket 關聯一個專門用於處理複製工作的文件事件處理器,這個處理器將負責後續的複製工作,比如接受全量複製的 RDB 文件以及服務器傳來的寫命令。同樣主服務器在接受從服務器的 socket 連接之後,將為該 socket 創建一個客戶端狀態,這時候的從服務器同時具有服務器和客戶端兩個身份,從服務器可以向主服務器發送命令請求而主服務器則會向從服務器返回命令回復。

3、發送 ping 命令

從服務器與主服務器連接成功后,做的第一件事情就是向主服務器發送一個 ping 命令,發送 ping 命令主要有以下目的:

  • 檢測主從之間網絡套接字是否可用
  • 檢測主節點當前是否可接受處理命令

在發送 ping 命令之後,正常情況下主服務器會返回 pong 命令,接受到主服務器返回的 pong 回復之後就會進行下一步工作,如果沒有收到主節點的 pong 回復或者超時,比如網絡超時或者主節點正在阻塞無法響應命令,從服務器會斷開複製連接,等待下一次定時任務的調度。

4、身份驗證

從服務器在接收到主服務器返回的 pong 回復之後,下一步要做的事情就是根據配置信息決定是否需要身份驗證:

  • 如果從服務器設置了 masterauth 參數,則進行身份驗證
  • 如果從服務器沒有設置 masterauth 參數,則不進行身份驗證

在需要身份驗證的情況下,從服務器將就向主服務器發送一條 auth 命令,命令參數為從服務器 masterauth 選項的值,舉個例子,如果從服務器的配置里將 masterauth 參數設置為:123456,那麼從服務器將向主服務器發送 auth 123456 命令,身份驗證的過程也不是一帆風順的,可能會遇到以下幾種情況:

  • 從服務器通過 auth 命令發送的密碼與主服務器的 requirepass 參數值一致,那麼將繼續進行後續操作,如果密碼不一致,主服務將返回一個 invalid password 錯誤
  • 如果主服務器沒有設置 requirepass 參數,那麼主服務器將返回一個 no password is set 錯誤

所有的錯誤情況都會令從服務器中止當前的複製工作,並且要從建立 socket 開始重新發起複制流程,直到身份驗證通過或者從服務器放棄執行複製為止

5、發送端口信息

在身份驗證通過後,從服務器將執行 REPLCONF listening 命令,向主服務器發送從服務器的監聽端口號,例如在我們的例子中從服務器監聽的端口為 6480,那麼從服務器將向主服務器發送 REPLCONF listening 6480 命令,主服務器接收到這個命令之後,會將端口號記錄在從服務器所對應的客戶端狀態的 slave_listening_port 屬性了,也就是我們在 master 服務器的 info replication 裏面看到的 port 值。

6、數據複製

數據複製是最複雜的一塊了,由 psync 命令來完成,從服務器會向主服務器發送一個 psync 命令來進行數據同步,在 redis 2.8 版本以前使用的是 sync 命令,除了命令不同之外,在複製的方式上也有很大的不同,在 redis 2.8 版本以前使用的都是全量複製,這對主節點和網絡會造成很大的開銷,在 redis 2.8 版本以後,數據同步將分為全量同步和部分同步。

  • 全量複製:一般用於初次複製場景,不管是新舊版本的 redis 在從服務器第一次與主服務連接時都將進行一次全量複製,它會把主節點的全部數據一次性發給從節點,當數據較大時,會對主節點和網絡造成很大的開銷,redis 的早期版本只支持全量複製,這不是一種高效的數據複製方式

  • 部分複製:用於處理在主從複製中因網絡閃斷等原因造成的數據丟失 場景,當從節點再次連上主節點后,如果條件允許,主節點會補發丟失數據 給從節點。因為補發的數據遠遠小於全量數據,可以有效避免全量複製的過高開銷,部分複製是對老版複製的重大優化,有效避免了不必要的全量複製操作

redis 之所以能夠支持全量複製和部分複製,主要是對 sync 命令的優化,在 redis 2.8 版本以後使用的是一個全新的 psync 命令,命令格式為:psync {runId} {offset},這兩個參數的意義:

  • runId:主節點運行的id
  • offset:當前從節點複製的數據偏移量

也許你對上面的 runid、offset 比較陌生,沒關係,我們先來看看下面三個概念:

1、複製偏移量

參与複製的主從節點都會分別維護自身複製偏移量:主服務器每次向從服務器傳播 N 個字節的數據時,就將自己的偏移量的值加上 N,從服務器每次接收到主服務器傳播的 N個字節的數據時,將自己的偏移量值加上 N。通過對比主從服務器的複製偏移量,就可以知道主從服務器的數據是否一致,如果主從服務器的偏移量總是相同,那麼主從數據一致,相反,如果主從服務器兩個的偏移量並不相同,那麼說明主從服務器並未處於數據一致的狀態,比如在有多個從服務器時,在傳輸的過程中某一個服務器離線了,如下圖所示:

由於從服務器A 在數據傳輸時,由於網絡原因掉線了,導致偏移量與主服務器不一致,那麼當從服務器A 重啟並且與主服務器連接成功后,重新向主服務器發送 psync 命令,這時候數據複製應該執行全量複製還是部分複製呢?如果執行部分複製,主服務器又如何補償從服務器A 在斷線期間丟失的那部分數據呢?這些問題的答案都在複製積壓緩衝區裏面

2、複製積壓緩衝區

複製積壓緩衝區是保存在主節點上的一個固定長度的隊列,默認大小為 1MB,當主節點有連接的從節點(slave)時被創建,這時主節點(master) 響應寫命令時,不但會把命令發送給從節點,還會寫入複製積壓緩衝區,如下圖所示:

因此,主服務器的複製積壓緩衝區裏面會保存着一部分最近傳播的寫命令,並且複製積壓緩衝區會為隊列中的每個字節記錄相應的複製偏移量。所以當從服務器重新連上主服務器時,從服務器通過 psync 命令將自己的複製偏移量 offset 發送給主服務器,主服務器會根據這個複製偏移量來決定對從服務器執行何種數據同步操作:

  • 如果從服務器的複製偏移量之後的數據仍然存在於複製積壓緩衝區裏面,那麼主服務器將對從服務器執行部分複製操作
  • 如果從服務器的複製偏移量之後的數據不存在於複製積壓緩衝區裏面,那麼主服務器將對從服務器執行全量複製操作

3、服務器運行ID

每個 Redis 節點啟動后都會動態分配一個 40 位的十六進制字符串作為運行 ID,運行 ID 的主要作用是用來唯一識別 Redis 節點,我們可以使用 info server 命令來查看

127.0.0.1:6379> info server
# Server
redis_version:5.0.5
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:2ef1d58592147923
redis_mode:standalone
os:Linux 3.10.0-957.27.2.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:25214
run_id:7b987673dfb4dfc10dd8d65b9a198e239d20d2b1
tcp_port:6379
uptime_in_seconds:14382
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:14554933
executable:/usr/local/redis-5.0.5/src/./redis-server
config_file:/usr/local/redis-5.0.5/redis.conf
127.0.0.1:6379> 

這裏面有一個run_id 字段就是服務器運行的ID

了解這幾個概念之後,我們一起來看看 psync 命令的運行流程,psync 命令運行流程如下圖所示:

psync 命令的邏輯比較簡單,整個流程分為兩步:

1、從節點發送 psync 命令給主節點,參數 runId 是當前從節點保存的主節點運行ID,參數offset是當前從節點保存的複製偏移量,如果是第一次參与複製則默認值為 -1。

2、主節點接收到 psync 命令之後,會向從服務器返回以下三種回復中的一種:

  • 回復 +FULLRESYNC {runId} {offset}:表示主服務器將與從服務器執行一次全量複製操作,其中 runid 是這個主服務器的運行 id,從服務器會保存這個id,在下一次發送 psync 命令時使用,而 offset 則是主服務器當前的複製偏移量,從服務器會將這個值作為自己的初始化偏移量
  • 回復 +CONTINUE:那麼表示主服務器與從服務器將執行部分複製操作,從服務器只要等着主服務器將自己缺少的那部分數據發送過來就可以了
  • 回復 +ERR:那麼表示主服務器的版本低於 redis 2.8,它識別不了 psync 命令,從服務器將向主服務器發送 sync 命令,並與主服務器執行全量複製

7、命令持續複製

當主節點把當前的數據同步給從節點后,便完成了複製的建立流程。但是主從服務器並不會斷開連接,因為接下來主節點會持續地把寫命令發送給從節點,保證主從數據一致性。

經過上面 7 步就完成了主從服務器之間的數據同步,由於這篇文章的篇幅比較長,關於全量複製和部分複製的細節就不介紹了,全量複製就是將主節點的當前的數據生產 RDB 文件,發送給從服務器,從服務器再從本地磁盤加載,這樣當文件過大時就需要特別大的網絡開銷,不然由於數據傳輸比較慢會導致主從數據延時較大,部分複製就是主服務器將複製積壓緩衝區的寫命令直接發送給從服務器。

心跳檢測

心跳檢測是發生在主從節點在建立複製后,它們之間維護着長連接並彼此發送心跳命令,便以後續持續發送寫命令,主從心跳檢測如下圖所示:

主從節點彼此都有心跳檢測機制,各自模擬成對方的客戶端進行通信,主從心跳檢測的規則如下:

  • 主節點默認每隔 10 秒對從節點發送 ping 命令,判斷從節點的存活性和連接狀態。可通過修改 redis.conf 配置文件裏面的 repl-ping-replica-period 參數來控制發送頻率
  • 從節點在主線程中每隔 1 秒發送 replconf ack {offset} 命令,給主節點 上報自身當前的複製偏移量,這條命令除了檢測主從節點網絡之外,還通過發送複製偏移量來保證主從的數據一致

主節點根據 replconf 命令判斷從節點超時時間,體現在 info replication 統 計中的 lag 信息中,我們在主服務器上執行 info replication 命令:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6480,state=online,offset=25774,lag=0
master_replid:c62b6621e3acac55d122556a94f92d8679d93ea0
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:25774
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:25774
127.0.0.1:6379> 

可以看出 slave0 字段的值最後面有一個 lag,lag 表示與從節點最後一次通信延遲的秒數,正常延遲應該在 0 和 1 之間。如果超過 repl-timeout 配置的值(默認60秒),則判定從節點下線並斷開複製客戶端連接,如果從節點重新恢復,心跳檢測會繼續進行。

主從拓撲架構

Redis的主從拓撲結構可以支持單層或多層複製關係,根據拓撲複雜性可以分為以下三種:一主一從、一主多從、樹狀主從架構

一主一從結構

一主一從結構是最簡單的複製拓撲結構,我們前面搭建的就是一主一從的架構,架構如圖所示:

一主一從架構用於主節點出現宕機時從節點 提供故障轉移支持,當應用寫命令併發量較高且需要持久化時,可以只在從節點上開啟 AOF,這樣既保證數據安全性同時也避免了持久化對主節點的性能干擾。但是這裡有一個坑,需要你注意,就是當主節點關閉持久化功能時, 如果主節點脫機要避免自動重啟操作。因為主節點之前沒有開啟持久化功能自動重啟后數據集為空,這時從節點如果繼續複製主節點會導致從節點數據也被清空的情況,喪失了持久化的意義。安全的做法是在從節點上執行 slaveof no one 斷開與主節點的複製關係,再重啟主節點從而避免這一問題

一主多從架構

一主多從架構又稱為星形拓撲結構,一主多從架構如下圖所示:

一主多從架構可以實現讀寫分離來減輕主服務器的壓力,對於讀佔比較大的場景,可以把讀命令發送到 從節點來分擔主節點壓力。同時在日常開發中如果需要執行一些比較耗時的讀命令,如:keys、sort等,可以在其中一台從節點上執行,防止慢查詢對主節點造成阻塞從而影響線上服務的穩定性。對於寫併發量較高的場景,多個從節點會導致主節點寫命令的多次發送從而過度消耗網絡帶寬,同時也加重了主節點的負載影響服務穩定性。

樹狀主從架構

樹狀主從架構又稱為樹狀拓撲架構,樹狀主從架構如下圖所示:

樹狀主從架構使得從節點不但可以複製主節 數據,同時可以作為其他從節點的主節點繼續向下層複製。解決了一主多從架構中的不足,通過引入複製中 間層,可以有效降低主節點負載和需要傳送給從節點的數據量。如架構圖中,數據寫入節點A 後會同步到 B 和 C節點,B節點再把數據同步到 D 和 E節點,數據實現了一層一層的向下複製。當主節點需要掛載多個從節點時為了避免對主節點的性能干擾,可以採用樹狀主從結構降低主節點壓力。

最後

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

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

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

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

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

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

物聯網架構成長之路(47)-利用GitLab實現CI持續集成

0.前言
  前段時間,考慮到要練習部署一套CI/CD的系統。一開始考慮到Jenkins,隨着這两天的了解,發現最新版的GitLab已經提供有CI/CD集成了。所以本次博客,乾脆一步到位,直接用GitLab裏面的CI/CD模塊。Jenkins可能需要更高級的應用場合。經過測試GitLab自帶的功能完全符合我的需求。

1. 安裝GitLab和GitLab-CI(gitlab-runner)
  英語比較好的,可以直接看官方文檔。https://docs.gitlab.com/omnibus/docker/#install-gitlab-using-docker-compose https://docs.gitlab.com/ee/ci/quick_start/README.html
  下面提供我使用的 docker-compose.yml

 1 version: '3'
 2 services:
 3     gitlab:
 4         image: twang2218/gitlab-ce-zh:latest
 5         #image: gitlab/gitlab-ce:rc
 6         restart: always
 7         hostname: '172.16.23.203'
 8         environment:
 9             GITLAB_OMNIBUS_CONFIG: |
10                 external_url 'http://172.16.23.203:8929'
11                 gitlab_rails["time_zone"] = "Asia/Shanghai"
12         ports:
13             - 8929:8929
14             - 1080:80
15             - 1443:443
16             - 1022:22
17         volumes:
18             - /root/workspace/docker/gitlab/1/config:/etc/gitlab
19             - /root/workspace/docker/gitlab/1/logs:/var/log/gitlab
20             - /root/workspace/docker/gitlab/1/data:/var/opt/gitlab
21     gitlab-runner:
22         image: gitlab/gitlab-runner:latest
23         restart: always
24         volumes:
25             - /root/workspace/docker/gitlab/2/config:/etc/gitlab-runner
26             - /var/run/docker.sock:/var/run/docker.sock

  執行docker-compose up -d 就運行起來,幾點需要說明的
    1. gitlab的image,可以選擇中文版或者英文版
    2. hostname 這裏指定本機IP地址
    3. gitlab環境變量,external_url表示提供訪問的IP和端口,時區配置上海
    4. 端口映射,默認是80端口,由於我上面配置了8929,所以映射8929到Host主機
    5. volumes 配置持久化數據
    6. 這裏的/var/run/docker.sock 要映射到主機,因為會用到主機的一些資源,同時還會在docker裏面安裝docker
  下面是運行效果,第一次運行會比較久,因為要拉取鏡像和初始化GitLab

2. 登錄使用GitLab
  首次登錄,設置密碼。 登錄默認用戶名是root
  利用模版,新建一個Spring項目

  利用IDE,或者其他工具,或者直接在GitLab修改代碼

3. 配置CI/CD,把機器(gitlab-runner)註冊到GitLab中
  可以在項目配置CI/CD機器,也可以在個人所有項目下配置,也可以由管理員配置所有項目下CI/CD機器。原理和流程都是一樣的,只是比Jenkins更加細粒度控制而已。

  進入gitlab-runner的Docker,執行初始化命令 gitlab-ci-multi-runner register,完整命令如下:

1 sudo docker exec -it gitlab-runner gitlab-ci-multi-runner register

  需要錄入的信息,安裝上圖進行,填寫,後續還可以修改。

  如果需要修改,可以修改之前volumes配置的路徑下, config/config.toml

 

 1 concurrent = 1
 2 check_interval = 0
 3 
 4 [session_server]
 5   session_timeout = 1800
 6 
 7 [[runners]]
 8   name = "myRunner"
 9   url = "http://172.16.23.203:8929/"
10   token = "96beefdaa54832b0c8369ffa3811c9"
11   executor = "docker"
12   [runners.custom_build_dir]
13   [runners.docker]
14     tls_verify = false
15     image = "docker:latest"
16     privileged = true
17     disable_entrypoint_overwrite = false
18     oom_kill_disable = false
19     disable_cache = false
20     volumes = ["/cache", "/root/.m2:/root/.m2", "/var/run/docker.sock:/var/run/docker.sock"]
21     shm_size = 0
22   [runners.cache]
23     [runners.cache.s3]
24     [runners.cache.gcs]

 

  上面這個是配置文件,裏面有幾個注意點
    1. privileged 這裏要配置 true,因為要在docker裏面安裝docker
    2. /root/.m2 這個是配置maven的倉庫使用宿主主機的緩存,這樣就不用每次CI都要下載依賴
    3. /var/run/docker.sock 這個也要配置,在構建dockerfile的時候會用到
  還有一個需要配置的就是,這個Runner需要設置tag,這個是標識Runner的名稱。在.gitlab-ci.yml中會用到

4. 配置CI/CD
  默認GitLab是啟用該功能的,根目錄配置新增 .gitlab-ci.yml 文件,然後每次git push,都會觸發CI持續集成。當然可以在yml配置,在主線master觸發。
  來個簡單的配置,測試一下

 1 image: maven:3-jdk-8
 2 cache:
 3     paths:
 4         - .m2/repository
 5 test:
 6     stage: test
 7     script:
 8         - mvn package
 9     tags:
10         - tag

  上面這個配置,寫到.gitlab-ci.yml然後提交到repo,我們提交該文件到gitlab對應項目上去。

1 git add .gitlab-ci.yml
2 git commit -m "Add .gitlab-ci.yml"
3 git push origin master

  如果嫌慢,pom.xml 可以換個阿里源

 1         <repository>
 2             <id>maven-ali</id>
 3             <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
 4             <releases>
 5                 <enabled>true</enabled>
 6             </releases>
 7             <snapshots>
 8                 <enabled>true</enabled>
 9                 <updatePolicy>always</updatePolicy>
10                 <checksumPolicy>fail</checksumPolicy>
11             </snapshots>
12         </repository>

  一提交,就會觸發自動構建

  可以看到整個構建過程,如果出現錯誤,也是到這個日誌裏面排查問題。

 

 

5. 測試、打包、發布
  這一步,我們實現一個簡單的測試、打包、發布
5.1 增加 Dockerfile

1 FROM openjdk:8-jdk-alpine
2 VOLUME /tmp
3 COPY  target/demo-0.0.1-SNAPSHOT.jar app.jar
4 ENV PORT 5000
5 EXPOSE $PORT
6 ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-Dserver.port=${PORT}","-jar","/app.jar"]

5.2 修改 .gitlab-ci.yml

 1 image: maven:3-jdk-8
 2 
 3 variables:
 4     DOCKER_TAG: test/demo-spring:0.1
 5 
 6 cache:
 7     paths:
 8         - .m2/repository
 9 
10 stages:
11     - test
12     - package
13     - deploy
14 
15 test:
16     stage: test
17     tags:
18         - tag
19     script:
20         - mvn test
21 
22 package:
23     stage: package
24     tags:
25         - tag
26     script:
27         - mvn clean package -Dmaven.test.skip=true
28     artifacts:
29         paths:
30             - target/*.jar
31 
32 deploy:
33     image: docker:latest
34     stage: deploy
35     services:
36         - docker:dind
37     tags:
38         - tag
39     script:
40         - docker version 
41         - docker build -t $DOCKER_TAG .
42         - docker rm -f test || true
43         - docker run -d --name test -p 5000:5000 $DOCKER_TAG

  那個artifacts.paths 配置,提交target目錄下的文件到下一個流水線,因為不同流水線,由於是基於Docker,所以每一步都是隔離的。同時,上傳的附件還可以在構建成功后,在流水線pipelines界面進行下載。每一步的image都是可以指定的,那個tags也是可以指定的。可以提交到不同的機器進行構建。
  上面一共就三步流程,先test(測試),然後package(打包編譯),最後deploy(發布測試)。前兩個比較好理解,就是maven的基本命令。最後那個deploy就是利用docker裏面的docker來進行打包成docker,然後運行起來,作為測試發布。
  更新代碼.gitlab-ci.yml,然後提交,觸發持續集成。

  查看構建日誌

  查看宿主機鏡像和運行狀態

  查看瀏覽器,已經發布到測試環境了

5.3 釘釘通知

 1 image: maven:3-jdk-8
 2 
 3 variables:
 4     DOCKER_TAG: test/demo-spring:0.1
 5 
 6 cache:
 7     paths:
 8         - .m2/repository
 9 
10 stages:
11     - test
12     - package
13     - deploy
14     - notify
15 
16 test:
17     stage: test
18     tags:
19         - tag
20     script:
21         - mvn test
22 
23 package:
24     stage: package
25     tags:
26         - tag
27     script:
28         - mvn clean package -Dmaven.test.skip=true
29     artifacts:
30         paths:
31             - target/*.jar
32 
33 deploy:
34     image: docker:latest
35     stage: deploy
36     services:
37         - docker:dind
38     tags:
39         - tag
40     script:
41         - docker version 
42         - docker build -t $DOCKER_TAG .
43         - docker rm -f test || true
44         - docker run -d --name test -p 5000:5000 $DOCKER_TAG
45 
46 notify:
47     image: appropriate/curl:latest
48     stage: notify
49     tags:
50         - tag
51     script: "curl 'https://oapi.dingtalk.com/robot/send?access_token=d6c15304c1***************************************' -H 'Content-Type: application/json' -d '{\"msgtype\": \"text\", \"text\": {\"content\": \"功能已更新部署至測試環境\"}}' "

  有了這個通知,就可以做很多事情了,寫個腳本,封裝成一個Docker 鏡像,可以發送釘釘,發送郵件,可以對接到第三方系統等。

  更多高級應用,如集成之前了解的Harbor,Rancher。使整個系統更加強大,更加智能化。

 

參考資料
  
  
  
  
  

本文地址:
本系列目錄:
個人主頁:

volumes

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

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

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

JavaScript 是否應該重命名

  在誕生 25 年之後,JavaScript 語言仍然讓很多人困惑不已。所以一個老生常談的問題是:它是否應該重命名?呼籲改名的支持者列舉了一系列理由,包括:

  • JavaScript 本意指的是 ECMAScript 的子集,但使用中它經常被指代多種不同的 ECMAScript 超集
  • JavaScript 是甲骨文公司的商標,這與 JavaScript 作為 Web 平台核心組件的身份不相符合,Web 平台是建立在開放技術和標準基礎上的
  • JavaScript 連官方 logo 都沒有
  • JavaScript 與 Java 沒有一點關係,幾十年來它給非技術人員造成了混淆。

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

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

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

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

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

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

雅虎日本在其餐廳徵收“油炸食品稅”

  為了推廣健康生活方式,減少僱員中間的肥胖率,雅虎日本在其總部餐廳開始徵收“油炸食品稅”。從 10 月 8 日開始,炸豬排之類的油炸食品價格上漲,而水煮魚或烤魚之類的魚類食品則價格下降。

  它在 2017 年的體檢显示,45% 的僱員 LDL 膽固醇含量較高。它的自助餐廳每天有 1000 名僱員吃飯,油炸食品要比水煮魚或烤魚受歡迎得多。除了炸豬排漲價外,炸雞排也漲了 100 日元至 691 日元。如今到了午餐點,魚類食品一售而空,官員表示效果顯著。

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

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

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

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

※帶您來看台北網站建置台北網頁設計,各種案例分享