Azure 上的 PostgreSQL 如何撐起 ChatGPT 8 億用戶?微軟工程師親揭幕後秘辛

今天要來聊一個超有料的主題——ChatGPT 背後的資料庫架構,以及微軟工程團隊如何幫 OpenAI 撐過爆炸性的用戶成長。 這篇文章源自微軟官方部落格,由 Azure PostgreSQL 工程副總裁 Affan Dar 領銜撰寫。乾貨滿滿,讓我來幫你翻譯成人話。

先說背景:ChatGPT 有多誇張?

OpenAI 過去一年把資料庫規模擴大了 10 倍,要支撐的是高達 8 億月活躍用戶。這個量級是什麼概念?整個系統底層用的是 Azure Database for PostgreSQL,也就是微軟雲端上的 PostgreSQL 託管服務。 PostgreSQL 這個開源資料庫,平常我們可能覺得它就是個「普通關聯式資料庫」,但這次的故事告訴我們:只要配置得當,它真的可以撐到超大規模。

問題一:讀取副本老是跟不上主節點

什麼是讀取副本(Read Replica)?

簡單說,就是把資料庫「複製一份」給其他伺服器來分擔讀取流量,這樣主節點就不用一個人扛所有查詢。ChatGPT 的架構裡,一台主節點撐著超過 50 個分布在多個地區的副本,這數字已經很嚇人了。

發生了什麼問題?

在 OpenAI 某次大型服務上線前,工程師發現一個詭異現象:副本的資料會「越落越遠」,跟不上主節點的更新速度(這叫做 Replication Lag,複製延遲),而且它不會自己恢復,只能靠重啟副本才能解決,然後一天內又再次發生——陷入一個惡性循環。

問題的根源是什麼?

深挖之後,找到了罪魁禍首:TCP 壅塞控制演算法。 預設的 CUBIC 演算法在偵測到封包遺失(跨地區傳輸本來就難免)時,會把傳輸速度猛踩煞車,拼命退讓,導致複製速度大幅下降。

怎麼解決?

微軟團隊做了三件事:

  • 把壅塞控制演算法從 CUBIC 換成 BBR(對封包遺失更不敏感)
  • 調整 TCP 視窗大小設定
  • 引入**公平佇列(Fair Queuing)**網路排程,讓封包傳送更平滑 這三招組合拳下去,問題就解決了。

問題二:讀副本超過 50 個後怎麼辦?

微軟加入了**串聯副本(Cascading Replica)**支援,讓副本可以再複製給下一層副本,不用所有副本都直接連主節點。這樣就能在不影響主節點的情況下,繼續橫向擴展讀取能力。 此外,他們還開發了一個新技巧:從同地區的另一個副本快照建立新的異地副本,避免過去需要跨地區大量複製資料(可能要花幾小時甚至幾天)的痛苦。

問題三:寫入量太大,單台主節點 IOPS 不夠了

讀取問題解決了,但寫入量的成長讓單台 PostgreSQL 主節點的 I/O 效能上限捉襟見肘。這也是為什麼 OpenAI 後來把部分適合拆分的新工作負載移到 Azure Cosmos DB(NoSQL)去了。 但問題是,有些資料就是很難拆分(sharding 困難),這時候怎麼辦? 這就帶出了微軟的新架構:Azure HorizonDB,在 2025 年 11 月進入私人預覽。

Azure HorizonDB:為超大規模打造的 Postgres

這是目前最令人興奮的部分。HorizonDB 從根本上重新設計了 PostgreSQL 的儲存層,核心概念叫做「以 WAL 為中心的儲存模型」。

WAL 是什麼?

WAL(Write-Ahead Log,預寫日誌)是資料庫記錄「我要做什麼改變」的日誌,用來確保資料不會因為系統崩潰而遺失。PostgreSQL 傳統上是先寫 WAL、再把資料頁寫到磁碟。

HorizonDB 的創新在哪?

PostgreSQL 的計算節點不再直接寫資料頁到磁碟,所有持久化都透過 WAL 完成,資料頁由獨立的儲存層負責重建。 儲存層分成兩個獨立服務:

