在 ARM64 上面運行 TiDB

相比于 Intel 的 x86-64 架構，ARM 架構雖然作為后來者，但在服務器領域也開始在不停地攻城拔寨，很多企業也開始將自己的服務遷移到 ARM 架構上面，自然，對于 TiDB 來說，大家也想將 TiDB 運行到 ARM 上面。因為 AWS 上面直接提供了 ARM 機型，所以我們決定先嘗試在 AWS 的 ARM 上面編譯運行 TiDB。

目前創新互聯建站已為上1000+的企業提供了網站建設、域名、網站空間、網站托管、服務器托管、企業網站設計、四方臺網站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協力一起成長，共同發展。

TiDB 主要包含三個組件 - PD，TiKV 和 TiDB，對于 PD 和 TiDB 來說，使用的是 Go 進行編譯的，所以我們只需要在 ARM 機器上面裝好 Go 的版本就可以了。這里，我使用的是 go1.12.6.linux-arm64 這個版本。

用 Go 編譯 TiDB 和 PD 比較容易，中途遇到了一個 TiDB 的編譯問題，只需要升級下 vendor 就解決了。

編譯 TiKV 就比較麻煩了，因為我們使用的是 CentOS 系統，系統用 yum 就能安裝相關的依賴，除了 cmake3 ，裝 cmake 需要做如下處理：

當然，編譯 RocksDB 還有 Titan 的時候還遇到了一些錯誤，不過多數就是傳遞編譯參數的時候需要處理下 ARM64 相關的選項，并不是特別的困難。

總的來說，編譯并沒有花太多的時間，這里有一個 腳本 ，大家可以自行去看如何在 ARM64 上面編譯 TiDB。對于運行集群需要的 Grafana 和 Prometheus，官方都提供了 ARM64 版本，大家可以直接去 Google。

編譯好了 ARM64 的版本，自然就是測試了，這里我使用了 go-ycsb 進行了簡單的測試，這里我使用的是 16c32g 的 ARM64 機器，順帶也開了一臺同配置的 x86 作為對比。

在每臺測試機器上面，啟動一個 PD，一個 TiKV，使用的是默認配置，然后 go-ycsb 使用 100 并發，導入 1 百萬數據，操作次數 1 百萬，batch size 為 0。

結果如下：

可以看到，ARM 的機器性能比 x86 的差了很多，需要來優化了。在網上找了這篇 文章 ，使用了上面的腳本，但發現沒有什么變化。在這個腳本里面，主要的優化就是將網卡中斷的處理綁定到某一個 CPU 上面，然后將 RPS 分散到不同的 CPU。對于 16c32g 的機器來說，這個腳本將網卡中斷的處理綁定到 CPU core 0 和 8 上面，然后把 RPS 分散到所有的 CPU 上面，但是我通過 mpstat 發現，core 0 和 8 幾乎被打滿：

于是我重新調了下，將 RPS 分散到除開 core 0 和 8 的地方：

然后 OPS 稍微提升了一點，但 CPU core 0 和 8 仍然是瓶頸。而這個瓶頸明顯是網絡處理造成的，直觀的優化就是減少網絡消息的處理，于是將 batch size 設為 128，可以發現在 ARM 上面性能提升很多，譬如對于 workload C，OPS 能提升到 118270。但即使這樣，CPU core 0 和 8 還是會成為瓶頸。

對比 ARM，x86 下面 CPU 的分配明顯的均勻很多：

所以后面我們要考慮的事情就是如何讓 ARM 能更好的處理網絡消息。

上面簡單的說了一下如何在 ARM 上面編譯運行 TiDB，以及一些調優策略。個人認為，雖然 ARM 在性能上面還趕不上相同配置的 x86，但低功耗，成本這些是一個非常大的優勢，加上很多不可說的原因，個人認為會有越來越多的企業使用 ARM，所以這塊也會是趨勢。

