ProHoster > บล็อก > การบริหาร > การสร้างและกำหนดค่า CDN ของคุณ

การสร้างและกำหนดค่า CDN ของคุณ

เครือข่ายการจัดส่งเนื้อหา (CDN) ใช้ในเว็บไซต์และแอปพลิเคชันเป็นหลักเพื่อเพิ่มความเร็วในการโหลดองค์ประกอบคงที่ สิ่งนี้เกิดขึ้นเนื่องจากการแคชไฟล์บนเซิร์ฟเวอร์ CDN ที่อยู่ในภูมิภาคทางภูมิศาสตร์ที่แตกต่างกัน โดยการร้องขอข้อมูลผ่าน CDN ผู้ใช้จะได้รับข้อมูลจากเซิร์ฟเวอร์ที่ใกล้ที่สุด

หลักการทำงานและฟังก์ชันการทำงานของเครือข่ายการจัดส่งเนื้อหาทั้งหมดนั้นใกล้เคียงกัน เมื่อได้รับคำขอดาวน์โหลดไฟล์แล้ว เซิร์ฟเวอร์ CDN จะนำไฟล์ดังกล่าวจากเซิร์ฟเวอร์เดิมเพียงครั้งเดียวและมอบให้กับผู้ใช้ ขณะเดียวกันก็แคชไฟล์ตามระยะเวลาที่กำหนด คำขอที่ตามมาทั้งหมดจะได้รับคำตอบจากแคช CDN ทั้งหมดมีตัวเลือกในการโหลดไฟล์ล่วงหน้า ล้างแคช กำหนดวันหมดอายุ และอื่นๆ อีกมากมาย

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

การสร้างและกำหนดค่า CDN ของคุณ
ที่มา: เวกเตอร์อินโฟกราฟิกที่สร้างโดย pikisuperstar - www.freepik.com

เมื่อคุณต้องการ CDN ของคุณเอง

พิจารณากรณีที่การเรียกใช้ CDN ของคุณเองสมเหตุสมผล:

  • เมื่อมีความปรารถนาที่จะประหยัดเงิน และดำเนินการต้นทุนแม้ว่าจะใช้ CDN ที่ราคาไม่แพงก็ตาม บันนี่ซีดีเอ็น เป็นจำนวนเงินหลายร้อยเหรียญต่อเดือน
  • หากเราต้องการได้รับแคชถาวรหรือแคชที่ไม่มีเซิร์ฟเวอร์และเพื่อนบ้านช่อง
  • บริการ CDN ไม่มีจุดให้บริการในภูมิภาคที่คุณต้องการ
  • การตั้งค่าการนำส่งเนื้อหาพิเศษใดๆ ที่จำเป็น
  • เราต้องการเพิ่มความเร็วในการจัดส่งเนื้อหาแบบไดนามิกโดยการวางเซิร์ฟเวอร์ที่ใช้งานจริงให้ใกล้กับผู้ใช้มากขึ้น
  • มีความกังวลว่าบริการ CDN ของบุคคลที่สามอาจรวบรวมหรือใช้ข้อมูลเกี่ยวกับพฤติกรรมของผู้ใช้อย่างผิดกฎหมาย (สวัสดีบริการที่ไม่สอดคล้องกับ GDPR) หรือมีส่วนร่วมในกิจกรรมที่ผิดกฎหมายอื่น ๆ

ในกรณีอื่น ๆ ส่วนใหญ่ การใช้โซลูชันสำเร็จรูปที่มีอยู่จะเหมาะสมกว่า

คุณต้องเริ่มต้นอะไร

จะดีมากหากคุณมี Autonomous System (AS) เป็นของตัวเอง ด้วยสิ่งนี้ คุณสามารถกำหนด IP เดียวกันให้กับเซิร์ฟเวอร์หลายเครื่องและ ตามคำแนะนำนี้ ที่ระดับเครือข่าย ให้นำผู้ใช้ไปยังเครือข่ายที่ใกล้ที่สุด เป็นเรื่องที่ควรค่าแก่การกล่าวว่าแม้จะมีบล็อกที่อยู่ /24 แต่ก็สามารถสร้างเครือข่ายการจัดส่งเนื้อหาได้ ผู้ให้บริการเซิร์ฟเวอร์บางรายอนุญาตให้คุณประกาศเพื่อใช้ในทุกภูมิภาคที่มีให้บริการ

