>>232 จริงๆ assets hash ที่อยู่ข้างหลังไฟล์ CSS ใน URL นี่ใช้ LRU cache ครับ
เหตุผลที่ไม่ใช้ memory ในการ cache ส่วนอื่นๆ คือเรามีความจำเป็นที่จะ
1. รัน process web server หลาย process เพื่อรองรับ traffic spike
2. สามารถ expire ค่าใน cache ได้อิสระ (และต้อง populate ทุก process ตาม 1)
ในความเป็นจริง สามารถใช้ memory cache ที่ฝั่ง Python ได้ (ก็คือแต่ละ process เก็บ cache แยกกัน)
แต่ถ้าใช้ memory cache แล้วต้องการจะทำข้อ 2 ให้มี complexity น้อยที่สุด ก็ต้อง expire จาก cache key
เช่นตั้ง key สำหรับ cache เป็น cache:key:timestamp (เช่น settings:timezone:1545288880)
ทีนี้มันจะมีปัญหาว่า timestamp นี่ต้องเป็น last updated timestamp แล้วเราจะเอา timestamp นี้มาจากไหน
ง่ายที่สุดก็คงเป็นเก็บลงฐานข้อมูล ซึ่งนั่นก็หมายถึงการต้อง hit ฐานข้อมูลตลอดเวลา เวลาที่ต้องดึงจาก cache ซึ่งจะช้า
ทำให้การใช้ Redis ในการเก็บข้อมูลที่ค่อนข้าง dynamic (เปลี่ยนได้ตลอดเวลา) เป็นวิธีที่เหมาะสมกว่าครับ
กรณีของ assets hash ที่บอกตอนแรก เหตุผลที่ใช้ LRU cache แทน Redis คือ assets hash มันเป็น static
มันจะเปลี่ยนแค่หลัง deploy ซึ่งจำเป็นต้องมีการ restart server ทำให้ในกรณีนี้ memory cache เหมาะสมกว่า
key ของเว็บที่เก็บในตอนนี้ พยายามจะตั้งชื่อให้เป็น module.function:key1=value,key2=value,...
แล้วจะเอา key นี้ไปแปลงเป็น SHA256 ก่อนส่งเข้าสู่ Redis เพื่อให้ขนาดของ key เป็น fixed length
โดยจะเซ็ทให้ expire ทุก 1 ชั่วโมง เพื่อกัน stale cache ครับ ถ้ามีอัพเดทอะไรก็ force expire ทิ้ง
แล้วรอให้มี request ถัดไปเรียกใช้ เพื่อสร้าง cache
ข้อมูลที่เก็บไว้ใน Redis คือจะดึงค่าทุก request ที่มีการใช้งานครับ เพราะเหตุผลเรื่อง expiration ตามที่บอกไว้ข้างต้น
ถ้ามีการแคชค่าที่ได้รับจาก Redis อีกต่อ จะเก็บค่านี้ไว้แค่ภายใน request lifecycle ครับ
ที่จริงมันมีเรื่อง low-level อย่าง locking เวลาสร้าง cache อยู่ด้วย อันนี้ลองอ่าน dogpile.cache น่าจะดีกว่า
https://dogpilecache.sqlalchemy.org/en/latest/
