前言

當一個專案越來越大，在開發新產品時同時要兼顧程式碼品質會越來越困難，今天要介紹的　Ndepend 是一個很優秀靜態分析 .Net 專案好物

會幫我們產生一個 DashBoard 來了解目前專案大致上分析後的問題，並提供建議解法和處理方向，讓我們提前更快速抓出未來或目前存在 bug，減少發生需要晚上起來 support 機率，讓客戶，老闆，工程師都開心的三大歡喜

另外我們也可以透過 Ndepend 來撰寫我們自己 Code Rule 並在 CI/CD 流程中進行靜態掃描，讓我們出產軟體更有品質

本文我使用我自己的開源專案 ElectronicInvoice_TW 來當作分析案例

建立 Ndepend 開始分析

安裝完 Ndepend 後我們可以在 virtual studio 上面的[延伸模組] 出現建立 Ndepend 項目，一開始我們利用 Attach New Ndepend Project to Current VS Solution ，來建立分析項目

NDepend 分析完程式後我們會在 sln 檔同級目錄下看到一個 NDependOut 資料夾跟 .ndproj 檔案

• .ndproj 是 XML 格式儲存的專案檔，內容包含 NDepend 專案資訊及分析設定資訊
• NDependOut 資料夾中會有一個 .ndar 檔案這次一個二進制格式儲存的分析後結果
• NDependOut 中有一個 NDependReport.html 是一個分析後 Html 報表

前言

在 Postgresql 世界裡每建立一個 Connection，都會有一個 process 來服務該請求，Postgresql 沒有 ThreadPool 概念所以在 Connection 使用量大時會發生一些問題

• 資源浪費
• 超過同時間超過 max_connection 後面連接會無法連接

一個 open source 插件 PgBouncer 就是幫我們解決上面問題，不過如果你是使用 AWS RDS 來當作 DB 就很適合使用 RDS Proxy

本次使用免費帳號範圍提供的機器 db.t2.micro

另外因為 RDS Proxy 在 EC2 內網才能連接，所以我也利用免費帳號準備一台 EC2 並安裝 pgbench 進行壓力測試

壓測前準備 & 說明

我把 max_connections 最大連接數量調整成 550

前言

資料結構跟演算法是程式設計師的內功，在中小型系統懂這兩樣東西效用可能有限，但在大型系統中熟不熟用資料結構跟演算法做出來的效益會天差地遠

對於常使用的物件和變數我們會放置在 Redis 上( cache server )，但記憶體有限，我們想放的東西無限，造就無法將所有物件都存放在 Redis 或 Server Memory 上.

假如你有設定過 Redis config 你會看到一個 property maxmemory_policy 來管理如何淘汰，記憶體中的物件

• volatile-lru
• allkeys-lru

上面有個名稱 LRU (Least Recently Used Cache)　代表甚麼意涵呢？稍後會跟大家做解釋

Github Sample Project

LRU 算法概念

LRU (Least Recently Used Cache) 顧名思義，會記憶體不夠用時優先保留最近常使用的 Cache 資料，並剔除最舊的資料來緩解壓力

這個算法策略可以確保 Hot Data 在記憶體不足時不會被刪除

前文

我認為 DB query optimizer (QO) 產生執行計畫並執行查詢和 使用地圖找尋最佳路徑很類似

下面會跟大家分享我心中 地圖理論 希望可以對於想了解 DB 運作的人更快上手

看見全貌

在了解一個事情跟技術，我們需要先用宏觀的角度來看待事情

下圖是 postgresql DB 運作核心概念圖

其中在執行語法前後最重要的幾個步驟是

1. Parser：檢查語法是否有錯誤，如果錯誤就不執行後續步驟
2. ReWriter：嘗試優化改寫 SQL
3. Planner：利用統計資訊 & 演算法建立執行計畫
4. Executor：挑選一個成本最低的執行計劃來查找資料

我認為資料 Search Engine 的 Planner & Executor 核心概念跟查找地圖( google map 很類似 )

前言

我之前有寫透過 lock or CAS 來防治，Racing condition 問題，但如果這個問題延深到多台服務器甚至是 micor-services 架構我們要怎麼處理資料問題呢?

下面程式在單體服務或應用程式不會出問題，但如果服務器有多台問題可就大了，因為下面的 lock 只限於單體 Server 上

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

private readonly static object _lock = new object();
[HttpGet()]
public string Get()
{
    int remainCount;
    lock (_lock)
    {
        
        remainCount = (int)RedisConnection.GetDatabase().StringGet(_productId);
        if (remainCount > 0)
        {
            RedisConnection.GetDatabase().StringSet(_productId, --remainCount);
        }
    }

    string productMsg = remainCount <= 0 ? "沒貨了賣完了" : $"還剩下 {remainCount} 商品";
    string result = $"{Dns.GetHostName()} 處理貨物狀態!! {productMsg}";
    _logger.LogInformation(result);
    return result;
}

如果有聽過 Redis 可能就會聽過 RedLock.net 來處理，但您知道 RedLock.net 底層大致上怎麼實作的嗎?

本篇文章會帶領大家透過 distlock 算法時做出，自己的Redlock

本篇只介紹核心概念，細部防錯我沒有寫出來，所以建議本篇程式不要用在 prod 環境

我使用 docker-compose 建立問題架構，架構圖如下

原始碼位置 Redlock-Csharp

前言

執行計畫代表此次查詢要怎麼樣的演算法查詢我們的資料，而成本是決定使用哪個執行計畫的重要因素

