標籤: 網站設計

附010.Kubernetes永久存儲之GlusterFS超融合部署

admin

一 前期準備

1.1 基礎知識


在Kubernetes中，使用GlusterFS文件系統，操作步驟通常是：

創建brick–>創建volume–>創建PV–>創建PVC–>Pod掛載PVC

如果要創建多個PV，則需要手動重複執行，可通過Heketi管理glusterfs。

Heketi是用來管理GlusterFS卷的生命周期的，並提供了一個RESTful API接口供Kubernetes調用，因為GlusterFS沒有提供API調用的方式，所以我們藉助heketi。通過Heketi，Kubernetes可以動態配置GlusterFS卷，Heketi會動態在集群內選擇bricks創建所需的volumes，確保數據的副本會分散到集群不同的故障域內，同時Heketi還支持GlusterFS多集群管理，便於管理員對GlusterFS進行操作。

Heketi要求在每個glusterfs節點上配備裸磁盤，用於Heketi創建PV和VG。通過Hekete，Kubernetes中使用PV步驟為：

創建StorageClass–>創建PVC–>Pod掛載PVC

這種方式稱為基於StorageClass的動態資源供應。

提示：本實驗基於Kubernetes部署glusterfs，同時glusterfs管理組件Heketi也使用Kubernetes部署。

1.2 架構示意



提示：本實驗不涉及Kubernetes部署，Kubernetes部署參考001-019。

1.3 相關規劃






主機

IP

磁盤

備註

k8smaster01

172.24.8.71

Kubernetes master節點

k8smaster02

172.24.8.72

Kubernetes master節點

k8smaster03

172.24.8.73

Kubernetes master節點

k8snode01

172.24.8.74

sdb

Kubernetes node節點

glusterfs節點

k8snode02

172.24.8.75

sdb

Kubernetes node節點

glusterfs節點

k8snode03

172.24.8.76

sdb

Kubernetes node節點

glusterfs節點

磁盤規劃

k8snode01 k8snode02 k8snode03
PV sdb1 sdb1 sdb1





1.4 部署條件

超融合部署需要具有已經部署的Kubernetes集群管理訪問權限。如果Kubernetes節點滿足以下要求，則可以選擇將GlusterFS作為超融合服務部署：

  • 必須至少有三個節點用於glusterfs；

  • 每個節點必須至少連接一個裸磁盤設備，以供heketi使用。這些設備上不得包含任何數據，heketi將會格式化和分區此設備；

  • 每個節點必須打開以下端口才能進行GlusterFS通信：

    • 2222：GlusterFS pod的sshd端口；

    • 24007：GlusterFS守護程序；

    • 24008：GlusterFS管理；

    • 49152——49251：主機上每個卷的每個brick都需要有獨立的端口。對於每塊新brick，將從49152開始使用一個新端口。建議每台主機的默認範圍為49152-49251，也可根據需要進行調整。

  • 必須加載以下內核模塊：

    • dm_snapshot

    • dm_mirror

    • dm_thin_pool

  • 對於內核模塊，可通過lsmod | grep <name>查看模塊是否存在，並modprobe <name>加載給定的模塊。

  • 每個節點都要求該mount.glusterfs命令可用。在所有基於Red Hat的操作系統下，此命令由glusterfs-fuse軟件包提供。


注意：節點上安裝的GlusterFS客戶端版本應盡可能接近服務器的版本。要獲取已安裝的版本，可通過glusterfs –version或kubectl exec <pod> — glusterfs –version命令查看。

1.5 其他準備


所有節點NTP配置；

所有節點添加相應主機名解析：

  1 172.24.8.71 k8smaster01
  2 172.24.8.72 k8smaster02
  3 172.24.8.73 k8smaster03
  4 172.24.8.74 k8snode01
  5 172.24.8.75 k8snode02
  6 172.24.8.76 k8snode03



注意：若非必要，建議關閉防火牆和SELinux。

二 規劃裸設備

2.1 確認磁盤

  1 [root@k8snode01 ~]# fdisk /dev/sdb -l		#檢查sdb是否為裸磁盤

三 安裝glusterfs-fuse

3.1 安裝相應RPM源

  1 [root@k8snode01 ~]# yum -y install centos-release-gluster
  2 [root@k8snode01 ~]# yum -y install glusterfs-fuse		#安裝glusterfs-fuse



提示：k8snode01、k8snode02、k8snode03類似操作，根據1.4要求安裝glusterfs-fuse組件；

安裝相應源之後，會在/etc/yum.repos.d/目錄多出文件CentOS-Storage-common.repo，內容如下：

# CentOS-Storage.repo

#

# Please see http://wiki.centos.org/SpecialInterestGroup/Storage for more

# information




[centos-storage-debuginfo]

name=CentOS-$releasever – Storage SIG – debuginfo

baseurl=http://debuginfo.centos.org/$contentdir/$releasever/storage/$basearch/

gpgcheck=1

enabled=0

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Storage

3.2 加載相應模塊

  1 [root@k8snode01 ~]# cat > /etc/sysconfig/modules/glusterfs.modules <<EOF
  2 #!/bin/bash
  3 
  4 for kernel_module in dm_snapshot dm_mirror dm_thin_pool;do
  5     /sbin/modinfo -F filename \${kernel_module} > /dev/null 2>&1
  6     if [ \$? -eq 0 ]; then
  7         /sbin/modprobe \${kernel_module}
  8     fi
  9 done;
 10 EOF
 11 [root@k8snode01 ~]# chmod +x /etc/sysconfig/modules/glusterfs.modules
 12 [root@k8snode01 ~]# lsmod |egrep "dm_snapshot|dm_mirror|dm_thin_pool"	#所有glusterfs node節點檢查



提示：可通過modprobe <name>加載給定的模塊。

四 Kubernetes部署glusterfs

4.1 Node tag

  1 [root@k8smaster01 ~]# kubectl label nodes k8snode01 storagenode=glusterfs
  2 [root@k8smaster01 ~]# kubectl label nodes k8snode02 storagenode=glusterfs
  3 [root@k8smaster01 ~]# kubectl label nodes k8snode03 storagenode=glusterfs




提示：在後續使用DaemonSet部署時候kube-templates/glusterfs-daemonset.yaml存在如下針對label的Selector：

spec:

nodeSelector:

storagenode: glusterfs

4.2 下載glusterfs-Kubernetes

  1 [root@k8smaster01 ~]# yum -y install git
  2 [root@k8smaster01 ~]# git clone https://github.com/gluster/gluster-kubernetes.git


4.3 修改glusterfs拓撲

  1 [root@k8smaster01 ~]# cd gluster-kubernetes/deploy/
  2 [root@k8smaster01 deploy]# cp topology.json.sample topology.json
  3 [root@k8smaster01 deploy]# vi topology.json


  1 {
  2   "clusters": [
  3     {
  4       "nodes": [
  5         {
  6           "node": {
  7             "hostnames": {
  8               "manage": [
  9                 "k8snode01"
 10               ],
 11               "storage": [
 12                 "172.24.8.74"
 13               ]
 14             },
 15             "zone": 1
 16           },
 17           "devices": [
 18             "/dev/sdb"
 19           ]
 20         },
 21         {
 22           "node": {
 23             "hostnames": {
 24               "manage": [
 25                 "k8snode02"
 26               ],
 27               "storage": [
 28                 "172.24.8.75"
 29               ]
 30             },
 31             "zone": 1
 32           },
 33           "devices": [
 34             "/dev/sdb"
 35           ]
 36         },
 37         {
 38           "node": {
 39             "hostnames": {
 40               "manage": [
 41                 "k8snode03"
 42               ],
 43               "storage": [
 44                 "172.24.8.76"
 45               ]
 46             },
 47             "zone": 1
 48           },
 49           "devices": [
 50             "/dev/sdb"
 51           ]
 52         }
 53       ]
 54     }
 55   ]
 56 }


提示：heketi配置文件及介紹參考《附009.Kubernetes永久存儲之GlusterFS獨立部署》。

若需要修改heketi的暴露方式，若需要修改為NodePort，可參考https://lichi6174.github.io/glusterfs-heketi/。

所有部署相關yaml位於/root/gluster-kubernetes/deploy/kube-templates，本實驗採用默認參數。

4.4 配置heketi

  1 [root@k8smaster01 deploy]# cp heketi.json.template heketi.json
  2 [root@k8smaster01 deploy]# vi heketi.json
  3 {
  4     "_port_comment": "Heketi Server Port Number",
  5     "port" : "8080",
  6 
  7     "_use_auth": "Enable JWT authorization. Please enable for deployment",
  8     "use_auth" : true,				#開啟用戶認證
  9 
 10     "_jwt" : "Private keys for access",
 11     "jwt" : {
 12         "_admin" : "Admin has access to all APIs",
 13         "admin" : {
 14             "key" : "admin123"			#管理員密碼
 15         },
 16         "_user" : "User only has access to /volumes endpoint",
 17         "user" : {
 18             "key" : "xianghy"			#用戶密碼
 19         }
 20     },
 21 
 22     "_glusterfs_comment": "GlusterFS Configuration",
 23     "glusterfs" : {
 24 
 25         "_executor_comment": "Execute plugin. Possible choices: mock, kubernetes, ssh",
 26         "executor" : "${HEKETI_EXECUTOR}",	        #本實驗使用Kubernetes方式
 27 
 28         "_db_comment": "Database file name",
 29         "db" : "/var/lib/heketi/heketi.db",	        #heketi數據存儲
 30 
 31         "kubeexec" : {
 32             "rebalance_on_expansion": true
 33         },
 34 
 35         "sshexec" : {
 36             "rebalance_on_expansion": true,
 37             "keyfile" : "/etc/heketi/private_key",
 38             "port" : "${SSH_PORT}",
 39             "user" : "${SSH_USER}",
 40             "sudo" : ${SSH_SUDO}
 41         }
 42     },
 43 
 44     "backup_db_to_kube_secret": false
 45 }