หากคุณไม่ใช่เจ้าของบล็อกที่อยู่ IP อย่างมีความสุข คุณจะต้องมี: เพื่อเรียกใช้ CDN แบบง่าย

  • ชื่อโดเมนหรือโดเมนย่อย
  • เซิร์ฟเวอร์อย่างน้อยสองเครื่องในภูมิภาคต่างๆ เซิร์ฟเวอร์อาจเป็นแบบเฉพาะหรือเสมือนก็ได้
  • เครื่องมือ geoDNS เมื่อผู้ใช้ระบุโดเมนแล้วจะถูกส่งไปยังเซิร์ฟเวอร์ที่ใกล้ที่สุด

ลงทะเบียนโดเมนและสั่งซื้อเซิร์ฟเวอร์

ด้วยการจดทะเบียนโดเมน ทุกอย่างง่ายดาย - เราจดทะเบียนในโซนใดก็ได้กับผู้รับจดทะเบียนคนใดก็ได้ คุณยังสามารถใช้โดเมนย่อยสำหรับ CDN ได้ เช่น cdn.domainname.com. จริงๆ แล้ว ในตัวอย่างของเรา เราจะทำอย่างนั้น

สำหรับการสั่งซื้อเซิร์ฟเวอร์ ควรเช่าเซิร์ฟเวอร์ในภูมิภาคและประเทศที่กลุ่มเป้าหมายผู้ใช้ของคุณตั้งอยู่ หากโปรเจ็กต์เป็นแบบข้ามทวีป ก็สะดวกในการเลือกผู้ให้บริการโฮสติ้งที่ให้บริการเซิร์ฟเวอร์ทั่วโลกในคราวเดียว ตัวอย่าง: OVH, เว็บเช่า и 100Tb - สำหรับเซิร์ฟเวอร์เฉพาะ Vultr и DigitalOcean — สำหรับคลาวด์เสมือน*

สำหรับ CDN ส่วนตัวของเรา เราจะสั่งซื้อเซิร์ฟเวอร์เสมือน 3 เครื่องในทวีปต่างๆ ที่ Vultr บนเซิร์ฟเวอร์สำหรับ $5/เดือน เราจะได้รับ SSD 25GB สถานที่และ ปริมาณการรับส่งข้อมูล 1TB. เมื่อติดตั้ง ให้เลือก Debian ล่าสุด เซิร์ฟเวอร์ของเรา:

การสร้างและกำหนดค่า CDN ของคุณ แฟรงค์เฟิร์ต, ไอพี: 199.247.18.199

การสร้างและกำหนดค่า CDN ของคุณ เมืองชิคาโก, ไอพี: 149.28.121.123

การสร้างและกำหนดค่า CDN ของคุณ สิงคโปร์, ไอพี: 157.230.240.216

* Vultr และ DigitalOcean สัญญาว่าจะให้เครดิต 100 ดอลลาร์แก่ผู้ใช้ที่ลงทะเบียนผ่านลิงก์ในบทความทันทีหลังจากเพิ่มวิธีการชำระเงิน ผู้เขียนยังได้รับคำชมเล็กๆ น้อยๆ จากสิ่งนี้ ซึ่งสำคัญมากสำหรับเขาในตอนนี้ กรุณาเข้าใจ.

การตั้งค่า geoDNS

เพื่อให้ผู้ใช้ถูกนำทางไปยังเซิร์ฟเวอร์ที่ต้องการ (ใกล้เคียงที่สุด) เมื่อเข้าถึงโดเมนหรือโดเมนย่อย CDN เราจำเป็นต้องมีเซิร์ฟเวอร์ DNS ที่มีฟังก์ชัน geoDNS

หลักการและการทำงานของ geoDNS มีดังนี้:

  1. ระบุ IP ของไคลเอ็นต์ที่ส่งคำขอ DNS หรือ IP ของเซิร์ฟเวอร์ DNS แบบเรียกซ้ำที่ใช้เมื่อประมวลผลคำขอของไคลเอ็นต์ เซิร์ฟเวอร์แบบเรียกซ้ำดังกล่าวมักเป็น DNS ของผู้ให้บริการ
  2. IP ของลูกค้ารู้จักประเทศหรือภูมิภาคของเขา ด้วยเหตุนี้ จึงมีการใช้ฐานข้อมูล GeoIP ซึ่งมีอยู่มากมายในปัจจุบัน มีดี ตัวเลือกฟรี.
  3. ให้ที่อยู่ IP ของเซิร์ฟเวอร์ CDN ที่ใกล้ที่สุดแก่เขา ทั้งนี้ขึ้นอยู่กับตำแหน่งของลูกค้า

