德國將蓋鋰電池廠制衡Tesla,鋰電池成本望下滑

特斯拉(Tesla)懷著超級工廠大夢,準備在電池領域一統江湖,歐洲強國也不甘示弱,德國總理梅克爾(Angela Merkel)參加德國戴姆勒汽車(Daimler)斥資5 億歐元興建的鋰電池工廠的動土典禮,這項歐洲大陸的超級電池工廠計畫,將挑戰Tesla 在綠色電力領域的領導地位。

彭博報導,德國電池工廠位於柏林南部130 公里處,突顯主要汽車製造商和電力公司進入儲能的行動,這項技術對推動下一代綠色車輛,以及在需要時儲存風力與太陽能電力上至關重要。報導認為,隨著汽車製造商與電力公司同步發展,電池成本可能會迅速下滑。

彭博分析師認為,電池成本下降與能源密度增加,預計2030 年就可以看到電動車比燃料汽車更便宜的情況。根據彭博新能源財經(BNEF)數據,全球電池製造產能將在2021 年翻倍,達到2.78 億度,現在約1.03 億度,屆時歐洲市場佔比將從現在的2.5% 提高一倍。

瑞典、匈牙利和波蘭計劃中的大型工廠,以及戴姆勒在德國的電池組裝廠,預計會為福斯與雷諾等汽車製造商提供需求,屆時鋰離子電池成本將降低43%,使電動汽車成為主流。

對於公用事業而言,便宜的電池可以降低儲存單元的成本,儲存單元可將變動型再生能源如風能與太陽能的電力傳送至電網。義大利國家電力公司Enel SpA 將電池與風力發電場配套使用,電網管理人員對電力輸出的預測準度因此提高30%。

1990 年代初期消費類電子產品如電腦和手機使用的鋰離子電池,已經跨界應用於運輸和電力行業,但礙於成本,鋰電池在電網和汽車上的應用才剛剛開始,電池的興起對於電動汽車的消費者來說最為明顯,大多數主要汽車製造商將充電式電動車訂為未來10 年的中期計劃。

目前電池業務仍由亞洲電子製造商所主導。根據BNEF,韓國LG 和三星SDI 是頂級供應商,亞洲有望繼續保持領先地位,中國另有8 個工廠正在興建。

汽車製造商採取行動確保電池供應源,戴姆勒的工廠將是歐洲最大的工廠,供應旗下汽車與梅賽德斯賓士,並與屋頂太陽能安裝商Vivint Solar 合資生產家庭能源儲存系統。

2017 年1 月Tesla 的工廠完成三分之一,完工後每年產能可達35 千兆瓦,足以支持每年生產50 萬輛電動車,這將使Tesla 成為繼LG 化學之後的第2 大供應商,特斯拉也在計畫興建更多超級工廠。

戴姆勒的投資規模較小,且尚未披露產能目標。福斯正在與電池廠商討論投資項目,並計劃在德國興建原型組裝廠以開發自己的技術。位於斯德哥爾摩的創業公司NorthVolt AB 宣布計劃在2023 年在瑞典設立一家40 億歐元的電池廠。鋰電池產量大增可望降低所有應用的電池成本,讓家庭和電網的儲存更加實惠。

未來10 年電動汽車價格可望能與汽油或柴油車競爭,由於電池組是充電電動車中最昂貴的部分,佔總成本的三分之一,預計到2021 年,鋰離子電池將便宜43%,從目前的每千瓦273 美元降至156 美元。

鋰電池普及是可以預見的事,但問題是儲存對消費者或大型公用事業而言是否有利可圖仍然是一個懸而未決的問題。即使如此,電動汽車廠商也正在尋找未來,根據BNEF,2030 年前充電式電動車可能佔新車銷售的五分之一,即2,100 萬台。梅克爾訪問戴姆勒工廠展現了德國政府計劃2030 年讓600 萬輛電動汽車上路的決心。

(合作媒體:。圖片出處:Tesla)

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

電動車發展腳步快,石油恐2040年前觸頂

Thomson Reuters報導,嘉能可(Glencore)董事長Tony Hayward 22日表示,電動車的快速進步意味著石油需求可能會在2040年以前觸頂,深海鑽油、加拿大油砂等高成本原油生產商恐將先被淘汰出局,擁有生產成本優勢的石油輸出國組織(OPEC)相對較不受衝擊。Hayward曾任英國石油公司(BP Plc)執行長。

嘉能可執行長Ivan Glasenberg表示,石油需求可能提前觸頂對嘉能可有利、因為旗下投資組合並沒有太多的原油。Glasenberg指出,如果電動車在2035年拿下90-95%的市占率,全球年度銅需求量可望較目前的2,300萬噸呈現倍增。德國總理梅克爾(Angela Merkel)22日指出,鋰電池技術已經進步到可以讓電動車擁有1千公里的續航力、遠高於目前的200-300公里,德國必須大舉投資以確保產業繼續保有優勢。

戴姆勒(Daimler AG)董事長Deiter Zetsche 22日表示,預估到2022年旗下將有超過10款的純電動轎車系列。戴姆勒旗下全資子公司ACCUMOTIVE 22日在德國卡門茨(Kamenz)為第二座電池工廠舉行奠基儀式、邀請梅克爾出席。這座工廠耗資5億歐元、預計在2018年年中正式營運。

英國金融時報去年8月報導,麥格理集團全球能源策略師Vikas Dwivedi指出,沙烏地阿拉伯對電動車的長期發展存有戒心,這可能就是它為何宣布將讓沙烏地阿拉伯國家石油公司(Saudi Aramco)初次公開發行(IPO)的原因之一。

通用汽車(General Motors)Chevrolet Bolt電動車續航力達238英里(383公里)、建議零售價37,495美元起(註:最多可取得7,500美元的聯邦折抵稅額、扣除後入手價相當於29,995美元)。美聯社報導,IHS Markit汽車業分析師Stephanie Brinley指出,Bolt續航力遠高於美國平均來回通勤距離(40英里),但有時人們回家後可能忘了或沒有足夠時間進行充電,這是電動車主得多加費心的地方。

(本文內容由授權使用。圖片出處:public domain CC0)

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

【其他文章推薦】

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

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

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

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

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

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

打個總結:Web性能優化

前段時間優化一個公司歷史老項目的Web性能,卻引出了一系列的問題,讓我反思良多。
我通過Chrome的Lighthouse工具可以看出一些性能參數和問題反饋,我逐一對其進行優化。
根據資源請求的不同,大致可以分為前端資源性能和後端程序性能兩個方面。
先分析一下前端資源吧:

  1. Defer offscreen images。

Chrome給出的建議是:

Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive. Learn more.

意思是可以考慮延遲加載一些圖片或者隱藏一些圖片在所有關鍵資源完成加載后再考慮加載,通過延遲加載來降低交互時間。
lazy-load的實現方法很多,開源框架推薦:lazysizes。
當然也可以使用npm方式安裝:

npm install lazysizes
使用方式很簡單,先引入lazysize到需要的頁面:

<script src="lazysizes.min.js" async=""></script>

然後給需要被lazyload的img標籤上加新的屬性,如下:

<img
    data-sizes="auto"
    data-src="image2.jpg"
    data-srcset="image1.jpg 300w,
    image2.jpg 600w,
    image3.jpg 900w" class="lazyload" />

特別要注意,有時候太多background方式加載的圖片也會影響性能,lazysizes也可以處理這樣的圖片。方法如下,使用data-bg屬性即可:

<div class="lazyload" data-bg="/path/to/image.jpg"></div>
  1. Reduce JavaScript execution time

解決這個問題方法很多,第一個想到的就是壓縮資源。
比如壓縮js和css文件,可以考慮使用webpack工具或者gulp來壓縮大資源文件,合併一些文件資源請求。
還可以通過預加載來提高響應速度,可以在最重要的js資源文件的引入上加入預加載,代碼如下:

<link rel="preload" as="style" href="css/style.css">

通過增加preload
最後還可以異步加載資源,異步不會阻塞主進程,代碼調整也很小:

<script src="xxx" async></script>

除此之外JavaScript的執行時間過長還有可能是有大量邏輯運算,有很多頁面把一些邏輯判斷和計算都交給前端去計算,這樣也不利於渲染,建議還是把複雜邏輯和計算盡可能交給後端去處理,讓前端渲染更加“輕量”。
3. Backend response
數據接口返回有時候也很拖累響應時間,因為一些前端結構需要根據返回的數據進行組裝新的頁面結構。
這裏可以考慮找到性能真正的瓶頸,到底是數據庫查詢導致的慢,還是業務邏輯不清晰導致的冗餘,或者其他原因。
我遇到的是因為老項目的數據庫操作類不是單例,會每次產生一個數據庫連接句柄,且該頁面複雜又多的sql查詢。
我勇敢地修改着10多年歷史的代碼,編寫了單例模式的操作類,然後增加了必要的緩存機制。
然而後面我遇到了問題,首先單例類在一些特殊情形下不滿足之前的代碼需求,導致奇特的數據庫報錯,而async屬性導致一些js文件無法同步加載到位,而有一些依賴這些資源的php文件執行報錯。
最終在同事的幫助下,恢復了服務,我也再一次體會到了任何一種性能提升都要謹慎,特別是對一個古老的項目。
前人不敢動的代碼,可能是深淵。

PS:我的公眾號 成都有娃兒會同步發布該文章,也可以關注哦!

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

【其他文章推薦】

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

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

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

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

新北清潔公司,居家、辦公、裝潢細清專業服務

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

容器技術之Docker-swarm

  前文我聊到了docker machine的簡單使用和基本原理的說明,回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13160915.html;今天我們來聊一聊docker集群管理工具docker swarm;docker swarm是docker 官方的集群管理工具,它可以讓跨主機節點來創建,管理docker 集群;它的主要作用就是可以把多個節點主機的docker環境整合成一個大的docker資源池;docker swarm面向的就是這個大的docker 資源池在上面管理容器;在前面我們都只是在單台主機上的創建,管理容器,但是在生產環境中通常一台物理機上的容器實在是不能夠滿足當前業務的需求,所以docker swarm提供了一種集群解決方案,方便在多個節點上創建,管理容器;接下來我們來看看docker swarm集群的搭建過程吧;

  docker swarm 在我們安裝好docker時就已經安裝好了,我們可以使用docker info來查看

[root@node1 ~]# docker info
Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 19.03.11
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 3.10.0-693.el7.x86_64
 Operating System: CentOS Linux 7 (Core)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 3.686GiB
 Name: docker-node01
 ID: 4HXP:YJ5W:4SM5:NAPM:NXPZ:QFIU:ARVJ:BYDG:KVWU:5AAJ:77GC:X7GQ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
  provider=generic
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[root@node1 ~]# 

  提示:從上面的信息可以看到,swarm是處於非活躍狀態,這是因為我們還沒有初始化集群,所以對應的swarm選項的值是處於inactive狀態;

  初始化集群

[root@docker-node01 ~]# docker swarm init --advertise-addr 192.168.0.41
Swarm initialized: current node (ynz304mbltxx10v3i15ldkmj1) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

[root@docker-node01 ~]# 

  提示:從上面反饋的信息可以看到,集群初始化成功,並且告訴我們當前節點為管理節點,如果想要其他節點加入到該集群,可以在對應節點上運行docker swarm join –token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377 這個命令,就把對應節點當作work節點加入到該集群,如果想要以管理節點身份加入到集群,我們需要在當前終端運行docker swarm join-token manager命令

[root@docker-node01 ~]# docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-dqjeh8hp6cp99bksjc03b8yu3 192.168.0.41:2377

[root@docker-node01 ~]# 

  提示:我們執行docker swarm join-token manager命令,它返回了一個命令,並告訴我們添加一個管理節點,在對應節點上執行docker swarm join –token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-dqjeh8hp6cp99bksjc03b8yu3 192.168.0.41:2377命令即可;

  到此docker swarm集群就初始化完畢,接下來我們把其他節點加入到該集群

  把docker-node02以work節點身份加入集群