4.5 相關修正


新版Kubernetes的# kubectl get pod命令無–show-all選項，需要如下操作修正部署gk-deploy腳本。

  1 [root@k8smaster01 deploy]# vi gk-deploy
  2 924 #heketi_pod=$(${CLI} get pod --no-headers --show-all --selector="heketi" | awk '{print $1}')
  3 925 heketi_pod=$(${CLI} get pod --no-headers --selector="heketi" | awk '{print $1}')






由於國內glusterfs鏡像可能無法pull，建議通過VPN等方式提前pull鏡像，然後上傳至所有glusterfs node節點。

  1 [root@VPN ~]# docker pull gluster/gluster-centos:latest
  2 [root@VPN ~]# docker pull heketi/heketi:dev
  3 [root@VPN ~]# docker save -o gluster_latest.tar gluster/gluster-centos:latest
  4 [root@VPN ~]# docker save -o heketi_dev.tar heketi/heketi:dev
  5 [root@k8snode01 ~]# docker load -i gluster_latest.tar
  6 [root@k8snode01 ~]# docker load -i heketi_dev.tar
  7 [root@k8snode01 ~]# docker images
  8


4.6 正式部署

  1 [root@k8smaster01 deploy]# ./gk-deploy -h			#查看部署參數
  2 [root@k8smaster01 deploy]# kubectl create ns heketi		#建議部署在獨立的namespace中
  3 [root@k8smaster01 deploy]# ./gk-deploy -g -n heketi topology.json --admin-key admin123 --user-key xianghy
  4 ……
  5 Do you wish to proceed with deployment?
  6 
  7 [Y]es, [N]o? [Default: Y]: y





提示：部署腳本更多參數參考：https://github.com/gluster/gluster-kubernetes/blob/master/deploy/gk-deploy。

注意：若部署失敗，需要通過下方式徹底刪除后重新部署：

  1 [root@k8smaster01 deploy]# ./gk-deploy --abort --admin-key admin123 --user-key xianghy -y -n heketi
  2 [root@k8smaster01 deploy]# kubectl delete -f kube-templates/ -n heketi



glusterfs node節點需要執行如下徹底清理：

  1 [root@k8snode01 ~]# dmsetup ls
  2 [root@k8snode01 ~]# dmsetup remove_all
  3 [root@k8snode01 ~]# rm -rf /var/log/glusterfs/
  4 [root@k8snode01 ~]# rm -rf /var/lib/heketi
  5 [root@k8snode01 ~]# rm -rf /var/lib/glusterd/
  6 [root@k8snode01 ~]# rm -rf /etc/glusterfs/
  7 [root@k8snode01 ~]# dd if=/dev/zero of=/dev/sdb bs=512k count=1
  8 [root@k8snode01 ~]# wipefs -af /dev/sdb


4.7 Kubernetes集群查看驗證

  1 [root@k8smaster01 ~]# kubectl get nodes --show-labels | grep -E 'NAME|node'
  2 [root@k8smaster01 ~]# kubectl get all -n heketi




  1 [root@k8smaster01 ~]# kubectl get pods -o wide -n heketi



4.8 gluster集群查看驗證

  1 [root@k8smaster01 ~]# kubectl exec -it heketi-65f4555d74-72hrf -n heketi -- heketi-cli cluster list --user admin --secret admin123								#集群列表
  2 [root@k8smaster01 ~]# kubectl -n heketi exec -ti heketi-65f4555d74-72hrf /bin/bash                               [root@heketi-65f4555d74-72hrf /]# heketi-cli cluster list --user admin --secret admin123	#進入heketi容器查看
  3 [root@k8smaster01 ~]# curl http://10.254.111.219:8080/hello
  4 Hello from Heketi



注意：使用4.6腳本為一鍵部署，也可使用gluster-kubernetes/deploy/目錄下的文件，分開逐步部署，整理部署思路如下：

  1. 使用glusterfs-daemonset.json部署glusterfs DaemonSet；

  2. 對node節點進行打標籤；

  3. 使用heketi-service-account.json部署Heketi的服務帳戶；

  4. 對Heketi所創建的服務帳戶授權；

  5. 創建secret；

  6. 轉發本地8080端口至deploy-heketi。


獨立部署完整過程參考：https://jimmysong.io/kubernetes-handbook/practice/using-heketi-gluster-for-persistent-storage.html。

五 安裝heketi-cli


由於在master節點管理heketi需要進入heketi容器或者使用kubectl exec -ti 方式，建議直接在master節點安裝heketi客戶端，直接管理、

5.1 安裝heketi服務

  1 [root@k8smaster01 ~]# yum -y install centos-release-gluster
  2 [root@k8smaster01 ~]# yum -y install heketi-client


5.2 配置heketi

  1 [root@k8smaster01 ~]# echo "export HEKETI_CLI_SERVER=http://$(kubectl get svc heketi -n heketi -o go-template='{{.spec.clusterIP}}'):8080" >> /etc/profile.d/heketi.sh
  2 [root@k8smaster01 ~]# echo "alias heketi-cli='heketi-cli --user admin --secret admin123'" >> ~/.bashrc
  3 [root@k8smaster01 ~]# source /etc/profile.d/heketi.sh
  4 [root@k8smaster01 ~]# source ~/.bashrc
  5 [root@k8smaster01 ~]# echo $HEKETI_CLI_SERVER
  6 http://heketi:8080


5.3 集群管理

  1 [root@k8smaster01 ~]# heketi-cli cluster list
  2 Clusters:
  3 Id:67004a06fbcb4fa525bcec1fbaa9ef2d [file][block]
  4 [root@k8smaster01 ~]# heketi-cli cluster info 67004a06fbcb4fa525bcec1fbaa9ef2d	#集群詳細信息
  5 Cluster id: 67004a06fbcb4fa525bcec1fbaa9ef2d
  6 Nodes:
  7 40cdd4c1d0c389939193d6dea3c5bfe8
  8 62873c54cf61025fda91e6d44433378b
  9 d48986357840d28653304e7170599da5
 10 Volumes:
 11 5f15f201d623e56b66af56313a1975e7
 12 Block: true
 13 
 14 File: true
 15 [root@k8smaster01 ~]# heketi-cli topology info 67004a06fbcb4fa525bcec1fbaa9ef2d	#查看拓撲信息
 16 [root@k8smaster01 ~]# heketi-cli node list					        #查看所有node
 17 Id:40cdd4c1d0c389939193d6dea3c5bfe8     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 18 Id:62873c54cf61025fda91e6d44433378b     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 19 Id:d48986357840d28653304e7170599da5     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 20 [root@k8smaster01 ~]# heketi-cli node info 40cdd4c1d0c389939193d6dea3c5bfe8  	#node節點信息
 21 [root@k8smaster01 ~]# heketi-cli volume create --size=2 --replica=2		        #默認為3副本的replica模式



  1 [root@k8smaster01 ~]# heketi-cli volume list					#列出所有卷
  2 [root@k8smaster01 ~]# heketi-cli volume info fc296ab350dcc36e00dd3b3643a04645	#卷信息
  3 [root@k8smaster01 ~]# heketi-cli volume delete fc296ab350dcc36e00dd3b3643a04645	#刪除卷


六 Kubernetes動態掛載glusterfs

6.1 StorageClass動態存儲


kubernetes共享存儲provider模式：

靜態模式(Static)：集群管理員手工創建PV，在定義PV時設置後端存儲的特性；

動態模式(Dynamic)：集群管理員不需要手工創建PV，而是通過StorageClass的設置對後端存儲進行描述，標記為某種”類型(Class)”；此時要求PVC對存儲的類型進行說明，系統將自動完成PV的創建及與PVC的綁定；PVC可以聲明Class為””，說明PVC禁止使用動態模式。

基於StorageClass的動態存儲供應整體過程如下圖所示：


  1. 集群管理員預先創建存儲類（StorageClass）；

  2. 用戶創建使用存儲類的持久化存儲聲明(PVC：PersistentVolumeClaim)；

  3. 存儲持久化聲明通知系統，它需要一個持久化存儲(PV: PersistentVolume)；

  4. 系統讀取存儲類的信息；

  5. 系統基於存儲類的信息，在後台自動創建PVC需要的PV；

  6. 用戶創建一個使用PVC的Pod；

  7. Pod中的應用通過PVC進行數據的持久化；

  8. 而PVC使用PV進行數據的最終持久化處理。


提示：關於Kubernetes的部署參考《附003.Kubeadm部署Kubernetes》。

6.2 定義StorageClass


關鍵字說明：

  • provisioner：表示存儲分配器，需要根據後端存儲的不同而變更；

  • reclaimPolicy: 默認即”Delete”，刪除pvc后，相應的pv及後端的volume，brick(lvm)等一起刪除；設置為”Retain”時則保留數據，若需刪除則需要手工處理；

  • resturl：heketi API服務提供的url；

  • restauthenabled：可選參數，默認值為”false”，heketi服務開啟認證時必須設置為”true”；

  • restuser：可選參數，開啟認證時設置相應用戶名；

  • secretNamespace：可選參數，開啟認證時可以設置為使用持久化存儲的namespace；

  • secretName：可選參數，開啟認證時，需要將heketi服務的認證密碼保存在secret資源中；

  • clusterid：可選參數，指定集群id，也可以是1個clusterid列表，格式為”id1,id2”；

  • volumetype：可選參數，設置卷類型及其參數，如果未分配卷類型，則有分配器決定卷類型；如”volumetype: replicate:3”表示3副本的replicate卷，”volumetype: disperse:4:2”表示disperse卷，其中‘4’是數據，’2’是冗餘校驗，”volumetype: none”表示distribute卷