在 postgreSQL DB query optimizer 會選擇成本最低的執行計劃，當作查詢資料使用算法

在 Sql-sevrer 成本計算封裝在程式內部，我們無法透過一些因子來調整，但 postgreSQL 可以

我認為 query optimizer 判斷成本概念有點類似 google map 在找尋最佳路徑

我對於資料庫有定義一個，地圖理論來說明 RDBMS 執行計畫相關的事情

本篇成本因子效能調教會涉 Linux kernel systemtap ，國中數學，postgreSQL 運作模型，篇幅可能會有點多且複雜

但我認為本篇學會可以對於　query optimizer 有更進一步了解

預設成本因子潛在問題

下面我使用一個例子來

前言

AWS 在有眾多服務，其中我對於 Lambda 最有興趣 (因為 .net 有一個 Lambda 表達式 )

最近申辦帳號可以使用 12 個月部分免費服務(有條件限制)，看我還不玩爆 AWS XD

經過了解得知 Lambda 是一個 EDA 架構並幫我們解決開發時需要煩惱硬體上配置(記憶體要多少，CPU，是否需要 load balance scale out…)，做一個 serverless 服務

讓我們可以專心開發程式，本篇會針對 .net core 建立一個 sample 專案到上傳到 AWS Lambda 服務上說明

安裝aws cli & 設定 profile

首先我們需要先安裝 aws cli，如果是 windows 我們可以透過 powershell，來完成

1

C:\> msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

1
2

$ aws --version
aws-cli/2.2.44 Python/3.8.8 Windows/10 exe/AMD64 prompt/off

確定安裝完後我們可以執行 aws configure 設定我們 AWS 服務相關 IAM 資訊

前言

WAL 是一種 Tx Log實踐機制

WAL 核心概念是先寫 tx log，在把資料寫資料，資料的修改必须發生在寫入 Tx Log之後，使用 WAL 紀錄資料庫系統在commit transaction

使用 WAL 機制後我們不需要在每次 Commit Transaction 後就把資料 flush 到 Disk 上(提高IO效率)， WAL 需要保證 Dirty Block flush 到 Disk 之前，該 Block 對應 Tx log 紀錄已經 flush 到 Disk 中

因為假如系統突然崩潰我們可以藉由 WAL 寫入 Tx Log 來 roll-forward recovery (REDO)

WAL 寫入時機簡介

LSN序號是一個 globale 變數(透過 info_lck 輕量鎖設計避免同一時間取得同一個 LSN )

寫入資料會經由下面幾個步驟

1. Log (LSN–Log) 是一個有順序性標誌的紀錄 (可以想像是一個 sequence ) ，一開始存在 RAM 中，在 RAM 中有一個 flushLSN 位置會記錄 log LSN 寫入 Disk 最後位置.
2. 每個 block 在 pageheader 會有一個欄位 PageXLogRecPtr pd_lsn; 指到 log 紀錄位置，此位置在 Dirty Block 存在 buffer Pool 時就會決定
3. 最後把　Dirty Block flush 到 Disk 之前 postgresSQL 會檢查是否滿足此條件 pd_lsn <= flushLSN ，確保 Log 已經寫入 Disk 上才會把資料 flush 到資料庫中
4. 如果是 synchronous_commit = ON 代表同步提交，在 Transaction commit 時會把對應的 Tx Log 馬上 flush 進 Disk中才能返回成功

經過上面步驟我們就可以確保 先寫 Tx Log 歷程，後寫 Dirty Block

前言

Postgresql DB 目前預設在更新資料時會在 Heap Table 新增一條新版本資料，舊版本會先存在直到使用 VACUUM 回收

HOT update 作用在，當資料更新時通過 Heap Block 內部串聯所有 tuple 版本，則 Index 索引不變

HOT update 必須滿足以下兩個條件:

1. 索引欄位值不變。(其中任意一個索引字段的值發生了變化，則所有索引都需要新增版本)
2. 新版本資料和舊版本資料在同一個HEAP Block中。

在測試前我們要先開啟 pageinspect 了解查看 block 底層訊息

sample data

1

create extension pageinspect -- 打開可以查看底層 Page 功能，需要有 admin 權限

1
2
3
4
5
6
7

CREATE TABLE tt2(id int,a int,b int);  

INSERT INTO tt2 
SELECT generate_series(1,10), random()*100, random()*100;

CREATE INDEX ix_tt2_id ON tt2 (ID);
CREATE INDEX ix_tt2_a ON tt2 (a);

接著我們透過 bt_page_items 查看 Index 儲存資料，heap_page_items 查看 heap table 儲存資料

前言

因為工作需要最近在研究 postgresql DB，發現跟 sql-server 相比有許多不同之處，所以一開始就先研究 Page 差別，沒想到還真的有不少細節上的差異

在postgresql DB Page size 預設是 8KB

我們想要看page使用大小在 Sql-Server 可以用 DBCC命令在 postgresql DB 沒有 DBCC 還好有其他方式可以查看 Page 儲存原理

如果要了解存儲怎麼辦呢?

關於 page 存儲

使用sample data

1
2
3
4

CREATE TABLE t1 (id int PRIMARY KEY);

insert into t1 select generate_series(1,2000);
insert into t1 select generate_series(2001,4000);

建立完表後我們透過 \d+ t1 指令查看資料表訊息，可以看到PK成功被建立

1
2
3
4
5
6
7

postgres=# \d+ t1
                                    Table "public.t1"
 Column |  Type   | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------
 id     | integer |           | not null |         | plain   |              |
Indexes:
    "t1_pkey" PRIMARY KEY, btree (id)