tidb使用坑記錄

1、對硬盤要求很高，沒上SSD硬盤的不建議使用

2、不支持分區，刪除數據是個大坑。

解決方案：set @@session.tidb_batch_delete=1;?

3、插入數據太大也會報錯

解決方案：set @@session.tidb_batch_insert=1;?

4、刪除表數據時不支持別名

delete from 表名 表別名?where?表別名.col = '1' ?會報錯

5、內存使用有問題，GO語言導致不知道回收機制什么時候運作。內存使用過多會導致TIDB當機（這點完全不像MYSQL）

測試情況是，32G內存，在10分鐘后才回收一半。

6、數據寫入的時候，tidb壓力很大, tikv的CPU也占用很高

7、不支持GBK

8、不支持存儲過程

9、列數支持太少，只支持100列，和oralce/mysql的1000列少太多（Oracle 最大列數為 1000；MySQL對于每個表具有4096個列的硬限制, 其中InnoDB每個表的限制為1017列, 最大行大小限制為65,535字節）

TiDB 基礎操作集

1、測試環境推薦配置

2、生產環境推薦配置

3、 如果 tikv 服務器的 CPU及磁盤配置較高，可以考慮多實例部署，按照每個 tikv 實例16~20core + 64G 內存 + 800G 磁盤的比例分配硬件資源。

同時需要注意 inventory.ini 及 ansible/conf/tikv.yml 的相關配置。

4、tidb 服務器視業務類型，如果業務邏輯有偏 AP 類的 SQL，需要考慮配置大內存，防止出現 OOM。

如果是純 TP 類業務，tidb 服務器 CPU 配置較高的話，也可以考慮多實例部署，每個 tidb-server 分配20~32core，可以避免無謂的CPU上下文切換， 減少 system cpu 消耗。

5、pd 服務器的磁盤可以配置200~500G 的SSD 盤，主要用來保存源數據信息。在集群規模較大，源數據信息較多的時候，SSD 磁盤能夠避免源數據信息存取成為集群的瓶頸點。

1、操作系統版本要求

建議 centos 7.3及以上，支持 redhat 7.3版本及以上，不推薦其他版本的系統。

2、ansible、jinja 等軟件依賴包版本，只需要驗證中控機（運行ansible 機器）上軟件版本滿足條件即可

中控機：

監控機（grafana）：

3、測試環境磁盤 IO 不滿足需求

ansible-playbook bootstrap.yml --extra-vars "dev_mode=True"

加上 dev_mode=True 可以在部署時，繞過系統磁盤相關的 benchmark

4、關閉防火墻、開啟時鐘同步

systemctl status firewalld

systemctl status chronyd/ntpd

5、集群下所有服務器要配置不同的 hostname

如果否，可以編輯 inventory.ini 的配置項 set_hostname=True 來自動修改 hostname

6、調整參數

參數在 ansible/conf/目錄下，tidb.yml，tikv.yml，常見的可能需要調整的參數

tidb.yml：

grpc-connection-count: 如果服務器 CPU 配置較高，tikv 實例個數較多，該參數可以調整至20~32之間

slow-threshold：slow-query 記錄的閾值，默認300ms

level：日志級別，默認 info，可以視情況調整為 debug 或 error

tikv.yml：

sync-log：raft-log sync配置，默認值true，對于磁盤 io 消耗較高，測試/非金融生產環境建議設置為 false

region-split-check-diff：檢測 region 分裂的閾值，非 SSD 磁盤建議調大至32MB

rocksdb defaultcf block-cache-size(GB)?= MEM * 80% / TiKV 實例數量 * 30%（多實例部署下配置，單實例部署不需要修改）

rocksdb writecf block-cache-size(GB)?= MEM * 80% / TiKV 實例數量 * 45%（多實例部署下配置，單實例部署不需要修改）

