陸充電樁建設料加速,充換電設備規模上看千億RMB

大陸工信部部長近日表示,今(2016)年新能源車產銷有望成長一倍以上,並著力突破充電樁等環節發展瓶頸。根據在此之前出臺的電動汽車充電基礎設施發展指南提出,到2020年新增分散式充電樁超過480萬個,滿足500萬輛電動車的充電需求。陸媒引述機構估算,到2020年,充換電設備市場規模將達到1,240億元(人民幣,下同),且在政策推動和市場需求雙重推動下,充電網路建設運營發展可望進一步加速,相關訂單也將進入落實階段。

充電網路作為大陸新能源車推廣的基礎設施,獲得系列政策扶持。今年1月,財政部等五部委聯合發佈十三五充電基礎設施獎勵政策通知,明確2016-2020年中央財政將繼續安排資金對充電基礎設施建設、運營給予獎補。《通知》中要求獎補資金應當專門用於支持充電設施建設運營、改造升級、充換電服務網路運營監控系統建設等相關領域。其中,對於今年大氣污染治理重點城市,在標準車推廣量不低於3萬輛時,可獲得充電設施獎勵9,000萬元。

去年11月,大陸發改委印發的2015-2020年電動汽車充電基礎設施發展指南,按照適度超前原則明確充電基礎設施建設目標,到2020年滿足全國500萬輛電動汽車充電需求。同時,優先建設公交、出租及環衛與物流等公共服務領域充電基礎設施,新增超過3,850座公車充換電站、2,500座計程車充換電站、2,450座環衛物流等專用車充電站;另將結合骨幹高速公路網,建設「四縱四橫」的城際快充網路,新增超過800座城際快充站,以滿足城際出行需要。

而大陸各地方政府也在積極落實充電網路建設,京滬等重點城市進展最快。根據京津冀充電設施協同建設的需求,國網北京市電力公司今年計畫將建設14座高速公路快充站、5,880個城市快充樁,今年年底前實現北京區域內高速公路服務區全覆蓋。日前,上海提出到今年底,新能源汽車分時租賃服務網點超過1,000個,純電動汽車超過3,000輛,充電樁超過5,000個。

機構認為,大陸新能源車高速發展將迫使充電設施建設加速,預計今年充電設施投資將超過百億元,增速達到400%以上,未來幾年均有望保持高速增長;同時,充電樁管理APP等互聯網工具在充電運營網路的應用,加強充電樁統一管理的同時,也有望構建新的獲利模式。

(本文內容由授權使用;首圖來源: CC BY 2.0)

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

【其他文章推薦】

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

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

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

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

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

etcd-operator快速入門完全教程

Operator是指一類基於Kubernetes自定義資源對象(CRD)和控制器(Controller)的雲原生拓展服務,其中CRD定義了每個operator所創建和管理的自定義資源對象,Controller則包含了管理這些對象所相關的運維邏輯代碼。

對於普通用戶來說,如果要在k8s集群中部署一個高可用的etcd集群,那麼不僅要了解其相關的配置,同時又需要特定的etcd專業知識才能完成維護仲裁,重新配置集群成員,創建備份,處理災難恢復等等繁瑣的事件。

而在operator這一類拓展服務的協助下,我們就可以使用簡單易懂的YAML文件(同理參考Deployment)來聲明式的配置,創建和管理我們的etcd集群,下面我們就來一同了解下etcd-operator這個服務的架構以及它所包含的一些功能。

目 標

  1. 了解etcd-operator的架構與CRD資源對象

  2. 部署etcd-operator

  3. 使用etcd-operator創建etcd cluster

  4. 基於etcd-operator備份和恢復etcd cluster

服務架構

etcd-operator的設計是基於k8s的API Extension機制來進行拓展的,它為用戶設計了一個類似於Deployment的Controller,只不過這個Controller是用來專門管理etcd這一服務的。

用戶默認還是通過kubectl或UI來與k8s的API進行交互,只不過在這個k8s集群中多了一個用戶自定義的控制器(custom controller),operator controller的服務是以Pod的方式運行在k8s集群中的,同時這個服務也需要配置所需的RBAC權限(比如對Pod,Deployment,Volume等使用到的資源進行增刪改查的操作),下面我們用一個簡單的架構圖來進行闡述:

etcd-operator的自定義資源對象(CRD)

在k8s中,所有自定義的Controller和其自定義的資源對象(CRD)都必須滿足k8s API的規範(參考下圖):

  • apiVersion描述了當前自定義資源對象的版本號

  • Kind表示自定義資源對象的名稱,用戶可通過執行kubectl get $KIND_NAME來獲取所創建的CRD對象

  • Metadata繼承了原生k8s的metadata,用於添加標籤,Annotations等元數據

  • Spec是用戶可自定義設計的服務配置參數,如鏡像版本號,節點數量,資源配置等等..

  • Status包含了當前資源的的相關狀態,每個operator controller可自定義status所包含的信息,一般會選擇添加如conditions,updateTime和message等一類的信息。

下面先我們來了解一下etcd-operator所包含的幾個自定義資源對象(CRDs):

1、EtcdCluster: etcdcluster用來描述用戶自定義的etcd集群,可一鍵式部署和配置一個相關的etcd集群。

apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: etcd-cluster
spec:
  size: 3
  version: 3.2.25