服務 優化目標
WAL Server 超低延遲的順序寫入
Page Server 超大規模的隨機讀寫
WAL Server 可以在一次網路跳轉內就把一筆交易持久化到 3 個可用區域(傳統架構需要 4 次跳轉),大幅降低提交延遲。
Page Server 則把資料分散在大量 NVMe 高速磁碟上,讓單個 PostgreSQL 實例可以達到數十萬 IOPS 的讀取能力。

計算節點變成無狀態引擎

最妙的是,這個架構讓 PostgreSQL 的計算節點從此「輕裝上陣」——備份、複製、Checkpoint 等繁重工作全部交給儲存層,計算節點只需要專心處理業務邏輯,CPU、磁碟、網路資源都省下來了。 讀取副本也不再需要各自保存一份完整的資料拷貝,瞬間就能建立新副本,且每多一個副本完全不影響主節點效能。

總結:從這件事可以學到什麼?

這篇文章最有價值的地方,不只是技術細節,而是工程師解決問題的思路: 先找根本原因,而不是用重啟來掩蓋問題(TCP 壅塞控制的案例)。一步一步拆解問題,先解讀取延遲、再解讀取擴展、最後解寫入擴展。為未來設計,HorizonDB 的架構不是為了應付今天的問題,而是為了更大的明天。 PostgreSQL 在 8 億用戶的規模下能正常運行,背後是無數工程師的調校與創新。下次有人說「PostgreSQL 不能水平擴展」,你可以把這篇故事講給他聽。

原文來源:Microsoft Community Hub — Supporting ChatGPT on PostgreSQL in Azure(2026/1/29)

Antoropic claude 5x 跟 20x 方案差別?到底那個划算?有工程師算出來了!!

原文: https://she-llac.com/claude-limits故事是這樣開始的……

話說有個工程師,平常就是那種會把什麼都拆開來看的人。他在用 Claude 的時候心裡一直有個疑問:

「Anthropic 說 Max 20× 方案有 20 倍用量,但……20 倍是哪個 20 倍啊?」

於是他開始挖。沒想到,他在 API 的回應資料裡發現了一個「忘記四捨五入」的小數:

0.16327272727272726

一般人看到這個數字:「哦,好像是 16% 左右。」

這位工程師看到這個數字:「等等,這個數字精確得有點可疑……」

然後他就把 Claude 的整個內部計費系統給挖出來了。就這樣。


先說結論:誰才是真正划算的方案?

作者把幾個方案的「實際用量」給算清楚了,結果讓人頗為傻眼:

每 5 小時的用量上限

方案 官方說幾倍 實際幾倍
Pro 基準 基準
Max 5× 5 倍 實際 6 倍!
Max 20× 20 倍 20 倍(這次沒騙人)

每週的用量上限

方案 官方說幾倍 實際幾倍
Pro 基準 基準
Max 5× 5 倍 實際 8.33 倍!
Max 20× 20 倍 實際只有 16.67 倍…

看到了嗎?Max 5× 根本是在送福利,每週用量比官方宣稱的多了超過六成!

反觀 Max 20× 就比較尷尬了——每 5 小時確實給你 20 倍,但每週的總量上限,說好的 20 倍,實際只有 16.67 倍。更糟的是,Max 20× 每週能做的事,也只有 Max 5× 的兩倍,但價格卻是兩倍。所以 CP 值根本沒有更好。

結論:Max 5× 才是甜蜜點,Max 20× 的星號(*)是有原因的。


跟直接用 API 比呢?

好,那如果你是開發者,直接用 Anthropic 的 API 付錢,跟買訂閱方案比起來差多少?

方案 你付多少 等於 API 費用多少 賺了幾倍
Pro $20/月 $163/月 賺 8 倍
Max 5× $100/月 $1,354/月 賺 13.5 倍
Max 20× $200/月 $2,708/月 賺 13.5 倍

也就是說,你花 100 塊買 Max 5×,等於在 API 上用了 1,354 塊的量。

這還只是「保守估計」。因為有個東西叫做快取(Cache)

  • 你和 Claude 聊天時,之前說過的話會被暫存起來(快取)。

  • 下次 Claude 回答時,可以直接讀取快取,不用重新處理。

  • 用 API 的話:讀快取也要付費(收正常費用的 10%)。

  • 用訂閱方案的話:讀快取完全免費!

