สามคำขอ ฐานข้อมูลถูกถามครั้งเดียว แล้ว clinic-b ได้แถวของ clinic-a

คอร์สคัดกรองผู้เรียกของคลินิก จบด้วยกฎข้อเดียว ผู้เรียกเห็นได้เฉพาะแถวของผู้เช่าตัวเอง

บทนี้ไม่แก้กฎนั้นสักตัวอักษร มันเพิ่มชั้นที่จำคำตอบไว้เข้ามาหนึ่งชั้น แล้ววัดว่ากฎเดิมยังยืนอยู่ไหม

📦 clinic — โปรเจกต์เดิมของซีรีส์ ไม่ได้เริ่มใหม่

คอร์สนี้ต่อจากโปรเจกต์ของ clinic-security โดยตรง โดเมน repository และกฎ security เดิมทั้งหมด

ตัวเลขทุกตัวในคอร์สนี้มาจาก probe ที่คุณรันเองได้ สั่ง scripts/clinic-cache/up.sh แล้วตามด้วย python3 scripts/clinic-cache/probe.py

ปลายทางที่คอร์สก่อนหน้าส่งมาให้

ทรงตั้งต้นคืนแถวของผู้เช่าตัวเองให้ทั้งสองราย และฐานข้อมูลถูกถามสามครั้งจากสามคำขอ

ในฐานข้อมูลมีสามแถว แบ่งเป็นของสองคลินิก

clinic-a มีสองแถว คือ พิมพ์ใจ กับ สมชาย
clinic-b มีหนึ่งแถว คือ วีระ
ทุกการวัดยิงสามคำขอ ตามลำดับ clinic-a แล้ว clinic-b แล้ว clinic-a อีกครั้ง

ทรงนี้ชื่อ scoped ผู้เรียกของ clinic-a ได้สองแถวของตัวเอง ผู้เรียกของ clinic-b ได้หนึ่งแถวของตัวเอง และฐานข้อมูลถูกถาม 3 ครั้ง

ผู้เช่าไม่ได้เดินทางมาเป็น parameter

รูปของโดเมนตัดสินใจไว้แล้วว่าผู้เช่าอยู่ใน SecurityContext ไม่ใช่ในรายการ parameter

@Component("currentTenant")
class CurrentTenant {
    val id: String
        get() = if (SecurityContextHolder.getContext().authentication?.name == "kaen-a")
            "clinic-a" else "clinic-b"
}

@Service
class VisitService(private val repo: VisitRepo, private val tenant: CurrentTenant) {
    fun visits(): List<Visit> = repo.findByTenantId(tenant.id)
}

visits() ไม่รับ parameter สักตัว ผู้เช่าเข้ามาทาง SecurityContext แล้วถูกอ่านข้างใน รูปนี้คือรูปที่คอร์สที่ 35 ส่งมอบมา และเป็นรูปที่บทนี้ไม่แก้สักตัวอักษร

ติด annotation บน method เดิม แล้ววัดใหม่

ตัวงานข้างใน visits() ไม่ขยับสักตัวอักษร ไม่มีการแก้กฎของโดเมนและไม่มีการแก้กฎความปลอดภัย

@Service
class VisitService(private val repo: VisitRepo, private val tenant: CurrentTenant) {
    @Cacheable("visits")
    fun visits(): List<Visit> = repo.findByTenantId(tenant.id)
}

@Cacheable ประกาศว่าผลของ method นี้เก็บไว้ใช้ซ้ำได้ ผู้เรียกที่ได้กุญแจตรงกัน จะได้ค่าเดิมกลับไปจาก cache โดยไม่มีคำขอไหนลงไปถึงฐานข้อมูล

สิ่งที่วัดได้จากสองทรง

เทียบสองทรงช่องต่อช่อง แล้วดูว่าช่องไหนเปลี่ยนและช่องไหนเหมือนเดิม

ช่องที่วัด	ทรง `scoped`	ทรง `cached`
`clinic-a` เห็น	พิมพ์ใจ, สมชาย	พิมพ์ใจ, สมชาย
`clinic-b` เห็น	วีระ	พิมพ์ใจ, สมชาย
ฐานข้อมูลถูกถาม	3 ครั้ง	1 ครั้ง
bean ของ `CacheManager`	ไม่มี	มี

ผู้เรียกของ clinic-b ได้แถวของ clinic-a กลับไปทั้งสองแถว นี่คือ cross-tenant leak และมันกลับมาโดยที่ไม่มีใครแก้กฎข้อไหนเลย

รหัสยังเป็น 200

คำตอบที่รั่วไม่ได้ผิดรูป มันมีรูปเดียวกับคำตอบที่ถูกต้อง และรหัสเดียวกันด้วย

คำขอของ clinic-b ในทรง cached คืนรหัส 200 เท่ากับคำขอที่ไม่ได้รั่ว ไม่มีรหัสข้อผิดพลาดสักตัวให้ดู ในคำตอบนั้นไม่มีช่องไหนบอกว่าแถวที่ได้ไปเป็นของผู้เช่ารายอื่น