2、EtcdBackup: etcdbackup用來描述和管理一個etcd集群的備份,當前支持定期備份到雲端存儲,如AWS s3, Aliyun oss(oss當前需使用quay.io/coreos/etcd-operator:dev鏡像)。


apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdBackup
metadata:
  name: etcd-backup
spec:
  etcdEndpoints: [<etcd-cluster-endpoints>]
  storageType: OSS #options are S3/ABS/GCS/OSS
  backupPolicy:
    backupIntervalInSecond: 125
    maxBackups: 4
  oss:
    #"<oss-bucket-name>/<path-to-backup-file>"
    path: <full-oss-path>
    ossSecret: <oss-secret>
    # Details about regions and endpoints, see https://www.alibabacloud.com/help/doc-detail/31837.htm
    endpoint: <endpoint> 

3、EtcdRestore:etcdrestore用來幫助將etcdbackup服務所創建的備份恢復到一個指定的etcd的集群。

apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdRestore
metadata:
  # name must be same to the spec.etcdCluster.name
  name: example-etcd-cluster
spec:
  etcdCluster:
    name: example-etcd-cluster
  backupStorageType: OSS
  oss:
    path: <full-oss-path> 
    ossSecret: <oss-secret>
    endpoint: <endpoint>

如何部署和使用etcd-operator

1、部署etcd-operator

在Rancher最新的stable v2.3.2 的版本中,用戶可通過應用商店(Catalog)來一鍵式部署 etcd-operator v0.9.0版本,同時原生k8s也可下載rancher/charts到本地后通過helm install的方式進行部署。

1)(可選)部署etcd-operator時可選擇同時創建一個etcd集群(此集群在etcd-operator被刪除時會被一同移除),當然用戶也可待etcd-operator部署完成通過kubectl apply -f myetcd.yaml來創建一個新的etcd集群。

2)部署時,如果用戶選擇啟動Enable Clusterwide of etcd Operator這個選項,那麼這個etcd-operator將作為集群層級對象來使用(否則為namespaced隔離),如果enable這個選項,那麼在創建etcd集群時需添加以下註釋才能創建創建:

kind: EtcdCluster
metadata:
  name: etcd-cluster
  # add this annotation when the clusterWide is enabled
  annotations:
    etcd.database.coreos.com/scope: clusterwide

2、創建etcd集群

接下來我們就可以使用上述的CRD自定義資源對象對來創建和管理我們的etcd集群了。

2.1 手動創建etcd集群

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: "etcd-cluster"
spec:
  size: 3 # 默認etcd節點數
  version: "3.2.25" # etcd版本號
EOF

2.2 部署后可通過CRD對象來查看我們創建的etcd集群和pod狀態

$ kubectl get etcdcluster
NAME            AGE
etcd-cluster    2m

$ kubectl get pod
NAME                     READY   STATUS  RESTARTS AGE
etcd-cluster-g28f552vvx  1/1   Running    0      2m
etcd-cluster-lpftgqngl8  1/1   Running    0      2m
etcd-cluster-sdpcfrtv99  1/1   Running    0      2m

2.3 可以往etcd集群任意的寫入幾條數據驗證etcd集群是正常工作的(後續也可用來驗證集群的備份和恢復功能)

$ kubectl get svc
NAME                  TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
etcd-cluster          ClusterIP   None           <none>        2379/TCP,2380/TCP   17h
etcd-cluster-client   ClusterIP   10.43.130.71   <none>        2379/TCP            17h
## write data
$ kubectl exec -it any-etcd-pod -- env "ETCDCTL_API=3" etcdctl --endpoints http://etcd-cluster-client:2379 put foo "Hello World"
## get data
$ kubectl exec -it any-etcd-pod -- env "ETCDCTL_API=3" etcdctl --endpoints http://etcd-cluster-client:2379 get foo
foo
Hello World

3、基於operator備份etcd cluster

3.1 確認了etcd集群正常運行后,作為devops後面要考慮的就是如何創建etcd集群的自動化備份,下面以阿里雲的OSS舉例:

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdBackup
metadata:
  name: example-etcd-cluster-periodic-backup