rocksdb lockcf block-cache-size(GB)?= MEM * 80% / TiKV 實例數量 * 2.5% (最小 128 MB)（多實例部署下配置，單實例部署不需要修改）

raftdb defaultcf block-cache-size(GB)?= MEM * 80% / TiKV 實例數量 * 2.5% (最小 128 MB)（多實例部署下配置，單實例部署不需要修改）

多實例情況下，需要修改?

readpool:

coprocessor:

high-concurrency

normal-concurrency

low-concurrency

三個參數，推薦為實例數*參數值 = CPU 核數 * 0.8。

raftstore:

capacity

磁盤總容量 / TiKV 實例數量，例如 “100GB”

修改完后，可以使用下面命令驗證

cat tidb-ansible/conf/tikv.yml |grep -Ev "^$|#"

無誤后執行?

ansible-playbook rolling_update.yml --tags=tidb/tikv

滾動升級，tags 可選

7、官網有比較完善的在線+離線部署方案、在線升級指導、在線擴容縮容文檔，具體參考：

1、從 MySQL 遷移

TiDB 兼容 MySQL 語法，小數據量建議直接使用 mysqldump、mydumper 來全量導出數據，再通過 source、myloader 的方式導入 TiDB。

./bin/mydumper -h?127.0.0.1 -P?3306?-u root -t?16?-F?64?-B test -T t1,t2 --skip-tz-utc -o ./var/test

./bin/loader -h?127.0.0.1 -u root -P?4000?-t?32?-d ./var/test

詳情請參考： 使用-mydumper-loader-全量導入數據

如果數據量較大，超過幾百 G，可以聯系原廠申請試用 lightning 工具，loader 導入數據平均速度是20G/小時，lightning 約為100~150G/小時

2、從 Oracle 遷移

目前有幾種方式可以參考

使用 OGG 做全量+增量同步

使用 Navicat Premium 版的 data transfer 功能，支持從 Oracle/SqlServer 遷移全量數據至 TiDB

通過 kafka 等消息隊列工具，解析 OGG 的日志，開發寫入 TiDB/MySQL 的工具

目前我們也在積極跟專業的數據異構平臺合作，爭取能夠盡快在更多的數據遷移工具中兼容 TiDB 數據源。

1、啟動集群

ansible-playbook start.yml --tags=tidb/tikv/pd

在正確的 ansible 目錄下，確保 inventory.ini 里的配置正確，tags 可選

2、停止集群

ansible-playbook stop.yml --tags=tidb/tikv/pd

在正確的 ansible 目錄下，確保 inventory.ini 里的配置正確，tags 可選

3、停止單個 tidb-server / tikv-server

ansible-playbook stop.yml --tags=tidb/tikv/pd -l IP

-l 后面接 inventory.ini 配置的IP 或別名

4、訪問 tidb

TiDB 兼容 MySQL 協議，所有連接 MySQL 的方式都適用于TiDB

mysql -uroot -h127.0.0.1 -P4000 -p

常見的圖形化界面工具，navicat 等都可以直接訪問 tidb

同時也支持jdbc、odbc 等，需要注意的是 mysql 8.0版本的客戶端，及 mariadb 客戶端可能存在兼容性問題，不建議使用

SQL 語法基本兼容 MySQL，某些不兼容的場景見： 與-mysql-兼容性對比

5、修改參數

可以通過修改 tidb-ansible/conf/tidb.yml 配置文件，然后執行

ansible-playbook rolling_update.yml --tags=tidb/tikv

也可以直接登錄服務器，找到deploy_dir/conf/tidb.toml，直接編輯文件，然后 pkill tidb-server 來重啟服務

6、查看 tidb 版本信息

select tidb_version();

Release Version: v2.1.0-rc.3-24-g23f90a6

Git Commit Hash: 23f90a68be321e724280da6033a2b63ebf6cc7dd

Git Branch: HEAD

UTC Build Time: 2018-10-10 09:18:39