提示：關於glusterfs各種不同類型的卷見《004.RHGS-創建volume》。

  1 [root@k8smaster01 ~]# echo -n "admin123" | base64		#將密碼轉換為64位編碼
  2 YWRtaW4xMjM=
  3 [root@k8smaster01 ~]# mkdir -p heketi
  4 [root@k8smaster01 ~]# cd heketi/
  5 [root@k8smaster01 ~]# vi heketi-secret.yaml			#創建用於保存密碼的secret
  6 apiVersion: v1
  7 kind: Secret
  8 metadata:
  9   name: heketi-secret
 10   namespace: heketi
 11 data:
 12   # base64 encoded password. E.g.: echo -n "mypassword" | base64
 13   key: YWRtaW4xMjM=
 14 type: kubernetes.io/glusterfs
 15 [root@k8smaster01 heketi]# kubectl create -f heketi-secret.yaml	#創建heketi
 16 [root@k8smaster01 heketi]# kubectl get secrets -n heketi
 17 NAME                                 TYPE                                  DATA   AGE
 18 default-token-6n746                  kubernetes.io/service-account-token   3      144m
 19 heketi-config-secret                 Opaque                                3      142m
 20 heketi-secret                        kubernetes.io/glusterfs               1      3m1s
 21 heketi-service-account-token-ljlkb   kubernetes.io/service-account-token   3      143m
 22 [root@kubenode1 heketi]# vim gluster-heketi-storageclass.yaml	#正式創建StorageClass
 23 apiVersion: storage.k8s.io/v1
 24 kind: StorageClass
 25 metadata:
 26   name: gluster-heketi-storageclass
 27 parameters:
 28   resturl: "http://10.254.111.219:8080"
 29   clusterid: "67004a06fbcb4fa525bcec1fbaa9ef2d"
 30   restauthenabled: "true"					#若heketi開啟認證此處也必須開啟auth認證
 31   restuser: "admin"
 32   secretName: "heketi-secret"					#name/namespace與secret資源中定義一致
 33   secretNamespace: "heketi"
 34   volumetype: "replicate:3"
 35 provisioner: kubernetes.io/glusterfs
 36 reclaimPolicy: Delete
 37 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-storageclass.yaml



注意：storageclass資源創建后不可變更，如修改只能刪除后重建。

  1 [root@k8smaster01 heketi]# kubectl get storageclasses		#查看確認
  2 NAME                          PROVISIONER               AGE
  3 gluster-heketi-storageclass   kubernetes.io/glusterfs   85s
  4 [root@k8smaster01 heketi]# kubectl describe storageclasses gluster-heketi-storageclass




6.3 定義PVC

  1 [root@k8smaster01 heketi]# vi gluster-heketi-pvc.yaml
  2 apiVersion: v1
  3 kind: PersistentVolumeClaim
  4 metadata:
  5   name: gluster-heketi-pvc
  6   annotations:
  7     volume.beta.kubernetes.io/storage-class: gluster-heketi-storageclass
  8 spec:
  9   accessModes:
 10   - ReadWriteOnce
 11   resources:
 12     requests:
 13       storage: 1Gi


注意：accessModes可有如下簡寫：

  • ReadWriteOnce：簡寫RWO，讀寫權限，且只能被單個node掛載；

  • ReadOnlyMany：簡寫ROX，只讀權限，允許被多個node掛載；

  • ReadWriteMany：簡寫RWX，讀寫權限，允許被多個node掛載。


  1 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-pvc.yaml -n heketi
  2 [root@k8smaster01 heketi]# kubectl get pvc -n heketi
  3 [root@k8smaster01 heketi]# kubectl describe pvc gluster-heketi-pvc -n heketi
  4 [root@k8smaster01 heketi]# kubectl get pv -n heketi
  5 [root@k8smaster01 heketi]# kubectl describe pv pvc-ca949559-094a-11ea-8b3c-000c29fa7a79 -n heketi




  1 [root@k8smaster01 heketi]# kubectl describe endpoints glusterfs-dynamic-ca949559-094a-11ea-8b3c-000c29fa7a79 -n heketi




提示：由上可知：PVC狀態為Bound，Capacity為1G。查看PV詳細信息，除容量，引用storageclass信息，狀態，回收策略等外，同時可知GlusterFS的Endpoint與path。EndpointsName為固定格式：glusterfs-dynamic-PV_NAME，且endpoints資源中指定了掛載存儲時的具體地址。

6.4 確認查看


通過5.3所創建的信息：

  • volume與brick已經創建；

  • 主掛載點（通信）在172.24.8.41節點，其餘兩個節點備選；

  • 三副本的情況下，所有節點都會創建brick。

  1 [root@k8smaster01 ~]# kubectl get pod -n heketi
  2 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- lsblk	#glusterfs節點查看
  3 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- df -hT	#glusterfs節點查看
  4 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- gluster volume list
  5 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- gluster volume info vol_29ba6f9665522ad5893412e61799a433				#glusterfs節點查看




6.5 Pod掛載測試

  1 [root@xxx ~]# yum -y install centos-release-gluster
  2 [root@xxx ~]# yum -y install glusterfs-fuse					#安裝glusterfs-fuse



提示：本環境master節點也允許分發pod，因此所有master也必須安裝glusterfs-fuse以便於正常掛載，同時版本需要和glusterfs節點一致。

  1 [root@k8smaster01 heketi]# vi gluster-heketi-pod.yaml
  2 kind: Pod
  3 apiVersion: v1
  4 metadata:
  5   name: gluster-heketi-pod
  6 spec:
  7   containers:
  8   - name: gluster-heketi-container
  9     image: busybox
 10     command:
 11     - sleep
 12     - "3600"
 13     volumeMounts:
 14     - name: gluster-heketi-volume			#必須和volumes中name一致
 15       mountPath: "/pv-data"
 16       readOnly: false
 17   volumes:
 18   - name: gluster-heketi-volume
 19     persistentVolumeClaim:
 20       claimName: gluster-heketi-pvc	  	 	#必須和5.3創建的PVC中的name一致
 21 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-pod.yaml -n heketi	#創建Pod


6.6 確認驗證

  1 [root@k8smaster01 ~]# kubectl get pod -n heketi | grep gluster-heketi
  2 gluster-heketi-pod        1/1     Running   0          4m58s
  3 [root@k8smaster01 ~]# kubectl exec -it gluster-heketi-pod /bin/sh -n heketi 	#進入Pod寫入測試文件
  4 / # cd /pv-data/
  5 /pv-data # echo "This is a file!" >> a.txt
  6 /pv-data # echo "This is b file!" >> b.txt
  7 /pv-data # ls
  8 a.txt  b.txt
  9 [root@k8smaster01 ~]# kubectl exec -it gluster-heketi-pod -n heketi -- df -h	#查看所掛載的glusterfs



  1 [root@k8smaster01 ~]# kubectl get pods -n heketi -o wide		#查看對應的glusterfs node



  1 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- cat /var/lib/heketi/mounts/vg_2c7a02d1b1b7c1f165283b6691062102/brick_16e37a18a5e5fd40e14338ba78d99565/brick/a.txt
  2 This is a file!



提示：通過Pod寫入相應的測試文件，然後通過glusterfs node節點查看是否存在。

6.7 刪除資源

  1 [root@k8smaster01 ~]# cd heketi/
  2 [root@k8smaster01 heketi]# kubectl delete -f gluster-heketi-pod.yaml -n heketi
  3 [root@k8smaster01 heketi]# kubectl delete -f gluster-heketi-pvc.yaml
  4 [root@k8smaster01 heketi]# kubectl get pvc -n heketi
  5 [root@k8smaster01 heketi]# kubectl get pv -n heketi
  6 [root@k8smaster01 heketi]# kubectl exec -ti glusterfs-b854k -n heketi gluster volume list | grep gluster




參考：https://www.linuxba.com/archives/8152

https://www.cnblogs.com/blackmood/p/11389811.html本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

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

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

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

Arduino驅動ILI9341彩屏（一）——顏色問題

admin

 

最近在淘寶的店鋪上淘到了一塊ILI9341的彩色液晶屏，打算研究一下如何使用。

淘寶店鋪購買屏幕之後有附源代碼可供下載，代碼質量慘不忍睹，各種縮進不規範就不說了，先拿來試一下吧。

這是淘寶店鋪代碼的核心部分：

void setup()
{
  Lcd_Init();
 //LCD_Clear(0xf800);
}

void loop()
{  
   LCD_Clear(0xf800);
   LCD_Clear(0x07E0);
   LCD_Clear(0x001F);
  /*   
  for(int i=0;i<1000;i++)
  {
    Rect(random(300),random(300),random(300),random(300),random(65535)); // rectangle at x, y, with, hight, color
  }*/
  
//  LCD_Clear(0xf800);
}

代碼裏面的setup()和loop()是arduino特有的主函數，和普通C程序的main()函數一樣。

setup()函數在開機時只運行一次，運行完之後就開始循環運行loop()函數。

程序先在setup()函數里做了一下初始化操作Lcd_Init()，接着開始連續用不同顏色清屏。

這裏的LCD_Clear()就是清屏函數了，原型如下：

void LCD_Clear(unsigned int j)                   
{    
  unsigned int i,m;
 Address_set(0,0,240,320);
  //Lcd_Write_Com(0x02c); //write_memory_start
  //digitalWrite(LCD_RS,HIGH);
  digitalWrite(LCD_CS,LOW);


  for(i=0;i<240;i++)
    for(m=0;m<320;m++)
    {
      Lcd_Write_Data(j>>8);
      Lcd_Write_Data(j);

    }
  digitalWrite(LCD_CS,HIGH);   
}

縮進不規範就不吐槽了(；へ：)，連變量名都起得亂七八糟，簡直慘不忍睹。稍微重寫了一下函數，長這樣：