หน่วยเดียวที่จับรูนี้ได้คือจำนวนแถว ผู้เรียกที่ควรได้หนึ่งแถวได้ไปสองแถว ถ้าไม่นับแถว ก็ไม่มีอะไรให้ดู

สามคำขอ ฐานข้อมูลถูกถามครั้งเดียว

คำขอแรกเดินไปถึงฐานข้อมูล ส่วนอีกสองคำขอจบที่ cache และไม่เดินต่อ

flowchart TB
  A["คำขอที่ 1 · ผู้เรียกของ clinic-a"] --> K{"กุญแจใบนี้อยู่ใน cache แล้วหรือยัง"}
  B["คำขอที่ 2 · ผู้เรียกของ clinic-b"] --> K
  C["คำขอที่ 3 · ผู้เรียกของ clinic-a อีกครั้ง"] --> K
  K -->|"ยังไม่มี · เฉพาะคำขอที่ 1"| DB[("ฐานข้อมูล · ถูกถามครั้งเดียว")]
  DB --> R1["พิมพ์ใจ, สมชาย"]
  R1 --> W["เก็บลง cache ชื่อ visits"]
  K -->|"มีแล้ว · คำขอที่ 2 และที่ 3"| R2["พิมพ์ใจ, สมชาย · 200"]

คำบรรยายภาพ: สามคำขอเดินมาถึงกุญแจใบเดียวกัน คำขอแรกจึงลงไปถึงฐานข้อมูล ส่วนคำขอที่สองกับที่สามได้คำตอบของคำขอแรกกลับไป

จากสามคำขอ ฐานข้อมูลถูกถาม 1 ครั้ง ส่วนทรง scoped ถูกถาม 3 ครั้ง คำขอที่สามซึ่งเป็นของ clinic-a ก็ได้ค่าจาก cache เช่นกัน

ตัวเลขที่ลดลงคือสิ่งที่คนเปิด cache ต้องการ และมันเกิดขึ้นจริง สิ่งที่มาพร้อมกันคือคำตอบของผู้เช่ารายหนึ่ง กลายเป็นคำตอบของอีกราย

คำถามที่บทนี้ทิ้งไว้

รู้แล้วว่ารูกลับมา ยังไม่รู้ว่าอะไรทำให้คำขอของสองผู้เช่าตกลงช่องเดียวกัน

กฎของโดเมนไม่ได้เปลี่ยน กฎความปลอดภัยไม่ได้เปลี่ยน visits() ยังอ่านผู้เช่าจาก SecurityContext เหมือนเดิมทุกคำขอ แต่ตัวงานข้างใน visits() ไม่เคยรันในคำขอที่สอง

คำถามคือทำไมสองผู้เช่าถึงใช้ช่องเดียวกันใน cache ใครเป็นคนตัดสินว่าคำขอสองใบนี้ ถามเรื่องเดียวกัน ในเมื่อไม่มี code บรรทัดไหนของเราเขียนกุญแจนั้นขึ้นมา

ก่อนถึงคำถามนั้น บทที่ 2 ถามข้อที่มาก่อน คือติด annotation ครบแล้วแอปสตาร์ตหรือยัง ส่วนคำถามข้างบนเปิดกล่องดูกันในบทที่ 3

🔗 อ้างอิงต้นทางของบทนี้

Spring Framework — Annotation-based Caching (เข้าถึง 2026-09-04) — ที่มาของความหมายของ @Cacheable
ตัวเลขทุกตัวในบทนี้มาจาก scripts/clinic-cache/probe.py ซึ่งสร้างโปรเจกต์ขึ้นใหม่ ทีละทรงแล้วเทียบผลทีละช่อง · ต้องสั่ง scripts/clinic-cache/up.sh ก่อน ซึ่งยก container ของคอร์สนี้เองขึ้นที่ port 55436

เช็กความเข้าใจ — บทที่ 1

ข้อ 1 / 3

ทรง `cached` ยิงสามคำขอตามลำดับ clinic-a แล้ว clinic-b แล้ว clinic-a อีกครั้ง ฐานข้อมูลถูกถามกี่ครั้ง

สาม​คำขอ ฐาน​ข้อมูล​ถูก​ถาม​ครั้ง​เดียว แล้ว clinic-b ได้​แถว​ของ clinic-a

ปลาย​ทาง​ที่​คอร์ส​ก่อน​หน้า​ส่ง​มา​ให้

ผู้​เช่า​ไม่​ได้​เดิน​ทาง​มา​เป็น parameter

ติด annotation บน method เดิม แล้ว​วัด​ใหม่

สิ่ง​ที่​วัด​ได้​จาก​สอง​ทรง

รหัส​ยัง​เป็น 200

สาม​คำขอ ฐาน​ข้อมูล​ถูก​ถาม​ครั้ง​เดียว

คำถาม​ที่​บท​นี้​ทิ้ง​ไว้