GoVersion: go version go1.11 linux/amd64

Race Enabled: false

TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e

Check Table Before Drop: false

7、備份 tidb 數據

全量備份可以采用 mydumper，增量備份需要開啟 binlog，實時恢復采用商業版工具 reparo。

8、查看監控數據

在 ansible 的配置文件 inventory.ini 里，有一個監控服務器的配置

[monitoring_servers]

10.1.163.87

deploy 的時候會默認在這個配置服務器上部署 grafana 組件，通過

admin/admin? 訪問

具體一些常見的監控指標，請參考：

9、收集統計信息

set @@tidb_build_stats_concurrency=20;

set @@tidb_distsql_scan_concurrency=100;

set @@tidb_index_serial_scan_concurrency=20;

analyze table xxx index xxx;

修改上面三個參數可以提升 scan 效率。

具體統計信息相關，請參考： 統計信息簡介

1、Transaction too large

TiDB 對于事務有限制，簡單來說以下幾點：

單個事務的SQL 語句數量不能超過5000，（ 在 tidb.yml 可配 stmt-count-limit ）

單條 KV entry 不超過 6MB

KV entry 的總條數不超過 30w

KV entry 的總大小不超過 100MB

備注：假設某張表有4個索引，那么一條數據對應的 kv entry 為數據+索引，一共5個kv 記錄。

如果是批量 insert 或delete，建議先修改

set tidb_batch_insert = 1;?

set?tidb_batch_delete = 1;

update mysql.tidb set variable_value='24h' where variable_name='tikv_gc_life_time';

再執行 SQL。

如果是批量 update，建議采用 limit 循環的方式執行。

2、GC life time is shorter than transaction duration

GC Life Time?間隔時間過短，長事務本應讀到的數據可能被清理了，可使用如下命令增加?GC Life Time?：

update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';

3、Lost connection to MySQL server during query

log 中是否有 panic

dmesg 中是否有 oom，命令：?dmesg -T | grep -i oom

長時間沒有訪問，也會收到這個報錯，一般是 tcp 超時導致的，tcp 長時間不用, 會被操作系統 kill。

tidb數據庫和mysql的區別

tidb數據庫和mysql的區別為：開發公司不同、事務更新機制不同、事務方式不同。

一、開發公司不同

1、tidb數據庫：tidb數據庫是北京的創業公司PingCAP的產品。

2、mysql：mysql是由瑞典MySQL AB 公司開發，屬于?Oracle?旗下產品。

二、事務更新機制不同

1、tidb數據庫：tidb數據庫采用樂觀鎖機制來保證事務更新的一致性和持久性。

2、mysql：mysql采用redo log機制來保證事務更新的一致性和持久性。

三、事務方式不同

1、tidb數據庫：tidb數據庫使用的是扁平事務。

2、mysql：mysql使用的是分布式事務。

Go語言的應用

Go語言由Google公司開發，并于2009年開源，相比Java/Python/C等語言，Go尤其擅長并發編程，性能堪比C語言，開發效率肩比Python，被譽為“21世紀的C語言”。

Go語言在云計算、大數據、微服務、高并發領域應用應用非常廣泛。BAT大廠正在把Go作為新項目開發的首選語言。

Go語言應用范圍：

1、服務端開發：以前你使用C或者C++做的那些事情，用Go來做很合適，例如日志處理、文件系統、監控系統等;

2、DevOps：運維生態中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go語言開發;

3、網絡編程：大量優秀的Web框架如Echo、Gin、Iris、beego等，而且Go內置的 net/http包十分的優秀;

4、Paas云平臺領域：Kubernetes和Docker Swarm等;

5、分布式存儲領域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;

6、區塊鏈領域：區塊鏈里面有兩個明星項目以太坊和fabric都使用Go語言;

7、容器虛擬化：大名鼎鼎的Docker就是使用Go語言實現的;