如果你在用 Claude Code(讓 Claude 自動幫你寫程式、改程式),每次它呼叫工具、做操作,都會重複讀取大量快取。這種情況下,訂閱方案的實際效益可以高達 API 費用的 36.7 倍

三十六點七倍。你沒看錯。


他到底是怎麼挖出這些數字的?

這才是文章最有趣的部分,來聽工程師辦案過程:

第一步:發現可疑現場

作者做了個 Chrome 擴充套件,方便自己查看 Claude 的使用量。在研究過程中,他發現 Claude 在生成回應時,會在背景偷偷傳一個數字給瀏覽器,代表「你已經用掉的比例」,長這樣:

 0.16327272727272726

一個正常工程師會把這個數字四捨五入,顯示成「16%」就好了。但 Anthropic 的工程師忘了這樣做,把原始數字直接送出來了。

而這個原始數字,其實是:你用掉的量 ÷ 總上限

第二步:用數學魔法還原分數

這個小數點背後,藏的是一個分數。比如 0.5 背後是 1/20.333... 背後是 1/3

0.16327272727272726 背後是什麼?

作者用了一個叫做 Stern-Brocot 樹 的數學演算法。這個方法就像在玩「猜數字」遊戲,但它特別聰明——它會優先猜「簡單」的分數,因為電腦系統內部用的數字通常都是整數,分母不會是天文數字。

這個演算法跑了幾十步之後,找到了答案:

449 / 2750

驗算:449 ÷ 2750 = 0.16327272727272726 ✓ 完美吻合!

第三步:收集更多證據,確認總上限

分母 2750 是什麼意思?就是那個時間點的「總上限比例分母」,但因為分數會被化簡,不一定是真正的上限。

所以作者在不同的使用量下,重複採樣了很多次,對所有還原出的分母取最小公倍數(LCM)

當這個最小公倍數不再增加的時候,答案就出現了:3,300,000

這就是 Max 5× 方案每 5 小時的真實 Credits 上限。

第四步:搞清楚「Credits 是什麼」

知道了上限之後,還要知道「每次對話到底會消耗多少 Credits」。這部分作者就靠老派方法了:大量手動測試、記錄數據、列表格、盯著看、問 Claude、問 GPT、提假設、驗證假設……

最後他得出了這個公式:

 消耗的 Credits = 無條件進位(輸入 Token × 輸入費率 + 輸出 Token × 輸出費率)

費率的部分,跟 API 定價的比例完全一致:Opus 最貴、Haiku 最便宜,輸出 Token 是輸入的 5 倍。


這件事告訴我們什麼?

對使用者的啟示:

  • 能買訂閱方案就買,CP 值遠勝 API。

  • Max 5× 是最划算的選擇,Max 20× 沒有成比例地更好。

  • 如果你在跑 AI 代理程式(像 Claude Code),省下的快取費用更是驚人。

對工程師的啟示:

  • 側通道洩漏(Side Channel Leak)真的無所不在。Anthropic 只是忘了把兩個數字四捨五入,結果被人把整個計費架構給挖出來了。

  • 這不是駭客攻擊,不需要入侵任何系統,只需要一點數學和一點好奇心。


最後

作者在文章結尾說了一句話,頗有意思:

「截至撰文時,那兩個浮點數還沒有被四捨五入。我猜如果這篇文章引起足夠的關注,這種情況可能不會持續太久。到時候我會有點難過,因為這樣我的擴充套件就沒辦法那麼精準了。」

翻譯成白話就是:「我剛剛把 Anthropic 的底細公開在網路上,我猜他們很快就會把漏洞補起來,然後我的工具就沒這麼好用了。但這篇文章我還是要發。」

工程師的浪漫,大概就是這樣吧。

解決 Vite 專案中 ngrok 連線失敗的「安全門檻」

最近有團隊成員在進行外部對接調試時,反應使用 ngrok 進行內網穿透時,遇到了連線被阻擋的問題。這其實不是 ngrok 的服務異常,而是 Vite 在升級到新版本後,為了防禦 DNS Rebinding(DNS 再綁定攻擊) 所加強的安全檢查機制。

🛠️ 解決方案