void LCD_Clear(unsigned int color){
  Address_set(0,0,240,320);
  digitalWrite(LCD_CS,LOW);
  for(int i=0;i<240;i++){
    for(int m=0;m<320;m++){
      Lcd_Write_Data(color>>8);
      Lcd_Write_Data(color);
    }
  }
  digitalWrite(LCD_CS,HIGH);
}

這個函數先使用Address_set()設置了刷新區域，然後把LCD_CS針腳電壓拉低，之後循環寫入color。

color分兩次寫入，一次寫入高八位(16位整形前面8個bit)，一次寫入低八位。

看上去好像沒什麼問題，但loop()函數中LCD_Clear()卻是直接用十六進制寫入的。

寫一個RGB()函數把RGB顏色轉換成十六進制，不是更人性化嗎？

讀了一遍源代碼，結果真的找到了店家的RGB函數：

int RGB(int r,int g,int b)
{return r << 16 | g << 8 | b;
}

還是不規範的縮進(╯︵╰)。但有總比沒有好，輸出紅色試一下：

void setup()
{
  Lcd_Init();
  LCD_Clear(RGB(255,0,0));
}

void loop()
{  
   //nothing
}

出故障了。

 

 

 

Arduino重啟后，屏幕輸出了黑色！再試着排除一下故障，把RGB(255,0,0)改成RGB(0,255,0)，輸出綠色試試：

 

 

 

 

結果輸出了橙色！

之後我又反覆嘗試了，沒有一次輸出正確的顏色。莫非是這個RGB()函數有問題，淘寶店鋪才用十六進制数字？

再仔細推導了一下：return r << 16 | g << 8 | b;把紅色左移16位，綠色左移8位，藍色不動，所以合成的二進制應該是這樣的：

RRRRRRRRGGGGGGGGBBBBBBBB

R代表紅色位，G代表綠色位，B代表藍色位，每種顏色8位，總共24位。計算了一下可能性：

 

 

 總共1677萬種可能，也就是1677萬種顏色，這就是普通電腦的真彩顏色。但LCD_Clear()函數是這麼寫的：

Lcd_Write_Data(color>>8);
Lcd_Write_Data(color);

總的只能寫入十六個bit，也就是16位，這和24位對不上號啊？

再回頭看了一下，店鋪代碼的setup()函數中有這樣一行白色清屏指令：

//LCD_Clear(0xf800);

0xf800換算成十進制，是63488，有沒有感覺很接近一個數？

沒錯，就是65535，單個16位無符號整數的最大儲存範圍。

16位整型變量，顧名思義就是用16個0和1組成的變量。可以儲存的整數範圍是-32768 ~ 32767，32768 + 32767剛好等於65535，換算到二進制，就是1111111111111111,16個1。

 

這時，真相出現了——這台機器所採用的，是16位顏色，也被成為RGB565顏色模式。

 

早期的16位計算機由於架構的設計，一次只能處理一個16位二進制數。而圖形显示對速度要求特別高，所以一個像素必須要用一個16進制數來表示，也就是16位顏色。

如果用採用24位顏色，就需要兩個16進制數，也就是2Bytes，速度就慢了一半。

而每個像素都是使用紅黃藍三基色來显示的，所以一個16進制數必須分3份，來分別表示紅、黃、藍的數據。

這就出現了一個問題：

16 / 3 = 5.33333

紅黃藍三種顏色平均佔用5.33333個bit。

可bit是計算機存儲的基本單位，要麼是1，要麼是0，不能再分割。必須要有一種顏色多用一個位，才能充分單個利用16進制整數。

人體的綠色視錐細胞比較敏感，正好，那綠色就用6位，紅色藍色就用5位吧。

這就是著名的RGB565模式，總共能存儲65535種顏色。

早期的遊戲都採用這種模式，所以顏色不夠豐富，很有特色：

 

 

 

 這塊ILI9341显示屏模塊（注意不是ILI9341芯片本身）也剛好只有16根數據引腳，所以就採用了這種RGB565的顏色模式。

找到了問題，那就改一下程序吧：

int RGB(int r,int g,int b)
{
  return r << 11 | g << 5 | b;
}

光改RGB()函數還不夠，現在使用了RGB565模式，所以綠色範圍是從0-63，紅色、藍色的範圍是0-31。

所以還得改setup裏面的清屏函數：

void setup()
{
  Lcd_Init();
  LCD_Clear(RGB(0,63,0));
}

重新下載了程序，屏幕成功显示，輸出了正確的綠色！⁄(⁄⁄•⁄ω⁄•⁄⁄)⁄

 

 

 那麼問題來了，開頭店家給的LCD_Clear(0xf800)這條清屏指令，是怎麼來的？畢竟他連RGB565都不知道呢！

這是我提供的一種可能性：

“0xf600試一下?”

“不行，太灰了！”

“那0xf700呢？”

“還是不行！老闆，我們都試了一下午了，肯定是屏幕壞了！”

“加油，還差一點點了，肯定可以的！”

“0xf800好像還行，但是還是有點灰！”

“沒關係，反正買家能點亮屏幕就行，其他的我們不管！”

“……”

所以這家淘寶店鋪根本不知道自己在買什麼。ヽ(￣▽￣)ﾉ

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

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

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

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

Gogoro 與小牛歐洲廝殺，搶佔德國灘頭堡

admin

德國因為天氣較冷，摩托車被視為是夏天的玩具，但現在卻成為Gogoro 與中國牛電科技等亞洲電動機車品牌進軍歐洲市場的敲門磚。

現在電動機車可以透過應用程式連結到智慧手機，進行簡易的充電、里程控制以及反偷竊與帳單功能等等。日經新聞報導，Gogoro 去年8 月開始在德國柏林透過電動機車分享計畫Coup 來布局市場，起初提供200 台，近期會再增加800 台，而中國的牛電科技則在全德國、奧利地、比利時與瑞士市場開始銷售，尚未公布銷售數字。

這兩家競爭者都與德國汽車零件供應商Bosch 合作，Coup 是Bosch 的子公司，而牛電科技電動機車則使用Bosch 的引擎。Bosch 也積極與電動車廠合作，作為從內燃機引擎轉向電動車引擎世代的契機，因為電動機車只需要數十個零件，而傳統機車需要上千個零件，德國許多汽車零件供應商都預告裁員。Coup 則是Bosch 成立來形塑城市移動趨勢的前哨戰，以提供用戶服務為核心。

報導指出，Gogoro 的電池充電概念讓Coup 印象深刻。Gogoro 自2015 年以來一直在台灣城市營運自己的電子移動計畫，但客戶必須購買相當於6 萬元新台幣的電動機車，然後在交換站網路交換電池，每月付款新台幣300~900 元。Gogoro 在柏林則提供全天出租20 歐元，或3 歐元30 分鐘，而不需要購買一台電動機車。

Coup 智慧手機應用程式可顯示客戶在哪裡可以找到可用的電動機車、解鎖和鎖定，並進行計費。在使用過程中，應用程式會顯示電動機車的位置，並通知電池狀態和剩餘里程。總距離約95 公里，最高時速45 公里，21 歲以上的人可以使用德國駕駛執照租用。

Gogoro 表示，選擇柏林而不是冬天仍溫暖怡人的羅馬與馬德里，是因為這裡能引領潮流，而且柏林人民擁抱新事物。1980 年柏林以自己的共享資本為傲，引進Airbnb 的前身Mitwohnzentralen，並在2014 年推出一個電動鑽機租借商店。這座城市擁有十幾個汽車共享計畫。分析師認為選擇德國也是利用德國公司高品質的聲譽來進軍其他歐洲市場。

中國牛電科技推出的電動機車售價2,700 歐元，也使用與Coup 類似的應用程式，趁Gogoro 專注布局柏林時快速佔領其他市場。在德國城鎮Fulda，三菱與鈴木汽車的經銷商自3 月來開始銷售小牛電動機車。

Coup 即將進軍巴黎，提供首批600 台Gogoro，讓Gogoro 在歐洲銷售量達到1,600 台，另外在台灣銷售2 萬台。牛電科技預計到2018 年全球賣出15 萬台。截至2016 年9 月，中國已經賣出10 萬台。

（合作媒體：。圖片出處：Gogoro）

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

【其他文章推薦】

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

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

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

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

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

上海新能源汽車展8月23舉行 吉利將攜帝豪PHEV亮相

admin

進入2017年以來，上海市新能源汽車推廣應用和產業發展繼續保持高增長，1-5月新能源汽車推廣上牌數量達到10699輛。據瞭解，目前在上海市場上銷售的新能源車型累計超過100款，其中本地品牌占比為35%，其他省市品牌占比達到65%，市場累計推廣前5位的品牌依次為比亞迪、榮威、北汽、奇瑞、Tesla。

當前，上海已成為新能源汽車全球保有量最大的城市，吉利汽車自然不會放過這個巨大的市場。在最近上海市經信委公佈的4批新能源汽車備案資訊表中，吉利分別在第三批、第四批目錄中均有車型進入。據悉，吉利進入上海市新能源汽車備案資訊表中的車型為吉利帝豪EV300及吉利帝豪PHEV。

吉利帝豪EV300自推出以來，頗受市場的歡迎，今年5月還登頂了新能源汽車單車銷量排行板的第一位，而帝豪PHEV作為吉利旗下首款插電式混合動力車型，自公佈以來也是備受關注。

據瞭解，吉利帝豪PHEV外觀上與吉利帝豪EV基本相同。內飾方面，帝豪PHEV配備三輻式真皮方向盤並集成了CCS定速巡航、多媒體播放、語音控制等控制按鈕。而與帝豪EV不同的是，在中控部分帝豪PHEV增加了旋鈕式檔位，使車輛可在純電動、混合動力等模式中進行切換，增強了操作的便利性及駕駛體驗。