spec:
  etcdEndpoints: [http://etcd-cluster-client:2379] #內網可使用svc地址,外網可用NodePort或LB代理地址
  storageType: OSS
  backupPolicy:
    backupIntervalInSecond: 120 #備份時間間隔
    maxBackups: 4 #最大備份數
  oss:
    path: my-bucket/etcd.backup
    ossSecret: oss-secret #需預先創建oss secret
    endpoint: oss-cn-hangzhou.aliyuncs.com
EOF

3.2 若OSS Secret不存在,用戶可先手動創建,具體配置可參考如下:

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: oss-secret
type: Opaque
stringData:
  accessKeyID: myAccessKey
  accessKeySecret: mySecret
EOF

3.3 待etcdbackup創建成功后,用戶可以通過kubectl describe etcdbackup或查看etcd-backup controller日誌來查看備份狀態,如狀態显示為Succeeded: true,可以前往oss查看具體的備份內容。

4、基於operator恢復etcd cluster

最後,假設我們要將etcd集群A的備份數據恢復到另一個新的etcd集群B,那麼我們先手動創建一個名為etcd-cluster2的新集群(oss備份/恢復當前需使用quay.io/coreos/etcd-operator:dev鏡像)。

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: "etcd-cluster2"
spec:
  size: 3
  version: "3.2.25"
EOF

然後通過創建etcdresotre將備份數據恢復到etcd-cluster2集群


cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdRestore
metadata:
  # name必須與下面的spec.etcdCluster.name保持一致
  name: etcd-cluster2
spec:
  etcdCluster:
    name: etcd-cluster2
  backupStorageType: OSS
  oss:
    path: my-bucket/etcd.backup_v1_2019-08-07-06:44:17
    ossSecret: oss-secret
    endpoint: oss-cn-hangzhou.aliyuncs.com
EOF

待etcdresotre對象創建成功后,可以查看etcd-operator-restore的日誌,大致內容如下:

$ kubectl logs -f etcd-operator-restore
...
time="2019-08-07T06:50:26Z" level=info msg="listening on 0.0.0.0:19999"
time="2019-08-07T06:50:26Z" level=info msg="starting restore controller" pkg=controller
time="2019-08-07T06:56:25Z" level=info msg="serving backup for restore CR etcd-cluster2"

通過kubectl查看pod我們可以看到etcd-cluster2集群的etcd節點被刪除重建:

NAME                       READY   STATUS    RESTARTS   AGE
etcd-cluster2-5tq2d5bvpf    0/1     Terminating   0      93s
etcd-cluster2-kfgvc692pp    1/1     Terminating   0      101s
etcd-cluster2-xqkgz8chb8    0/1     Init:1/3      0      6s
etcd-cluster2-pf2qxgtg9d    1/1     Running       0      48s
etcd-cluster2-x92l9vpx97    1/1     Running       0      40s

最後可通過etcdctl來驗證之前的數據是否存在(需設置ETCDCTL_API=3):

$ kubectl exec -it etcd-pod -- env "ETCDCTL_API=3" etcdctl --endpoints http://etcd-cluster2-client:2379 get foo
foo
Hello World

小 結

Etcd作為當前非常流行的key-value分佈式文件存儲,它本身的強一致性和較優的性能可以為許多分佈式計算解決分佈式存儲的需求,如果你的微服務和應用需要用到此類的數據庫,不妨來試試Rancher Catalog應用中的etcd-operator吧,Just do it!

相關資料:

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

【其他文章推薦】

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

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

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

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

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

※試算大陸海運運費!

思源:秒級體驗百億級數據量監控鑽取

編者薦語:

當業務量快速增長的時候,業務保障平台就要應運而生,預判問題發出告警,越快越好,從宏觀到微觀一路下鑽響應越快越好,尤其是交易量暴漲的高峰時段。怎麼做到?看思源的現身說法:

以下文章來源於雲縱達摩院 ,作者劉勤紅

 

——業務保障平台性能提升走過的那些路
禧雲信息/研發中心/劉勤紅(思源) 2019年11月
 
業務保障平台需從多維度去監控業務的可靠性,快速定位問題並自動解決或推薦出解決方案,所以時效性顯得非常重要。接下來我將從以下三個維度展開如何將百億級數據量監控鑽取從十幾秒提升到秒級體驗:
· 工具升級:OpenTSDB–>Druid
· 調用鏈收集的優化
· 聚合查詢的優化
 

一、背景回顧

· 禧雲的團餐業務發展非常迅速,短短几個月的時間,日交易量就從數百萬拉高到千萬級,隨着調用鏈追蹤得愈發細緻,業務數據量也從億級上升到百億級別。
· 團餐的高峰交易量比外賣更集中,外賣可以提前預訂,而團餐的早中晚就餐非常集中,全國的學生幾乎都是一個點兒下課,從下單到吃完也就集中在20-30分鐘內,下圖0為交易量的曲線圖,坡度幾乎是直線上升,真是爭分奪秒!

圖0 團餐高峰期爭分奪秒不容有失
在這種高強度業務場景下,業務保障平台應運而生,它主要是多場景多維度實時監控大盤,從設備終端到服務端全鏈路監控,讓技術團隊從事後追查和整改,轉變為事前預警和快速判定根因。它主要涉及交易、業務調用鏈路、網絡監控、設備運行指標、業務日誌等維度數據。架構如下圖1所示。
圖1 基於OpenTSDB版的大致架構
· 千萬級日交易數據:從各業務系統或支付網關迴流的交易數據—>交易迴流服務—>多維度聚合入庫OpenTSDB和ElasticSearch集群;
· 十億級業務調用鏈數據:基於Jaeger Trace植入–>Nginx多路分發–>經Jaeger-collector收集到Kafka–>被多組消費者處理(Flink實時寫入OpenTSDB,批量寫入ES);
· 百億級網絡和設備指標數據:主要是智能設備上報的各種監控指標:基於HTTP/HTTPS層監視–>Nginx–>太空橋(我司IoT平台)設備監控–>批量入庫ES。
技術棧為:
· 鏈路採集:Uber開源的Jaeger
· 基礎數據存儲:ES
· 指標數據存儲:OpenTSDB
· 削峰填谷的消息隊列:Kafka
· 實時計算:Flink  

二、工具升級:OpenTSDB升級到Druid

在禧雲業務保障平台上,OpenTSDB確實沒有太好的性能表現,查詢數據量在百萬級的時候,速度還是可以的,在暑假交易額低谷期並未暴露出OpenTSDB的性能問題。但是進入9月開學季之後,數據延時和查詢緩慢的問題立馬就暴露出來了,中途也寄希望於升級OpenTSDB版本,但依然效果不佳。
 

A. OpenTSDB性能表現不佳的原因

第一個原因,Rowkey設計過長的問題。Rowkey第一大設計原則是保證唯一性,否則原先的數據會被覆蓋掉,第二大設計原則是長度原則,Rowkey是一個二進制,它的長度建議設計在10~100個字節,越短越好。Rowkey如果過長,對性能有以下影響:
1)HBase的持久化文件HFile是按照KeyValue存儲的,如果Rowkey過長,比如500個字節,1000萬列數據,光Rowkey就要佔用500*1000萬=50億個字節,將近1G數據,這會極大影響HFile的存儲效率。
2)MemStore緩存部分數據到內存,如果Rowkey字段過長,內存的有效利用率會降低,系統無法緩存更多的數據,這會降低檢索效率。
需要指出的是不僅Rowkey的長度越短越好,列族名、列名等也盡量使用短名字,因為這些名字都是會寫入HFile中的,過長的Rowkey、列族名、列名都會導致整體的存儲量成倍增加。
 