[root@node2 ~]# docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377
This node joined a swarm as a worker.
[root@node2 ~]# 

  提示:沒有報錯就表示加入集群成功;我們可以使用docker info來查看當前的docker 環境詳細信息

  提示:從上面的信息可以看到,在docker-node02這台主機上docker swarm 已經激活,並且可以看到管理節點的地址;除了以上方式可以確定docker-node02以及加入到集群;我們還可以在管理節點上運行docker node ls 查看集群節點信息;

  查看集群節點信息

  提示:在管理節點上運行docker node ls 就可以列出當前集群里有多少節點已經成功加入進來;

  把docker-node03以管理節點身份加入到集群

  提示:可以看到docker-node03已經是集群的管理節點,所以可以在docker-node03這個節點執行docker node ls 命令;到此docker swarm集群就搭建好了;接下來我們來說一說docker swarm集群的常用管理

  有關節點相關管理命令

  docker node ls :列出當前集群上的所有節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# 

  提示:該命令只能在管理節點上執行;

  docker node inspect :查看指定節點的詳細信息;

[root@docker-node01 ~]# docker node inspect docker-node01
[
    {
        "ID": "ynz304mbltxx10v3i15ldkmj1",
        "Version": {
            "Index": 9
        },
        "CreatedAt": "2020-06-20T05:57:17.57684293Z",
        "UpdatedAt": "2020-06-20T05:57:18.18575648Z",
        "Spec": {
            "Labels": {},
            "Role": "manager",
            "Availability": "active"
        },
        "Description": {
            "Hostname": "docker-node01",
            "Platform": {
                "Architecture": "x86_64",
                "OS": "linux"
            },
            "Resources": {
                "NanoCPUs": 4000000000,
                "MemoryBytes": 3958075392
            },
            "Engine": {
                "EngineVersion": "19.03.11",
                "Labels": {
                    "provider": "generic"
                },
                "Plugins": [
                    {
                        "Type": "Log",
                        "Name": "awslogs"
                    },
                    {
                        "Type": "Log",
                        "Name": "fluentd"
                    },
                    {
                        "Type": "Log",
                        "Name": "gcplogs"
                    },
                    {
                        "Type": "Log",
                        "Name": "gelf"
                    },
                    {
                        "Type": "Log",
                        "Name": "journald"
                    },
                    {
                        "Type": "Log",
                        "Name": "json-file"
                    },
                    {
                        "Type": "Log",
                        "Name": "local"
                    },
                    {
                        "Type": "Log",
                        "Name": "logentries"
                    },
                    {
                        "Type": "Log",
                        "Name": "splunk"
                    },
                    {
                        "Type": "Log",
                        "Name": "syslog"
                    },
                    {
                        "Type": "Network",
                        "Name": "bridge"
                    },
                    {
                        "Type": "Network",
                        "Name": "host"
                    },
                    {
                        "Type": "Network",
                        "Name": "ipvlan"
                    },
                    {
                        "Type": "Network",
                        "Name": "macvlan"
                    },
                    {
                        "Type": "Network",
                        "Name": "null"
                    },
                    {
                        "Type": "Network",
                        "Name": "overlay"
                    },
                    {
                        "Type": "Volume",
                        "Name": "local"
                    }
                ]
            },
            "TLSInfo": {
                "TrustRoot": "-----BEGIN CERTIFICATE-----\nMIIBaTCCARCgAwIBAgIUeBd/eSZ7WaiyLby9o1yWpjps3gwwCgYIKoZIzj0EAwIw\nEzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMjAwNjIwMDU1MjAwWhcNNDAwNjE1MDU1\nMjAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH\nA0IABMsYxnGoPbM4gqb23E1TvOeQcLcY56XysLuF8tYKm56GuKpeD/SqXrUCYqKZ\nHV+WSqcM0fD1g+mgZwlUwFzNxhajQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB\nAf8EBTADAQH/MB0GA1UdDgQWBBTV64kbvS83eRHyI6hdJeEIv3GmrTAKBggqhkjO\nPQQDAgNHADBEAiBBB4hLn0ijybJWH5j5rtMdAoj8l/6M3PXERnRSlhbcawIgLoby\newMHCnm8IIrUGe7s4CZ07iHG477punuPMKDgqJ0=\n-----END CERTIFICATE-----\n",
                "CertIssuerSubject": "MBMxETAPBgNVBAMTCHN3YXJtLWNh",
                "CertIssuerPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyxjGcag9sziCpvbcTVO855BwtxjnpfKwu4Xy1gqbnoa4ql4P9KpetQJiopkdX5ZKpwzR8PWD6aBnCVTAXM3GFg=="
            }
        },
        "Status": {
            "State": "ready",
            "Addr": "192.168.0.41"
        },
        "ManagerStatus": {
            "Leader": true,
            "Reachability": "reachable",
            "Addr": "192.168.0.41:2377"
        }
    }
]
[root@docker-node01 ~]#

  docker node ps :列出指定節點上運行容器的清單

[root@docker-node01 ~]# docker node ps 
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE       ERROR               PORTS
[root@docker-node01 ~]# docker node ps docker-node01
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE       ERROR               PORTS
[root@docker-node01 ~]# 

  提示:類似docker ps 命令,我上面沒有運行容器,所以看不到對應信息;默認不指定節點名稱表示查看當前節點上的運行容器清單;

  docker node rm :刪除指定節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# docker node rm docker-node03
Error response from daemon: rpc error: code = FailedPrecondition desc = node aeo8j7zit9qkoeeft3j0q1h0z is a cluster manager and is a member of the raft cluster. It must be demoted to worker before removal
[root@docker-node01 ~]# docker node rm docker-node02
Error response from daemon: rpc error: code = FailedPrecondition desc = node tzkm0ymzjdmc1r8d54snievf1 is not down and can't be removed
[root@docker-node01 ~]# 

  提示:刪除節點前必須滿足,被刪除的節點不是管理節點,其次就是要刪除的節點必須是down狀態;

  docker swarm leave:離開當前集群

[root@docker-node03 ~]# docker ps 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
e7958ffa16cd        nginx               "/docker-entrypoint.…"   28 seconds ago      Up 26 seconds       80/tcp              n1
[root@docker-node03 ~]# docker swarm leave 
Error response from daemon: You are attempting to leave the swarm on a node that is participating as a manager. Removing this node leaves 1 managers out of 2. Without a Raft quorum your swarm will be inaccessible. The only way to restore a swarm that has lost consensus is to reinitialize it with `--force-new-cluster`. Use `--force` to suppress this message.
[root@docker-node03 ~]# docker swarm leave -f
Node left the swarm.
[root@docker-node03 ~]# 

  提示:管理節點默認是不允許離開集群的,如果強制使用-f選項離開集群,會導致在其他管理節點無法正常管理集群;

[root@docker-node01 ~]# docker node ls
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.
[root@docker-node01 ~]#

  提示:我們在docker-node01上現在就不能使用docker node ls 來查看集群節點列表了;解決辦法重新初始化集群;

[root@docker-node01 ~]# docker node ls 
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.
[root@docker-node01 ~]# docker swarm init --advertise-addr 192.168.0.41
Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.
[root@docker-node01 ~]# docker swarm init --force-new-cluster 
Swarm initialized: current node (ynz304mbltxx10v3i15ldkmj1) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Unknown             Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Down                Active                                  19.03.11
rm3j7cjvmoa35yy8ckuzoay46     docker-node03       Unknown             Active                                  19.03.11
[root@docker-node01 ~]# 

  提示:重新初始化集群不能使用docker swarm init –advertise-addr 192.168.0.41這種方式初始化,必須使用docker swarm init –force-new-cluster,該命令表示使用從當前狀態強制創建一個集群;現在我們就可以使用docker node rm 把down狀態的節點從集群刪除;

  刪除down狀態的節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Down                Active                                  19.03.11
rm3j7cjvmoa35yy8ckuzoay46     docker-node03       Down                Active                                  19.03.11
[root@docker-node01 ~]# docker node rm aeo8j7zit9qkoeeft3j0q1h0z rm3j7cjvmoa35yy8ckuzoay46
aeo8j7zit9qkoeeft3j0q1h0z
rm3j7cjvmoa35yy8ckuzoay46
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# 

  docker node promote:把指定節點提升為管理節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# docker node promote docker-node02
Node docker-node02 promoted to a manager in the swarm.
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# 

  docker node demote:把指定節點降級為work節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# docker node demote docker-node02
Manager docker-node02 demoted in the swarm.
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# 

  docker node update:更新指定節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# docker node update docker-node01 --availability drain 
docker-node01
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Drain               Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# 

  提示:以上命令把docker-node01的availability屬性更改為drain,這樣更改后docker-node01的資源就不會被調度到用來運行容器;

  為docker swarm集群添加圖形界面

[root@docker-node01 docker]# docker run --name v1 -d -p 8888:8080 -e HOST=192.168.0.41 -e PORT=8080 -v /var/run/docker.sock:/var/run/docker.sock docker-registry.io/test/visualizer
Unable to find image 'docker-registry.io/test/visualizer:latest' locally
latest: Pulling from test/visualizer
cd784148e348: Pull complete 
f6268ae5d1d7: Pull complete 
97eb9028b14b: Pull complete 
9975a7a2a3d1: Pull complete 
ba903e5e6801: Pull complete 
7f034edb1086: Pull complete 
cd5dbf77b483: Pull complete 
5e7311667ddb: Pull complete 
687c1072bfcb: Pull complete 
aa18e5d3472c: Pull complete 
a3da1957bd6b: Pull complete 
e42dbf1c67c4: Pull complete 
5a18b01011d2: Pull complete 
Digest: sha256:54d65cbcbff52ee7d789cd285fbe68f07a46e3419c8fcded437af4c616915c85
Status: Downloaded newer image for docker-registry.io/test/visualizer:latest
3c15b186ff51848130393944e09a427bd40d2504c54614f93e28477a4961f8b6
[root@docker-node01 docker]# docker ps 
CONTAINER ID        IMAGE                                COMMAND             CREATED             STATUS                            PORTS                    NAMES
3c15b186ff51        docker-registry.io/test/visualizer   "npm start"         6 seconds ago       Up 5 seconds (health: starting)   0.0.0.0:8888->8080/tcp   v1
[root@docker-node01 docker]# 

  提示:我上面的命令是從私有倉庫中下載的鏡像,原因是互聯網下載太慢了,所以我提前下載好,放在私有倉庫中;有關私有倉庫的搭建使用,請參考https://www.cnblogs.com/qiuhom-1874/p/13061984.html或者https://www.cnblogs.com/qiuhom-1874/p/13058338.html;在管理節點上運行visualizer容器后,我們就可以直接訪問該管理節點地址的8888端口,就可以看到當前容器的情況;如下圖

  提示:從上面的信息可以看到當前集群有一個管理節點和兩個work節點;現目前集群里沒有運行任何容器;

  在docker swarm運行服務

[root@docker-node01 ~]# docker service create --name myweb docker-registry.io/test/nginx:latest
i0j6wvvtfe1360ibj04jxulmd
overall progress: 1 out of 1 tasks 
1/1: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          1/1                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service ps myweb
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
99y8towew77e        myweb.1             docker-registry.io/test/nginx:latest   docker-node03       Running             Running 1 minutes ago                       
[root@docker-node01 ~]#

  提示:docker service create 表示在當前swarm集群環境中創建一個服務;以上命令表示在swarm集群上創建一個名為myweb的服務,用docker-registry.io/test/nginx:latest鏡像;默認情況下只啟動一個副本;

  提示:可以看到當前集群中運行了一個myweb的容器,並且運行在docker-node03這台主機上;

  在swarm 集群上創建多個副本服務

[root@docker-node01 ~]# docker service create --replicas 3 --name web docker-registry.io/test/nginx:latest
mbiap412jyugfpi4a38mb5i1k
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          1/1                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          3/3                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]#docker service ps web
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
1rt0e7u4senz        web.1               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 28 seconds ago                       
31ll0zu7udld        web.2               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 28 seconds ago                       
l9jtbswl2x22        web.3               docker-registry.io/test/nginx:latest   docker-node03       Running             Running 32 seconds ago                       
[root@docker-node01 ~]# 

  提示:–replicas選項用來指定期望運行的副本數量,該選項會在集群上創建我們指定數量的副本,即便我們集群中有節點宕機,它始終會創建我們指定數量的容器在集群上運行着;

  測試:把docker-node03關機,看看我們運行的服務是否會遷移到節點2上呢?

  docker-node03關機前

  docker-node03關機后

  提示:從上面的截圖可以看到,當節點3宕機后,節點3上跑的所有容器,會全部遷移到節點2上來;這就是創建容器時用–replicas選項的作用;總結一點,創建服務使用副本模式,該服務所在節點故障,它會把對應節點上的服務遷移到其他節點上;這裏需要提醒一點的是,只要集群上的服務副本滿足我們指定的replicas的數量,即便故障的節點恢復了,它是不會把服務遷移回來的;