最亮眼的部分是帝豪PHEV採用了被稱為“聯擎”的功率分流式混合動力技術，搭載代號為JLγ-4G15H的1.5L發動機與兩台高性能電機和11.3kWh的三元鋰電池組組成的插電式混合動力系統。新車最高時速可達175km/h，NEDC工況油耗1.5L/100km，HEV模式下綜合工況油耗5.1L/100km，NEDC工況下純電續航里程61km。

作為全國插電式混合動力最大銷售城市，吉利帝豪PHEV本次順利進入上海新能源汽車目錄無疑是個極好的信號。為了與各位大咖搶佔市場份額，吉利汽車將攜帝豪EV300，帝豪PHEV亮相2017上海國際新能源汽車產業博覽會。其中帝豪PHEV是進入上海新能源汽車目錄後，首度亮相上海。

據瞭解，2017上海國際新能源汽車產業博覽會是由充電設施線上網、廣東省充電設施協會、廣東省新能源汽車產業協會、中國土木工程學會城市公共交通學會和振威展覽股份聯合舉辦，展示面積達45000平米，參展企業涵蓋了整車、核心三電（電池、電機、電控）、充電設備等產業板塊，是我國新能源汽車產業領域最專業的展覽展示和技術交流的綜合性展會平臺。

除吉利外，比亞迪、申龍客車、珠海銀隆、上汽集團、上饒客車、中植新能源、中通、江淮、眾泰、知豆、南京金龍、成功汽車、新吉奧集團、瑞馳新能源、福汽新龍馬等新能源汽車企業，以及精進電動、英威騰、東風電機、力神、沃特瑪、國軒高科、地上鐵、特來電、科陸、巴斯巴、萬馬專纜、奧美格、瑞可達等核心三電及零部件知名企業將亮相本次展會。

參觀預登記，請點擊：

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

【其他文章推薦】

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

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

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

圖解Elasticsearch的核心概念

admin

本文講解大綱，分8個核心概念講解說明：

  • NRT
  • Cluster
  • Node
  • Document&Field
  • Index
  • Type
  • Shard
  • Replica

Near Realtime（NRT）近實時

Elasticsearch的核心優勢就是（Near Real Time NRT）近乎實時，我們稱之為近實時。
NRT有兩個意思，下面舉例說明下：

  • 從寫入索引數據到數據可以被搜索到有一個小延遲（大概1秒）；

舉個例子：電商平台新上架一個新商品，1秒後用戶就可搜索到這個商品信息，這就是近實時。

  • 基於Elasticsearch執行搜索和分析可以達到秒級查詢

也舉個例子說明，比如我現在想查詢我在淘寶，最近一年都買過幾件商品，總共花了多少錢，最貴的商品多少錢，哪個月買到東西最多，什麼類型的商品買的最多這樣的信息，如果淘寶說，你要等待10分鐘才能出結果，你是不是很崩潰，這個延遲的時間就不是近實時，如果淘寶可以秒級別返回給你，就是近實時了。

下面畫一個圖，解釋下三個基本概念的

Cluster：集群

包含多個節點，每個節點屬於哪個集群是通過一個配置（集群名稱，默認是elasticsearch）來決定的，對於中小型應用來說，剛開始一個集群就一個節點很正常。集群的目的為了提供高可用和海量數據的存儲以及更快的跨節點查詢能力。

Node：節點

集群中的一個節點，節點也有一個名稱（默認是隨機分配的），節點名稱很重要（在執行運維管理操作的時候），默認節點會去加入一個名稱為“elasticsearch”的集群，如果直接啟動一堆節點，那麼它們會自動組成一個elasticsearch集群，當然一個節點也可以組成一個elasticsearch集群

Document&field：文檔和字段

document 是es中的最小數據單元，一個document可以是一條客戶數據，一條商品分類數據，一條訂單數據，通常用JSON數據結構表示，每個index下的type中，都可以去存儲多個document。一個document裏面有多個field，每個field就是一個數據字段。

相當於mysql里的行，可以簡單這麼理解，舉個例子。一個商品的文檔數據一條如下：

product document
{
  "product_id": "1000",
  "product_name": "mac pro 2019 款筆記本",
  "product_desc": "高性能，高分辨率，編程必備神器",
  "category_id": "2",
  "category_name": "电子產品"
}

Index：索引

包含一堆有相似結構的文檔數據，比如可以有一個客戶索引，商品分類索引，訂單索引，索引有一個名稱。
一個index包含很多document，一個index就代表了一類類似的或者相同的document。比如說建立一個product index，商品索引，裏面可能就存放了所有的商品數據，所有的商品document。

Type：類型

每個索引里都可以有一個或多個type，type是index中的一個邏輯數據分類，一個type下的document，都有相同的field，比如博客系統，有一個索引，可以定義用戶數據type，博客數據type，評論數據type。

商品index，裏面存放了所有的商品數據，商品document

但是商品分很多種類，每個種類的document的field可能不太一樣，比如說電器商品，可能還包含一些諸如售後時間範圍這樣的特殊field；生鮮商品，還包含一些諸如生鮮保質期之類的特殊field

type，日化商品type，電器商品type，生鮮商品type

日化商品type：product_id，product_name，product_desc，category_id，category_name
電器商品type：product_id，product_name，product_desc，category_id，category_name，service_period
生鮮商品type：product_id，product_name，product_desc，category_id，category_name，eat_period

每一個type裏面，都會包含一堆document

{
“product_id”: “2”,
“product_name”: “長虹電視機”,
“product_desc”: “4k高清”,
“category_id”: “3”,
“category_name”: “電器”,
“service_period”: “1年”
}

{
“product_id”: “3”,
“product_name”: “基圍蝦”,
“product_desc”: “純天然，冰島產”,
“category_id”: “4”,
“category_name”: “生鮮”,
“eat_period”: “7天”
}

Shard 分片，也稱 Primary Shard

單台機器無法存儲大量數據，es可以將一個索引中的數據切分為多個shard，分佈在多台服務器上存儲。有了shard就可以橫向擴展，存儲更多數據，讓搜索和分析等操作分佈到多台服務器上去執行，提升吞吐量和性能。

每個shard都是一個lucene index。

Replica 副本,也稱 Replica Shard

任何一個服務器隨時可能故障或宕機，此時shard可能就會丟失，因此可以為每個shard創建多個replica副本。replica可以在shard故障時提供備用服務，保證數據不丟失，多個replica還可以提升搜索操作的吞吐量和性能。

primary shard（建立索引時一次設置，不能修改，默認5個），

replica shard（隨時修改數量，默認1個），

默認每個索引10個shard，5個primary shard，5個replica shard，最小的高可用配置，是2台服務器。

相關索引解釋說明：

  • index包含多個shard
  • 每個shard都是一個最小工作單元，承載部分數據，lucene實例，完整的建立索引和處理請求的能力
  • 增減節點時，shard會自動在nodes中負載均衡
  • primary shard和replica shard，每個document肯定只存在於某一個primary shard以及其對應的replica shard中，不可能存在於多個primary shard
  • replica shard是primary shard的副本，負責容錯，以及承擔讀請求負載
  • primary shard的數量在創建索引的時候就固定了，replica shard的數量可以隨時修改
  • primary shard的默認數量是5，replica默認是1，默認有10個shard，5個primary shard，5個replica shard
  • primary shard不能和自己的replica shard放在同一個節點上（否則節點宕機，primary shard和副本都丟失，起不到容錯的作用），但是可以和其他primary shard的replica shard放在同一個節點上

索引在集群中分配圖：

本文由博客一文多發平台 發布！

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

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

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

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

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

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

組件設計 —— 重新認識受控與非受控組件

admin

重新定義受控與非受控組件的邊界

對非受控組件與受控組件作了如圖中下劃線的邊界定義。一經推敲, 該定義是缺乏了些完整性和嚴謹性的, 比如針對非表單組件(彈框、輪播圖)如何劃分受控與非受控的邊界? 又比如非受控組件是否真的如文案上所說的數據的展示與變更都由 dom 自身接管呢?

在非受控組件中, 通常業務調用方只需傳入一個初始默認值便可使用該組件。以 Input 組件為例:

// 組件提供方
function Input({ defaultValue }) {
  return <input defaultValue={defaultValue} />
}

// 調用方
function Demo() {
  return <Input defaultValue={1} />
}

在受控組件中, 數值的展示與變更則分別由組件的 state 與 setState 接管。同樣以 Input 組件為例:

// 組件提供方
function Input() {
  const [value, setValue] = React.useState(1)
  return <input value={value} onChange={e => setValue(e.target.value)} />
}

// 調用方
function Demo() {
  return <Input />
}

有意思的一個問題來了, Input 組件到底是受控的還是非受控的? 我們甚至還可以對代碼稍加改動成 <Input defaultValue={1} /> 的最初調用方式:

// 組件提供方
function Input({ defaultValue }) {
  const [value, setValue] = React.useState(defaultValue)
  return <input value={value} onChange={e => setValue(e.target.value)} />
}

// 調用方
function Demo() {
  return <Input defaultValue={1} />
}

儘管此時 Input 組件本身是一個受控組件, 但與之相對的調用方失去了更改 Input 組件值的控制權, 所以對調用方而言, Input 組件是一個非受控組件。值得一提的是, 以非受控組件的使用方式去調用受控組件是一種反模式, 在下文中會分析其中的弊端。

如何做到不管對於組件提供方還是調用方 Input 組件都為受控組件呢? 提供方讓出控制權即可, 調整代碼如下:

// 組件提供方
function Input({ value, onChange }) {
  return <input value={value} onChange={onChange} />
}

// 調用方
function Demo() {
  const [value, setValue] = React.useState(1)
  return <Input value={value} onChange={e => setValue(e.target.value)} />
}