เซิร์ฟเวอร์ DNS พร้อมฟังก์ชัน geoDNS สามารถทำได้ ประกอบด้วยตัวเองแต่จะดีกว่าถ้าใช้โซลูชันสำเร็จรูปกับเครือข่ายเซิร์ฟเวอร์ DNS ทั่วโลกและ anycast จากกล่อง:

  • CloudDNS จาก $9.95/เดือน, อัตราภาษี GeoDNS โดยค่าเริ่มต้นจะมี DNS Failover หนึ่งรายการ
  • ซีลอเร่ จาก $25/เดือนเปิดใช้งาน DNS Failover แล้ว
  • Amazon เส้นทาง 53 จาก $35/เดือน สำหรับคำขอทางภูมิศาสตร์สุทธิ 50M DNS Failover มีการเรียกเก็บเงินแยกต่างหาก
  • DNS ทำให้ง่าย จาก $125/เดือนมี DNS Failover 10 รายการ
  • Cloudflareคุณลักษณะ "Geo Steering" มีให้ใช้งานในแผน Enterprise

เมื่อสั่งซื้อ geoDNS คุณควรใส่ใจกับจำนวนคำขอที่รวมอยู่ในภาษีและโปรดจำไว้ว่าจำนวนคำขอจริงไปยังโดเมนอาจเกินความคาดหมายได้หลายครั้ง สไปเดอร์ เครื่องสแกน ผู้ส่งอีเมลขยะ และวิญญาณชั่วร้ายอื่นๆ หลายล้านตัวทำงานอย่างไม่รู้จักเหน็ดเหนื่อย

บริการ DNS เกือบทั้งหมดมีบริการที่ขาดไม่ได้สำหรับการสร้าง CDN - DNS Failover ด้วยความช่วยเหลือนี้ คุณสามารถตั้งค่าการตรวจสอบการทำงานของเซิร์ฟเวอร์ของคุณได้ และในกรณีที่ไม่มีสัญญาณของชีวิต คุณจะแทนที่ที่อยู่ของเซิร์ฟเวอร์ที่ไม่ทำงานโดยอัตโนมัติด้วยที่อยู่สำรองในการตอบกลับ DNS

ในการสร้าง CDN เราจะใช้ CloudDNS, อัตราภาษี GeoDNS

มาเพิ่มโซน DNS ใหม่ในบัญชีส่วนตัวของคุณ โดยระบุโดเมนของคุณ หากเรากำลังสร้าง CDN บนโดเมนย่อยและมีการใช้งานโดเมนหลักอยู่แล้ว หลังจากเพิ่มโซนแล้ว อย่าลืมเพิ่มบันทึก DNS ที่ใช้งานได้ที่มีอยู่ทันที ขั้นตอนต่อไปคือการสร้าง A-record หลายรายการสำหรับโดเมน CDN / โดเมนย่อย ซึ่งแต่ละรายการจะถูกนำไปใช้กับภูมิภาคที่เราระบุ คุณสามารถระบุทวีปหรือประเทศเป็นภูมิภาคได้ โดยจะมีภูมิภาคย่อยสำหรับสหรัฐอเมริกาและแคนาดา

ในกรณีของเรา CDN จะถูกยกขึ้นในโดเมนย่อย cdn.sayt.in. โดยการเพิ่มโซน พูด.inสร้าง A-record แรกสำหรับโดเมนย่อยและชี้อเมริกาเหนือทั้งหมดไปยังเซิร์ฟเวอร์ในชิคาโก:

การสร้างและกำหนดค่า CDN ของคุณ
เรามาทำซ้ำการดำเนินการสำหรับภูมิภาคอื่นๆ โดยอย่าลืมสร้างหนึ่งรายการสำหรับภูมิภาคเริ่มต้น นี่คือสิ่งที่เกิดขึ้นในที่สุด:

การสร้างและกำหนดค่า CDN ของคุณ

รายการเริ่มต้นสุดท้ายในภาพหน้าจอหมายความว่าภูมิภาคที่ไม่ได้ระบุทั้งหมด (และได้แก่ ยุโรป แอฟริกา ผู้ใช้อินเทอร์เน็ตผ่านดาวเทียม ฯลฯ) จะถูกส่งไปยังเซิร์ฟเวอร์ในแฟรงก์เฟิร์ต

