溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章為大家展示了在Istio中如何實現 Redis 集群的數據分片、讀寫分離和流量鏡像，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
Redis 是一個高性能的 key-value 存儲系統，被廣泛用于微服務架構中。如果我們想要使用 Redis 集群模式提供的高級特性，則需要對客戶端代碼進行改動，這帶來了應用升級和維護的一些困難。利用 Istio 和 Envoy ，我們可以在不修改客戶端代碼的前提下實現客戶端無感知的 Redis Cluster 數據分片，并提供讀寫分離、流量鏡像等高級流量管理功能。
Redis 的一個常見用途是用作數據高速緩存。通過在應用服務器和數據庫服務器之間加入一個 Redis 緩存層，可以減少應用服務器對數據庫的大量讀操作，避免數據庫服務器在大壓力下響應緩慢甚至宕機的風險，顯著加強整個系統的健壯性。Redis 作為數據緩存的原理如圖所示：
在一個小規模的系統中，上圖所示的單個 Redis 就可以很好地實現緩存層的功能。當系統中需要緩存的數據量較大時，一個 Redis 服務器無法承擔所有應用服務器的緩存需求；同時單個 Redis 實例失效時也會導致大量讀請求被直接發送到后端的數據庫服務器上，導致數據庫服務器瞬時壓力超標，影響系統的穩定性。我們可以采用 Redis Cluster 來對緩存數據進行分片，將不同的數據放到不同的 Redis 分片中，以提高 Redis 緩存層的容量能力。在每個 Redis 分片中，還可以采用多個 replica 節點對緩存的讀請求進行負載分擔，并實現 Redis 的高可用。采用了 Redis Cluster 的系統如下圖所示：
從圖中可以看到，在 Redis Cluster 模式下，客戶端需要根據集群的分片規則將不同 key 的讀寫操作發送到集群中不同的 Redis 節點上，因此客戶端需要了解 Redis Cluster 的拓撲結構，這導致我們無法在不修改客戶端的情況下將一個使用 Redis 獨立節點模式的應用平滑遷移到 Redis Cluster 上。另外，由于客戶端需要了解 Redis Cluster 的內部拓撲，也將導致客戶端代碼和 Redis Cluster 運維上的耦合，例如要實現讀寫分離或者流量鏡像的話，就需要修改每個客戶端的代碼并重新部署。
這種場景下，我們可以在應用服務器和 Redis Cluster 之間放置一個 Envoy 代理服務器，由 Envoy 來負責將應用發出的緩存讀寫請求路由到正確的 Redis 節點上。一個微服務系統中存在大量需要訪問緩存服務器的應用進程，為了避免單點故障和性能瓶頸，我們以 Sidecar 的形式為每個應用進程部署一個 Envoy 代理。同時，為了簡化對這些代理的管理工作，我們可以采用 Istio 作為控制面來統一對所有 Envoy 代理進行配置,如下圖所示：
在本文的后續部分，我們將介紹如何通過 Istio 和 Envoy 來管理 Redis Cluster，實現客戶端無感知的數據分區，以及讀寫分離、流量鏡像等高級路由策略。
Pilot 中已經支持了 Redis 協議，但功能較弱，只能為 Redis 代理配置一個缺省路由，而且不支持 Redis Cluster 模式，無法實現 Redis filter 的數據分片、讀寫分離、流量鏡像等高級流量管理功能。為了讓 Istio 可以將 Redis Cluster 相關的配置下發到 Envoy Sidecar 上，我們修改了 EnvoyFilter 配置相關代碼，以支持 EnvoyFilter 的 "REPLCAE" 操作。該修改的 PR Implement REPLACE operation for EnvoyFilter patch 已經提交到 Istio 社區，并合入到了主分支中，將在 Istio 后續的版本中發布。
在撰寫本文的時候，最新的 Istio 發布版本 1.7.3 中尚未合入該 PR。因此我構建了一個 Pilot 鏡像，以啟用 EnvoyFilter 的 "REPLACE" 操作。在安裝 Istio 時，我們需要在 istioctl 命令中指定采用該 Pilot 鏡像，如下面的命令行所示：
$ cd istio-1.7.3/bin $ ./istioctl install --set components.pilot.hub=zhaohuabing --set components.pilot.tag=1.7.3-enable-ef-replace
備注：如果你采用的 Istio 版本新于 1.7.3，并且已經合入了該 PR，則可以直接采用 Istio 版本中缺省的 Pilot 鏡像。
請從 https://github.com/zhaohuabing/istio-redis-culster 下載下面示例中需要用到的相關代碼：
$ git clone https://github.com/zhaohuabing/istio-redis-culster.git $ cd istio-redis-culster
我們創建一個 "redis" namespace 來部署本例中的 Redis Cluster。
$ kubectl create ns redis namespace/redis created
部署 Redis 服務器的 Statefulset 和 Configmap。
$ kubectl apply -f k8s/redis-cluster.yaml -n redis configmap/redis-cluster created statefulset.apps/redis-cluster created service/redis-cluster created
確認 Redis 節點已經啟動并正常運行：
$ kubectl get pod -n redis NAME READY STATUS RESTARTS AGE redis-cluster-0 2/2 Running 0 4m25s redis-cluster-1 2/2 Running 0 3m56s redis-cluster-2 2/2 Running 0 3m28s redis-cluster-3 2/2 Running 0 2m58s redis-cluster-4 2/2 Running 0 2m27s redis-cluster-5 2/2 Running 0 117s
在上面的步驟中，我們采用 Statefulset 部署了6個 Redis 節點，但目前這6個節點還是相互獨立的，并未形成一個集群。下面我們采用 Redis 的 cluster create 命令將這些節點組成一個 Redis Cluster。
$ kubectl exec -it redis-cluster-0 -n redis -- redis-cli --cluster create --cluster-replicas 1 $(kubectl get pods -l app=redis-cluster -o jsonpath='{range.items[*]}{.status.podIP}:6379 ' -n redis)
Defaulting container name to redis.
Use 'kubectl describe pod/redis-cluster-0 -n redis' to see all of the containers in this pod.
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 172.16.0.72:6379 to 172.16.0.138:6379
Adding replica 172.16.0.201:6379 to 172.16.1.52:6379
Adding replica 172.16.0.139:6379 to 172.16.1.53:6379
M: 8fdc7aa28a6217b049a2265b87bff9723f202af0 172.16.0.138:6379
slots:[0-5460] (5461 slots) master
M: 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c 172.16.1.52:6379
slots:[5461-10922] (5462 slots) master
M: 0b86a0fbe76cdd4b48434b616b759936ca99d71c 172.16.1.53:6379
slots:[10923-16383] (5461 slots) master
S: 94b139d247e9274b553c82fbbc6897bfd6d7f693 172.16.0.139:6379
replicates 0b86a0fbe76cdd4b48434b616b759936ca99d71c
S: e293d25881c3cf6db86034cd9c26a1af29bc585a 172.16.0.72:6379
replicates 8fdc7aa28a6217b049a2265b87bff9723f202af0
S: ab897de0eca1376558e006c5b0a49f5004252eb6 172.16.0.201:6379
replicates 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 172.16.0.138:6379)
M: 8fdc7aa28a6217b049a2265b87bff9723f202af0 172.16.0.138:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c 172.16.1.52:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 94b139d247e9274b553c82fbbc6897bfd6d7f693 172.16.0.139:6379
slots: (0 slots) slave
replicates 0b86a0fbe76cdd4b48434b616b759936ca99d71c
M: 0b86a0fbe76cdd4b48434b616b759936ca99d71c 172.16.1.53:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: ab897de0eca1376558e006c5b0a49f5004252eb6 172.16.0.201:6379
slots: (0 slots) slave
replicates 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c
S: e293d25881c3cf6db86034cd9c26a1af29bc585a 172.16.0.72:6379
slots: (0 slots) slave
replicates 8fdc7aa28a6217b049a2265b87bff9723f202af0
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.我們可以采用 cluster info 命令查看 Redis Cluster 的配置信息和 Cluster 中的成員節點，以驗證集群是否創建成功。
$ kubectl exec -it redis-cluster-0 -c redis -n redis -- redis-cli cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:6 cluster_my_epoch:1 cluster_stats_messages_ping_sent:206 cluster_stats_messages_pong_sent:210 cluster_stats_messages_sent:416 cluster_stats_messages_ping_received:205 cluster_stats_messages_pong_received:206 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:416
我們部署一個客戶端，以用于發送測試命令:
$ kubectl apply -f k8s/redis-client.yaml -n redis deployment.apps/redis-client created
在下面的步驟中，我們將通過 Istio 向 Envoy Sidecar 下發 Redis Cluster 相關配置，以在無需改動客戶端的情況下啟用 Redis Cluster 的高級功能，包括數據分片、讀寫分離和流量鏡像。
Envoy 提供了 "envoy.clusters.redis" 類型的 Envoy Cluster 來連接后端的 Redis Cluster，Envoy 會通過該 Cluster 獲取后端 Redis Cluster 的拓撲結構，包括有多少個分片（shard），每個分片負責哪些 slot，以及分片中包含哪些節點，以將來自客戶端的請求分發到正確的 Redis 節點上。
采用 EnvoyFilter 來創建所需的 Envoy Redis Cluster：
$ kubectl apply -f istio/envoyfilter-custom-redis-cluster.yaml envoyfilter.networking.istio.io/custom-redis-cluster created
Istio 缺省下發的 LDS 中配置的是 TCP proxy filter，我們需要將其替換為 Redis Proxy filter。
由于 1.7.3 中尚不支持 EnvoyFilter 的 "REPLACE" 操作，我們首先需要更新 EnvoyFilter 的 CRD 定義，然后才能創建該 EnvoyFilter：
$ kubectl apply -f istio/envoyfilter-crd.yaml customresourcedefinition.apiextensions.k8s.io/envoyfilters.networking.istio.io configured
采用 EnvoyFilter 來將 TCP proxy filter 替換為 Redis Proxy filter，以使 Envoy 可以代理來自客戶端的 Redis 操作請求：
$ sed -i .bak "s/\${REDIS_VIP}/`kubectl get svc redis-cluster -n redis -o=jsonpath='{.spec.clusterIP}'`/" istio/envoyfilter-redis-proxy.yaml
$ kubectl apply -f istio/envoyfilter-redis-proxy.yaml
envoyfilter.networking.istio.io/add-redis-proxy created現在一切就緒，下面我們來驗證 Redis Cluster 的各項功能。
我們通過 Istio 將 EnvoyFilter 中定義的配置下發到 Envoy 后，Envoy 就能夠自動發現后端 Redis Cluster 的拓撲結構，并根據客戶端請求中的 key 將請求自動分發到 Redis Cluster 中正確的節點上。
根據前面創建 Redis Cluster 步驟中的命令行輸出，我們可以看出該 Redis Cluster 的拓撲結構：Cluster 中有三個分片，每個分片中有一個 Master 節點，一個 Slave(Replica) 節點。客戶端通過和其部署在同一個 Pod 中的 Envoy Proxy 訪問 Redis Cluster，如下圖所示：
Redis Cluster 中各個分片的 Master 和 Slave 節點地址：
Shard[0] Master[0] redis-cluster-0 172.16.0.138:6379 replica redis-cluster-4 172.16.0.72:6379 -> Slots 0 - 5460 Shard[1] Master[1] redis-cluster-1 172.16.1.52:6379 replica redis-cluster-5 172.16.0.201:6379 -> Slots 5461 - 10922 Shard[2] Master[2] redis-cluster-2 172.16.1.53:6379 replica redis-cluster-3 172.16.0.139:6379 -> Slots 10923 - 16383
備注：如果你在自己的 K8s cluster 中部署該示例，那么 Redis Cluster 中各個節點的 IP 地址和拓撲結構可能稍有不同，但基本結構應該是類似的。
我們嘗試從客戶端向 Rdeis Cluster 發送一些不同 key 的 set 請求:
$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> set a a
OK
redis-cluster:6379> set b b
OK
redis-cluster:6379> set c c
OK
redis-cluster:6379> set d d
OK
redis-cluster:6379> set e e
OK
redis-cluster:6379> set f f
OK
redis-cluster:6379> set g g
OK
redis-cluster:6379> set h h
OK從客戶端來看，所有的請求都成功了，我們可以使用 scan 命令在服務器端查看各個節點中的數據：
查看分片 Shard[0] 中的數據，master 節點是 redis-cluster-0 slave 節點是 redis-cluster-4。
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli --scan b f $ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli --scan f b
查看分片 Shard[1] 中的數據，master 節點是 redis-cluster-1 slave 節點是 redis-cluster-5。
$ kubectl exec redis-cluster-1 -c redis -n redis -- redis-cli --scan c g $ kubectl exec redis-cluster-5 -c redis -n redis -- redis-cli --scan g c
查看分片 Shard[2] 中的數據，master 節點是 redis-cluster-2 slave 節點是 redis-cluster-3。
$ kubectl exec redis-cluster-2 -c redis -n redis -- redis-cli --scan a e d h $ kubectl exec redis-cluster-3 -c redis -n redis -- redis-cli --scan h e d a
從上面的驗證結果中可以看到，客戶端設置的數據被分發到了 Redis Cluster 中的三個分片中。該數據分發過程是由 Envoy Redis Proxy 自動實現的，客戶端并不感知后端的 Redis Cluster，對客戶端而言，和該 Redis Cluster 的交互與和一個單一 Redis 節點的交互是相同的。
采用該方法，我們可以在應用業務規模逐漸擴張，單一 Redis 節點壓力過大時，將系統中的 Redis 從單節點無縫遷移到集群模式。在集群模式下，不同 key 的數據被緩存在不同的數據分片中，我們可以增加分片中 Replica 節點的數量來對一個分片進行擴容，也可以增加分片個數來對整個集群進行擴展，以應對由于業務不斷擴展而增加的數據壓力。由于 Envoy 可以感知 Redis Cluster 集群拓撲，數據的分發由 Envoy 完成，整個遷移和擴容過程無需客戶端，不會影響到線上業務的正常運行。
在一個 Redis 分片中，通常有一個 Master 節點，一到多個 Slave（Replica）節點，Master 節點負責寫操作，并將數據變化同步到 Slave 節點。當來自應用的讀操作壓力較大時，我們可以在分片中增加更多的 Replica，以對讀操作進行負載分擔。Envoy Redis Rroxy 支持設置不同的讀策略：
MASTER： 只從 Master 節點讀取數據，當客戶端要求數據強一致性時需要采用該模式。該模式對 Master 壓力較大，在同一個分片內無法采用多個節點對讀操作進行負載分擔。
PREFER_MASTER： 優先從 Master 節點讀取數據，當 Master 節點不可用時，從 Replica 節點讀取。
REPLICA： 只從 Replica 節點讀取數據，由于 Master 到 Replica 的數據復制過程是異步執行的，采用該方式有可能讀取到過期的數據，因此適用于客戶端對數據一致性要求不高的場景。該模式下可以采用多個 Replica 節點來分擔來自客戶端的讀負載。
PREFER_REPLICA： 優先從 Replica 節點讀取數據，當 Replica 節點不可用時，從 Master 節點讀取。
ANY： 從任意節點讀取數據。
在前面下發的 EnvoyFilter 中，我們將 Envoy Redis Proxy 的讀策略設置為了 "REPLICA"， 因此客戶端的讀操作應該只會被發送到 Replica 節點。讓我們使用下面的命令來驗證讀寫分離的策略:
通過客戶端發起一系列 key 為 "b" 的 get 和 set 操作：
$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> set b bb
OK
redis-cluster:6379> get b
"bb"
redis-cluster:6379>在前面的 Redis Cluster 拓撲中，我們已經得知 key "b" 屬于 Shard[0] 這個分片。我們可以通過命令 redis-cli monitor 查看該分片中 Master 和 Replica 節點中收到的命令。
Master 節點：
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitor
Slave 節點:
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitor
從下圖中可以看到，所有 get 請求都被 Envoy 發送到了 Replica 節點上。
Envoy Redis Proxy 支持流量鏡像，即將客戶端發送的請求同時發送到一個鏡像 Redis 服務器/集群上。流量鏡像是一個非常有用的功能，我們可以使用流量鏡像將生產環境中的線上數據導入到測試環境中，以使用線上數據對應用進行盡可能真實的模擬測試，同時又不會影響到線上用戶的正常使用。
我們創建一個單節點的 Redis 節點，用做鏡像服務器：
$ kubectl apply -f k8s/redis-mirror.yaml -n redis deployment.apps/redis-mirror created service/redis-mirror created
采用 EnvoFilter 來啟用鏡像策略：
$ sed -i .bak "s/\${REDIS_VIP}/`kubectl get svc redis-cluster -n redis -o=jsonpath='{.spec.clusterIP}'`/" istio/envoyfilter-redis-proxy-with-mirror.yaml
$ kubectl apply -f istio/envoyfilter-redis-proxy-with-mirror.yaml
envoyfilter.networking.istio.io/add-redis-proxy configured通過客戶端發起一系列 key 為 "b" 的 get 和 set 操作：
$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> set b bb
OK
redis-cluster:6379> get b
"bb"
redis-cluster:6379> set b bbb
OK
redis-cluster:6379> get b
"bbb"
redis-cluster:6379> get b
"bbb"可以通過命令 redis-cli monitor 分別查看 Master、Replica 和鏡像節點中收到的命令。
Master 節點:
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitor
Slave 節點:
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitor
鏡像 節點:
$ kubectl exec -it `kubectl get pod -l app=redis-mirror -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-mirror -n redis -- redis-cli monitor從下圖中可以看到，所有 set 請求都被 Envoy 發送到了一份鏡像節點上。
在上面的步驟中，我們在 Istio 中創建了兩個 EnvoyFilter 配置對象。這兩個 EnvoyFilter 修改了 Envoy 代理的配置，主要包括兩部分內容：Redis Proxy Network Filter 配置和 Redis Cluster 配置。
下面的 EnvoyFilter 替換了 Pilot 為 Redis Service 創建的 Listener 中的 TCP Proxy Network Filter，將其替換為一個 "type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy" 類型的 Network Filter。 該 Redis Proxy 的缺省路由指向 "custom-redis-cluster"，并且配置了讀寫分離策略和流量鏡像策略。
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: add-redis-proxy
namespace: istio-system
spec:
configPatches:
- applyTo: NETWORK_FILTER
match:
listener:
name: ${REDIS_VIP}_6379 # Replace REDIS_VIP with the cluster IP of "redis-cluster service
filterChain:
filter:
name: "envoy.filters.network.tcp_proxy"
patch:
operation: REPLACE
value:
name: envoy.redis_proxy
typed_config:
"@type": type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy
stat_prefix: redis_stats
prefix_routes:
catch_all_route:
request_mirror_policy: # Send requests to the mirror cluster
- cluster: outbound|6379||redis-mirror.redis.svc.cluster.local
exclude_read_commands: True # Mirror write commands only:
cluster: custom-redis-cluster
settings:
op_timeout: 5s
enable_redirection: true
enable_command_stats: true
read_policy: REPLICA # Send read requests to replica下面的 EnvoyFilter 在 Pilot 下發的 CDS 中創建了一個 "envoy.clusters.redis" 類型的 Cluster： "custom-redis-cluster"，該 Cluster 會采用 CLUSTER SLOTS 命令 向 Redis 集群中的一個隨機節點查詢集群的拓撲結構，并在本地保存該拓撲結構，以將來自客戶端的請求分發到集群中正確的 Redis 節點上。
apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: custom-redis-cluster namespace: istio-system spec: configPatches: - applyTo: CLUSTER patch: operation: INSERT_FIRST value: name: "custom-redis-cluster" connect_timeout: 0.5s lb_policy: CLUSTER_PROVIDED load_assignment: cluster_name: custom-redis-cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: redis-cluster-0.redis-cluster.redis.svc.cluster.local port_value: 6379 - endpoint: address: socket_address: address: redis-cluster-1.redis-cluster.redis.svc.cluster.local port_value: 6379 - endpoint: address: socket_address: address: redis-cluster-2.redis-cluster.redis.svc.cluster.local port_value: 6379 - endpoint: address: socket_address: address: redis-cluster-3.redis-cluster.redis.svc.cluster.local port_value: 6379 - endpoint: address: socket_address: address: redis-cluster-4.redis-cluster.redis.svc.cluster.local port_value: 6379 - endpoint: address: socket_address: address: redis-cluster-5.redis-cluster.redis.svc.cluster.local port_value: 6379 cluster_type: name: envoy.clusters.redis typed_config: "@type": type.googleapis.com/google.protobuf.Struct value: cluster_refresh_rate: 5s cluster_refresh_timeout: 3s redirect_refresh_interval: 5s redirect_refresh_threshold: 5
這里介紹了如何使用 Envoy 為微服務應用提供客戶端無感知的 Redis 數據分片，以及如何通過 Istio 來統一管理系統中多個 Envoy 代理的 Redis Cluster 配置。我們可以看到，采用 Istio 和 Envoy 可以大大簡化客戶端使用 Redis Cluster 的編碼和配置工作，并且可以在線修改 Redis Cluster 的運維策略，實現讀寫分離、流量鏡像等高級流量管理。當然，引入 Istio 和 Envoy 并未減少整個系統的復雜度，而是將 Redis Cluster 維護的工作從各個分散的應用代碼中集中到了服務網格基礎設施層。對應廣大應用開放者來說，其業務價值主要來自于應用代碼，將大量精力投入此類基礎設施是不太劃算的。
上述內容就是在Istio中如何實現 Redis 集群的數據分片、讀寫分離和流量鏡像，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