[root@docker-node01 ~]# docker service ps web
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE             ERROR               PORTS
1rt0e7u4senz        web.1               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 15 minutes ago                        
31ll0zu7udld        web.2               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 15 minutes ago                        
t3gjvsgtpuql        web.3               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 6 minutes ago                         
l9jtbswl2x22         \_ web.3           docker-registry.io/test/nginx:latest   docker-node03       Shutdown            Shutdown 23 seconds ago                       
[root@docker-node01 ~]# 

  提示:我們在管理節點查看服務列表,可以看到它遷移服務就是把對應節點上的副本停掉,然後在其他節點創建一個新的副本;

  服務伸縮

[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          1/1                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          3/3                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service scale myweb=3 web=5
myweb scaled to 3
web scaled to 5
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged 
overall progress: 5 out of 5 tasks 
1/5: running   [==================================================>] 
2/5: running   [==================================================>] 
3/5: running   [==================================================>] 
4/5: running   [==================================================>] 
5/5: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          3/3                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          5/5                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service ps myweb web
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
j7w490h2lons        myweb.1             docker-registry.io/test/nginx:latest   docker-node02       Running             Running 12 minutes ago                       
1rt0e7u4senz        web.1               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 21 minutes ago                       
99y8towew77e        myweb.1             docker-registry.io/test/nginx:latest   docker-node03       Shutdown            Shutdown 5 minutes ago                       
en5rk0jf09wu        myweb.2             docker-registry.io/test/nginx:latest   docker-node03       Running             Running 31 seconds ago                       
31ll0zu7udld        web.2               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 21 minutes ago                       
h1hze7h819ca        myweb.3             docker-registry.io/test/nginx:latest   docker-node03       Running             Running 30 seconds ago                       
t3gjvsgtpuql        web.3               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 12 minutes ago                       
l9jtbswl2x22         \_ web.3           docker-registry.io/test/nginx:latest   docker-node03       Shutdown            Shutdown 5 minutes ago                       
od3ti2ixpsgc        web.4               docker-registry.io/test/nginx:latest   docker-node03       Running             Running 31 seconds ago                       
n1vur8wbmkgz        web.5               docker-registry.io/test/nginx:latest   docker-node03       Running             Running 31 seconds ago                       
[root@docker-node01 ~]# 

  提示:docker service scale 命令用來指定服務的副本數量,從而實現動態伸縮;

  服務暴露

[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          3/3                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          5/5                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service update  --publish-add 80:80 myweb 
myweb
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]#

  提示:docker swarm集群中的服務暴露和docker裏面的端口暴露原理是一樣的,都是通過iptables 規則表或LVS規則實現的;

  提示:我們可以在管理節點上看到對應80端口已經處於監聽狀態,並且在iptables規則表中多了一項訪問本機80端口都DNAT到172.18.0.2的80上了;其實不光是在管理節點,在work節點上相應的iptables規則也都發生了變化;如下

  提示:從上面的規則來看,我們訪問節點地址的80端口,都會DNAT到172.18.0.2的80;

  提示:從上面是显示結果看,我們不難得知在docker-node02運行myweb容器的內部地址是10.0.0.7,那為什麼我們訪問172.18.0.2是能夠訪問到容器內部的服務呢?

  測試:我們在docker-node02追蹤查看nginx容器的訪問日誌,看看到容器的IP地址是那個?

[root@docker-node02 ~]# docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
2134e1b2c689        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   24 minutes ago      Up 24 minutes       80/tcp              nginx.1.ych7y3ugxp6o592pbz5k2i412
[root@docker-node02 ~]# docker logs -f nginx.1.ych7y3ugxp6o592pbz5k2i412 
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
10.0.0.3 - - [21/Jun/2020:02:37:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
172.18.0.1 - - [21/Jun/2020:02:38:35 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.0.0.2 - - [21/Jun/2020:02:53:32 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.0.0.2 - - [21/Jun/2020:02:53:58 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
^C
[root@docker-node02 ~]# 

  提示:我們在管理節點上訪問172.18.0.2在node2節點上看到的日誌是10.0.0.2的ip訪問到nginx服務;這是為什麼呢?其實原因就是在每個節點上都有一個ingress-sbox容器,該容器的地址就10.0.0.2;不同節點上的ingress-sbox的地址都不同,所以我們訪問不同節點地址,在nginx上看到地址也就不同;如下圖所示

  提示:訪問不同的節點地址,在nginx日誌上記錄的IP各不相同

  提示:從上面的截圖可以了解到每個節點的ingress-sbox容器的地址各不相同,但他們都把網關指向10.0.0.1,這意味着各個節點容器通信就可以基於這個網關來進行,從而實現了swarm集群上的容器間通信能夠基於ingress網絡進行;現在還有一個問題就是172.18.0.0/18的網絡是怎麼和10.0.0.0/24的網絡通信的?

  提示:從上面的截圖可以看到,在管理節點上有兩個網絡名稱空間,一個id為0,而id為0的網絡名稱空間中有veth0和vxlan0這兩個網卡;而veth0和vxlan0都是橋接到br0上的,br0的地址就是10.0.0.1/24;vxlan的vlan id為4096;結合上面nginx的日誌,不難想到

我們訪問管理節點上的80,通過iptables規則把流量轉發給docker-gwbridge網絡上;現在我們還不清楚docker-gwbridge網絡上那個名稱空間的網絡,但是我們清楚知道在容器內部有兩張網卡,一張是eth0,一張是eth1,而eth1就是橋接到docker-gwbridge網絡上,這也就意味着容docker-gwbridge網絡的名稱空間和容器內部的eth1網絡名稱空間相同;

  提示:從上面的截圖看,1-u5mwgfq7rb這個名稱的網絡名稱空間有三張網卡,分別是eth0,eth1和vxlan0,它們都是橋接在br0這個網卡上;而上面管理節點也在1-u5mwgfq7rb這個網絡名稱空間,並且它們中的vxlan0的vlan id都是4096,這意味着管理節點上的vxlan0可以同node2上的vxlan0直接通信(相同網絡名稱空間中的相同VLAN id是可以直接通信的),而vxlan0又是直接橋接到br0這塊網卡,所以我們在nginx日誌中能夠看到ingress-sbox容器的地址在訪問nginx;這其中的原因是ingress-sbox的網關就是br0;其實node3也是相同邏輯,不同節點上的容器間通信都是走vxlan0,與外部通信走eth1—->然後通過SNAT走docker-gwbridge—->物理網卡出去;

  提示:一個容器上有兩個網絡,一個是eth0 ingress網絡,一個是eth1屬於docker-gwbridge網絡,兩者都屬於同一容器中的網絡名稱空間,所以我們訪問172.18.0.2就會通過ingress-sbox容器把源地址更改為docker-gwbridge上的ingress-sbox的地址,從而我們在看nginx日誌,就會看到10.0.0.2的地址;ingress-sbox容器作用我們可以理解為做SNAT的作用;

  測試:訪問管理節點的80服務看看是否能夠訪問到nginx提供的頁面呢?

[root@docker-node02 ~]# docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
b829991d6966        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   About an hour ago   Up About an hour    80/tcp              myweb.1.ilhkslrlnreyo6xx5j2h9isjb
8c2965fbdc27        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.2.pthe8da2n45i06oee4n7h4krd
b019d663e48e        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.3.w26gqpoyysgplm7qwhjbgisiv
a7c1afd76f1f        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.1.ho0d7u3wensl0kah0ioz1lpk5
[root@docker-node02 ~]# docker exec -it myweb.1.ilhkslrlnreyo6xx5j2h9isjb  bash
root@b829991d6966:/# cd /usr/share/nginx/html/
root@b829991d6966:/usr/share/nginx/html# ls
50x.html  index.html
root@b829991d6966:/usr/share/nginx/html# echo "this is docker-node02 index page" >index.html
root@b829991d6966:/usr/share/nginx/html# cat index.html
this is docker-node02 index page
root@b829991d6966:/usr/share/nginx/html# 

  提示:以上是在docker-node02節點上對運行的nginx容器的主頁進行了修改,接下我們訪問管理節點的80端口,看看是否能夠訪問得到work節點上的容器,它們會有什麼效果?是輪詢?還是一直訪問一個容器?

  提示:可以看到我們訪問管理節點的80端口,會輪詢的訪問到work節點上的容器;用瀏覽器測試可能存在緩存的問題,我們可以用curl命令測試比較準確;如下

[root@docker-node03 ~]# docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
f43fdb9ec7fc        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              myweb.3.pgdjutofb5thlk02aj7387oj0
4470785f3d00        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              myweb.2.uwxbe182qzq00qgfc7odcmx87
7493dcac95ba        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.4.rix50fhlmg6m9txw9urk66gvw
118880d300f4        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.5.vo7c7vjgpf92b0ryelb7eque0
[root@docker-node03 ~]# docker exec -it myweb.2.uwxbe182qzq00qgfc7odcmx87 bash
root@4470785f3d00:/# cd /usr/share/nginx/html/
root@4470785f3d00:/usr/share/nginx/html# echo "this is myweb.2 index page" > index.html 
root@4470785f3d00:/usr/share/nginx/html# cat index.html
this is myweb.2 index page
root@4470785f3d00:/usr/share/nginx/html# exit
exit
[root@docker-node03 ~]# docker exec -it myweb.3.pgdjutofb5thlk02aj7387oj0 bash
root@f43fdb9ec7fc:/# cd /usr/share/nginx/html/
root@f43fdb9ec7fc:/usr/share/nginx/html# echo "this is myweb.3 index page" >index.html 
root@f43fdb9ec7fc:/usr/share/nginx/html# cat index.html
this is myweb.3 index page
root@f43fdb9ec7fc:/usr/share/nginx/html# exit
exit
[root@docker-node03 ~]# 

  提示:為了訪問方便看得出效果,我們把myweb.2和myweb.3的主頁都更改了內容

[root@docker-node01 ~]# for i in {1..10} ; do curl 192.168.0.41; done
this is myweb.3 index page
this is docker-node02 index page
this is myweb.2 index page
this is myweb.3 index page
this is docker-node02 index page
this is myweb.2 index page
this is myweb.3 index page
this is docker-node02 index page
this is myweb.2 index page
this is myweb.3 index page
[root@docker-node01 ~]# 

  提示:通過上面的測試,我們在使用–publish-add 暴露服務時,就相當於在管理節點創建了一個load balance;

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

【Spring註解驅動開發】如何使用@Bean註解指定初始化和銷毀的方法?看這一篇就夠了!!

寫在前面

在【String註解驅動開發專題】中,前面的文章我們主要講了有關於如何向Spring容器中註冊bean的知識,大家可以到【String註解驅動開發專題】中系統學習。接下來,我們繼續肝Spring,只不過從本篇文章開始,我們就進入Spring容器中有關Bean的生命周期的學習。

項目工程源碼已經提交到GitHub:https://github.com/sunshinelyz/spring-annotation

Bean的生命周期

通常意義上講的bean的名稱周期,指的是bean從創建到初始化,經過一系列的流程,最終銷毀的過程。只不過,在Spring中,bean的生命周期是由Spring容器來管理的。在Spring中,我們可以自己來指定bean的初始化和銷毀的方法。當我們指定了bean的初始化和銷毀方法時,當容器在bean進行到當前生命周期的階段時,會自動調用我們自定義的初始化和銷毀方法。

如何定義初始化和銷毀方法?

我們已經知道了由Spring管理bean的生命周期時,我們可以指定bean的初始化和銷毀方法,那具體該如何定義這些初始化和銷毀方法呢?接下來,我們就介紹第一種定義初始化和銷毀方法的方式: 通過@Bean註解指定初始化和銷毀方法。

如果是使用XML文件的方式配置bean的話,可以在 標籤中指定bean的初始化和銷毀方法,如下所示。

<bean id = "person" class="io.mykit.spring.plugins.register.bean.Person" init-method="init" destroy-method="destroy">
    <property name="name" value="binghe"></property>
    <property name="age" value="18"></property>
</bean>

這裏,需要注意的是,在我們寫的Person類中,需要存在init()方法和destroy()方法。而且Spring中規定,這裏的init()方法和destroy()方法必須是無參方法,但可以拋異常。

如果我們使用註解的方式,該如何實現指定bean的初始化和銷毀方法呢?接下來,我們就一起來搞定它!!

首先,創建一個名稱為Student的類,這個類的實現比較簡單,如下所示。

package io.mykit.spring.plugins.register.bean;
/**
 * @author binghe
 * @version 1.0.0
 * @description 測試bean的初始化和銷毀方法
 */
public class Student {
    
    public Student(){
        System.out.println("Student類的構造方法");
    }

    public void init(){
        System.out.println("初始化Student對象");
    }

    public void destroy(){
        System.out.println("銷毀Student對象");
    }
}

接下來,我們將Student類對象通過註解的方式註冊到Spring容器中,具體的做法就是新建一個LifeCircleConfig類作為Spring的配置類,將Student類對象通過LifeCircleConfig類註冊到Spring容器中,LifeCircleConfig類的代碼如下所示。

package io.mykit.spring.plugins.register.config;

import io.mykit.spring.plugins.register.bean.Student;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author binghe
 * @version 1.0.0
 * @description Bean的生命周期
 */
@Configuration
public class LifeCircleConfig {
    @Bean
    public Student student(){
        return new Student();
    }
}

接下來,我們就新建一個BeanLifeCircleTest類來測試容器中的Student對象,BeanLifeCircleTest類的部分代碼如下所示。

package io.mykit.spring.test;

import io.mykit.spring.plugins.register.config.LifeCircleConfig;
import org.junit.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

/**
 * @author binghe
 * @version 1.0.0
 * @description 測試bean的生命周期
 */
public class BeanLifeCircleTest {

    @Test
    public void testBeanLifeCircle01(){
        //創建IOC容器
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(LifeCircleConfig.class);
        System.out.println("容器創建完成...");
    }
}

在前面的文章中,我們說過:對於單實例bean對象來說,在Spring容器創建完成后,就會對單實例bean進行實例化。那麼,我們先來運行下BeanLifeCircleTest類中的testBeanLifeCircle01()方法,輸出的結果信息如下所示。

Student類的構造方法
容器創建完成...

可以看到,在Spring容器創建完成時,自動調用單實例bean的構造方法,對單實例bean進行了實例化操作。

總之:對於單實例bean來說,在Spring容器啟動的時候創建對象;對於多實例bean來說,在每次獲取bean的時候創建對象。

現在,我們在Student類中指定了init()方法和destroy()方法,那麼,如何讓Spring容器知道Student類中的init()方法是用來執行對象的初始化操作,而destroy()方法是用來執行對象的銷毀操作呢?如果是使用XML文件配置的話,我們可以使用如下配置來實現。

<bean id="student" class="io.mykit.spring.plugins.register.bean.Student" init-method="init" destroy-method="destroy"></bean>

如果我們在@Bean註解中該如何實現呢?其實就更簡單了,我們來看下@Bean註解的源碼,如下所示。

package org.springframework.context.annotation;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import org.springframework.beans.factory.annotation.Autowire;
import org.springframework.beans.factory.support.AbstractBeanDefinition;
import org.springframework.core.annotation.AliasFor;

@Target({ElementType.METHOD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Bean {

	@AliasFor("name")
	String[] value() default {};

	@AliasFor("value")
	String[] name() default {};

	@Deprecated
	Autowire autowire() default Autowire.NO;

	boolean autowireCandidate() default true;

	String initMethod() default "";

	String destroyMethod() default AbstractBeanDefinition.INFER_METHOD;

}

看到@Bean註解的源碼,相信小夥伴們會有種豁然開朗的感覺:沒錯,就是使用@Bean註解的initMethod屬性和destroyMethod屬性來指定bean的初始化方法和銷毀方法。

所以,我們在LifeCircleConfig類中的@Bean註解中指定initMethod屬性和destroyMethod屬性,如下所示。

@Bean(initMethod = "init", destroyMethod = "destroy")
public Student student(){
    return new Student();
}

此時,我們再來運行BeanLifeCircleTest類中的testBeanLifeCircle01()方法,輸出的結果信息如下所示。

Student類的構造方法
初始化Student對象
容器創建完成...

從輸出結果可以看出,在Spring容器中,先是調用了Student類的構造方法來創建Student對象,接下來調用了Student對象的init()方法來進行初始化。

那小夥伴們可能會問,運行上面的代碼沒有打印出bean的銷毀方法中的信息啊,那什麼時候執行bean的銷毀方法呢? 這個問題問的很好, bean的銷毀方法是在容器關閉的時候調用的。

接下來,我們在BeanLifeCircleTest類中的testBeanLifeCircle01()方法中,添加關閉容器的代碼,如下所示。

@Test
public void testBeanLifeCircle01(){
    //創建IOC容器
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(LifeCircleConfig.class);
    System.out.println("容器創建完成...");
    context.close();
}

我們再來運行BeanLifeCircleTest類中的testBeanLifeCircle01()方法,輸出的結果信息如下所示。

Student類的構造方法
初始化Student對象
容器創建完成...
銷毀Student對象

可以看到,此時輸出了對象的銷毀方法中的信息,說明執行了對象的銷毀方法。

指定初始化和銷毀方法的使用場景

一個典型的使用場景就是對於數據源的管理。例如,在配置數據源時,在初始化的時候,對很多的數據源的屬性進行賦值操作;在銷毀的時候,我們需要對數據源的連接等信息進行關閉和清理。此時,我們就可以在自定義的初始化和銷毀方法中來做這些事情!

初始化和銷毀方法調用的時機

  • bean對象的初始化方法調用的時機:對象創建完成,如果對象中存在一些屬性,並且這些屬性也都賦值好之後,會調用bean的初始化方法。對於單實例bean來說,在Spring容器創建完成后,Spring容器會自動調用bean的初始化和銷毀方法;對於單實例bean來說,在每次獲取bean對象的時候,調用bean的初始化和銷毀方法。
  • bean對象的銷毀方法調用的時機:對於單實例bean來說,在容器關閉的時候,會調用bean的銷毀方法;對於多實例bean來說,Spring容器不會管理這個bean,也不會自動調用這個bean的銷毀方法。不過,小夥伴們可以手動調用多實例bean的銷毀方法。

前面,我們已經說了單實例bean的初始化和銷毀方法。接下來,我們來說下多實例bean的初始化和銷毀方法。我們將Student對象變成多實例bean來驗證下。接下來,我們在LifeCircleConfig類的student()方法上通過@Scope註解將Student對象設置成多實例bean,如下所示。

@Scope("prototype")
@Bean(initMethod = "init", destroyMethod = "destroy")
public Student student(){
    return new Student();
}

接下來,我們再來運行BeanLifeCircleTest類中的testBeanLifeCircle01()方法,輸出的結果信息如下所示。

容器創建完成...

可以看到,當我們將Student對象設置成多實例bean,並且沒有獲取bean實例對象時,Spring容器並沒有執行bean的構造方法、初始化方法和銷毀方法。

說到這,我們就在BeanLifeCircleTest類中的testBeanLifeCircle01()方法中添加一行獲取Student對象的代碼,如下所示。

@Test
public void testBeanLifeCircle01(){
    //創建IOC容器
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(LifeCircleConfig.class);
    System.out.println("容器創建完成...");
    context.getBean(Student.class);
    context.close();
}

此時,我們再來運行BeanLifeCircleTest類中的testBeanLifeCircle01()方法,輸出的結果信息如下所示。

容器創建完成...
Student類的構造方法
初始化Student對象

可以看到,此時,結果信息中輸出了構造方法和初始化方法中的信息。但是當容器關閉時,並沒有輸出bean的銷毀方法中的信息。

這是因為 將bean設置成多實例時,Spring不會自動調用bean對象的銷毀方法。至於多實例bean對象何時銷毀,那就是程序員自己的事情了!!Spring容器不再管理多實例bean。

好了,咱們今天就聊到這兒吧!別忘了給個在看和轉發,讓更多的人看到,一起學習一起進步!!

項目工程源碼已經提交到GitHub:https://github.com/sunshinelyz/spring-annotation

寫在最後

如果覺得文章對你有點幫助,請微信搜索並關注「 冰河技術 」微信公眾號,跟冰河學習Spring註解驅動開發。公眾號回復“spring註解”關鍵字,領取Spring註解驅動開發核心知識圖,讓Spring註解驅動開發不再迷茫。

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

【其他文章推薦】

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

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

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

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

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

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

一文搞懂:Adaboost及手推算法案例

boosting

Boosting 算法的特點在於:將表現一般的弱分類器通過組合變成更好的模型。代表自然就是我們的隨即森林了。

GBDT和Adaboost是boost算法中比較常見的兩種,這裏主要講解Adaboost。

Adaboost

Adaboost算法的核心就是兩個權重。對於數據有一個權重,權重大的數據計算的損失就大;然後對於每一個弱分類器有一個權重,這個權重就是每一個弱分類器最終投票的比重。

【先給出Adaboost關鍵的公式】
\(\alpha_1=\frac{1}{2}ln(\frac{1-\epsilon_1}{\epsilon_1})\) 分類器的投票權重
\(W_i=W_ie^{-\alpha_i y_i \hat{h}(x_i)}\) 更新樣本的權重

【隨即森林中最終投票每一個弱分類器的比重相同】

大概流程就是,現在有一個數據集,然後每個數據的比重都相同,然後訓練了好幾個不同的弱分類器。

  1. 挑選錯誤率最低的弱分類器,然後通過【某種算法】得到這個弱分類器最終投票的比重,然後通過【某種算法】更新每一個數據的比重;
  2. 因為每一個數據的比重更新了,所以再選擇一個錯誤率最低的弱分類器,然後通過【某種算法】得到這個弱分類器最終投票的比重,然後通過【某種算法】更新每一個數據的比重;
  3. 重複這個過程。

算法的流程:

這裏給一個具體計算的例子:
假設這裡有10個數據:

加號和減號分別代表不同的類別。然後每個類別有5個樣本。

下面會給出3個弱分類器:

這三個分類器分別是\(h_1(x),h_2(x),h_3(x)\)
圖中畫圈的數據就是分類錯誤的數據。可以發現每個弱分類器都分錯了3個。下面開始Adaboost的算法。

先計算三個弱分類器的錯誤率,因為一開始每個樣本的權重都是0.1,每個分類器又都錯了3個樣本,所以錯誤率都是0.3。這裏就隨機選取第一個分類器作為錯誤率最低的那個好了。
我們這裏通過第一個【某種算法】計算第一個弱分類器在最終的投票權重:
\(\alpha_1=\frac{1}{2}ln(\frac{1-\epsilon_1}{\epsilon_1})=0.5*ln(\frac{0.7}{0.3})=0.4236\)

然後通過這個\(\alpha_1=0.4236\)來更新每一個樣本的權重。這也就是上面提到的第二個【某種算法】:
\(W(i)=W(i)*e^{-\alpha y_i \hat {h}(x_i)}\)

這啥意思的,現在假設第一個樣本+1,這個樣本的權重是0.1(更新前),然後這個樣本在第一個分類器中是非類正確的,所以\(y_i \hat{h}(x_i)=1\),所以這個樣本更新后的權重就是\(0.1e^{-0.4236}=0.0655\)

當然,對於+3這個樣本,第一個分類器就分類錯誤,所以\(y_i \hat{h}(x_i)=-1\),所以呢這個樣本更新后的權重就是:\(0.1e^{0.4236}=0.1527\)

下面經過第一個分類器之後的樣本的權重:

然後再計算每一個分類器的基於更新之後樣本權重的錯誤率:

這一次選的是第二個分類器,然後計算它的\(\alpha_2\),然後再更新每一個樣本的權重值:

然後是再尋找錯誤率最低的分類器:

到這一步的時候,我們已經有了\(\alpha_1,\alpha_2,\alpha_3\),所以我們的adaboost已經得到了所有分類器的投票權重,所以最終的模型投票公式就是:

喜歡的話請關注我們的微信公眾號~【你好世界煉丹師】。

  • 公眾號主要講統計學,數據科學,機器學習,深度學習,以及一些參加Kaggle競賽的經驗。
  • 公眾號內容建議作為課後的一些相關知識的補充,飯後甜點。
  • 此外,為了不過多打擾,公眾號每周推送一次,每次4~6篇精選文章。

微信搜索公眾號:你好世界煉丹師。期待您的關注。

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

【其他文章推薦】

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

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

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

南投搬家公司費用需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

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

計算機網絡之應用層

應用層協議

應用層協議 (application-layer protocol) 定義了運行在不同端系統上的應用程序進程如何相互傳遞報文,特別是應用層協議定義了:

  • 交換的報文類型,例如請求報文和響應報文
  • 各種報文類型的語法,如報文中的各個字段及這些字段是如何描述的
  • 字段的語義,即這些字段中包含的信息的含義
  • 一個進程何時以及如何發送報文,對報文進行響應的規則。

  在本文中主要是講5種重要的應用: Web 、文件傳輸、电子郵件、目錄服務和P2P,我們首先討論 Web應用,不僅因為它是極為流行的應用,而且因為它的應用層協議 HTTP 相對比較簡單並且易於理解。討論完 Web ,我們簡要地討論FTP,因為它與 HTTP 形成了很好的對照 我們接下來討論电子郵件應用,這是因特網上最早的招人喜愛的應用程序。說电子郵件比 Web更複雜,是因為它使用了多個而不是一個應用層協議。在电子郵件之後,我們討論DNS它為因特網提供目錄服務,大多數用戶不直接與 DNS 打交道,而是通過其他的應用(包括Web 、文件傳輸和电子郵件)間接使用它,DNS 很好地說明了一種核心的網絡功能(網絡名字到網絡地址的轉換)是怎樣在因特網的應用層實現的。

HTTP概況

  Web 的應用層協議是超文本傳輸協議 (HyperText Transfer Protocol , HTTP) ,它是Web的核心,HTTP 由兩個程序實現:一個客戶程序和一個服務器程序。客戶程序和服務器程序運行在不同的端系統中,通過交換HTTP報文進行會話。 HTTP 定義了這些報文的結構以及客戶和服務器進行報文交換的方式。HTTP使用TCP作為它的支撐運輸協議(而不是在 UDP 上運行)。HTTP 客戶首先發起一個與服務器的TCP連接,一旦連接建立,該瀏覽器和服務器進程就可以通過套接字接口訪問TCP。

注意:服務器向客戶發送被請求的文件,而不存儲任何關於該客戶的狀態信息,假如某個特定的客戶在短短的幾秒鐘內兩次請求同一個對象,服務器並不會因為剛剛為該客戶提供了該對象就不再做出反應,而是重新發送該對象,就像服務器已經完全忘記不久之前所做過的事一樣,因為 HTTP 服務器並不保存關於客戶的任何信息,所以我們說HTTP是一個無狀態協議 (stateless protocol)

非持續連接和持續連接

  在許多因特網應用程序中,客戶和服務器在一個相當長的時間範圍內通信,其中客戶發出一系列請求並且服務器對每個請求進行響應 依據應用程序以及該應用程序的使用方式,這一系列請求可以以規則的間隔周期性地或者間斷性地一個接一個發出。當這種客戶-服務器的交互是經TCP進行的,應用程序的研製者就需要做一個重要決定,即每個請求/響應對是經一個單獨的 TCP 連接發送,還是所有的請求及其響應經相同的TCP連接發送呢?採用前一種方法,該應用程序被稱為使用非持續連接( non- persistent connection) ;採用后一種方法,該應用程序被稱為使用持續連接( persistent connection)。儘管 HTTP在其默認方式下使用持續連接, HTTP 客戶和服務器也能配置成使用非持續連接。

  非持續連接有一些缺點:首先,必須為每一個請求的對象建立和維護一個全新的連接。對於每個這樣的連接,在客戶和服務器巾都要分配 TCP 的緩衝區和保持 TCP 變量。這給 Web 服務器帶來了嚴重的負擔,因為一台 Web 服務器可能同時服務於數以百計不同的客戶的請求。第二,每一個對象經受兩倍 RTT 的交付時延,即一個RTT 用於創建 TCP ,另一個 RTT 用於請求和接收一個對象。在採用持續連接的情況下,服務器在發送響應后保持該 TCP 連接打開。在相同的客戶與服務器之間的後續請求和響應報文能夠通過相同的連接進行傳送

HTTP報文格式

  1. 請求報文
      GET /somedir/page.html HTTP/l.l
      Host: www.someschool.edu
      Connection: close
      User-agent: Mozilla/5.0
      Accept-language: fr

  我們看到該報文由5行組成,每行由一個回車和換行符結束。最後一行后再附加一個回車換行。雖然這個特定的報文僅有5行,但一個請求報文能夠具有更多的行或者至少為一行。HTTP 請求報文的第一行叫做請求行 (request line) ,其後繼的行叫做首部行( headerline)。請求行有3個字段:方法字段、URL字段和HTTP版本字段。方法宇段可以取幾種不同的值,包括 GET、POST、HEAD、PUT和DELETE。絕大部分的 HTTP 請求報文使用GET方法,當瀏覽器請求一個對象時,使用 GET 方法,在 URL 字段帶有請求對象的標識。在本例中,該瀏覽器正在請求對象/somedirl page. html 其版本字段是自解釋的;在本例中,瀏覽器實現的是 HTTP/ l. 版本。

  現在我們看看本例的首部行:首部行 Host: www. someschool. edu 指明了對象所在的主機。你也許認為該首部行是不必要的,因為在該主機中已經有一條 TCP 連接存在了,但是,該首部行提供的信息是 Web 代理高速緩存所要求的,通過包含 Connection: close 首部行,該瀏覽器告訴服務器不希望麻煩地使用持續連接,它要求服務器在發送完被請求的對象后就關閉這條連接。User- agent: 首部行用來指明用戶代理,即向服務器發送請求的瀏覽器的類型。這裏瀏覽器類型是 Mozilla/5. 0,即Firefox 瀏覽器,這個首部行是有用的,因為服務器可以有效地為不同類型的用戶代理,實際發送相同對象的不同版本 (每個版本都由相同的URL尋址)。最後Accept-language:首部行表示用戶想得到該對象的法語版本(如果服務器中有這樣的對象的話);否則,服務器應當發送它的默認版本 Accept -language:首部行僅是 HTTP 中可用的眾多內容協商首部之一。

  HEAD方法類似於GET方法,當服務器收到使用HEAD方法的請求時,將會用一個HTTP報文進行響應,但是並不返回請求對象,應用程序開發者常用HEAD方法進行調試,跟蹤PUT方法常與Web發行工具聯合使用,它允許用戶上傳對象到指定的 Web 服務器上指定的路徑(目錄)。PUT方法也被那些需要向 Web 服務器上傳對象的應用程序使用。DELETE 方法允許用戶或者應用程序刪除 Web 服務器上的對象

  1. HTTP響應報文
    下面我們提供了一條典型的HTTP響應報文 該響應報文可以是對剛剛討論的例子中請求報文的響應:
HTTP/ 1. 1 200 OK
Connection: close 
Date: Tue , 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue , 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html 

(data data data data data ...) 

  我們仔細看一下這個響應報文 它有三個部分:一個初始狀態行 (sLatus line) ,6個首部行 (header 1ine) ,然後是實體體 (enLity body) 實體體部分是報文的主要部分,即它包含了所請求的對象本身(表示為 dala dala data data …)。 狀態行有3個字段:協議版本字段、狀態碼和相應狀態信息。在這個例子中,狀態行指示服務器正在使用 HTTP/l.1,並且一切正常(即服務器已經找到並正在發送所請求的對象)。

  我們現在來看看首部行。服務器用 Connection: close 首部行告訴客戶,發送完報文後將關閉該 TCP 連接。Date: 首部行指示服務器產生併發送該響應報文的日期和時間。值得一提的是,這個時間不是指對象創建或者最後修改的時間;而是服務器從它的文件系統中檢索到該對象,插入到響應報文,併發送該響應報文的時間。Server: 首部行指示該報文是由一台 Apache Web 服務器產生的,它類似於 HTTP 請求報文中的 User- agent 首部行。Last- Modified: 首部行指示了對象創建或者最後修改的日期和時間。Lasl-Modified: 首部行對既可能在本地客戶也可能在網絡緩存服務器上的對象緩存來說非常重要。下面將會介紹緩存服務器(也叫代理服務器)。Content- Length: 首部行指示了被發送對象中的字節數;Conlent- Type: 首部行指示了實體體中的對象是 HTML 文本 (該對象類型應該正式地由 Conlent- Type: 首部行而不是用文件擴展名來指示。

Web 緩存

  Web緩存器 (Web cache)也叫代理服務器 (proxy server),它是能夠代表初始 Web 服務器來滿足 HTTP 請求的網絡實體。Web 緩存器有自己的磁盤存儲空間,並在存儲空間中保存最近請求過的對象的副本 如圖 2-11 所示,可以配置用戶的瀏覽器,使得用戶的所有 HTTP請求首先指向 Web 緩存器。一旦某瀏覽器被配置,每個對某對象的瀏覽器請求首先被定向到該 Web 緩存器。舉例來說,假設瀏覽器正在請求對象 http://www.someschool. edu/ campus.giI.將會發生如下情況:

  • 瀏覽器建立一個到Web緩存器的TCP連接,並向 Web 緩存器中的對象發送一個HTTP請求
  • Web 緩存器進行檢查,看看本地是否存儲了該對象副本 如果有, Web 緩存器就向客戶瀏覽器用 HTTP 響應報文返回該對象
  • 如果 Web 緩存器中沒有該對象,它就打開一個與該對象的初始服務器(如www. someschool. edu),TCP 連接 Web 緩存器則在這個緩存器到服務器的TCP連接上發送一個對該對象的 HTTP 請求,在收到該請求后,初始服務器向該 Web緩存器發送具有該對象的 HTTP響應
  • 當 Web 緩存器接收到該對象時,它在本地存儲空間存儲一份副本,並向客戶的瀏覽器用盯TP 響應報文發送該副本(通過現有的客戶瀏覽器和 Web 緩存器之間的TCP連接)

DHCP協議

  DHCP(Dynamic Host Configuration Protocol: 動態主機設置協議,DHCP是一個局域網協議,DHCP是應用UDP協議的應用層協議。使用UDP協議工作,主要有兩個用途:給內部網絡或網絡服務供應商自動分配IP地址,給用戶或者內部網絡管理員作為對所有計算機作中央管理的手段。
對於一個 臨時設備,是如何知道自己的IP地址的?
  DHCP服務器監聽默認端口:67,主機使用UDP協議廣播DHCP發現報文,DHCP服務器發出DHCP提供報文,主機向DHCP服務器發出DHCP請求報文,DHCP服務器回應並提供IP地址。

HTTPS

  由於HTTP是明文傳輸的,則HTTPS(Secure)是安全的HTTP協議,默認端口為443,http(s): //<主機>:<端口>/<路徑>

  • A、B是擁有一定數學關係的一組秘鑰
    • 私鑰:私鑰自己使用,不對外公開
    • 公鑰:公鑰給大家使用,對外公開

      使用公鑰加密,使用私鑰解密。

  • 数字證書是可信任組織頒發給特定對象的認證
證書格式、版本號
證書序列號
簽名算法
有效期
對象名稱
對象公開秘鑰
  • SSL(Secure Sockets Layer: 安全套接層)
    • 數據安全和數據完整
    • 對傳輸層數據進行加密後傳輸

HTTPS 原理

  1. 客戶端將它所支持的算法列表和一個用作產生密鑰的隨機數發送給服務器 ;
  2. 服務器從算法列表中選擇一種加密算法,並將它和一份包含服務器公用密鑰的證書發送給客戶端;該證書還包含了用於認證目的的服務器標識,服務器同時還提供了一個用作產生密鑰的隨機數;
  3. 客戶端對服務器的證書進行驗證(有關驗證證書,可以參考数字簽名),並抽取服務器的公用密鑰;然後,再產生一個稱作 pre_master_secret 的隨機密碼串,並使用服務器的公用密鑰對其進行加密(參考非對稱加 / 解密),並將加密后的信息發送給服務器 ;
  4. 客戶端與服務器端根據 pre_master_secret 以及客戶端與服務器的隨機數值獨立計算出加密和 MAC密鑰(參考 DH密鑰交換算法);
  5. 客戶端將所有握手消息的 MAC 值發送給服務器;
  6. 服務器將所有握手消息的 MAC 值發送給客戶端

文件傳輸協議:FTP

  在一個典型的FTP會話中,用戶坐在一台主機(本地主機)前面,向一台遠程主機傳輸(或接收來自遠程主機的)文件 為使用戶能訪問它的遠程賬戶,用戶必須提供一個用戶標識和口令 在提供了這種授權信息后,用戶就能從本地文件系統向遠程主機文件系統傳送文件,反之亦然 如圖 2-14 所示,用戶通過一個FTP用戶代理與FTP交互。該用戶首先提供遠程主機的主機名,使本地主機的FTP客戶進程建立一個到遠程主機FTP服務器進程的 TCP 連接。該用戶接着提供用戶標識和口令,作為 FTP 命令的一部分在該 TCP連接上傳送。一旦該服務器向該用戶授權,用戶可以將存放在本地文件系統中的一個或者多個文件複製到遠程文件系統(反之亦然)。

  HTTP和FTP 都是文件傳輸協議,並且有很多共同的特點,例如,它們都運行在 TCP上,然而,這兩個應用層協議也有一些重要的區別 其中最顯著的就是FTP 使用了兩個并行的 TCP 連接來傳輸文件,一個是控制連接 (control connection) ,一個是數據連接( data connection) 。控制連接用於在兩主機之間傳輸控制信息,如用戶標識、口令、改變遠程目錄的命令以及”存放 (put) “和”獲取 (get)”文件的命令。數據連接用於實際發送一個文件,因為FTP協議使用一個獨立的控制連接,所以我們也稱FTP的控制信息是帶外(out-of-band)傳送的。如你所知,HTTP協議是在傳輸文件的同一個 TCP 連接中發送請求和響應首部行的 因此,HTTP也可以說是帶內 (in-band) 發送控制信息的。FTP協議的控制連接和數據連接如圖二 15 所示:

  當用戶主機與遠程主機開始一個FTP會話時,FTP的客戶(用戶)端首先在服務器21號端口與服務器(遠程主機)端發起一個用於控制的 TCP 連接。FTP的客戶端也通過該控制連接發送用戶的標識和口令,發送改變遠程目錄的命令,當FTP的服務器端從該連接上收到一個文件傳輸的命令后(無論是向還是來自遠程主機) ,就發起一個到客戶端的 TCP 數據連接 FTP 在該數據連接上準確地傳送一個文件,然後關閉該連接。在同一個會話期間,如果用戶還需要傳輸另一個文件,FTP則打開另一個數據連接,因而對FTP傳輸而言,控制連接貫穿了整個用戶會話期間,但是對會話中的每一次文件傳輸都需要建立一個新的數據連接(即數據連接是非持續的)。

  FTP服務器必須在整個會話期間保留用戶的狀態(state) 特別是,服務器必須把特定的用戶賬戶與控制連接聯繫起來,隨着用戶在遠程目錄樹上徘徊,服務器必須追蹤用戶在遠程目錄樹上的當前位置,對每個進行中的用戶會話的狀態信息進行追蹤,大大限制了FTP同時維持的會話總數。而另一方面,前面講過 HTTP 是無狀態的,即它不必對任何用戶狀態進行追蹤。

因特網中的电子郵件

  圖2-16 給出了因特網电子郵件系統的總體情況,從該圖中我們可以看到它有3個主要組成部分: 用戶代理( user agenl) 、郵件服務器 (mail server) 簡單郵件傳輸協議(Simple Mai] Transfer Prolocol , SMTP) 。

SMTP 是因特網电子郵件中主要的應用層協議,它使用 TCP 可靠數據傳輸服務,從發送方的郵件服務器向接收方的郵件服務器發送郵件,像大多數應用層協議一樣, SMTP有兩個部分:運行在發送方郵件服務器的客戶端和運行在接收方郵件服務器的服務器端,每台郵件服務器上既運行 SMTP 的客戶端也運行 SMTP 的服務器端 。當一個郵件服務器向其他郵件服務器發送郵件時,它就表現為 SMTP 的客戶;當郵件服務器從其他郵件服務器上接收郵件時,它就表現為SMTP的服務器。目前有一些流行的郵件訪問協議,包括第三版的郵局協議 (POSl OfficeProtocol-Version 3 , POP3)、因特網郵件訪問協議 (Intemet Mail Access Protocol , IMAP)以及 HTTP。

總結:應用層為操作系統或網絡應用程序提供訪問網絡服務的接口。數據傳輸基本單位為報文;包含的主要協議:FTP(文件傳送協議)、Telnet(遠程登錄協議)、DNS(域名解析協議)、SMTP(郵件傳送協議),POP3協議(郵局協議),HTTP協議(Hyper Text Transfer Protocol)。

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

【其他文章推薦】

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

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

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

※幫你省時又省力,新北清潔一流服務好口碑

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

※產品缺大量曝光嗎?你需要的是一流包裝設計!

Nginx 如何自定義變量?

之前的兩篇文章 Nginx 變量介紹以及利用 Nginx 變量做防盜鏈 講的是 Nginx 有哪些變量以及一個常見的應用。那麼如此靈活的 Nginx 怎麼能不支持自定義變量呢,今天的文章就來說一下自定義變量的幾個模塊以及 Nginx 的 keepalive 特性。

通過映射新變量提供更多的可能性:map 模塊

  • 功能:基於已有變量,使用類似 switch {case: … default: …} 的語法創建新變量,為其他基於變量值實現功能的模塊提供更多的可能性
  • 模塊:ngx_http_map_module 默認編譯進 Nginx,通過 --without-http_map_module 禁用

指令

Syntax: map string $variable { ... }
Default: —
Context: http

Syntax: map_hash_bucket_size size;
Default: map_hash_bucket_size 32|64|128; 
Context: http

Syntax: map_hash_max_size size;
Default: map_hash_max_size 2048; 
Context: http

我們主要看一下 map string $variable { ... } 這個指令。所謂類似 switch case 的語法是指,string 的值可以有多個,可以根據 string 值的不同,來給 $variable 賦不同的值。

規則

  • 已有變量:string 需要是已有的變量,可以分為下面這三種情況
    • 字符串
    • 一個或者多個變量
    • 變量與字符串的組合
  • case 規則:{…} 內的匹配規則需要遵循以下規則,尤其是要注意當使用 hostnames 指令時,與 server name 的匹配規則是一致的,可以看之前的文章 Nginx 的配置指令
    • 字符串嚴格匹配
    • 使用 hostnames 指令,可以對域名使用前綴 * 泛域名匹配
    • ~ 和 ~* 正則表達式匹配,後者忽略大小寫
  • default 規則
    • 沒有匹配到任何規則時,使用 default
    • 確實 default 時,返回空字符串給新變量
  • 其他
    • 使用 include 語法提升可讀性
    • 使用 volatile 禁止變量值緩存

大家看到上面這些規則可能都有些暈,廢話不多說,直接來看一個實戰配置文件就懂了。

實戰

這裏我們有一個配置文件,在這個文件裏面我們定義了兩個 map 塊,分別配置了兩個變量,$name 和 $mobile,$name 中包含 hostnames 指令。

map $http_host $name {
    hostnames;

    default       0;

    ~map\.ziyang\w+\.org.cn 1;
    *.ziyang.org.cn   2;
    map.ziyang.com   3;
    map.ziyang.*    4;
}

map $http_user_agent $mobile {
    default       0;
    "~Opera Mini" 1;
}

server {
	listen 10001;
	default_type text/plain;
	location /{
		return 200 '$name:$mobile\n';
	}
}

下面看一下實際的請求:

  test_nginx curl -H "Host: map.ziyang.org.cn" 127.0.0.1:10001
2:0

為什麼會返回 2:0 呢?我們來看一下匹配順序。

map.ziyang.org.cn 有三個規則可以生效,分別是:

  • ~map.ziyang\w+.org.cn 1;
  • *.ziyang.org.cn 2;
  • map.ziyang.* 4;

而泛域名是優先於正則表達式的,* 在前的泛域名優先於在後面的泛域名,因此最終匹配到的就是:

  • *.ziyang.org.cn 2;

而第二個變量 $mobile 自然走的是 default 規則,不用多說。

這就是 map 模塊的作用,大家可以多嘗試一下。

下面再來看一個與 map 模塊有點類似的 split_clients 模塊,這個模塊也是通過生成新的變量來完成 AB 測試功能的,它可以按照變量的值,按照百分比的方式,生成新的變量。

實現 AB 測試:split_clients 模塊

  • 功能:基於已有變量創建新變量,為其他 AB 測試提供更多的可能性
    • 對已有變量的值執行 MurmurHash2 算法,得到 32 位整形哈希数字,記為 hash
    • 32 位無符號整形的最大数字 2^32-1,記為 max
    • 哈希数字與最大数字相除,hash/max,可以得到百分比 percent
    • 配置指令中指示了各個百分比構成的範圍,如 0-1%,1%-5% 等,及範圍對應的值
    • 當 percent 落在哪個範圍里,新變量的值就對應着其後的參數
  • 模塊:ngx_http_split_clients_module,默認編譯進 Nginx,通過 --without-http_split_clients_module 禁用

規則

  • 已有變量
    • 字符串
    • 一個或者多個變量
    • 變量與字符串的組合
  • case 規則:
    • xx.xx%,支持小數點后 2 位,所有項的百分比相加不能超過 100%
    • *,由它匹配剩餘的百分比(100% 減去以上所有項相加的百分比)

指令

Syntax: split_clients string $variable { ... }
Default: —
Context: http

split_clients 的指令與 map 是非常相似的,可以看一下前面的介紹,這裏不再贅述了。

下面這個配置,來看下有沒有啥問題:

split_clients "${http_testcli}" $variant {
    0.51% .one;
    20.0% .two;
    50.5% .three;
    40% .four;
    * "";
}

細心的同學可能已經發現了,所有的百分比相加已經超過了 100%,所以 Nginx 直接會拋出一個錯誤,禁止執行。

  test_nginx ./sbin/nginx -s reload
nginx: [emerg] percent total is greater than 100% in /Users/mtdp/myproject/nginx/test_nginx/conf/example/17.map.conf:31

然後將 40% .four; 這一行給屏蔽掉再試試看:

  test_nginx curl -H "testcli: split_clients.ziyang.com" --resolve "split_clients.ziyang.com:80:127.0.0.1" http://split_clients.ziyang.com
ABtestfile.three

正常執行。

geo 模塊

geo 模塊與前面兩個模塊也很相似,不同之處在於,這個模塊是基於 IP 地址或者子網掩碼這樣的變量值來生成新的變量的。

  • 功能:根據 IP 地址創建新變量

  • 模塊: ngx_http_geo_module,默認編譯進 Nginx,通過 --without-http_geo_module 禁用

  • 指令

Syntax: geo [$address] $variable { ... }
Default: —
Context: http

規則

  • 如果 geo 指令后不輸入 $address,那麼默認使用 $remote_addr 變量作為 IP 地址

  • {} 內的指令匹配:優先最長匹配

    • 通過 IP 地址及子網掩碼的方式,定義 IP 範圍,當 IP 地址在範圍內時新變量使用其後的參數值

    • default 指定了當以上範圍都未匹配上時,新變量的默認值

    • 通過 proxy 指令指定可信地址(參考 realip 模塊),此時 remote_addr 的值為 X-Forwarded-For 頭部值中最後一個 IP 地址

    • proxy_recursive 允許循環地址搜索

    • include,優化可讀性

    • delete 刪除指定網絡

geo $country {
default ZZ;
#include conf/geo.conf;
#proxy 172.18.144.211;
127.0.0.0/24 US;
127.0.0.1/32 RU;
10.1.0.0/16 RU;
192.168.1.0/24 UK;
}


問題:以下命令執行時,變量 country 的值各為多少?(proxy 實際上為客戶端地址,這裏設置為本機的局域網地址即可,我這裡是 172.18.144.211)

curl -H ‘X-Forwarded-For: 10.1.0.0,127.0.0.2’ geo.ziyang.com
curl -H ‘X-Forwarded-For: 10.1.0.0,127.0.0.1’ geo.ziyang.com
curl -H ‘X-Forwarded-For: 10.1.0.0,127.0.0.1,1.2.3.4’ geo.ziyang.com


結果如下:

```shell
  test_nginx curl -H 'X-Forwarded-For: 10.1.0.0,127.0.0.2' geo.ziyang.com
US
  test_nginx curl -H 'X-Forwarded-For: 10.1.0.0,127.0.0.1' geo.ziyang.com
RU
  test_nginx curl -H 'X-Forwarded-For: 10.1.0.0,127.0.0.1,1.2.3.4' geo.ziyang.com
ZZ

這裏可以看出來,匹配規則實際上是遵循最長匹配的規則的。

geoip 模塊

geoip 模塊可以根據 IP 地址生成對應的地址變量,用法與前面的也都類似,Nginx 是基於 MaxMind 數據庫來生成對應的地址的。

  • 功能:根據 IP 地址創建新變量
  • 模塊: ngx_http_geoip_module,默認未編譯進 Nginx,通過 --with-http_geoip_module 禁用

使用這個模塊是需要安裝 MaxMind 庫的,安裝步驟如下:

  • 安裝 MaxMind 里 geoip 的 C 開發庫(https://dev.maxmind.com/geoip/legacy/downloadable/ )
  • 編譯 Nginx 時帶上 --with-http_geoip_module 參數
  • 下載 MaxMind 中的二進制地址庫,這個地址庫是需要在指令中指定對應的地址的
  • 使用 geoip_country 或者 geoip_city 指令配置好 nginx.conf
  • 運行或者升級 Nginx

geoip_country 指令提供的變量

指令

Syntax: geoip_country file; # 指定國家類的地址文件
Default: —
Context: http

Syntax: geoip_proxy address | CIDR;
Default: —
Context: http

變量

  • $geoip_country_code:兩個字母的國家代碼,比如 CN 或者 US
  • $geoip_country_code3:三個字母的國家代碼,比如 CHN 或者 USA
  • $geoip_country_name:國家名稱,例如 “China”, “United States”

geoip_city 指令提供的變量

指令

Syntax: geoip_city file;
Default: —
Context: http

變量

  • $geoip_latitude:緯度
  • $geoip_longitude:經度
  • $geoip_city_continent_code:位於全球哪個洲,例如 EU 或 AS
  • 與 $geoip_country 指令生成的變量重疊
    • $geoip_country_code:兩個字母的國家代碼,比如 CN 或者 US
    • $geoip_country_code3:三個字母的國家代碼,比如 CHN 或者 USA
    • $geoip_country_name:國家名稱,例如 “China”, “United States”
  • $geoip_region:洲或者省的編碼,例如 02
  • $geoip_region_name:洲或者省的名稱,例如 Zhejiang 或者 Saint Petersburg
  • $geoip_city:城市名
  • $geoip_postal_code:郵編號
  • $geoip_area_code:僅美國使用的郵編號,例如 408
  • $geoip_dma_code:僅美國使用的 DMA 編號,例如 807

keepalive 模塊

前面說的都是 Nginx 的變量相關的內容,其實 Nginx 還有一個很具有特色的模塊,那就是 keepalive 模塊,由於內容不是很多,所以我就直接寫到這篇文章裏面了,單寫一篇顯得內容不夠哈。

這裏指的是 HTTP 的 keepalive,TCP 也有 keepalive,後面會說。

而且是對客戶端的 keepalive,不是對上游服務器的。

  • 功能:多個 HTTP 請求通過復用 TCP 連接,可以實現以下功能:

    • 減少握手次數
    • 通過減少併發連接數減少了服務器資源消耗
    • 降低 TCP 擁塞控制的影響,保證滑動窗口維持在一個最優的大小
  • Connection 頭部

    • close:表示請求處理完就關閉連接
    • keepalive:表示復用連接處理下一條請求
  • Keepalive 頭部:timeout=n,單位是秒,表示連接至少保持 n 秒

指令

對客戶端行為控制的指令:

Syntax: keepalive_disable none | browser ...;
Default: keepalive_disable msie6; 
Context: http, server, location

Syntax: keepalive_requests number;
Default: keepalive_requests 100; 
Context: http, server, location

Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s; 
Context: http, server, location
  • keepalive_disable 設置為 none 表示對所有瀏覽器啟用 keepalive,msie6 表示在老版本 MSIE 上禁用 keepalive
  • keepalive_requests 設置允許保持 keepalive 的請求的數量
  • keepalive_timeout 表示超時時間

好了,關於 Nginx 的模塊介紹就已經全部介紹完了,有興趣的同學可以去翻我前面的系列文章。當然還有一部分重要的內容還沒有介紹,那就是關於 Nginx 的反向代理和負載均衡部分,這塊咱們單獨抽出來說,別著急,馬上乾貨就出來。

本文首發於我的個人博客:iziyang.github.io,所有配置文件我已經放在了 Nginx 配置文件,大家可以自取。

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

【其他文章推薦】

新北清潔公司,居家、辦公、裝潢細清專業服務

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

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

※超省錢租車方案

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

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

【案例演示】JVM之強引用、軟引用、弱引用、虛引用

1.背景

想要理解對象什麼時候回收,就要理解到對象引用這個概念,於是有了下文

2.java中引用對象結構圖

3.引用詳解

3.1.什麼是強引用

a.當內存不足,JVM開始垃圾回收,對於強引用的對象,就算是出現了00M也不會對該對象進行回收,死都不收。

b.強引用是我們最常見的普通對象引用,只要還有強引用指向一個對象,就能表明對象還“活着”,垃圾收集器不會碰這種對象。

在Java中最常見的就是強引用,把一個對象賦給一個引用變量,這個引用變量就是一個強引用。

當一個對象被強引用變量引用時,它處於可達狀態,它是不可能被垃圾回收機制回收的,即使該對象以後永遠都不會被用到JVM也不會回收。

因此強引用是造成Java內存泄漏的主要原因之一

c.對於一個普通的對象,如果沒有其他的引用關係,只要超過了引用的作用域或者顯式地將相應(強)引用賦值為null,一般認為就是可以被垃圾收集的了〈當然具體回收時機還是要看垃圾收集策略)。

案例:

package com.wfd360.demo03GC.referDemo;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 12:12
 * @description
 */
public class StrongRefer {
    /**
     * 強引用的理解
     *
     * @param args
     */
    public static void main(String[] args) {
        Object obj1 = new Object();
        // 建立強引用
        Object obj2 = obj1;
        // 觀察obj1 和 obj2 的各種內存地址
        System.out.println("obj1=" + obj1);
        System.out.println("obj2=" + obj2);
        // obj1創建可以回收的條件
        obj1 = null;
        // gc回收
        System.gc();
        // 觀察各對象情況
        System.out.println("obj1=" + obj1);
        System.out.println("obj2=" + obj2);
    }
}

View Code

 從測試結果課程看出,obj1的實際對象別沒有回收;

3.2.什麼是軟引用

a.軟引用是用來描述一些還有用但並非必需的對象,需要用java.lang.ref.SoftReference類來實現。

b.對於軟引用關聯着的對象,在系統將要發生內存溢出異常之前,將會把這些對象列進回收範圍之中進行第二次回收。如果這次回收還沒有足夠的內存,才會拋出內存溢出異常。在JDK1.2之後,提供了Soft Reference類來實現軟引用。

c.軟引用通常用在對內存敏感的程序中,比如高速緩存就有用到軟引用,內存夠用的時候就保留,不夠用就回收!

案例:

package com.wfd360.demo03GC.referDemo;

import java.lang.ref.SoftReference;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 12:12
 * @description
 */
public class SoftRefer {

    /**
     * 軟引用的理解
     * 通過設置jvm參數,在不同的條件下觀察
     *
     * @param -Xms5m -Xmx5m -XX:+PrintGCDetails
     * @param args
     */
    public static void main(String[] args) {
        // 測試內存充足(不回收軟引用)
        //testSoftReferNOGc();
        // 測試內存不充足(回收軟引用)
        testSoftReferGc();
    }

    /**
     * 模擬內存充足的情況
     */
    public static void testSoftReferNOGc() {
        Object obj1 = new Object();
        // 建立軟引用
        SoftReference softRefer = new SoftReference<>(obj1);
        // 觀察內存地址
        System.out.println("obj1=" + obj1);
        System.out.println("softRefer=" + softRefer.get());
        // obj1創建可以回收的條件
        obj1 = null;
        // gc回收
        System.gc();
        // 再次觀察內存地址
        System.out.println("obj1=" + obj1);
        System.out.println("softRefer=" + softRefer.get());
    }

    /**
     * 模擬內存不足
     * 1.設置較小的堆內存
     * 2.創建大對象
     * 3.jvm參
     * -Xms5m -Xmx5m -XX:+PrintGCDetails
     */
    public static void testSoftReferGc() {
        Object obj1 = new Object();
        // 建立軟引用
        SoftReference softRefer = new SoftReference<>(obj1);
        // 觀察內存地址
        System.out.println("obj1=" + obj1);
        System.out.println("softRefer=" + softRefer.get());
        // obj1創建可以回收的條件
        obj1 = null;
        try {
            byte[] bytes = new byte[6 * 1024 * 1024];
        } catch (Throwable e) {
            System.out.println("===============>error:" + e.getMessage());
        } finally {
            // 再次觀察內存地址
            System.out.println("obj1=" + obj1);
            System.out.println("softRefer=" + softRefer.get());
        }
    }
}

View Code

內存充足測試結果:

 內存不充足測試結果:

 實際案例

假如有一個應用需要讀取大量的本地數據(圖片、通訊率、臨時文件等):

如果每次讀取數據都從硬盤讀取則會嚴重影響性能,

如果一次性全部加載到內存中又可能造成內存溢出。

此時使用軟引用可以解決這個問題。

設計思路是:用一個HashMap來保存數據的路徑和相應數據對象關聯的軟引用之間的映射關係,在內存不足時,

JVM會自動回收這些緩存數據對象所佔用的空間,從而有效地避免了00M的問題。

Map<String,SoftReference>imageCache=new HashMap<String,SoftReference>();

 3.3.什麼是弱引用

a.弱引用也是用來描述非必需對象的,但是它的強度比軟引用更弱一些,被弱引用關聯的對象只能生存到下一次垃圾收集發生之前。

b..當垃圾收集器工作時,無論當前內存是否足夠,都會回收掉只被弱引用關聯的對象。在JDK1.2之後,提供廣Weak Reference類來實現弱引用。

c.弱引用需要用Java.lang.ref.WeakReference類來實現,它比軟引用的生存期更短.

案例:

package com.wfd360.demo03GC.referDemo;

import java.lang.ref.WeakReference;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 12:12
 * @description
 */
public class WeakRefer {

    /**
     * 弱引用的理解
     *
     * @param args
     */
    public static void main(String[] args) {
        Object obj1 = new Object();
        // 建立弱引用
        WeakReference softRefer = new WeakReference<>(obj1);
        // 觀察內存地址
        System.out.println("obj1=" + obj1);
        System.out.println("softRefer=" + softRefer.get());
        // obj1創建可以回收的條件
        obj1 = null;
        // gc回收
        System.gc();
        // 再次觀察內存地址
        System.out.println("obj1=" + obj1);
        System.out.println("softRefer=" + softRefer.get());
    }

}

View Code

 擴展知識-WeakHashMap

查看API介紹:

 測試代碼:

package com.wfd360.demo03GC.referDemo;

import java.util.HashMap;
import java.util.WeakHashMap;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 5:10
 * @description <p>
 * 弱引用引用之:WeakHashMap
 * 以弱鍵 實現的基於哈希表的 Map。在 WeakHashMap 中,當某個鍵不再正常使用時,將自動移除其條目。
 * 更精確地說,對於一個給定的鍵,其映射的存在並不阻止垃圾回收器對該鍵的丟棄,這就使該鍵成為可終止的,被終止,
 * 然後被回收。丟棄某個鍵時,其條目從映射中有效地移除,因此,該類的行為與其他的 Map 實現有所不同。
 * </p>
 */
public class WeakReferMap {
    /**
     * 測試 HashMap 與 WeakHashMap 區別
     * 測試邏輯:
     * 1.創建不同的map
     * 2.創建key  value值
     * 3.放入各自的map,並打印結果
     * 4.將key設置為null,並打印結果
     * 5.手動GC,並打印結果
     *
     * @param args
     */
    public static void main(String[] args) {
        hashMapMethod();
        System.out.println("--------華麗的分割線--------");
        weakHashMapMethod();
    }

    /**
     * HashMap測試(強引用)
     */
    private static void hashMapMethod() {
        HashMap<String, String> map = new HashMap<>();
        String key = "key1";
        String value = "HashMap-value";

        map.put(key, value);
        System.out.println(map);

        key = null;
        System.out.println(map);

        System.gc();
        System.out.println(map);
    }

    /**
     * 若引用(WeakHashMap測試)
     */
    private static void weakHashMapMethod() {
        WeakHashMap<String, String> map = new WeakHashMap<>();
        // 注意這裏的new一個字符串與直接寫key="key2"對測試結果是有區別的,詳細原因可以看之前講的內存分配
        String key = new String("key2");
        String value = "WeakHashMap-value";

        map.put(key, value);
        System.out.println(map);

        key = null;
        System.out.println(map);

        System.gc();
        System.out.println(map);

    }

}

View Code

測試結果:

 從測試結果可以看出:弱引用的map數據已經被回收。

 擴展知識-ReferenceQueue引用隊列

 代碼:

package com.wfd360.demo03GC.referDemo;

import java.lang.ref.ReferenceQueue;
import java.lang.ref.WeakReference;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 7:23
 * @description
 */
public class QueueRefer {
    /**
     * 測試弱引用回收前,把數據放入隊列中
     *
     * @param args
     * @throws InterruptedException
     */
    public static void main(String[] args) throws InterruptedException {
        Object obj1 = new Object();
        ReferenceQueue<Object> referenceQueue = new ReferenceQueue();
        // 當GC釋放對象內存的時候,會將引用加入到引用隊列
        WeakReference<Object> weakReference = new WeakReference<>(obj1, referenceQueue);

        System.out.println(obj1);
        System.out.println(weakReference.get());
        System.out.println(referenceQueue.poll());

        System.out.println("--------華麗的分割線--------");
        obj1 = null;
        System.gc();
        Thread.sleep(500);

        System.out.println(obj1);
        System.out.println(weakReference.get());
        System.out.println(referenceQueue.poll());
    }

}

View Code

採用弱引用的方式測試結果:

從測試結果可以看出,需要回收的對象已經進入隊列。

 採用軟引用的方式測試結果:

 從測試結果可以看出,軟引用,沒有到達回收的條件,並沒有進行回收,也不會進入隊列;

3.4.什麼是虛引用

1.虛引用需要java.lang.ref.PhantomReference類來實現。

2.與其他幾種引用都不同,虛引用並不會決定對象的生命周期。如果一個對象僅持有

虛引用,那麼它就和沒有任何引用一樣,在任何時候都可能被垃圾回收器回收,它不能單獨使用也不能通過它訪

問對象,虛引用必須和引用隊列(ReferenceQueue)聯合使用。

3.虛引用的主要作用是跟蹤對象被垃圾回收的狀態。僅僅是提供了一種確保對象被finalize以後,做某些事情的

機制。PhantomReference的get方法總是返回null,因此無法訪問對應的引用對象。其意義在於說明一個對象己

經進入俑finalization階段,可以被gc回收,用來實現比finalization機制更靈活的回收操作。

4.設置虛引用關聯的唯一目的,就是在這個對象被收集器回收的時候收到一個系統通知或者後續添加

進一步的處理。Java技術允許使用finalize()方法在垃圾收集器將對象從內存中清除出去之前做必要的清理工作。

代碼:

package com.wfd360.demo03GC.referDemo;

import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 7:44
 * @description
 */
public class PhantomRefer {
    /**
     * 虛引用測試
     * @param args
     * @throws InterruptedException
     */
    public static void main(String[] args) throws InterruptedException {
        Object obj1 = new Object();
        ReferenceQueue<Object> referenceQueue = new ReferenceQueue();
        PhantomReference<Object> phantomReference = new PhantomReference<>(obj1,referenceQueue);

        System.out.println(obj1);
        System.out.println(phantomReference.get());
        System.out.println(referenceQueue.poll());

        System.out.println("--------華麗的分割線--------");

        obj1 = null;
        System.gc();
        Thread.sleep(500);

        System.out.println(obj1);
        System.out.println(phantomReference.get());
        System.out.println(referenceQueue.poll());
    }

}

View Code

測試結果:

4.重要總結

對象是否存活判斷流程:

1.可達性分析,看是否有GC Roots的引用鏈,如果沒有將做第一次標記;

2.檢查是否需要執行finalize()方法,

如果沒必要(之前執行過了),直接回收內存;

如果要執行finalize()方法,這個時候對象如果再次建立引用鏈(唯一自救機會),對象不會被回收,否則直接回收;

總結:

1.對象回收滿足兩個條件:

a.沒有引用鏈。

b.回收前會執行finalize()方法,如果執行finalize(),沒有再次建立連接(如果重新與引用鏈上的任意對象建立連接,例如給對象賦值,該對象都不會被回收)

2.在gc回收前會執行finalize()方法,只執行一次,並且是異步執行不保證執行成功,線程優先級低

代碼演示:

package com.wfd360.demo03GC.referDemo;

/**
 * @author 姿勢帝-博客園
 * @address https://www.cnblogs.com/newAndHui/
 * @WeChat 851298348
 * @create 06/20 8:34
 * @description
 */
public class FinalizeGC {
    public static FinalizeGC obj1 = null;

    /**
     * 重寫finalize方法
     * @throws Throwable
     */
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("執行finalize方法");
        // 自救,在回收時建立引用鏈
        FinalizeGC.obj1 = this;
    }

    public static void main(String[] args) throws InterruptedException {
        obj1  = new FinalizeGC();

        obj1 = null;
        System.gc();
        Thread.sleep(600);
        System.out.println("第一次自救成功:"+obj1);

        obj1 = null;
        System.gc();
        Thread.sleep(600);
        System.out.println("第二次自救失敗,不會再次執行finalize方法:"+obj1);
    }
}

View Code

測試結果:

 完美!

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

【其他文章推薦】

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

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

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

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

新北清潔公司,居家、辦公、裝潢細清專業服務

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

垃圾回收相關算法

這裏介紹的垃圾回收相關算法,主要解決的問題:

判斷哪些內存是垃圾(需要回收的)?

常用的兩種算法:

  • 引用計數
  • 可達性分析(GC Root)

首先介紹算法前,得定義:

如何判斷一個對象的死亡?

我們一般這樣定義:當一個對象不再被任何存活的對象繼續引用的時候,這個對象就死亡了。

引用計數

引用計數算法,是給每一個對象添加一個計數器,當有對象引用它的時候,計數器+1,當有對象取消對它的引用時,計數就會-1。

當計數器的值為 0 時,即說明沒有對象引用它,也就是這個對象死亡了。

這種算法很簡單,但是有個重大缺陷,那就是無法解決循環引用的問題。

什麼是循環引用問題呢?

比如對象A 引用 對象B,對象B 引用 對象A,那麼 對象A 和 對象B 的計數器都為1。但是如果後續的運行環境再也用不到對象A 和 對象B,那麼就造成了內存泄漏。

上圖就是循環引用的例子。對象引用 Obj1 和 Obj2 在棧中,然後分別指向在堆中的具體實例。然後兩個相互實例中的成員互相引用。那麼對於堆中的對象而言,就有2個引用。一個是來自Obj1,一個來自堆對象的另一方。

如果,現在將 Obj1 指向 nu l l,那麼就如下圖:

這個時候,引用已經不可用了,但是堆中的對象仍然相互引用,他們的計數器不為0,所以無法死亡。

但是,Java 沒有使用這種算法,而是使用了我們後面說的可達性算法,所以接下來的演示,GC 會將這種情況的內存給其清理。

package GC;

public class ReferenceCountGC {
    public Object instance = null;

    private static final int _1MB = 1024 * 1024;
    // 每個對象中包含2M的成員,方便觀察
    private byte[] bigSize = new byte[2 * _1MB];
    public static void main(String[] args) {
        ReferenceCountGC objA = new ReferenceCountGC();
        ReferenceCountGC objB = new ReferenceCountGC();
        objA.instance = objB.instance;
        objB.instance = objA.instance;

        //取消對對象的引用
        objA = null;
        objB = null;
      // 是否進行垃圾回收
        System.gc();
    }
}

這段代碼實現的就是上面圖片所描述的情況。

首先,我們將 System.gc() 註釋掉,也就是我們在默認情況下,不去觸發垃圾回收。並在運行的時候,添加參數 -XX:+PrintGCDetails。我們觀察輸出結果

可以看到,這個時候,佔用的空間為8M左右。

如果我們取消註釋,也就是主動去調用垃圾回收器,那麼運行結果為:

佔用空間為2M左右。

可以看出來,Java 的垃圾回收,並非採用我們上面介紹的引用計數方式。

可達性分析

可達性算法,還有一系列的別名:根搜索算法,追蹤性垃圾收集,GC Root。

之後,看到原理,其實這些別名都是描述原理的。

首先,我們選取一些對象,這些對象是存活的,也被稱為 GC Roots,然後根據這些對象的引用關係,凡是直接或者間接跟 GC Roots 相關聯的對象,都是存活的。就像圖中的連通性判斷一樣。

這個算法的想法不難。難的是,如何確定 GC Roots。

我們考慮,我們什麼時候需要用到對象?(我們需要對象的時候,肯定需要這個對象是存活的)

  • 棧中保存着,我們當前或者之後需要運行的方法及相關參數,所以,棧上所引用的堆中對象肯定是存活的。
  • 類中的一些屬性,比如,靜態屬性,因為它不依賴於具體的類
  • 一些常用的對象,以免清理后,又要重複加載,比如常用的異常對象,基本數據類型對應的 Class 對象。

除此之外,還有很多零零碎碎的。

在堆結構周圍的一些結構,其中引用的對象可以作為GC Roots

具體 GC Roots 可以概括為:

  • 虛擬機棧上(確切的說,是棧幀上的本地變量表)所引用的對象

  • 本地方法棧引用的對象

  • 方法區中的靜態屬性,常量引用

  • Java 虛擬機的內部引用,常用數據類型的 Class 對象,常駐的異常對象,系統類加載器

  • 所有被同步鎖持有的對象

除此之外,還有一些臨時的 GC Roots 可以加入進來。這裏涉及到新生代老年代。

比如老年代中的對象一般都存活時間比較久,也就是大概率是活着的對象,也可臨時作為 GC Roots。

可達性算法的一些細節

前面說了可達性算法,我們根據 GC Roots 來進行標記對象的死活。

但是,被判定為不可達的對象,並不立刻死亡。它仍然有次機會進行自救。

這個自救的機會,是需要重寫 finalize()進行自救。

也就是可達性算法的邏輯大致是這樣的:

  • 第一次進行標記,凡是不可達 GC Roots 的對象,都暫時判定為死亡,只是暫時
  • 檢查暫時被判定為死亡對象,檢查是否有重寫 finalize()方法,如果有,則觸發,對象可以在裏面完成自救。

如果沒有自救成功 或者 沒有重寫 finalize()方法,則宣告這個對象的死亡。

除此之外,這個對象中的 finalize()方法,只能被調用一次,一生只有一次自救機會。

這個方法,官方並不推薦,所以不必細究。

接下來,演示下上面的兩次標記過程以及自救過程。

(個人認為,《深入理解 Java 虛擬機》中的此章節代碼,略有點不夠完善,故略微改動)

package GC;

import javax.swing.tree.VariableHeightLayoutCache;

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    private byte[] bigSize = new byte[5*1024*1024];

    public void isAlive(){
        System.out.println("Yes, i am alive");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("Finalize method executed");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if(SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
            System.gc();
        }else {
            System.out.println("Dead");
            System.gc();
        }
    }
}

在這個程序中,我們給這個類,添加名為 bigSize 的屬性,其佔用 4M 大小的空間。

大致分析下代碼邏輯:

  • 創建了一個對象,其中有成員佔用 4M 的空間
  • 取消對這個對象的引用
  • 調用垃圾回收(第一次標記)
  • 調用 finalize 方法進行自救
  • 之後再次調用垃圾回收(第二次標記)

所以演示的時候,分為兩種情況:

  • FinalizeEscapeGC.SAVE_HOOK = this; 未註釋,完成自救

運行時,參數仍然設置為 +XX:PrintGCDetails,可以看到輸出結果:

第一次調用垃圾回收,仍然佔用 5M,說明此時即便失去引用,但是仍然未被清理。

在 finalize()中完成自救后,第二次調用垃圾回收的時候,仍然佔用 5M 的內存大小。說明自救成功。

  • FinalizeEscapeGC.SAVE_HOOK = this; 註釋,無法完成自救

第一次垃圾回收,佔用 5M,保留了對象。無法完成自救,然後第二次被清理掉。

所以我發現以下錶述也許更為確切:

  • 當對象重寫了 finalize()方法的時候,第一次垃圾回收的時候,如果為不可達對象,對其進行暫緩,並不清理。
  • 當對象沒有重寫 finalize()方法的時候,且為不可達對象的時候,直接判定死亡。

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案