目前窮小子售票系統的售票 API 已經能夠承受 2400 左右的 RPS 了，但承受了這麼高的流量最後持久化的資料是否是正確的呢? 接下來就一起驗證看看

起初為了節省成本， Cloud SQL 開得很小 Process Service 在處理入票時會需要話較長的時間，為了方便測試跟驗證，再建立一個座位較少的活動來進行測試驗證。

一樣使用先前撰寫的gen-event.js k6 腳本進行活動的建立

import http from 'k6/http';
export const options = {
    vus: 1,
    duration: '300s',
    iterations: 1
};
const baseUrl = 'https://ithome2024-salesservice-539812124803.asia-east1.run.app';

const arrayLength = 1000;
const resultArray = [];

for (let i = 0; i < arrayLength; i++) {
    resultArray.push({
        name: i.toString(),
    });
}

export default function () {
    var res = http.post(baseUrl + '/api/event', JSON.stringify({
        "name": "TestEvent005",
        "eventDate": "2024-09-25T15:15:39",
        "startSalesDate": "2024-09-25T15:15:39",
        "endSalesDate": "2024-09-25T15:15:39",
        "description": "Desc",
        "remark": "Re",
        "seats": resultArray
    }), {
        headers: {
            'Content-Type': 'application/json',
        },
    });
    console.log(res.status);

}

確認活動是否建立完成

接著對這個活動進行壓測

一共打了 16000 個 Request 出去，但 TestEvent005 的活動只有 1000 個座位，理論上應該是會全數售完，我們確認一下

DB 跟 Redis 內都同樣有著 1000 份購票紀錄，基本上可以確定我們的整個購票流程從最前面的外部服務到Pub/Sub緩衝到最後寫入DB資料持久化，整段流程都是順暢的，資料也都正確無誤。