經過上述代碼的推演后, 概括如下: 受控以及非受控組件的邊界劃分取決於當前組件對於子組件值的變更是否擁有控制權。如若有則該子組件是當前組件的受控組件; 如若沒有則該子組件是當前組件的非受控組件。

職能範圍

基於調用方對於受控組件擁有控制權這一認知, 因此受控組件相較非受控組件能賦予調用方更多的定製化職能。這一思路與軟件開發中的有異曲同工之妙, 同時讓筆者受益匪淺的 也是類似的思想。

藉助受控組件的賦能, 以 Input 組件為例, 比如調用方可以更為自由地對值進行校驗限制, 又比如在值發生變更時執行一些額外邏輯。

// 組件提供方
function Input({ value, onChange }) {
  return <input value={value} onChange={onChange} />
}

// 調用方
function Demo() {
  const [value, setValue] = React.useState(1)
  return <Input value={value} onChange={e =>
    // 只支持數值的變更
    if (/\D/.test(e.target.value)) return
    setValue(e.target.value)}
  />
}

因此綜合基礎組件擴展性與通用性的考慮, 受控組件的職能相較非受控組件更加寬泛, 建議優先使用受控組件來構建基礎組件。

反模式 —— 以非受控組件的使用方式調用受控組件

首先何謂反模式? 筆者將其總結為增大隱性 bug 出現概率的模式, 該模式是最佳實踐的對立經驗。如若使用了反模式就不得不花更多的精力去避免潛在 bug。官網對反模式也有很好的。

緣何上文提到以非受控組件的使用方式去調用受控組件是一種反模式? 觀察 Input 組件的第一行代碼, 其將 defaultValue 賦值給 value, 這種將 props 賦值給 state 的賦值行為在一定程度上會增加某些隱性 bug 的出現概率。

比如在切換導航欄的場景中, 恰巧兩個導航中傳進組件的 defaultValue 是相同的值, 在導航切換的過程中便會將導航一中的 Input 的狀態值帶到導航二中, 這顯然會讓使用方感到困惑。

// 組件提供方
function Input({ defaultValue }) {
  // 反模式
  const [value, setValue] = React.useState(defaultValue);
  React.useEffect(() => {
    setValue(defaultValue);
  }, [defaultValue]);
  return <input value={value} onChange={e => setValue(e.target.value)} />;
}

// 調用方
function Demo({ defaultValue }) {
  return <Input defaultValue={defaultValue} />;
}

function App() {
  const [tab, setTab] = React.useState(1);
  return (
    <>
      {tab === 1 ? <Demo defaultValue={1} /> : <Demo defaultValue={1} />}
      <button onClick={() => (tab === 1 ? setTab(2) : setTab(1))}>
        切換 Tab
      </button>
    </>
  );
}

如何避免使用該反模式同時有效解決問題呢? 官方提供了兩種較為優質的解法, 將其留給大家作為思考。

  1. 方法一: (更為推薦)
  2. 方法二:

歡迎關注

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

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

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

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

SpringBoot 配置文件與依賴庫分離打包配置

admin

一、應用場景

一般情況下我們對springboot應用打包時使用springboot的maven插件spring-boot-maven-plugin的maven進行打包，打包完成得到一個fatjar，fatjar的優點是可以直接運行，缺點是體積太大，不利於傳輸，springboot應用打出來的fatjar體積少則幾十M，多則上百M，在往服務器部署傳輸時十分不便，可能只改了某個類文件，都需要重新將整個fatjar重新傳輸一次，特別是走公網傳輸的時候，可能上傳速度只有幾百甚至幾十KB，而整個fatjar中真正我們項目的代碼文件可能也就幾百KB或幾兆的大小，所以有必要將fatjar中的依賴庫與我們項目的class進行分離打包，這樣每次更換項目class就方便很多，而將配置文件也分離出來的原因在於我們可能經常需要更改配置文件的內容，如果放在fatjar中這樣修改是非常不方便的，所以也需要將配置文件也分離出來。

 >  fatjar 即將項目需要的所有依賴庫及配置文件等打進一個jar或war，該文件可直接運行

 

二、配置

2.1 POM配置

下面對pom.xml進行配置，來實現分離打包，配置如下

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>chenyb</groupId>
    <artifactId>demo</artifactId>
    <version>v1.2-release</version>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.6.RELEASE</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- springboot 打包插件 -->
            <!--
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <mainClass>com.xx.xx</mainClass>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            -->

            <!-- maven 打包插件 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <!-- MANIFEST.MF 中 Class-Path 加入前綴 -->
                            <classpathPrefix>lib/</classpathPrefix>
                            <!-- jar包不包含唯一版本標識 -->
                            <useUniqueVersions>false</useUniqueVersions>
                            <!-- 指定入口類 -->
                            <mainClass>cn.test.DemoApplication</mainClass>
                        </manifest>
                    </archive>
                    <outputDirectory>${project.build.directory}</outputDirectory>
                </configuration>
            </plugin>

            <!-- 拷貝依賴 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
                            <overWriteReleases>true</overWriteReleases>
                            <overWriteSnapshots>true</overWriteSnapshots>
                            <overWriteIfNewer>true</overWriteIfNewer>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

        </plugins>
    </build>

</project>

關鍵配置說明：

(1) 去掉了spring-boot-maven-plugin打包插件

(2) 添加 maven-jar-plugin （maven標準打包插件）

(3) maven-dependency-plugin（依賴拷貝插件，主要用於將maven依賴庫拷貝出來）

插件具體的配置，pom.xml中已添加備註說明

 

2.2 打包

執行maven package 命令進行打包，得到的結果如下

 將 lib目錄 及 項目jar 文件拷貝到同一目錄下，我為了測試方便，先全部拷貝到桌面上，（放置服務器上時也需保證在同一目錄下）

 打開demo-v1.2-release可以看到，並沒有將依賴jar打進來，大小隻有不到4KB

 

2.3 config目錄創建

以上做完還還需要將項目配置文件拷貝出來，在與jar包平級目錄建立config目錄，將項目中的application.properties或yaml文件拷貝進來

  config 下的文件

經過以上步驟，全部配置完畢，下面進行一下簡單的測試

 

三、測試

 為了保證加載的是外部config目錄的配置文件，我將application-test.yaml中的server.port改為8085， 打開命令行輸入

C:\Users\Administrator\Desktop>java -jar -Dspring.profiles.active=dev -Dspring.location.config=config/ C:\Users\Administrator\Desktop\demo-v1.2-release.jar

回車運行，能正常啟動說明外部依賴可以正常加載進來

 可以看到啟動完成后tomcat監聽端口為8085，說明外部配置加載成功。

PS : 如果外部配置文件加載失敗，會使用項目jar中的配置文件，如下圖，也就是啟動後會是8080端口

application-dev.yaml中配置的端口是8080

 

而我已將外部config目錄下application-dev.yaml中端口做了修改，使用外部配置文件啟動後會是8085端口

 

四、一點小坑

默認情況下window命令行打開后，是在當前用戶目錄下，像這樣

 而我的config、lib、項目jar拷貝在桌面上，實際路徑是

一開始我在  C:\Users\Administrator> 直接執行下方命令，一直加載不到配置文件

java -jar -Dspring.profiles.active=dev -Dspring.location.config=config/ C:\Users\Administrator\Desktop\demo-v1.2-release.jar

原因就在於程序與配置文件不在同一目錄下，我在C:\Users\Administrator>運行啟動命令，而程序實際目錄在 C:\Users\Administrator\Desktop> 下，因為程序使用了絕對路徑，可以找到文件，所以程序的實際運行路徑為C:\Users\Administrator\Desktop，而我使用的配置 spring.location.config=config/ 使用的是相對路徑，，這個相對路徑又是相對 C:\Users\Administrator> 目錄，所以就會出現找不到配置文件的情況。

 

解決辦法一：

命令行切換到 C:\Users\Administrator\Desktop 目錄，即項目jar所在目錄，運行 java -jar 命令

 

解決辦法二：

將config拷貝到C:/Users/Administrator下，保證C:/Users/Administrator相對路徑下存在config目錄及配置文件（該方法可解決問題，但是不建議）

 

解決方法三：

spring.location.config=config/ 處使用絕對路徑，即C:/Users/Administrator/Desktop/config/ 

 

所以很重要一點，一定保證 執行命令 的目錄 與項目jar、lib、config都在同一目錄下。

 

五、完整demo地址

 

 

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

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

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

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

PL真有意思（二）：程序設計語言語法

admin

前言

雖然標題是程序語言的語法，但是講的是對詞法和語法的解析，其實關於這個前面那個寫編譯器系列的描述會更清楚，有關語言語法的部分應該是穿插在整個設計當中的，也看語言設計者的心情了

和英語漢語這些自然語言不一樣，計算機語言必須是精確的，它們的語法和語義都必須保證沒有歧義，這當然也讓語法分析更加簡單

所以對於編譯器一項很重要的任務就是時別程序設計語言的結構規則，要完成這個目標就需要兩個要求：

  • 完成對語法規則的描述
  • 確定給定程序是否按照這些規則構造起來，也就是符合語法規則

第一個要求主要由正則表達式和上下文無關文法來描述完成，而第二個要求就是由編譯器來完成，也就是語法分析了

描述語法：正則表達式和上下文無關語法

對於詞法，都可以用三種規則描述出來：

  1. 拼接
  2. 選擇
  3. Kleene（也就是重複任意多次）

比如一個整數常量就可以是多個数字重複任意多次，也叫做正則語言。如果對於一個字符串，我們再加入遞歸定義即可以描述整個語法，就可以稱作上下文無關語法

單詞正則表達式

對於程序語言，單詞的類型不外乎關鍵字、標識符、符合和各種類型的常量

對於整數常量就可以用這樣的正則表達式來表示

integer -> digit digit* digit -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

上下文無關文法