如果你的 ngrok 網址顯示攔截,請直接檢查你的 vite.config.ts。你必須顯式地將 ngrok 提供的 domain 加入「允許名單」中:

TypeScript

// vite.config.ts
export default defineConfig({
  server: {
    allowedHosts: [
      'a134-211-72-118-118.ngrok-free.app' // 替換為你當前的 ngrok 網址
    ]
  }
})

 為什麼我們要關注這個設定?

公司治理資安維護的角度來看,這項調整背後有兩個關鍵思考:

  1. 防止 Host Header 攻擊:Vite 預設不再信任隨機的 Host 請求。這能有效避免惡意網站利用瀏覽器漏洞,在使用者不知情的狀況下,與本地開發環境通訊並竊取原始碼或環境變數。

  2. 開發環境的最小權限原則:雖然 ngrok 方便,但隨意開放外部存取內網環境是有風險的。透過 allowedHosts 的明確宣告,我們能確保開發者清楚知道哪些外部網域正在與本地服務互動。

📢技術小提醒

在測試結束後,記得將該設定移除或將其移至 .env 進行管理,切勿將特定 ngrok 網址永久硬編碼在 code 中並推上主分支,保持乾淨且安全的 Repo 是每一位資深工程師的素養。

祝大家今天開發順利,Bug 自由!

#Vite #ngrok #FrontendDevelopment #資安意識 #DNSRebinding #軟體研發管理 #WebSecurity #TypeScript

AI coding工具cursor 推出cursor cli – Cursor Agent

今天收到cursor發來的信,推出cursor cli。安裝方法 curl https://cursor.com/install -fsS | bash

安裝後輸入 cursor-agent 執行

官方網址: https://cursor.com/cn/cli

不過目前看來是在wsl環境下,但可以讓cursor agent 跑在像jetbrians這類ide也是不錯。可以讓cursor的威力發揮在更多地方了

搭配 Claudia 的 Claude Code:輕鬆進階的 AI 助手工作流程

https://claudiacode.com/

結合終端機中的 Claude Code 與可視化桌面應用 Claudia,可同時享有強大 AI 編程能力與友善 GUI 體驗,大幅提升開發效率與可視化管理。

一、什麼是 Claude Code 與 Claudia

Claude Code

  • 由 Anthropic 開發的「Agentic 編程工具」,直接嵌入您熟悉的終端機,能透過自然語言指令理解並操作整個程式碼庫,執行測試、修復錯誤、搜尋 git 歷史等任務。

Claudia

  • 開源桌面應用(基於 Tauri),為 Claude Code 增添直觀的圖形化介面,整合專案管理、即時使用量儀表板、MCP 伺服器管理與沙盒環境,免去頻繁輸入 CLI 指令的困擾。

二、為何搭配使用?

優勢面向 Claude Code (CLI) Claudia (GUI)
學習曲線 低,熟悉 CLI 後快速上手 更低,點擊式操作不需記憶指令
上下文理解 直接載入整個專案結構,依賴 CLAUDE.md 最佳化 同樣支援 CLAUDE.md,並可視化呈現關鍵內容
任務自動化 鏈結多步驟指令,適合 CI/CD 自動化 一鍵執行常用流程,並提供「檢查點」還原功能
專案管理 需手動切換分支、查詢日誌 Projects 面板一覽所有 Session,點擊即可回顧
使用量與成本追蹤 無內建可視化 即時顯示 API 使用量、Token 成本與統計分析
安全沙盒 需手動設定權限 內建 seccomp/Seatbelt 沙盒,細粒度權限控管

三、安裝指南

  1. 安裝 Node.js (v18+),並確認 npm 可用

  2. 安裝 Claude Code

    bash
    npm install -g @anthropic-ai/claude-code

    驗證:執行 claude --version 應顯示版本號。

  3. 下載並安裝 Claudia

    • 方式一:從 GitHub Releases 取得最新的 macOS/Windows/Linux 執行檔

    • 方式二(進階用法):

      bash
      git clone https://github.com/getAsterisk/claudia.git
      cd claudia
      yarn install
      yarn tauri build

    執行後即會開啟可視化介面。