第二個原因,業務監控業務場景非常多,涉及到不同業務線的多個維度,比如多機房、多支付渠道、商戶/門店/設備/碼等多維度聚合,很難設計出一個滿足全場景的Rowkey方案。在任意維度的組合查詢下,OpenTSDB 查詢效率會明顯降低。
比如對於組合條件查詢使用的就是scan方式,在使用時有以下幾點值得注意:
1)通過setCaching、setBatch方法提高速度,以空間換時間;
2)通過setStartRow與setEndRow來限定範圍,範圍越小,性能越高;
3)通過setFilter方法添加過濾器,這也是分頁、多條件查詢的基礎,比如使用SingleColumnValueFilter。
以上優化當遇到真正海量數據時,會消耗很大的資源,每次都需要花較長的時間處理。
 

B. 升級為Druid

我司其他技術團隊已經試用了Druid, 其核心是通過數據預先聚合提高查詢性能,針對預先定義好的Schema,因此適合實時分析的場景,結果返回時間在亞秒級。
我們切換到Druid之後,響應速度上確實有一個數量級的提升,查詢千萬級的數據範圍基本秒級響應。
 

三、調用鏈收集的優化

調用鏈收集的數據流為:jaeger-collector–>Kafka–>jaeger-ingester 消費–>入庫ES。下面講一下如何優化。
A. 第一階段:Kafka消息堆積高峰期由千萬級降到百萬級
強調一點,合理的分區設置很重要。
剛開始我們嘗試調整每次拉取的消息條數,將ingester.parallelism由1000調整為6000,消息堆積似乎好了一點,但效果不明顯。
考慮到可能是因為併發數不夠,所以通過擴充Kafka的分區數去提高併發。先將分區數由5個擴到8個,消息堆積由千萬級降到百萬級。但繼續將分區擴到10個,就幾乎沒有什麼效果了。  
B. 第二階段:Kafka的版本選擇不可忽視
莫名其妙的是jaeger-ingester消費非常不穩定,頻繁與kafka斷開重連,嘗試去消費其他分區消息,導致消費速率上不去。
後來發現,當Kafka版本為v2.3時,多個jaeger-ingester節點會反覆觸發kafka的消費再平衡機制,結果導致jaeger-ingester只能單點消費。
所以我們又將Kafka版本回退到了v2.2,調整jaeger-ingester實例個數和Kafka分區數為1:1,可橫向擴容支持高併發。
 
C. 第三階段:消息堆積高峰期由百萬降到萬級,延時秒級已可接受
我們觀察到ES的負載已經很高了,單節點高峰期CPU負載達到16。之前為了方便定位問題,給網絡請求實時加上了traceId標記,調用的是jaeger原生的trace鏈路計算。現在分析發現查詢QPS太高,所以嘗試優化查詢邏輯,一方面改為自定義的邏輯直接查詢ES,一方面調整好批量閾值查詢(指的是1次查多少,目前是按時間10ms和數據條數100條一個批次去查ES)。
優化完成后,消息堆積又下降一個數量級。目前高峰期堆積非常少,秒級消費已可接受。
 

四、聚合查詢的優化

A. 散點圖 vs 柱狀圖

對於調用鏈宏觀展示來說,慣常使用散點圖,它可以表達出一段時間內請求的耗時分佈情況,如下圖2所示。

圖2 調用鏈散點圖
但是存在一個問題,當時間區間選得比較大的時候,服務端查詢的數據過多而響應變慢,客戶端要渲染的點太多也會非常卡。所以點要抽樣。抽樣方式能想得到的有:
a.過濾出耗時長的數據;
b.取最近一段時間的數據;
c.只取指定數量的數據;
d.對相同耗時進行聚合展示等等。
這些調整可謂犧牲了監控者的真實需求,因為有些數據監控者看不了,或者很難看全。
我們對比了阿里雲日誌服務的設計,他山之石可以攻玉,借鑒了以下兩點:
第一點,人們看問題的方式總是從宏觀一路下鑽到微觀,所以我們加了柱狀圖做為時間段聚合,方便從宏觀上看到請求量的規模分佈。下圖3是某區域的訂單趨勢柱狀圖。