一般正則表達式只適用於描述單詞，因為正則表達式無法描述嵌套結構，一般正則表達式的實現都是用有限狀態自動機，之前用Python實現了一個簡單的也是這樣，但是對於匹配任意深度的嵌套結構就需要有一個任意大的狀態機，顯然不符合。而定義嵌套結構對於描述語法非常有用，所以就有了上下文無關文法

expr := id | number | - expr | ( expr ) | expr or expr

op := + | - | * | /

對於上下文無關文法，每條規則叫做一個產生式，產生式左部的符合稱為非終結符，而右部則是多個終結符或者非終結符，最後所有規則都會推到至終結符上，而終結符就是正則表達式定義的單詞

推導和語法樹

一個正確的上下文無關文法，就可以指導我們如何生成一個合乎語法的終結符串

最簡單的就是從開始符號開始，用這個產生式的右部取代開始符合，再從得到的串選擇一個非終結符繼續進行推導，直到沒有剩下的非終結符，這個過程就像遞歸構造一個樹的過程

expr := expr op expr
     := expr op id
     := expr + id
     := expr op expr + id
     := expr op id + id
     := expr * id + id
     := id * id + id

但是對於給定的上下文語法有可能會推導出不止一顆語法分析樹，我們就說這個上下文語法是存在歧義性的。所以對於上面的上下文無關語法還有更好的文法

掃描

掃描也就是詞法分析，詞法分析完全可以不需要什麼正則表達式、自動機什麼的，徒手擼出來，現在業界為了更好的生成錯誤信息，應該很多也是手工的詞法分析器

手工的詞法分析器，無非就是一直讀入字符，到能判斷出它的token在送入語法分析器

有限狀態自動機

使用有限狀態機的詞法分析一般都是這樣的幾個步驟

  • 給出詞法的正則表達式

  • 將正則表達式轉換為非確定有限自動機（NFA）

其實對於任意的正則表達式都可以用拼接、選擇和Kleene閉包來表示

而同樣的，有限自動機也可以通過這三種方式來表示，圖就不畫了，這個在之前寫Python正則表達式引擎的文章里都畫過了（溜了

  • 將NFA轉換為確定性有限狀態自動機（DFA）

將NFA轉換到DFA可以採用的是子集構造法，主要思想就是，在讀入給定輸入之後所到達的DFA狀態，表示的是原來NFA讀入同樣輸入之後可能澳大的所有狀態

  • 最小化DFA

對於最小化DFA的主要思想是，我們把DFA所有狀態分為兩個等價類，終止態狀態和非終止狀態。然後我們就反覆搜索等價類X和輸入符合c，使得當給定C作為輸入時，X的狀態能轉換到位於k>1個不同等價類中的狀態。之後我們就把X劃分為k個類，使得類中所有轉檯對於C都會轉移到同一個老類的成員。直到無法再按這種方式找到劃分的類時，我們就完成了

這四個步驟在之前的寫的正則表達式引擎中都完成了，在那三篇文章里會更詳細一點

語法分析

一般語法分析器的輸入是token流，而輸出是一顆語法分析樹。其中分析方法一般可以分為自上而下和自下而上兩類，這些類中最重要的兩個分別稱為LL和LR

LL表示從左向右，最左推導，LR表示從左向右，最右推導。這兩類文法都是從左到右的順序讀取輸入，然後語法分析器試圖找出輸入的推導結果

自上而下的方式

一般自上而下的語法分析器比較符合之前的推導方法，從根節點開始像恭弘=叶 恭弘節點反覆的遞歸推導，直到當前的恭弘=叶 恭弘節點都是終結符

  • 遞歸下降

遞歸下降很符合上面說的從根節點出發進行推導，一般用於一些相對簡單一些的語言

read A
read B
sum := A + B
write sum
write sum / 2

比如對於這個程序的遞歸下降，語法分析器一開始調用program函數，在讀入第一個單詞read后，program將調用stmt_list，再接着調用stmt才真正開始匹配read A。以這種方式繼續下去，語法分析器執行路徑將追溯出語法分析樹的從左向右、自上而下的遍歷

  • 表格驅動的LL自上而下

表格驅動的LL是基於一個語法分析表格和一個棧

分析流程是

  1. 初始化一個棧
  2. 將開始符號壓入棧
  3. 彈出棧頂，然後根據棧頂的符號和當前的輸入符號查表
  4. 如果彈出的是非終結符，將會繼續查表來確定下一個壓入棧中的產生式
  5. 如果是終結符將進行匹配

預測集合

從上面可以看出來最重要的就是那個語法分析表格了，語法分析表格其實就是根據當前輸入字符對下一個產生式的預測，這裏就要用到一個概念：預測集合，也就是First和Follow集合。這個在之前寫編譯器系列講的比較詳細，在這裏就不寫了

當然LL語法也會有很多處理不了的文法，所以也才會有其它的語法分析方法

自下而上的方式

在實踐中，自下而上的語法分析都是表格驅動的，這種分析器在一個棧中保存所有部分完成的子樹的根。當它從掃描器中得到一個新的單詞時，就會將這個單詞移入棧。當它發現位於棧頂的若干符號組成一個右部時，它就會將這些符號歸約到對應的左部。

一個自底向上的語法分析過程對應為一個輸入串構造語法分析書的過程，它從恭弘=叶 恭弘子節點開始，通過shift和reduce操作逐漸向上到達根節點

自底向上的語法分析需要一個堆棧來存放解析的符號，例如對於如下語法：

0.  statement -> expr
1.  expr -> expr + factor
2.           | factor
3.  factor ->  ( expr )
4.           | NUM

來解析1+2

stack input
null 1 + 2
NUM + 2 開始讀入一個字符，並把對應的token放入解析堆棧，稱為shift操作
factor + 2 根據語法推導式，factor -> NUM,將NUM出棧，factor入棧，這個操作稱為reduce
expr + 2 這裏繼續做reduce操作，但是由於語法推導式有兩個產生式，所以需要向前看一個符合才能判斷是進行shift還是reduce，也就是語法解析的LA
expr + 2 shift操作
expr + NUM null shift操作
expr + factor null 根據fator的產生式進行reduce
expr null reduce操作
statement null reduce操作

此時規約到開始符號，並且輸入串也為空，代表語法解析成功

有限狀態自動機的構建

0.  s -> e
1.  e -> e + t
2.  e -> t
3.  t -> t * f
4.  t -> f
5.  f -> ( e )
6.  f -> NUM
  • 對起始推導式做閉包操作

先在起始產生式->右邊加上一個.

s -> .e

對.右邊的符號做閉包操作，也就是說如果 . 右邊的符號是一個非終結符，那麼肯定有某個表達式，->左邊是該非終結符，把這些表達式添加進來

s -> . e
e -> . e + t
e -> . t

對新添加進來的推導式反覆重複這個操作，直到所有推導式->右邊是非終結符的那個所在推導式都引入

  • 對引入的產生式進行分區

把 . 右邊擁有相同非終結符的表達式划入一個分區，比如

e -> t .
t -> t . * f

就作為同一個分區。最後把每個分區中的表達式中的 . 右移動一位，形成新的狀態節點

  • 對所有分區節點構建跳轉關係

根據每個節點 . 左邊的符號來判斷輸入什麼字符來跳入該節點

比如， . 左邊的符號是 t, 所以當狀態機處於狀態0時，輸入時 t 時， 跳轉到狀態1。

  • 對所有新生成的節點重複構建

最後對每個新生成的節點進行重複的構建，直到完成所有所有的狀態節點的構建和跳轉

小結

這一篇主要是提了對詞法和語法的分析過程，因為想要結合語言設計和實踐，更詳細的應該去看前面的寫一個編譯器系列

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

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

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

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

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

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

dbstructsync -mysql表、字段、索引差異解析工具（原創）

admin

最近寫了一個工具（比較兩套測試環境mysql數據庫中表、表字段、索引的差異，基於python）通過文章簡單介紹下工具的相關內容

  1. 工具名稱
  2. 主要功能
  3. 具體使用方法
  4. 部分實現代碼
  5. 後續

一、工具名稱：

dbstructsync （python庫）

二、主要功能：

比較兩套環境中mysql指定庫中表、表字段及索引的差異，返回同步的sql ，裡面包含建表，修改索引，修改字段的sql .

A環境的數據庫db 作為sourcedb， B環境的數據庫db targetdb ，程序邏輯比較的是 sourcedb 與targetdb 的差異，然後返回一個list的數據類型 

list中包含新建表sql，修改、增加字段sql, 刪除、新增索引sql 

現在總共有3個版本，0.0.1 和0.0.2 存在一定的bug, 所以請使用最新的0.0.3版本

 

 

其他說明：由於是剛完成不久的程序，所以暫時不對最終結果sql進行執行，避免對使用過程中產生不好的影響，這個版本大家可以通過python 自行選擇需要執行哪些操作；隨着之後程序的逐步深入修改和演變，會將執行sql這一步也都加進去

同時也會優化使用方式，讓使用這個工具的小夥伴更容易操作

三、具體使用方法：

1、 pip install  -i https://pypi.python.org/pypi  dbstructsync   

在代碼里引入使用，

from DbStructSync import cli 

result=cli.db_sync(sourcedb, targetdb) 
#sourcedb,targetdb是兩個dict的參數，具體參數看下面
# 這裏得到的    result = ['use 庫;', 
#             'CREATE TABLE `test_async` (\n  `test_async` #varchar(30) NOT NULL,\n  `aa` varchar(400) DEFAULT NULL,\n  #PRIMARY KEY (`test_async`)\n) ENGINE=InnoDB DEFAULT #CHARSET=utf8;',
#             'drop index `index_chaxx` on chanxx_auto_puxx_conf;',
#             'create index `index_chaxx` on #chanxx_auto_puxx_conf(`channel_nxx`,`channel_prxx`) USING #BTREE;']
#result 中包含  use 庫；
#              如果有少的表，會有 create table的數據; 如果有不同的索引，會#存在drop index 和create index的sql;
#              如果有不同的字段，會有alter table的sql ;
#只需要對這個結果，再通過pymysql的一些數據庫操作就可以保證 sourcedb #的內容與taragetdb一致。