เสร็จสิ้นการตั้งค่า DNS พื้นฐาน ยังคงไปที่เว็บไซต์ของผู้รับจดทะเบียนโดเมนและแทนที่ NS โดเมนปัจจุบันด้วยที่ออกโดย ClouDNS และในขณะที่ NS จะได้รับการอัปเดต เราจะเตรียมเซิร์ฟเวอร์

การติดตั้งใบรับรอง SSL

CDN ของเราจะทำงานบน HTTPS ดังนั้นหากคุณมีใบรับรอง SSL สำหรับโดเมนหรือโดเมนย่อยอยู่แล้ว ให้อัปโหลดใบรับรองเหล่านั้นไปยังเซิร์ฟเวอร์ทั้งหมด เช่น ไปยังไดเร็กทอรี /etc/ssl/โดเมนของคุณ/

หากไม่มีใบรับรอง คุณสามารถรับใบรับรองได้ฟรีจาก Let's Encrypt เหมาะสำหรับสิ่งนี้ ACME เชลล์สคริปต์. ไคลเอนต์สะดวกและติดตั้งง่าย และที่สำคัญที่สุดคือช่วยให้คุณสามารถตรวจสอบโดเมน/โดเมนย่อยด้วย DNS ผ่าน ClouDNS API

เราจะติดตั้ง acme.sh บนเซิร์ฟเวอร์เดียวเท่านั้น - European 199.247.18.199 ซึ่งใบรับรองจะถูกคัดลอกไปยังเซิร์ฟเวอร์อื่นทั้งหมด หากต้องการติดตั้ง ให้รัน:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

ในระหว่างการติดตั้งสคริปต์ งาน CRON จะถูกสร้างขึ้นเพื่อการต่ออายุใบรับรองเพิ่มเติมโดยที่เราไม่ต้องมีส่วนร่วม

เมื่อออกใบรับรอง โดเมนจะถูกตรวจสอบโดยใช้ DNS โดยใช้ API ดังนั้นในบัญชีส่วนตัว ClouDNS ในเมนู Reseller API คุณจะต้องสร้าง API ผู้ใช้ใหม่และตั้งรหัสผ่าน auth-id ที่เป็นผลลัพธ์พร้อมรหัสผ่านจะถูกเขียนลงในไฟล์ ~/.acme.sh/dnsapi/dns_cloudns.sh (เพื่อไม่ให้สับสนกับไฟล์ dns_cloudDNS.SH). บรรทัดที่ต้องไม่ใส่ข้อคิดเห็นและแก้ไขมีดังนี้

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

ตอนนี้เราจะขอใบรับรอง SSL สำหรับ cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

ในตัวเลือกในอนาคต เราได้ระบุคำสั่งให้โหลดการกำหนดค่าเว็บเซิร์ฟเวอร์โดยอัตโนมัติหลังจากการต่ออายุใบรับรองแต่ละครั้งในอนาคต

กระบวนการทั้งหมดในการรับใบรับรองอาจใช้เวลาถึง 2 นาที อย่าขัดจังหวะ หากเกิดข้อผิดพลาดในการตรวจสอบความถูกต้องของโดเมน ให้ลองเรียกใช้คำสั่งอีกครั้ง ในตอนท้ายเราจะดูว่าใบรับรองถูกอัปโหลดไปที่ใด:

การสร้างและกำหนดค่า CDN ของคุณ

จำเส้นทางเหล่านี้ไว้ซึ่งจะต้องระบุเมื่อคัดลอกใบรับรองไปยังเซิร์ฟเวอร์อื่นรวมถึงในการตั้งค่าเว็บเซิร์ฟเวอร์ เราไม่ใส่ใจกับข้อผิดพลาดในการโหลดการกำหนดค่า Nginx ซ้ำ - มันจะไม่ได้อยู่บนเซิร์ฟเวอร์ที่กำหนดค่าอย่างสมบูรณ์เมื่ออัปเดตใบรับรอง

สิ่งที่เราเหลือสำหรับ SSL คือการคัดลอกใบรับรองที่ได้รับไปยังเซิร์ฟเวอร์อื่นอีกสองเครื่องในขณะที่ยังคงเส้นทางไปยังไฟล์ไว้ มาสร้างไดเร็กทอรีเดียวกันในแต่ละไดเร็กทอรีและทำสำเนา:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