圖3 訂單趨勢柱狀圖
第二點,如果數據量非常大,可繼續點擊柱圖,展開當前時間條件下的子柱狀圖。系統根據數據量規模,自動展示出散點圖,方便用戶瀏覽耗時分佈。這樣一層層穿刺下鑽,既滿足了人的操作習慣,又提高了處理速度,做到了秒級響應。

圖4柱狀圖下鑽
 

B. 從宏觀到微觀,化繁為簡

就宏觀到微觀的監控下鑽,下面講三個案例。
案例一,單一維度下鑽
其實多數時候人們只想關注某一維度的分佈情況,比如按應用、按工程、按服務IP、按請求URL、按商戶、按門店、按設備看分佈。對於ES來說,單一條件聚合速度很快,秒級響應。
案例二,網絡質量監察
我司在全國大江南北分佈着大量餐飲中心(即食堂),如何快速定位出哪些食堂網絡環境糟糕呢?不能等客戶告訴我們。
我們從請求量級篩選(系統推薦和自定義)、dns/http/ssl/tcp/mqtt耗時情況、趨勢發展等諸多因子中分析出餐飲中心網絡情況,哪怕是學校食堂的一次網絡抖動,都可以被我們偵查到。不僅能分析出網絡問題,而且還能下鑽到請求鏈路上的任何階段,比如是DNS、TCP、SSL、首包等,並分析出受影響的終端設備。依然是秒級響應,如下圖5所示。

圖5 設備耗時下鑽
 
案例三,找出掉單
當用戶已支付而商戶未收款時,如何從千萬級訂單中快速找到丟失的那一筆訂單呢?內部稱sos訂單:

  • 秒級偵查出來;
  • 快速定位在哪個環節出了問題;
  • 系統自我修復能力

具體做法為:
第一步,將內部可能發生的業務場景圈出來,通過Flink實時計算形成閉環,當其中一個鏈條斷了,就會立馬把待排查的sos訂單壓入隊列任務,然後不斷主動查詢第三方支付渠道確認支付狀態。
第二步,對於一些疑難問題如短時間內系統無法解決時,比如第三方支付渠道出現了故障,就會發出告警消息給客服,客服預先跟進,減少用戶投訴處理時間。
 
總結一下:
OpenTSDB切換為Druid,明顯提升了從宏觀下鑽到微觀的響應時間,基本能做到百億級數據量秒級響應。高峰時段Kafka消息堆積也大幅降低。下鑽方式做了優化,更符合工程師探查習慣。
 
-完-

歡迎關注公眾號:老兵筆記

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

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

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

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

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

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

MySQL InnoDB MVCC

MySQL 原理篇

MVCC

MVCC 的定義

MVCC(Multiversion concurrency control):多版本併發控制,併發訪問(讀或寫)數據庫時,對正在事務內處理的數據做多版本的管理。以達到用來避免寫操作的堵塞,從而引發讀操作的併發問題。

MVCC 邏輯流程

插入

MySQL 在每一行數據中都會默認添加一些隱藏列 DB_TRX_ID、DB_ROLL_PT。

上面圖中的執行步驟如下:

  1. 手動開啟事務,從 InnoDB 引擎中獲取一個全局事務ID(1)
  2. 然後往 teacher 表中插入兩條數據,同時設置數據行的版本號為當前事務ID,刪除版本號為 NULL

思考:如果事務是自動提交的(SET AUTOCOMMIT = NO),且未手動開啟事務,執行如下兩條 SQL,插入的數據會是什麼樣子的?

INSERT INTO teacher (NAME, age) VALUE ('seven', 18) ;

INSERT INTO teacher (NAME, age) VALUE ('qingshan', 19) ;

因為事務是自動提交的,所以兩條插入語句會分別獲取事務ID,所以這裏插入的數據行的版本號是1和2。

刪除

上面圖中的執行步驟如下:

  1. 手動開啟事務,從 InnoDB 引擎中獲取一個全局事務ID(22)
  2. 然後執行一條刪除語句,InnoDB 會找到這條記錄,把它的刪除版本號設置為當前事務ID

修改

上面圖中的執行步驟如下:

  1. 手動開啟事務,從 InnoDB 引擎中獲取一個全局事務ID(33)
  2. 然後執行一條修改語句,InnoDB 會找到這條記錄,copy 一份原數據插入到表中,將新行數據的數據行的版本號的值設置為當前事務ID,將原行數據的刪除版本號的值設置為當前事務ID

查詢

上面圖中的執行步驟如下:

  1. 手動開啟事務,從 InnoDB 引擎中獲取一個全局事務ID(44)
  2. 根據數據查詢規則的描述
    1. 查找數據行版本早於當前事務版本的數據行,發現表中三行數據都滿足條件
    2. 查找刪除版本號要麼為 NULL,要麼大於當前事務版本號的記錄,發現只有最後一條數據滿足條件(1, seven, 19)

案例分析

數據準備:

CREATE TABLE `teacher` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(32) NOT NULL,
  `age` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

INSERT  INTO teacher(id,NAME,age) VALUES (1,'seven',18);
INSERT  INTO teacher(id,NAME,age) VALUES (2,'qingshan',20);

案例一

-- 事務A執行
BEGIN;                                     -- 1
SELECT * FROM teacher;                       -- 2
COMMIT;

--事務B執行
BEGIN;                                     -- 3
UPDATE teacher SET age =28 WHERE id=1;     -- 4
COMMIT;