2、同時還支持命令行操作，代碼寫入到x.py代碼中


result = cli.db_sync_commandline()
python x.py --source  host=10.1.1.x,port=3306,user=root,passwd=root,db=investx --target host=10.1.1.x,port=3306,user=root,passwd=root,db=investx


 


命令行中  –source  key=value;key2=value2;key3=value3  –target key=value;key2=value2;key3=value3


–source, –target 是兩給必輸的參數，後續的值會作為一個dict類型傳入程序。 –source是源庫的信息， –target是目標庫的信息


還包括其他幾個命令參數 –only-index , –only-fields ; –only-index 只比較索引差異， –only-fields 只比較字段差異， 非必填，默認都為False 


四、部分實現代碼：


 


def diff_tables(sourcetable, targettable):
    '''

    :param sourcetable:  源數據庫的表名列表
    :param targettable:  目的數據庫的表名列表
    :return: 返回dict，包含三種結果，源庫多的表，目標庫多的表，相同的表
    '''
    logger.info('開始比較兩個庫中表的差異,源庫表{}，目標庫表{}'.format(sourcetable, targettable))
    table_result={}
    if not isinstance(sourcetable, list) or not isinstance(targettable, list):
         raise  TypeError('sourcetable , targettable的類型不是list')
    source_diff = set(sourcetable) - set(targettable)
    target_diff = set(targettable) - set(sourcetable)
    same_tables = set(sourcetable)& set(targettable)
    table_result['source'] = source_diff
    table_result['target'] = target_diff
    table_result['same'] = same_tables
    logger.info('兩個庫中表的差異結果{}'.format(table_result))
    return  table_result
 

def  diff_indexs_fields(sourcesql, targetsql, type=1):
    '''
    :param sourcesql: 源數據庫表的創建sql
    :param targetsql: 目標數據表的創建sql
    :return: 記錄下索引不一致的地方
    '''
    result = {}
    logger.info('解析語句中的索引字段，並進行比較索引')
    sourcesql = parse_str(sourcesql)  # 從括號中提取需要的內容
    #logger.info('從括號中提取出來的信息數據{}'.format(sourcesql))
    sourcesql = lists2str(sourcesql)  #將list轉換為str，並對數據的空格數據進行處理
    logger.info('解析完的數據的信息{}'.format(sourcesql))
    sourcesql = sourcesql.split('\n') #將str按照'\\n'進行分割
    logger.info('解析完數據之後的信息{}'.format(sourcesql))
    targetsql = parse_str(targetsql)
    targetsql = lists2str(targetsql)
    targetsql = targetsql.split('\n')
    if type ==1:
        source_index = parse_fields(sourcesql,type)
        target_index = parse_fields(targetsql,type)

        result= compare_indexs_field(source_index, target_index, type)
    elif type ==2:
        source_field_sql = parse_fields(sourcesql, type)
        target_field_sql = parse_fields(targetsql, type)
        result = compare_indexs_field(source_field_sql, target_field_sql, type)
    return  result

def dict2sql(dict_str):
    '''
    將解析完成的數據轉換為對應的可執行sql
    :param dict_str:
    :return:
    '''
    dict_str = copy.deepcopy(dict_str) # 做一個深度copy，可以放心的進行相關數據處理

    if not isinstance(dict_str, dict):
        raise  TypeError('調用方法{}參數不是dict類型，請確認'.format('dict2sql'))
    #獲取db名字
    for key ,value in dict_str.items():
        dbname = key
        logger.info('數據庫名{}'.format(dbname))
        for table, table_desc  in  value.get('source').items():
               if table =='create_table':
                   #create_table_sql = lists2str(table_desc)
                   dict_str[dbname]['source'][table] = table_desc
                   #其他的都是table的名字
                   logger.info('數據庫的修改語句:{}'.format(table_desc))
               else:
                  logger.info('對於索引和字段的解析原始數據{}'.format(table_desc))
                  if table_desc.get('index'):
                      create_index_sql_lists=[]
                      #create_index_sql_lists.append('use {};'.format(dbname))
                      index_lists= (table_desc.get('index'))
                      result_index= parse_comma_split(str(index_lists)[1:-1])
                      for i in result_index:
                           if i.strip().startswith('\'KEY'):
                               #print(i.strip())
                               index_values = parse_space_split(i.strip())
                               drop_index_sql= 'drop index {} on {}'.format(index_values[1],table )
                               if len(index_values)<=3:
                                  create_index_sql='create index {} on {}{} '.format(index_values[1], table, index_values[2])
                               else:
                                  create_index_sql='create index {} on {}{} {}'.format(index_values[1], table, index_values[2], ' '.join(index_values[3:]))
                               create_index_sql_lists.append(drop_index_sql)
                               create_index_sql_lists.append(create_index_sql)

                           if i.strip().startswith('\'UNIQUE KEY'):
                                 index_values = parse_space_split(i.strip())
                                 drop_index_sql = 'drop index {} on {}'.format(index_values[2], table)
                                 if len(index_values) <= 4:
                                     create_index_sql = 'create unique index {} on {}{} '.format(index_values[2], table,
                                                                                          index_values[3])
                                 else:
                                     create_index_sql = 'create unique index {} on {}{} {}'.format(index_values[2], table,
                                                                                               index_values[3],
                                                                                               ' '.join(index_values[4:]),
                                                                                               )
                                 create_index_sql_lists.append(drop_index_sql)
                                 create_index_sql_lists.append(create_index_sql)
                      logger.info('表{}解析出來的索引的修改sql{}'.format(table, create_index_sql_lists))
                      dict_str[dbname]['source'][table]['index'] = create_index_sql_lists
                  if table_desc.get('fields'):
                      create_fields_sql_lists=[]
                      #create_fields_sql_lists.append('use {};'.format(dbname))
                      modify_field_sqls = table_desc.get('fields').get('modify',None)
                      create_field_sqls=table_desc.get('fields').get('lose',None)

                      if modify_field_sqls:
                           for modify_field_sql in modify_field_sqls:
                               sql_indexs = parse_space_split(str(modify_field_sql)[0:-1])
                               #print(sql_indexs)
                               alter_fields_sql='alter table {} modify column {} {} {}'.format(table, sql_indexs[0],sql_indexs[1],' '.join(sql_indexs[2:]))
                               create_fields_sql_lists.append(alter_fields_sql)
                      if create_field_sqls:
                           for  create_field_sql in create_field_sqls:
                                sql_indexs = parse_space_split(str(create_field_sql)[0:-1])
                                create_fields_sql='alter table {} add column {} {}'.format(table, sql_indexs[0],' '.join(sql_indexs[2:]))
                                create_fields_sql_lists.append(create_fields_sql)
                      logger.info('表{}解析出來的字段的修改sql{}'.format(table,create_fields_sql_lists))
                      dict_str[dbname]['source'][table]['fields'] = create_fields_sql_lists

    return  dict_str  # 返回給一個全部是可執行sql的dict




五、後續：


1、對使用過程中遇到對bug進行修復


2、對代碼進行優化


3、增加其他相關功能，讓工具越來越好用


4、希望使用的小夥伴多提意見，未來成為一個好用的小工具


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


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


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


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


							

					

	






	

				
							
		

			


				
特斯拉需求大！住友金屬追加擴產電池材料、增至2.5倍


								

					   admin
				
				

							


						


				
 






 






日本住友金屬礦山（Sumitomo Metal Mining）28日發布新聞稿宣布，該公司雖已於去年10月27日表示將砸下180億日圓於2018年1月將鋰離子電池正極材料「鎳酸鋰（見附圖）」月產能擴增至3,550噸，不過因電動車（EV）用鋰離子電池需求擴大，因此決議對「鎳酸鋰」進行追加增產措施，計畫投入40億日圓於磯浦工廠進行增產工程，目標在2018年6月將整體「鎳酸鋰」月產能擴增至4,550噸、將達現行的2.5倍。


住友金屬礦山指出，該公司正持續擴大與Panasonic攜手研發的高性能鎳酸鋰產能，此次為了因應Panasonic擴大鋰離子電池產能、故決定對鎳酸鋰進行追加增產投資。


據日經新聞指出，住友金屬礦山追加增產「鎳酸鋰」主要是因應美國EV廠特斯拉（Tesla）增產所需。據報導，住友金屬礦山目前透過Panasonic供應特斯拉電動車所需的大部分車用電池正極材料。


根據嘉實XQ全球贏家系統報價，截至台北時間31日上午8點50分為止，住友金屬礦山上揚1.34%至1,660.5日圓，稍早最高漲至1,664.5日圓創約5個月來（2月16日以來）新高水準。


特斯拉平價電動車「Model 3」於7月28日正式交車。Business Insider、The Motley Fool、Electrek等外電報導，Model 3售價35,000美元，特斯拉原本計畫要在2020年底前，將Model 3年產量提升至50萬台，但去（2016）年該公司把目標提前兩年、移至2018年。不過，Model 3目前的生產年率還只有10萬台，特斯拉想要達標、產速勢必得快速拉升。


富士經濟6月22日公布調查報告指出，預估2030年時EV年銷售量將增至407萬台、超越HV（油電混合車、2030年銷售量預估為391萬台），且之後雙方的差距將持續擴大。富士經濟預估，在中國需求增加加持下，2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍（較2016年增加12.4倍）。


  （本文內容由授權使用。圖片出處：MoneyDJ）


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


【其他文章推薦】


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


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


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


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


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