四、基本應用範例

  1. 互動式開發

    • CLI:claude 開啟 REPL,輸入「請幫我新增一個 POST /users API」

    • GUI:在 Claudia 中點擊「New Session」,選擇系統提示,再輸入需求

  2. 除錯與測試

    • CLI:claude run test 自動執行測試並修復失敗測試

    • GUI:在「Timeline」檢視每次測試結果差異,快速回溯錯誤

  3. 版本控制

    • CLI:claude git merge 自動解決衝突

    • GUI:在「Projects」面板切換分支並視覺化比較差異

  4. 自訂 AI 智能體

    • 建立 CLAUDE.md 記錄專案慣例與常用指令

    • GUI 中匯入/編輯 CLAUDE.md,讓 Claude 記憶專案規範

五、進階推薦用法

  1. 環境優化

    • 在專案根目錄放置 CLAUDE.md,記錄測試命令、程式風格與常用工具,讓 Claude 建立持久記憶。

  2. CI/CD 自動化

    • 結合 Claude Code CLI 於 GitHub Actions,於 PR 自動執行程式碼檢查與合併衝突解決。

  3. 多語言支援

    • 透過 Claudia MCP 管理器,註冊多個 Model Context Protocol 伺服器,讓 Claude 跨平台、跨服務庫檢索文件。

  4. 團隊協作

    • 使用 Claudia 的「檢查點」功能截取多個開發階段,並匯出差異報告,供團隊成員 review。

六、結語

將 Claude Code 與 Claudia 結合,既保有終端機指令的靈活與自動化能力,又能享有 GUI 的可視化便捷,適合各種規模與需求的專案。無論是程式新手,或是追求效率的資深開發者,都能透過這套組合顯著提升開發體驗與產出品質。

終端式代理人Claude Code與 Gemini Cli安裝到windows

原本在vscode就裝有github copilot 這個AI 程式寫作的輔助工具,但因為最近終端式的代理從codex cli 到claude code以及最新的gemini cli都太強了!於是想說多二個代理人也不錯~

