一開始以為網(wǎng)絡(luò)問題，刷新DNS、更換了WiFi都不行。
以為git出現(xiàn)問題了，又重新卸載安裝了git，故障依舊。
嘗試重新拉一個其他倉庫的代碼，也是一樣的問題。
最后甚至把ipV6也關(guān)掉的了，也不行。
在我打開IDE工具的時候，突然右下方提示我git收到windows defender的限制，可能影響性能。
于是去查看windows自帶的防火墻，不知道什么時候他自己開啟了。
關(guān)閉以后git一切就正常了。
]]>一、架構(gòu)設(shè)計與核心特性
TDSQL-C MySQL
-
架構(gòu)：采用計算與存儲分離的云原生架構(gòu)，支持秒級彈性擴(kuò)縮容（如單集群最多15個只讀實(shí)例），存儲層基于分布式云存儲，單實(shí)例最高支持PB級存儲。
-
性能優(yōu)化：
-
寫入性能：通過Redo日志同步機(jī)制，主從延遲低至毫秒級，寫入性能較傳統(tǒng)MySQL提升約140%69。
-
Serverless支持：按需自動啟停，無流量不計費(fèi)，適合業(yè)務(wù)波動場景。
-
網(wǎng)絡(luò)協(xié)議：使用RDMA技術(shù)（雙25Gbps），降低I/O延遲，提升吞吐量。
PolarDB MySQL
-
架構(gòu)：基于分布式存儲與共享存儲池，支持多主多寫（最多8節(jié)點(diǎn)）、HTAP混合負(fù)載，并集成列存索引（IMCI）加速分析查詢。
-
性能優(yōu)化：
-
查詢性能：列存索引（IMCI）可將復(fù)雜查詢耗時縮短數(shù)倍，彈性并行查詢（ePQ）利用多節(jié)點(diǎn)資源加速處理，適合大數(shù)據(jù)分析場景。
-
高可用性：無感秒切技術(shù)（5-10秒完成主備切換），支持跨地域容災(zāi)（RPO=0）。
-
擴(kuò)展性：在線彈性擴(kuò)縮容，支持Serverless模式下資源動態(tài)匹配。
二、關(guān)鍵性能指標(biāo)對比
| 對比維度 | TDSQL-C MySQL | PolarDB MySQL |
|---|---|---|
| 寫入吞吐量 | 單節(jié)點(diǎn)百萬級QPS，Redo日志同步延遲更低 | 一寫多讀架構(gòu)優(yōu)化，多主多寫支持更高并發(fā) |
| 查詢性能 | 適合OLTP場景，緩存命中率高時讀性能穩(wěn)定 | 列存索引（IMCI）提升復(fù)雜查詢性能400倍，支持HTAP混合負(fù)載 |
| 擴(kuò)展能力 | 秒級添加只讀節(jié)點(diǎn)，計算與存儲獨(dú)立擴(kuò)展 | 支持多節(jié)點(diǎn)并行擴(kuò)展，彈性并行查詢（ePQ）突破單機(jī)瓶頸 |
| 高可用性 | 秒級故障恢復(fù)，快照備份恢復(fù)速度達(dá)GB/秒 | 無感秒切技術(shù)，跨AZ容災(zāi)，事務(wù)不中斷 |
| 成本優(yōu)化 | Serverless按需計費(fèi)，無流量不計費(fèi) | Serverless動態(tài)資源匹配，冷溫?zé)釘?shù)據(jù)分層存儲降低成本 |
三、適用場景推薦
-
TDSQL-C MySQL更優(yōu)的場景：
-
高并發(fā)寫入：如實(shí)時交易系統(tǒng)、游戲日志處理，依賴Redo日志低延遲同步。
-
業(yè)務(wù)波動大：Serverless自動啟停，適合電商促銷、直播峰值等彈性需求。
-
強(qiáng)一致性要求：金融級事務(wù)場景，主從延遲敏感。
-
PolarDB MySQL更優(yōu)的場景：
-
混合負(fù)載（HTAP）：需同時處理事務(wù)與分析查詢，如實(shí)時報表、大數(shù)據(jù)分析。
-
多地域部署：全球數(shù)據(jù)庫網(wǎng)絡(luò)（GDN）支持跨地域數(shù)據(jù)同步，降低訪問延遲。
-
復(fù)雜查詢加速：列存索引（IMCI）和彈性并行查詢（ePQ）顯著提升OLAP性能。
四、總結(jié)建議
-
性能綜合對比：
-
寫入性能：TDSQL-C因Redo日志同步機(jī)制更優(yōu)，適合寫入密集型場景。
-
查詢性能：PolarDB在復(fù)雜查詢和HTAP場景表現(xiàn)更佳，尤其是IMCI和ePQ技術(shù)。
-
擴(kuò)展性與成本：兩者均支持Serverless，但TDSQL-C在秒級彈性伸縮上更突出，PolarDB在存儲分層和全局一致性上更具優(yōu)勢。
-
選擇建議：
-
若業(yè)務(wù)以高并發(fā)寫入、強(qiáng)一致性為主，且需頻繁彈性擴(kuò)縮容，TDSQL-C MySQL更合適。
-
若需兼顧事務(wù)與分析、多地域部署或復(fù)雜查詢優(yōu)化，PolarDB MySQL更具競爭力。
1. 架構(gòu)設(shè)計
-
TDSQL-C MySQL版：
基于云原生架構(gòu)，采用計算與存儲分離的設(shè)計，支持集群模式，一個集群最多包含1個讀寫實(shí)例和15個只讀實(shí)例。計算節(jié)點(diǎn)無狀態(tài)，支持秒級擴(kuò)縮容和故障恢復(fù)，且通過分布式存儲實(shí)現(xiàn)單實(shí)例最高400TB的容量。 -
云數(shù)據(jù)庫MySQL：
采用傳統(tǒng)主從架構(gòu)，分為單節(jié)點(diǎn)、雙節(jié)點(diǎn)（一主一備）、三節(jié)點(diǎn)（一主兩備）及集群版（最多5個只讀節(jié)點(diǎn)），存儲與計算耦合，擴(kuò)展需手動操作且耗時較長。
2. 核心特性對比
| 對比項 | TDSQL-C MySQL版 | 云數(shù)據(jù)庫MySQL |
|---|---|---|
| 引擎 | InnoDB、LibraDB（優(yōu)化寫入性能） | InnoDB、RocksDB（適用于特定存儲場景） |
| 版本兼容性 | 支持MySQL 5.7、8.0 | 支持MySQL 5.6、5.7、8.0 |
| Serverless支持 | 支持，自動彈性伸縮規(guī)格，無使用不計費(fèi) | 不支持 |
| 最大建表數(shù) | 無限制（僅受存儲空間限制） | 單個實(shí)例表數(shù)量不超過100萬 |
| 主從同步機(jī)制 | 基于Redo日志同步，延遲低至毫秒級 | 基于Binlog同步，存在主從延遲問題 |
| 備份與回檔速度 | 支持快照備份，每秒GB級恢復(fù)速度 | 物理備份，恢復(fù)速度較慢 |
3. 性能與擴(kuò)展性
-
寫入性能：TDSQL-C通過優(yōu)化日志機(jī)制（僅寫入Redo日志）提升140%的寫入性能。
-
擴(kuò)展能力：TDSQL-C支持秒級橫向擴(kuò)容（如增加只讀實(shí)例）、縱向彈性調(diào)整規(guī)格，且磁盤擴(kuò)容對業(yè)務(wù)無感知；而云數(shù)據(jù)庫MySQL需提前規(guī)劃資源，擴(kuò)展耗時較長。
-
存儲容量：TDSQL-C單實(shí)例支持PB級存儲，云數(shù)據(jù)庫MySQL受限于單物理機(jī)存儲上限。
4. 適用場景
-
TDSQL-C MySQL版：
-
業(yè)務(wù)波動大，需頻繁擴(kuò)縮容（如游戲、電商促銷場景）；
-
高寫入QPS需求（如實(shí)時交易系統(tǒng)）；
-
對主從延遲敏感（如金融級強(qiáng)一致性場景）；
-
需Serverless能力以降低運(yùn)維成本。
-
云數(shù)據(jù)庫MySQL：
-
傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用（如社交、內(nèi)容平臺）；
-
中小型金融或電商業(yè)務(wù)；
-
對成本敏感且無需高頻彈性擴(kuò)展的場景。
5. 成本與運(yùn)維
-
TDSQL-C：按需計費(fèi)（Serverless模式下無流量不計費(fèi)），自動化運(yùn)維（如自動備份、監(jiān)控）。
-
云數(shù)據(jù)庫MySQL：固定規(guī)格預(yù)付費(fèi)，需手動管理備份及擴(kuò)縮容。
總結(jié)建議
若業(yè)務(wù)需要高彈性、低延遲、海量存儲，或計劃使用Serverless模式，TDSQL-C MySQL版是更優(yōu)選擇；若需求偏向穩(wěn)定性與成本可控，且無需頻繁調(diào)整資源，云數(shù)據(jù)庫MySQL更適合。
]]>而且非常奇葩的是，溝通過程中，他們承認(rèn)不合理，但就是不改，只有去投訴才會給你按剩余多少退多少。
他的退款規(guī)則非常復(fù)雜，一個正常用戶，沒一個人能看懂的。只要你按照自主操作區(qū)退款，就會默認(rèn)按照他的規(guī)則給你退款，那么基本上你用了2/3的時間以后，退款金額就接近0了。
我以為是阿里云一家特例，沒想到騰訊云也一樣，難道出自同一個產(chǎn)品經(jīng)理？
我買了一個月的包年包月服務(wù)器，費(fèi)用是1260
用了20天
退款金額是2.9元
我也提交工單，看看客服怎么解釋的。
我就猜到會給我一個非常復(fù)雜的公式。
看他那個公式，我理解的就是比如我原來包年包月比較便宜，中途退款以后就按照按量計費(fèi)，但是按照按量計費(fèi)使用20天的費(fèi)用也是1180，也不知道為什么剩余2.9元。
2025-04-14 20:50:37 [ERRO] POST http://jms-core:8080/api/v1/terminal/terminal-registrations/ failed, get code: 400, {"error":"service account registration disabled"}
2025-04-14 20:50:42 [ERRO] POST http://jms-core:8080/api/v1/terminal/terminal-registrations/ failed, get code: 400, {"error":"service account registration disabled"}
2025-04-14 20:50:47 [ERRO] POST http://jms-core:8080/api/v1/terminal/terminal-registrations/ failed, get code: 400, {"error":"service account registration disabled"}
無法正常注冊
這個主要是因為在部署好之后，把注冊功能關(guān)閉了。
只要把這個開關(guān)打開就行了。
可以看到已經(jīng)注冊成功了。
這個問題的前提是要保證遷移前后的BOOTSTRAP_TOKEN一致。
]]>
但是通過命令 wsl -d ubuntu直接啟動缺正常。
主要原因就是Terminal Ubuntu這個配置里面的“啟動目錄設(shè)置的”~ Windows無法識別。
直接改成一個存在的目錄就行。
再去啟動就正常了。
于是卸載了wps，官網(wǎng)下載了最新的版本，安裝以后還是一樣的問題。
又換了一個版本安裝，安裝好還是打開就卡死。
開始懷疑是不是緩存文件導(dǎo)致的，于是又卸載WPS，擅長所有的緩存文件重新安裝，結(jié)果依然卡死。
在折騰了兩三個小時以后，無意間在配置和修復(fù)
的高級設(shè)置里面
設(shè)置了硬件加速
于是取消勾選以后，再去打開文件發(fā)現(xiàn)一切正常了。
]]>我們開發(fā)在開發(fā)環(huán)境build發(fā)布到集群以后，報錯docker: not found。
一開始以為是容器里面沒有安裝成功docker，檢查dockerfile沒有發(fā)現(xiàn)異常。
docker build以后本地測試鏡像里面docker命令可以正常運(yùn)行。
由于這個項目的部署沒有采用自動化，而且服務(wù)與服務(wù)之間的部署都是靠多個腳本去觸發(fā)。
一開始懷疑ECS上面運(yùn)行的鏡像不是我們本地推送的鏡像，經(jīng)過一些列的排查，發(fā)現(xiàn)使用的tag是正確的。
由于這個項目build需要很久，push鏡像也需要很久，就自己寫了一個dockerfile build測試，但是發(fā)布以后可以正常找到docker命令。
就在沒有方向的時候，開發(fā)說這個項目之前是部署在amd架構(gòu)的服務(wù)器上面的，最近項目方才改到了arm架構(gòu)上面，會不會是因為這個。
看了使用的build命令
buildx 默認(rèn)使用的 構(gòu)建器（ builder ） 驅(qū)動是 docker driver，它不支持同時構(gòu)建多個 platform 的鏡像。
需要使用 docker buildx create 創(chuàng)建docker-container driver的構(gòu)建器。
docker run --privileged --rm tonistiigi/binfmt --install all
docker buildx create --name mybuilder --driver docker-container --use
docker buildx inspect --bootstrap
]]>以前覺得AWS是最難用的，比較各種邏輯和UI不符合國人的使用習(xí)慣，但是自從使用了微軟的Azure以后，才知道原來可以這么難用。
公司有個外企項目指定要使用Azure，不然我也接觸不了這個平臺。
不知道是我操作沒對還是怎么的，這個平臺，國內(nèi)用戶必須要去azure點(diǎn)cn這個平臺下面注冊，在azure點(diǎn)microsoft點(diǎn)com注冊的是沒辦法用的。
就算是注冊成功以后，也沒辦法綁定銀行卡或者充值使用，反正邏輯很奇怪，不像國內(nèi)的充值就可以使用，AWS綁定信用卡就可以按量扣費(fèi)。
其實(shí)這個也還好，最流氓的是他讓每年續(xù)約，必須有個保底消費(fèi)，也就是最低消費(fèi)5300。
一開始我也不知道有這么流氓的云平臺，公司的續(xù)約到期以后，對方聯(lián)系我們是否繼續(xù)續(xù)約。我看對方發(fā)給我們的財務(wù)信息顯示還有余額8000多。
想著直接續(xù)不就好了，這個還有啥說的。
結(jié)果對方問那我們還是充值5300嗎？直接把我干蒙圈了。
我是使用云平臺第一次聽說充值的沒用完，第二年還清空的。
可能當(dāng)初合同就是這么簽的吧，我的確孤陋寡聞了。
如果說真不是非用這個平臺不可，我個人建議還是不要用。
像我們最近兩年的這個平臺就用了存儲，每個月幾十塊錢，一年才一百多兩百不到，卻要花費(fèi)5300。
整理了一下4個云平臺的自己的使用感受評分，主要針對國內(nèi)用戶使用，僅供參考。
| 平臺 | 產(chǎn)品生態(tài) | 產(chǎn)品功能 | 頁面易用性 | 相同配置費(fèi)用 | 運(yùn)維管理 | 售后服務(wù) |
| 阿里云 | 9 | 9 | 9 | 8 | 9 | 6 |
| 騰訊云 | 9 | 9 | 9 | 7 | 9 | 9 |
| 亞馬孫（AWS） | 8 | 7 | 7 | 10 | 6 | 5（自身產(chǎn)品問題都需要付費(fèi)） |
| 微軟云（Azure） | 7 | 6 | 5 | 10 | 5 | 5 |
至少目前，個人還是比較推薦實(shí)用騰訊云，不管是性價比還是售后都不錯，售后只有騰訊是響應(yīng)最快，處理最及時，最專業(yè)的。阿里云就要看運(yùn)氣，至少我之前接觸幾年80%反饋的問題，最后我都想給差評，騰訊云這邊基本98%的工單，我是給好評的。
]]>雙十一買了幾件小商品，到貨以后發(fā)現(xiàn)有兩件和宣傳頁面不符。
賣家宣傳：
收到貨：
投訴到平臺以后，聯(lián)系我說賠付幾塊錢，然后我問怎么處理，他說會記錄核實(shí)。
結(jié)果過了一周去看商品宣傳頁面依然還是沒有整改，投訴到12315要求下架或者整改改商品的宣傳圖片以后再上架，等了半個月，又是淘寶平臺聯(lián)系的我。
一來電話就是問：
收到你12315的投訴，商家的款退給你了嗎？
我說：退了，
平臺客服說：
那還有其他問題嗎？
我說：我的述求不是退款，退款我走的是7天無理由，投訴訴求寫的清楚。
平臺說：那你是對處理結(jié)果不滿意是嗎？
我說：是的。
然后淘寶平臺就沒有然后了，一個字沒提商品是否存在虛假宣傳，又沒說是否去核實(shí)了，全程就在問我購買商品的退款收到了沒，是否滿意。
然后我去看的的投訴單子，盡然寫著我認(rèn)可平臺本次溝通，協(xié)調(diào)和解成功。
我是萬萬沒想到，淘寶可以在12315這個平臺上面隨意操作。
本來也沒多少錢，我都已經(jīng)退款重新買了其他商品了，但是突然有點(diǎn)點(diǎn)進(jìn)去這個頁面，發(fā)現(xiàn)商家還是依然用原來那個宣傳圖在繼續(xù)賣，而且我去練習(xí)淘寶客服，客服非常非常官方，一直說我們會記錄，我說記錄可以，后續(xù)的處理結(jié)果，麻煩告知我一下，但是對方說我們的處理結(jié)果是不會告知用戶的。我問如果虛假宣傳屬實(shí)，那要怎么處理，平臺客服說，我們會記錄商家的行為，加強(qiáng)我們的管控，反正所有的話術(shù)都是培訓(xùn)話術(shù)。
我還天真以為可能是，個別客服行為。于是又去淘寶平臺，投訴了第二個虛假宣傳的商品。
平臺給的回復(fù)也是一樣的，首先來電話說陪我三分之一的貨款。
我說如果核實(shí)賣家的確存在虛假宣傳，讓他下架或者整改。
如果不存在，那你這個賠償我也不要。
客服也是和之前一樣，說的會記錄，然后怎么怎么...，也是那一套話術(shù)。
于是我又在12315去投訴，也是過了一周多，收到淘寶平臺的電話，來電話這次首先給我說，那個可能是商家發(fā)錯貨了，他們會讓商家加強(qiáng)管理。然后給我的方案是賠付30元。問我是否同意，我說如果是不是發(fā)錯貨，去看下其他買家評價的相片就知道了，如果都是我這個一樣，那就不存在發(fā)錯貨，而且我在和商家溝通的過程中，商家也沒說發(fā)錯貨了。然后扯了半天，最后我不同意他們的處理方案。
我去看12315投訴單，也是關(guān)閉狀態(tài)，也沒有下文了。
所以親身經(jīng)歷，給大家建議，遇到那種虛假宣傳的，退款投訴拿一點(diǎn)賠償就好了。商家和平臺都是穿一條褲子的。12315投訴并沒有想象的那么有用，不要報太大希望。也有可能是我的金額太小了，得不到重視。
之前在京東自營店也買到過一款和宣傳頁面不符合的充電寶，宣傳的20000mAh，結(jié)果到手是10000mAh，和客服溝通最后是退款不退貨，還賠付了一件商品的價格，根本就沒有走到12315投訴那一步。
平時在使用阿里系的產(chǎn)品，售后問題是最大的一個問題。比如阿里云和騰訊云，服務(wù)天差之別。
個人覺得是阿里系的產(chǎn)品，總覺得自己行業(yè)老大，有點(diǎn)對售后不屑一顧的感覺，處理售后問題，都是非常拖拉和敷衍用戶。
]]>