案例一的執行步驟是:1,2,3,4,2,執行效果如下圖所示:

雖然在執行 3,4 步驟的時候更新 id=1 的數據,但是根據 MVCC 的查詢邏輯流程,再次執行2,獲取到的數據依然和第一次一樣。

案例二

-- 事務A執行
BEGIN;                                     -- 1
SELECT * FROM teacher;                       -- 2
COMMIT;

--事務B執行
BEGIN;                                     -- 3
UPDATE teacher SET age =28 WHERE id=1;     -- 4
COMMIT;

案例二的執行步驟是:3,4,1,2,執行效果如下圖所示:

根據 MVCC 的查詢邏輯流程,執行1,2,獲取到的數據是事務B未提交的數據,這個是有問題的。

分析了案例一和案例二,發現 MVCC 不能解決案例二的問題,InnoDB 會使用 Undo log 解決案例二的問題。

Undo Log

Undo Log 的定義

Undo:意為取消,以撤銷操作為目的,返回指定某個狀態的操作。

Undo Log:數據庫事務提交之前,會將事務修改數據的鏡像(即修改前的舊版本)存放到 undo 日誌里,當事務回滾時,或者數據庫奔潰時,可以利用 undo 日誌,即舊版本數據,撤銷未提交事務對數據庫產生的影響。。

  • 對於 insert 操作,undo 日誌記錄新數據的 PK(ROW_ID),回滾時直接刪除;
  • 對於 delete/update 操作,undo 日誌記錄舊數據 row,回滾時直接恢復;
  • 他們分別存放在不同的buffer里。

Undo Log 是為了實現事務的原子性而出現的產物。

 

Undo Log 實現事務原子性:事務處理過程中,如果出現了錯誤或者用戶執行了 ROLLBACK 語句,MySQL 可以利用 Undo Log 中的備份將數據恢復到事務開始之前的狀態。

InnoDB 發現可以基於 Undo Log 來實現多版本併發控制。

Undo Log 在 MySQL InnoDB 存儲引擎中用來實現多版本併發控制。

 

Undo Log 實現多版本併發控制:事務未提交之前,Undo Log 保存了未提交之前的版本數據,Undo Log 中的數據可作為數據舊版本快照供其他併發事務進行快照讀。

分析下圖中 SQL 的執行過程。

  • 事務A手動開啟事務,執行更新操作,首先會把更新命中的數據拷貝到 Undo Buffer 中
  • 事務B手動開啟事務,執行查詢操作,會讀取 Undo Log 中數據返回,進行快照度

當前讀和快照讀

快照讀

SQL 讀取的數據是快照版本,也就是歷史版本,普通的 SELECT 就是快照讀。

InnoDB 快照讀,數據的讀取將由 cache(原本數據)+ Undo Log(事務修改過的數據)兩部分組成。

當前讀

SQL 讀取的數據是最新版本,通過鎖機制來保證讀取的數據無法通過其他事務進行修改。

UPDATE 、DELETE 、INSERT 、SELECT … LOCK IN SHARE MODE 、SELECT … FOR UPDATE 都是當前讀,這些操作在《MySQL InnoDB 鎖》這篇文章中有過演示,事務A執行這些 SQL,會阻塞事務B的 SQL 執行。

在 InnoDB 引擎裏面,快照讀通過 MVCC 解決幻讀的問題,當前讀通過 Next-Key Locks 解決幻讀的問題。

Redo Log

Redo Log 的定義

Redo:顧名思義就是重做。以恢復操作為目的,重現操作。

Redo Log:指事務中操作的任何數據,將最新的數據備份到一個地方(Redo Log)。

Redo Log 的持久化:不是隨着事務的提交才寫入的,而是在事務的執行過程中,便開始寫入 Redo Log 中,具體的落盤策略可以進行配置。

Redo Log 是為了實現事務的持久性而出現的產物。

Redo Log 實現事務持久性:防止在發生故障的時間點,尚有臟頁未寫入表的 IBD 文件中,在重啟 MySQL 服務的時候,根據 Redo Log 進行重做,從而達到事務的未入磁盤數據進行持久化這一特性。

根據下圖分析 Redo Log 的執行流程

InnoDB 不是每一次提交事務都把數據從緩存區持久化到硬盤的,因為每次提交事務都把數據持久化到硬盤,效率很低,每一次持久化都需要執行 IO 操作。

InnoDB 會把每次數據變化會先進入 Redo Buffer 中,事務提交了,會根據策略把新的數據寫入 Redo Log 中,InnoDB 就會認為這次事務提交成功了,數據並不一定馬上就進入表的 IBD 文件中。

疑問:持久化到 Redo Log 中和持久化到表的 IBD 文件一樣都是 IO 操作,為什麼要設計 Redo Log 呢?

其實是因為持久化到 Redo Log 中是順序 IO 的操作,而持久化到表的 IBD 文件中是一個隨機 IO 的操作,比如我們需要更新 id=1 和 id=8 的數據,如果是 Redo Log,就只需要把更新的數據順序存入 Redo Log 中;但如果是表的 IBD 文件,就需要先找到 id=1 和 id=8 的兩個不連續的磁盤文件地址,再做持久化操作,影響數據庫服務的併發性能。

Redo Log 的持久化配置

指定 Redo Log 記錄在 {datadir}/ib_logfile1 和 ib_logfile2 兩個文件中,可以通過 innodb_log_group_home_dir配置指定目錄存儲。