8、爬蟲及大數據：Go語言天生支持并發，所以十分適合編寫分布式爬蟲及大數據處理。

國內重要的 Go 語言項目：TiDB 3.0 GA，穩定性和性能大幅提升

TiDB 是 PingCAP 自主研發的開源分布式關系型數據庫，具備商業級數據庫的數據可靠性，可用性，安全性等特性，支持在線彈性水平擴展，兼容 MySQL 協議及生態，創新性實現 OLTP 及 OLAP 融合。

TiDB 3.0 版本顯著提升了大規模集群的穩定性，集群支持 150+ 存儲節點，300+TB 存儲容量長期穩定運行。易用性方面引入大量降低用戶運維成本的優化，包括引入 Information_Schema 中的多個實用系統視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因實現 View 可以執行，至此 TPC-H 22 個 Query 均可正常運行。新功能方面增加了窗口函數、視圖（實驗特性）、分區表、插件系統、悲觀鎖（實驗特性）。

截止本文發稿時 TiDB 已在 500+ 用戶的生產環境中長期穩定運行，涵蓋金融、保險、制造，互聯網， 游戲 等領域，涉及交易、數據中臺、 歷史 庫等多個業務場景。不同業務場景對關系型數據庫的訴求可用 “百花齊放”來形容，但對關系數據庫最根本的訴求未發生任何變化，如數據可靠性，系統穩定性，可擴展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什么樣的驚喜。

3.0 與 2.1 版本相比，顯著提升了大規模集群的穩定性，支持單集群 150+ 存儲節點，300+TB 存儲容量長期穩定運行，主要的優化點如下：

1. 優化 Raft 副本之間的心跳機制，按照 Region 的活躍程度調整心跳頻率，減小冷數據對集群的負擔。

2. 熱點調度策略支持更多參數配置，采用更高優先級，并提升熱點調度的準確性。

3. 優化 PD 調度流程，提供調度限流機制，提升系統穩定性。

4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統穩定性。

眾所周知，數據庫查詢計劃的穩定性對業務至關重要，TiDB 3.0 版本采用多種優化手段提升查詢計劃的穩定性，如下：

1. 新增 Fast Analyze 功能，提升收集統計信息的速度，降低集群資源的消耗及對業務的影響。

2. 新增 Incremental Analyze 功能，提升收集單調遞增的索引統計信息的速度，降低集群資源的消耗及對業務的影響。

3. 在 CM-Sketch 中新增 TopN 的統計信息，緩解 CM-Sketch 哈希沖突導致估算偏大，提升代價估算的準確性，提升查詢計劃的穩定性。

4. 引入 Skyline Pruning 框架，利用規則防止查詢計劃過度依賴統計信息，緩解因統計信息滯后導致選擇的查詢計劃不是最優的情況，提升查詢計劃的穩定性。

5. 新增 SQL Plan Management 功能，支持在查詢計劃不準確時手動綁定查詢計劃，提升查詢計劃的穩定性。

1. OLTP

3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優化點如下：

1. TiDB 持續優化 SQL 執行器，包括：優化 NOT EXISTS 子查詢轉化為 Anti Semi Join，優化多表 Join 時 Join 順序選擇等。

2. 優化 Index Join 邏輯，擴大 Index Join 算子的適用場景并提升代價估算的準確性。

3. TiKV 批量接收和發送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。

4. TiKV 優化內存管理，減少 Iterator Key Bound Option 的內存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。

5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁盤 IO 的占用。

6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節點內可擴展性，進而提升單節點內并發處理能力和資源利用率，降低延時，大幅提升集群寫入能力。

TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優化點，如下：

1. 提升 SQL 轉化成 KV Pairs 的性能，減少不必要的開銷。

2. 提升單表導入性能，單表支持批量導入。

3. 提升 TiKV-Importer 導入數據性能，支持將數據和索引分別導入。

4. TiKV-Importer 支持上傳 SST 文件限速功能。