หากต้องการอัปเดตใบรับรองเป็นประจำ ให้สร้างงาน CRON รายวันบนเซิร์ฟเวอร์ทั้งสองเครื่องด้วยคำสั่ง:

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

ในกรณีนี้ จะต้องกำหนดค่าการเข้าถึงเซิร์ฟเวอร์ต้นทางระยะไกล โดยที่สำคัญ, เช่น. โดยไม่ต้องใส่รหัสผ่าน อย่าลืมทำนะครับ

การติดตั้งและกำหนดค่า Nginx

เพื่อให้บริการเนื้อหาคงที่ เราจะใช้ Nginx ที่กำหนดค่าเป็นพร็อกซีเซิร์ฟเวอร์แคช อัพเดตรายการแพ็คเกจและติดตั้งบนเซิร์ฟเวอร์ทั้งสามเครื่อง:

root@cdn:~# apt update
root@cdn:~# apt install nginx

แทนที่จะเป็นค่าเริ่มต้น เราใช้การกำหนดค่าจากสปอยเลอร์ด้านล่าง:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

แก้ไขในการกำหนดค่า:

  • สูงสุด_ขนาด — ขนาดของแคช ไม่เกินพื้นที่ดิสก์ที่มีอยู่
  • ไม่ได้ใช้งาน - เวลาในการจัดเก็บข้อมูลแคชที่ไม่มีใครเข้าถึง
  • ssl_certificate и ssl_certificate_key — เส้นทางไปยังใบรับรอง SSL และไฟล์คีย์
  • proxy_cache_valid - เวลาในการจัดเก็บข้อมูลแคช
  • proxy_pass — ที่อยู่ของเซิร์ฟเวอร์ดั้งเดิมที่ CDN จะขอไฟล์สำหรับการแคช ในตัวอย่างของเรา สิ่งนี้ พูด.in

อย่างที่คุณเห็นทุกอย่างเรียบง่าย ความยากสามารถเกิดขึ้นได้เฉพาะในการตั้งเวลาแคชเท่านั้นเนื่องจากความคล้ายคลึงกันของคำสั่ง ไม่ได้ใช้งาน и proxy_cache_valid. มาวิเคราะห์ด้วยตัวอย่างของเรา นี่คือสิ่งที่เกิดขึ้นเมื่อ ไม่ใช้งาน=7วัน и proxy_cache_valid 90d:

  • หากไม่ส่งคำขอซ้ำภายใน 7 วัน ข้อมูลจะถูกลบออกจากแคชหลังจากช่วงเวลานี้
  • หากคำขอถูกทำซ้ำอย่างน้อยหนึ่งครั้งทุกๆ 7 วัน ข้อมูลในแคชจะถือว่าล้าสมัยหลังจาก 90 วัน และ Nginx จะอัปเดตด้วยคำขอถัดไป โดยนำมาจากเซิร์ฟเวอร์ดั้งเดิม

แก้ไขเสร็จแล้วครับ nginx.confให้โหลดการกำหนดค่าใหม่:

root@cdn:~# service nginx reload

CDN ของเราพร้อมแล้ว สำหรับ $15/เดือน เราได้รับจุดแสดงตนในสามทวีปและการรับส่งข้อมูล 3 TB: 1 TB ในแต่ละสถานที่

ตรวจสอบการทำงานของ CDN

มาดูการ Ping ไปยัง CDN ของเราจากที่ตั้งทางภูมิศาสตร์ต่างๆ บริการ ping ใดๆ ก็ตามจะได้ผลสำหรับสิ่งนี้

จุดเริ่มต้น
โฮสต์
IP
เวลาเฉลี่ย นางสาว

เยอรมนี เบอร์ลิน
cdn.sayt.in
199.247.18.199
9.6

เนเธอร์แลนด์ อัมสเตอร์ดัม
cdn.sayt.in
199.247.18.199
10.1

ฝรั่งเศส ปารีส
cdn.sayt.in
199.247.18.199
16.3

บริเตนใหญ่, ลอนดอน
cdn.sayt.in
199.247.18.199
14.9

แคนาดา,โตรอนโต
cdn.sayt.in
149.28.121.123
16.2

สหรัฐอเมริกา, ซานฟรานซิสโก
cdn.sayt.in
149.28.121.123
52.7