先記錄一下如何安裝,從最簡單的Gemini Cli (https://github.com/google-gemini/gemini-cli)好了,官方部落格文章在此「Gemini CLI:你的開源 AI 代理

首先,要先安裝 node.js 版本要20或更高 (下載安裝 https://nodejs.org/en/download ),安裝完成後直接在命令提示字元下輸入

npm install -g @google/gemini-cli

接著輸入

gemini

然後會出現設定與驗證後就可以使用了!

Gemini code完整命令說明
Gemini code說明手冊

Gemini 手冊

接下來要處理比較麻煩的claude code。

目前claude在windows只支援WSL(Windows Subsystem for Linux)模式安裝,所以必需先看一下WSL到底是什麼以及如何使用 WSL 在 Windows 上安裝 Linux  ,接著輸入

wsl --install
wsl --set-default-version 2   # 確保使用 WSL2
wsl --set-default Ubuntu      # 如果有多個版

接著進入wsl

sudo apt update #更新
sudo apt upgrade #升級
sudo apt install nodejs npm  #安裝nodejs 跟npm
npm install -g @anthropic-ai/claude-code #安裝claude code

安裝完成即可。

claude code手冊

https://github.com/getAsterisk/claudia

安裝openai codex

npm i -g @openai/codex

github codex

https://chatgpt.com/codex
codex說明

前端開發者必知的8個冷門卻超實用DOM技巧

身為前端開發者,每天都在與DOM (文件物件模型) 打交道,它就像是網頁的骨架,讓開發者能夠操控頁面上的各種元素。不過,在眾多DOM API中,藏著許多鮮為人知但非常實用的方法。

1. Element.checkVisibility()

這是什麼?

這個方法能夠檢測元素是否「真正可見」,不只是存在於DOM中而已。它考慮了多種因素:

  • CSS遮蓋(被其他元素擋住)
  • 滾動隱藏(元素在可視區域外)
  • 透明度為0(肉眼看不見)

實際應用場景

  • 表單驗證:只對用戶可見的表單欄位進行驗證
  • 廣告曝光統計:確保廣告真正被看到才計算曝光
  • 懶加載優化:精準判斷內容是否進入視野,再觸發加載
// 簡單範例
if (myElement.checkVisibility()) {
  // 元素真的被看到了,執行相應操作
}

2. TreeWalker API

這是什麼?

一種高效能遍歷DOM樹的方式,採用「迭代器模式」設計。想像它就像是一個聰明的導遊,可以按照您的要求有序地帶您參觀DOM樹的各個節點。

為什麼要用它?

相比於 querySelectorAll,TreeWalker在處理超大型DOM樹時更省記憶體,因為它不會一次性把所有匹配的節點都載入記憶體。

// 建立一個只遍歷段落元素的TreeWalker
const walker = document.createTreeWalker(
  document.body,           // 從body開始
  NodeFilter.SHOW_ELEMENT, // 只看元素節點
  {
    acceptNode(node) {
      return node.tagName === 'P' 
        ? NodeFilter.FILTER_ACCEPT 
        : NodeFilter.FILTER_SKIP;
    }
  }
);

// 逐一訪問每個段落元素
let currentNode;
while (currentNode = walker.nextNode()) {
  console.log(currentNode.textContent);
}

3. Node.compareDocumentPosition()

這是什麼?

這個方法能精確判斷兩個節點的「位置關係」,就像是網頁元素的GPS定位系統。

常用位置關係代碼

  • 2 (DOCUMENT_POSITION_PRECEDING): 節點A在B之前
  • 4 (DOCUMENT_POSITION_FOLLOWING): 節點A在B之後
  • 8 (DOCUMENT_POSITION_CONTAINS): A是B的祖先節點
// 實用範例:確定拖放元素的插入位置
function determineDropPosition(draggedElem, targetElem) {
  const position = draggedElem.compareDocumentPosition(targetElem);
  
  if (position & Node.DOCUMENT_POSITION_FOLLOWING) {
    return '目標元素在被拖動元素之後';
  } else if (position & Node.DOCUMENT_POSITION_PRECEDING) {
    return '目標元素在被拖動元素之前';
  }
}

4. scrollIntoViewIfNeeded()

這是什麼?

一個聰明的捲動功能,只有當元素不在視窗中時才會自動捲動,避免不必要的頁面跳動。

與傳統方法的比較

傳統的 scrollIntoView() 會無條件捲動到元素位置,而 scrollIntoViewIfNeeded() 則更加智能,避免了過度捲動帶來的使用體驗問題。

// 使用範例:點擊目錄項時,智能捲動到對應章節
catalogItem.addEventListener('click', () => {
  // 只有當章節不在視窗內時才捲動
  document.getElementById(chapterId).scrollIntoViewIfNeeded();
});

5. insertAdjacentElement()

這是什麼?

這是一個比 appendChild 更靈活的元素插入方法,讓您能精準控制插入的位置。

位置參數選項

  • ‘beforebegin’: 在目標元素前面插入
  • ‘afterbegin’: 在目標元素內部的最前面插入
  • ‘beforeend’: 在目標元素內部的最後面插入
  • ‘afterend’: 在目標元素後面插入
// 實用範例:在表單每個輸入框後加入提示訊息
const helpText = document.createElement('small');
helpText.textContent = '請輸入有效的電子郵件地址';
inputElement.insertAdjacentElement('afterend', helpText);

 

6. Range.surroundContents()

這是什麼?

這是一個處理文字區域的神器,能用指定的元素將選中的內容包裹起來。

實際應用場景

  • rich文件編輯器:快速套用格式如加粗、斜體
  • 文章批註系統:標註並高亮重點段落
  • 搜尋結果高亮:突顯頁面中匹配的搜尋詞
// 實現高亮功能
function highlightText(text) {
  const range = document.createRange();
  const selection = window.getSelection();
  
  if (selection.rangeCount > 0) {
    range.setStart(selection.anchorNode, selection.anchorOffset);
    range.setEnd(selection.focusNode, selection.focusOffset);
    
    const highlight = document.createElement('mark');
    highlight.style.backgroundColor = 'yellow';
    
    try {
      range.surroundContents(highlight);
    } catch(e) {
      console.log('選區跨越多個節點,無法直接包裹');
    }
  }
}

7. Node.isEqualNode()

這是什麼?

這個方法能深度比較兩個節點是否「結構相同」,就像比較兩棵樹的形狀是否一致。

重要注意點

它只比較節點的結構和屬性,不會比較動態綁定的事件處理器等內容。這與 === 比較參考是否相同完全不同。

// 實用範例:檢查模板渲染後結構是否符合預期
const expectedStructure = document.createElement('div');
expectedStructure.innerHTML = '';

預期結構

const renderResult = myTemplateEngine.render(data);

if (expectedStructure.firstChild.isEqualNode(renderResult.firstChild)) {
  console.log('渲染結果符合預期結構!');
}

8. document.createExpression()

這是什麼?

這是XPath表達式的預編譯功能,能大幅提升反覆使用同一XPath查詢的效能。

實際應用場景

  • 大數據量表格的快速篩選查詢
  • 複雜XML文檔的節點訪問
  • 需要重複執行同一查詢的場景
// 預編譯XPath表達式
const compiledXPath = document.createExpression(
  '//table[@id="data-table"]/tbody/tr[position() < 10]'
);

// 多次執行同一查詢而無需重複解析
function updateTable() {
  const result = compiledXPath.evaluate(
    document,
    XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
    null
  );
  
  for (let i = 0; i < result.snapshotLength; i++) {
    const row = result.snapshotItem(i);
    // 處理前10行資料
  }
}

小結

這些鮮為人知的DOM API能讓您的前端代碼更加優雅高效。不過在實際應用時,請注意以下幾點:

  • 部分API(如checkVisibility)需要較新的瀏覽器支援(Chrome 106+)
  • 使用前建議檢查Can I Use確認瀏覽器兼容性
  • 適當使用這些API能提升代碼質量,但請避免為了炫技而過度使用冷門API
  • 考慮添加polyfill或fallback方案來處理舊版瀏覽器

掌握這些實用技巧,您的前端開發效率將得到顯著提升!您有用過這些API嗎?歡迎在評論區分享您的經驗和其他實用技巧。

.net core 畫出奇門遁甲九宮圖

透過.net 做一個可以載入圖片,然後在圖片上寫字的功能。
這邊是以底圖(九宮圖.jpg)
然後依照x,y座標畫上文字的方式

程式碼

public void ProcessImage()
{
/*
* //Install-Package System.Drawing.Common
* using System.Drawing;
* using System.Drawing.Imaging;
* using System.Drawing.Text;
* using System.IO;
* using System.Drawing;
*/
// 創建一個新的 1024x768 的圖片
using (Bitmap newImage = new Bitmap(1024, 768))
using (Graphics g = Graphics.FromImage(newImage))
{
// 設置文字渲染品質
g.TextRenderingHint = TextRenderingHint.AntiAliasGridFit;

// 讀取原始圖片
using (Image sourceImage = Image.FromFile(Path.Combine(Directory.GetCurrentDirectory(), "wwwroot", "九宮圖.jpg")))

{
// 將原始圖片繪製到新圖片上
g.DrawImage(sourceImage, 0, 0, 1024, 768);
}

// 創建字體
string fontPath = Path.Combine(Directory.GetCurrentDirectory(), "wwwroot", "字型.ttf");

PrivateFontCollection privateFont = new PrivateFontCollection();
privateFont.AddFontFile(fontPath);
using (Font customFont = new Font(privateFont.Families[0], 25))
{
// 創建黑色畫筆
using (SolidBrush blackBrush = new SolidBrush(Color.Black))
{
// 繪製所有文字
string message;

// 巽4宮
message = "  太陰\n  休門 辛\n  天心 癸\n 巽4宮";
g.DrawString(message, customFont, blackBrush, 181, 114);

// 震3宮
message = " 六合\n  開門 庚\n  天柱 丁\n 震3宮";
g.DrawString(message, customFont, blackBrush, 181, 314);

// 艮8宮
message = " 白虎\n壬一 開門 庚\n天禽 天柱 丁\n 艮8宮";
g.DrawString(message, customFont, blackBrush, 181, 534);

// 離9宮
message = " 騰蛇\n 生門 乙\n 天蓬 戊\n 離9宮";
g.DrawString(message, customFont, blackBrush, 418, 114);

// 中5宮
message = " \n \n 壬\n 中5宮";
g.DrawString(message, customFont, blackBrush, 418, 314);

// 坎1宮
message = " 玄武\n 死門 戊\n 天英 乙\n 坎1宮";
g.DrawString(message, customFont, blackBrush, 418, 534);

// 坤2宮 (注意這裡字體大小是30)
using (Font largerFont = new Font(privateFont.Families[0], 30))
{
message = " 值符\n 傷門 己\n 天任 丙\n 坤2宮";
g.DrawString(message, largerFont, blackBrush, 648, 114);
}

// 兌7宮
message = " 九天\n 杜門 丁\n 天沖 庚\n 兌7宮";
g.DrawString(message, customFont, blackBrush, 648, 314);

// 乾6宮
message = " 九地\n 景門 癸\n 天輔 辛\n 乾6宮";
g.DrawString(message, customFont, blackBrush, 648, 534);
}
}

// 保存圖片
string fileName = DateTime.Now.ToString("yyyyMMddHHmmss") + ".jpg";
string savePath = Path.Combine(Directory.GetCurrentDirectory(), "wwwroot", "imagemake", fileName);
newImage.Save(savePath, ImageFormat.Jpeg);
}

透過azure openai / openai api with vision功能,讓人工智慧看懂圖片

做了個小玩具  網址: https://shoushan.happyweb.com.tw

上傳圖片後,可以做出

一、依照圖片內容生成商品文案給社群小編行銷

二、人工智慧ai 描述辨識圖片

三、上傳餐廳、飲料店等菜單,透過ai辨識回傳json

四、行為偵測,例如上傳照片 讓ai看看有沒有犯法或違法

五、上傳一張網頁的圖片/手繪的prototyp,然後生成規格書與欄位內容,最後搞出一個前端的prototype

聊架構 – 大型網站設計中多人上線指標Transactions Per Second(TPS)定義

大型網站的架構設計中,主要都是以同一時間系統能處理大量網頁請求或處理任務的能力當標準值。假設說,五月天的演唱會訂票系統瞬間會有大量搶票、支付,或是系統同時會有幾十萬客戶上線,這種有機會讓系統癱瘓掉的都屬於「高併發」。
而高併發衡量的指標主要是以”Transactions Per Second(TPS)”就是每秒處理交易數量,就如同剛才說的五月天演唱會搶票,以2024年6月統計7-11有12000家同時有人搶票,就算是高併發的一個場景。
一般而言TPS 落在1000-5000 屬於具有一定程度的併發,而5000以上就算高併發,像50000以上就屬於超大型網站會遇到的超高併發了。
要支撐這樣的場景,需要採用許多高併發的技術方案。
一、分散式架構
將系統的負載分散到多個伺服器的節點,提高擴展與可靠性。例如:增加伺服器的數量

二、微服務架構

把系統從單體拆分成相互獨立的服務,系統各自有自己的業務功能,彼此間透過RPC HTTP 做通訊。而每個微服務可以根據流量/負載做水平擴增。微服務的好處還可以獨立部署或擴增,減少耦合。

三、Cche機制

透過減少直接連接資料庫來提高回應速度,降低伺服器與資料庫的壓力。而用最多的莫過於使用redis 集群方式來擴展性能。把會頻繁查詢的資料,像商品、會員等放在記憶體中,提高併發量。

四、Load Balance 負載平衡

把客戶端的請求分配到不同伺服器,避免單一台伺服器過載,例如像nginx、HAProxy、F5等技術。而負載平衡有三種主要的策略來做分配

  • 輪詢:依順序把請求配到每一台伺服器
  • 權重:根據伺服器效能設定不同權重,能者多勞(不是過勞喔)的意思
  • IP Hash:透過請求的IP來分配,把同一個IP分配到同一台,這樣可以讓Session保持

五、流量的削峰

這是常用到的方式,避免瞬間大量沖垮服務過載。常用的方法是透過佇列的排隊來處理,比方說放到MQ這種訊息佇列來做承受大流量。

六、限流

透過限制請求的速率,主要有Token Bucket、Leaky bucket或計數器三種演算法

可參考:[Architecture] 架構設計 – 限流策略 Rate Limiting Strategies

七、熔斷

當某服務故障、過慢,熔斷機制可臨時中斷請求,避免影響

八、降級

關閉一些非核心的服務,降低系統壓力。