RBAC（Role-Based Access Control，基于角色的權限訪問控制） 是商業系統中最常見的權限管理技術之一，通過 RBAC 思想可以構建最簡單“用戶-角色-權限”的訪問權限控制模型。RBAC 中用戶與角色關聯，權限與角色關聯，角色與權限之間一般是多對多的關系，用戶通過成為什么樣的角色獲取該角色所擁有的權限，達到簡化權限管理的目的，通過此版本的迭代 RBAC 功能開發完成。

IP 白名單功能（企業版特性） ：TiDB 提供基于 IP 白名單實現網絡安全訪問控制，用戶可根據實際情況配置相關的訪問策略。

Audit log 功能（企業版特性） ：Audit log 記錄用戶對數據庫所執行的操作，通過記錄 Audit log 用戶可以對數據庫進行故障分析，行為分析，安全審計等，幫助用戶獲取數據執行情況。

加密存儲（企業版特性） ：TiDB 利用 RocksDB 自身加密功能，實現加密存儲的功能，保證所有寫入到磁盤的數據都經過加密，降低數據泄露的風險。

完善權限語句的權限檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句權限檢查。

1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢日志內容，如：Coprocessor 任務數，平均/最長/90% 執行/等待時間，執行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產品易用性。

2. 新增系統配置項合法性檢查，優化系統監控項等，提升產品易用性。

3. 新增對 TableReader、IndexReader 和 IndexLookupReader 算子內存使用情況統計信息，提高 Query 內存使用統計的準確性，提升處理內存消耗較大語句的效率。

4. 制定日志規范，重構日志系統，統一日志格式，方便用戶理解日志內容，有助于通過工具對日志進行定量分析。

5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調優的易用性。

6. 新增 SQL 語句 Trace 功能，方便排查問題。

7. 新增通過 unix_socket 方式連接數據庫。

8. 新增快速恢復被刪除表功能，當誤刪除數據時可通過此功能快速恢復數據。

TiDB 3.0 新增 TiFlash 組件，解決復雜分析及 HTAP 場景。TiFlash 是列式存儲系統，與行存儲系統實時同步，具備低延時，高性能，事務一致性讀等特性。 通過 Raft 協議從 TiKV 中實時同步行存數據并轉化成列存儲格式持久化到一組獨立的節點，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統（TiKV）實時鏡像，實時鏡像可獨立于行存儲系統，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務，提升約 10 倍復雜的混合查詢的性能。

TiFlash 目前處于 Beta 階段，計劃 2019 年 12 月 31 日之前 GA，歡迎大家申請試用。

未來我們會繼續投入到系統穩定性，易用性，性能，彈性擴展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗，極致的用戶體驗。

穩定性方面 V4.0 版本將繼續完善 V3.0 未 GA 的重大特性，例如：悲觀事務模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復解決分布數據庫備份恢復難題；優化 PD 調度功能等。

性能方面 V4.0 版本將繼續優化事務處理流程，減少事務資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。

彈性擴展方面，PD 將提供彈性擴展所需的元信息供外部系統調用，外部系統可根據元信息及負載情況動態伸縮集群規模，達成節省成本的目標。

我們相信戰勝“未知”最好的武器就是社區的力量，基礎軟件需要堅定地走開源路線。截止發稿我們已經完成 41 篇源碼閱讀文章。TiDB 開源社區總計 265 位 Contributor，6 位 Committer，在這里我們對社區貢獻者表示由衷的感謝，希望更多志同道合的人能加入進來，也希望大家在 TiDB 這個開源社區能夠有所收獲。

TiDB 3.0 GA Release Notes：

文章標題：關于tidb使用go語言的信息
標題URL：http://vcdvsql.cn/article22/hshejc.html

成都網站建設公司_創新互聯，為您提供App開發、網站設計公司、電子商務、企業網站制作、做網站、用戶體驗

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