一旦事務成功提交且數據持久化到表的 IBD 文件中之後,此時 Redo Log 中的對應事務數據記錄就失去了意義,所 以 Redo Log 的寫入是日誌文件循環寫入的過程,也就是覆蓋寫的過程。

  • 指定 Redo Log 日誌文件組中的數量 innodb_log_files_in_group 默認為2
  • 指定 Redo Log 每一個日誌文件最大存儲量 innodb_log_file_size 默認48M
  • 指定 Redo Log 在 cache/buffer 中的 buffer 池大小 innodb_log_buffer_size 默認16M

Redo Buffer 持久化到 Redo Log 的策略,通過設置 Innodb_flush_log_at_trx_commit 的值:

  • 取值0:每秒提交 Redo buffer -> Redo Log OS cache -> flush cache to disk,可能丟失一秒內的事務數據。
  • 取值1(默認值):每次事務提交執行 Redo Buffer -> Redo Log OS cache -> flush cache to disk,最安全,性能最差的方式
  • 取值2:每次事務提交執行 Redo Buffer -> Redo log OS cache 再每一秒執行 -> flush cache to disk 操作

一般建議選擇取值2,因為 MySQL 掛了最多損失一次事務提交的數據,整個服務期掛了才會損失一秒的事務提交數據。

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

【其他文章推薦】

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

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

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

※大陸寄台灣空運注意事項

※大陸海運台灣交貨時間多久?

※避免吃悶虧無故遭抬價!台中搬家公司免費估價,有契約讓您安心有保障!

圈養鯨豚退休後的家 世界第一個鯨魚安養中心 選在加拿大天然海灣

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

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

【其他文章推薦】

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

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

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

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

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

※試算大陸海運運費!

武漢肺炎疫情影響奈良鹿? 愛鹿協會:野生植物才是主食 鹿沒人餵不會餓死

文:宋瑞文

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

【其他文章推薦】

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

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

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

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

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

鮪魚業刺網混獲最大苦主 研究:印度洋海豚數量減少近90%

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

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

【其他文章推薦】

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

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

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

※大陸寄台灣空運注意事項

※大陸海運台灣交貨時間多久?

※避免吃悶虧無故遭抬價!台中搬家公司免費估價,有契約讓您安心有保障!

中國將大砍電動巴士補助?

中國大力補貼發展電動巴士,但狀況似乎有了改變。由於補貼過於慷慨,衍生「騙補」等弊端,因此中國方面擬減少電動巴士的補助,最高調降49.5%,平均降幅32%。

《鉅亨網》指出,由於中國先前對電動巴士的補貼方案太過寬鬆,以致2015下半年逐漸浮現弊端,2016年各地相關補貼辦法至今仍無法推出。中國考慮減少電動大巴的補貼額度,平均降幅可能達32%,最大規格巴士的補貼最多將減少49.5%,幾乎腰斬。此外,售價超過人民幣35萬元的電動車可能將被排除在政府補貼之外。

據消息人士指出,多個中國政府相關部門正在針對上述補貼調整計畫進行審核,需待國務院或人大批准後方可實行。

根據中國工信部資料,今年一月中國共生產1.61萬輛新能源車,比去年12月大幅減少83.8%。而中國電動汽車資源網數據更直指,中國宇通、中通、比亞迪、北汽等電動巴士生產商的二月產量只有3110輛。相較之下,2015年中國商用純電動巴士的生產與銷量都超過10萬輛。

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

【其他文章推薦】

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

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

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

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

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

※試算大陸海運運費!

路上跑的全是電動車!印度設下 2030 年達標,擬推電動車免頭期款政策

被視為未來趨勢的電動車,目前在車市中的市占仍然相當低,而若談到推動電動車發展,印度絕對是當前最野心勃勃的國家。近日,印度電力部長提出新政策,要讓電動車購車族免付頭期款,以提高民眾購買的意願,最終目標是要在 2030 年前,讓印度境內上路的車輛 100% 為電動車。

印度為目前全球空氣污染最嚴重的國家之一,國內有 13 個城市名列全球前 20 大最受污染城市。為了從根本改善印度的空氣品質,降低對化石燃料的依賴勢在必行,而印度電力部懷抱著強大的信心,表示不造成人民經濟上的壓力,就能全力推動國內電動車發展。   印度電力部長 Piyush Goyal 日前信誓旦旦的表示,「印度將成為全球首個在如此國土規模大小之下,100% 全電動車上路的國家」,且 Goyal 透露,將努力嘗試讓這項計畫由電力部的資金供應運作,「我們不需要用到政府與印度人民的任何一毛錢」。   有了電動車購車零頭期款的政策,Goyal 相信,這可提高購車意願,使人們更輕鬆的將省下大筆油錢轉往購買電動車。Goyal 透露,目前正與其他政府官員合作,由印度道路運輸與公路部部長 Nitin Gadkari、石油部長 Dharmendra Pradhan 及環境部長 Prakash Javadekar 帶領成立的工作小組,商討與評估這個政策提議是否可行,以及「確保電動車車主能享有便宜的充電價格」。   雖然利用電動車取代排放溫室氣體的傳統汽車,能夠為空氣品質本就相當糟糕的印度,減少交通運輸這部分所造成的碳排放,但也有人質疑,推動電動車的結果將造成電力需求上升,最終可能會導致供給發電的能源產業製造更多碳排放量也說不定,畢竟,印度目前約 60% 的能源產出來自燃煤發電,而燃煤發電廠在印度已經是一大污染來源之一,且其溫室氣體排放量在這幾年依然持續成長中。   此外,印度曾對外公開其再生能源目標,要使再生能源裝置量從 2016 年的不到 12 GW,增加到 2022 年的 175 GW,根據先前的報導曾指出,印度要達到 175 GW 的目標,所需花費的資金相當「可觀」,若又加上推動電動車發展所提出的免付頭期款政策,可能會讓印度走向再生能源主導之路,更顯困難重重了。