สหรัฐอเมริกา, ดัลลาส
cdn.sayt.in
149.28.121.123
23.1

สหรัฐอเมริกา, ชิคาโก
cdn.sayt.in
149.28.121.123
2.6

สหรัฐอเมริกานิวยอร์ก
cdn.sayt.in
149.28.121.123
19.8

สิงคโปร์
cdn.sayt.in
157.230.240.216
1.7

ญี่ปุ่น โตเกียว
cdn.sayt.in
157.230.240.216
74.8

ออสเตรเลีย, ซิดนีย์
cdn.sayt.in
157.230.240.216
95.9

ผลลัพธ์เป็นสิ่งที่ดี ตอนนี้เราจะวางรูปภาพทดสอบไว้ที่รูทของไซต์หลัก test.jpg และตรวจสอบความเร็วในการดาวน์โหลดผ่าน CDN ว่ากันว่า- ทำ. เนื้อหาถูกส่งอย่างรวดเร็ว

มาเขียนสคริปต์เล็กๆ กันเผื่อว่าเราต้องการล้างแคชที่จุด CDN
ล้าง.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

หากต้องการลบแคชทั้งหมด เพียงแค่เรียกใช้ สามารถล้างไฟล์แยกต่างหากได้ดังนี้:

root@cdn:~# ./purge.sh /test.jpg

แทนที่จะได้ข้อสรุป

สุดท้ายนี้ ฉันอยากจะให้คำแนะนำที่เป็นประโยชน์เพื่อที่จะก้าวข้ามคราดที่ทำให้ฉันรู้สึกปวดหัวในตอนนั้นทันที:

  • ในการเพิ่มความทนทานต่อข้อผิดพลาดของ CDN ขอแนะนำให้กำหนดค่า DNS Failover ซึ่งจะช่วยเปลี่ยนแปลงบันทึก A ได้อย่างรวดเร็วในกรณีที่เซิร์ฟเวอร์เสียหาย ซึ่งทำได้ในระเบียน DNS ของแผงควบคุมของโดเมน
  • ไม่ต้องสงสัยเลยว่าไซต์ที่มีความครอบคลุมทางภูมิศาสตร์ในวงกว้างจำเป็นต้องมี CDN จำนวนมาก แต่อย่าคลั่งไคล้ เป็นไปได้มากว่าผู้ใช้จะไม่สังเกตเห็นความแตกต่างที่มีนัยสำคัญเมื่อเทียบกับ CDN แบบชำระเงิน หากคุณวางเซิร์ฟเวอร์ไว้ในที่ตั้ง 6-7 แห่ง: ยุโรป อเมริกาเหนือ (ตะวันออก) อเมริกาเหนือ (ตะวันตก) สิงคโปร์ ออสเตรเลีย ฮ่องกง หรือญี่ปุ่น
  • บางครั้งโฮสต์ไม่อนุญาตให้ใช้เซิร์ฟเวอร์ที่เช่าเพื่อวัตถุประสงค์ CDN ดังนั้นหากคุณตัดสินใจปรับใช้เครือข่ายการจัดส่งเนื้อหาเป็นบริการอย่างกะทันหัน อย่าลืมอ่านกฎของผู้ให้บริการโฮสติ้งรายใดรายหนึ่งล่วงหน้า
  • สำรวจ แผนที่การสื่อสารใต้น้ำเพื่อแสดงถึงการเชื่อมต่อของทวีปต่างๆ และคำนึงถึงสิ่งนี้เมื่อสร้างเครือข่ายการจัดส่งเนื้อหา
  • ลองตรวจสอบดูนะครับ ปิงจากที่ต่างๆ ไปยังเซิร์ฟเวอร์ของคุณ วิธีนี้จะทำให้คุณเห็นภูมิภาคที่ใกล้กับจุด CDN มากที่สุด และกำหนดค่า GeoDNS ได้ถูกต้องมากขึ้น
  • จะมีประโยชน์ในการปรับแต่ง Nginx สำหรับข้อกำหนดแคชเฉพาะและคำนึงถึงภาระงานบนเซิร์ฟเวอร์ ทั้งนี้ขึ้นอยู่กับงาน บทความเกี่ยวกับแคช Nginx ช่วยฉันได้มากในเรื่องนี้ - ที่นี่ และความเร่งในการทำงานภายใต้ภาระหนัก: ที่นี่ и ที่นี่

ที่มา: will.com