(首圖來源: CC BY 2.0)

(本文授權轉載自《》─〈〉)

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

【其他文章推薦】

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

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

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

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

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

設計模式(Java語言)- 簡單工廠模式

  簡單工廠模式有稱為靜態工廠模式,屬於設計模式中的創建型模式。簡單工廠模式通過對外提供一個靜態方法來統一為類創建實例。簡單工廠模式的目的是實現類與類之間解耦,其次是客戶端不需要知道這個對象是如何被穿創建出來的,只需要調用簡單工廠模式的方法來統一創建就可以了,從而明確了各個類的職責。

  一、創建簡單工廠模式的步驟

  第一步:聲明一個抽象類(接口),以及對應的抽象方法,由實現類分別去實現這個方法。

  第二步: 創建具體實現類,實現抽象方法。

  第三步:創建一個簡單工廠類,聲明一個靜態方法,根據傳入的不同的類型來確定創建抽象類的具體實現類。

  第四步:客戶端通過工廠類獲取實例對象。

 

  二、應用案例: 

  下面以製造手機為例子,在現實生活中可能有很多工廠可以創建不同品牌的手機,這些工廠可以根據不同的需求來創建不同的手機。根據上面的步驟,首先我們需要一個抽象類,所以我們需要知道不同品牌的手機其實都是屬於手機這種類別,因此我們可以將手機抽出來做成一個抽象類:

/**
 * 手機類
 */
public interface Phone {
    //製造手機的方法,留給具體的實現類來製造
    void create();
}

  第二步我們需要開始製造不同品牌的手機了:

  製造華為手機

public class Huawei implements Phone {
    @Override
    public void create() {
        System.out.println("====正在製造華為手機======");
    }
}

  蘋果手機

public class Iphone implements Phone {
    @Override
    public void create() {
        System.out.println("====正在製造蘋果手機======");
    }
}

  第三步我們需要創建一個工廠方法,返回手機類。具體製造什麼品牌的手機,需要根據傳進來的手機名字來決定,因此我們可以這麼寫:

public class SimpleFactory {

    public static Phone createPhone(String name) {
        if ("huawei".equals(name))
            return new Huawei();
        else
            return new Iphone();

    }

}

  第四步,手機創建好了,我們就可以使用了,即客戶端調用工廠方法創建對象實例

public class Client {

public static void main(String[] args) {
Phone huawei = SimpleFactory.createPhone("huawei");
huawei.create();

Phone iphone = SimpleFactory.createPhone("iphone");
iphone.create();
}

}

//輸出結果

====正在製造華為手機======
====正在製造蘋果手機======

  到這裏,簡單工廠模式基本已經寫完了,仔細看會發現這種方法創建對象違反了ocp原則,每次增加不同品牌手機的時候都需要在工廠方法里添加不同的條件判斷。如果手機品牌越來越多,代碼看起來非常臃腫,很不利於後期的代碼維護。因此,我們改進一下,不要通過手機品牌名稱來判斷需要創建哪一中對象了,而是客戶端想要創建什麼對象,只需要傳入具體的實現類就可以了,然後通過Java的反射來創建對象。

public class SimpleFactory2 {

    public static Phone create(Class<? extends Phone> clazz) {
        try {
            return clazz.newInstance();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }

}

  客戶端調用

public class Client {

    public static void main(String[] args) {
        Phone huawei = SimpleFactory2.create(Huawei.class);
        huawei.create();

        Phone iphone = SimpleFactory2.create(Iphone.class);
        iphone.create();
    }

}
//運行結果

====正在製造華為手機======
====正在製造蘋果手機======

  經過修改之後,每次增加新的手機品牌時就不用修改工廠方法的邏輯了。但是,還是有一個問題,就是每次創建對象都是通過反射來創建的,所以在性能上是有一定的損耗的。

 

  三、總結:

  優點:

    1、簡單優化了軟件體繫結構,明確了各自功能模塊的職責和權利

    2、通過工廠類,外界不需要直接創建具體產品對象,只需要負責消費,不需要關心內部如何創建對象

  缺點:

    1、改進前的簡單工廠模式全部創建邏輯都集中在一個工廠類中,能創建的類只能是考慮到的,如果需要添加新的類,就必須改變工廠類了

    2、改進前的簡單工廠模式隨着具體產品的不斷增多,可能會出現共產類根據不同條件創建不同實例的需求,這種對條件的判斷和對具體產品類型的判斷交錯在一起,很難避免功能模塊的蔓延,對系統的維護和擴展不利

    3、改進后的簡單工廠模式主要是使用反射效率會低一些

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

【其他文章推薦】

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

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

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

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

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

※試算大陸海運運費!