Persediaan Temu Duga Pengaturcaraan · Pelajaran

Pencachean, CDN dan Pengimbangan Beban

Tambahkan lapisan pencachean Redis, hantar aset statik ke CDN, dan agihkan trafik merentas replika menggunakan pengimbang beban round-robin dan pencincangan konsisten.

Pelajaran 3 daripada 413 langkah

Pencachean, CDN dan Pengimbangan Beban ialah pelajaran Persediaan Temu Duga Pengaturcaraan percuma di CoddyKit. Ini ialah pelajaran 3 daripada 4. Anda boleh membaca keseluruhan pelajaran di bawah secara percuma — kemudian berlatih secara praktikal dalam pelayar menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Persediaan Temu Duga Pengaturcaraan, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Persediaan Temu Duga Pengaturcaraan merangkumi sejumlah 4 pelajaran.

Mengapa Cache Penting pada Skala Besar

Cache menyimpan salinan data yang kerap diakses dalam lapisan storan yang lebih pantas supaya permintaan seterusnya dapat dilayan tanpa mengakses stor sokongan yang lebih perlahan (pangkalan data, API luaran). Pada skala besar, sebilangan kecil item popular menerima sebahagian besar permintaan — peraturan 80/20 (prinsip Pareto) sering terpakai: 20% item menyumbang kepada 80% trafik.

Cache yang boleh memuatkan 20% data paling kerap diakses dalam memori boleh menampung 80% beban pangkalan data. Inilah sebabnya penambahan cache Redis sering mengurangkan penggunaan CPU pangkalan data sebanyak 70–90% dan mengurangkan kependaman p99 daripada 10ms kepada bawah 1ms untuk capaian cache — tanpa mengubah pangkalan data atau logik aplikasi dengan ketara.

# Demonstrating the 80/20 caching benefit
import random

# Simulate 1000 requests to 100 items with Zipf-like distribution
def zipf_sample(n_items, n_requests):
    access_counts = {}
    weights = [1.0 / (i + 1) for i in range(n_items)]  # Zipf: item 0 most popular
    total = sum(weights)
    probs = [w / total for w in weights]
    for _ in range(n_requests):
        item = random.choices(range(n_items), weights=probs)[0]
        access_counts[item] = access_counts.get(item, 0) + 1
    return access_counts

random.seed(42)
counts = zipf_sample(100, 10000)
top_20_items = sorted(counts, key=counts.get, reverse=True)[:20]
top_20_requests = sum(counts[i] for i in top_20_items)
print(f'Top 20% of items ({20} of 100) handle {top_20_requests/100:.1f}% of requests')

Corak Cache di Sisi Aplikasi (Pemuatan Malas)

Corak cache di sisi aplikasi (juga dipanggil pemuatan malas) ialah strategi cache yang paling lazim. Kod aplikasi bertanggungjawab mengurus cache: semasa bacaan, semak cache dahulu. Jika cache mempunyai data, kembalikan data itu serta-merta. Jika cache tidak mempunyai data, dapatkan data daripada pangkalan data, tulisnya ke cache, kemudian kembalikan data tersebut. Semasa penulisan, kemas kini pangkalan data dan batalkan kesahan (delete) entri cache supaya bacaan seterusnya memuatkannya semula.

Corak ini memastikan cache hanya menyimpan data yang benar-benar diminta (tiada pramuat yang tidak diperlukan) dan kekal konsisten dengan pangkalan data melalui pembatalan kesahan. Pertukarannya: capaian pertama selepas cache tidak mempunyai data perlu menanggung kos penuh pangkalan data (permulaan sejuk).

# Cache-aside pattern in Python
class CacheAsideService:
    def __init__(self, db, cache):
        self.db = db
        self.cache = cache   # e.g., Redis client

    def get_user(self, user_id):
        cache_key = f'user:{user_id}'
        # 1. Check cache
        cached = self.cache.get(cache_key)
        if cached:
            return cached    # cache hit
        # 2. Cache miss: fetch from DB
        user = self.db.query('SELECT * FROM users WHERE id=%s', user_id)
        # 3. Write to cache with TTL
        self.cache.set(cache_key, user, ttl=3600)  # 1 hour TTL
        return user

    def update_user(self, user_id, data):
        # 1. Write to DB
        self.db.execute('UPDATE users SET ... WHERE id=%s', user_id, data)
        # 2. Invalidate cache (delete, not update)
        self.cache.delete(f'user:{user_id}')
        # Next read will re-populate cache from DB

print('Cache-aside: READ from cache, miss? load from DB + write cache')
print('         WRITE to DB, then DELETE from cache (invalidate)')

Penggunaan Cache Tulis Terus dan Tulis Tertangguh

Tulis terus: pada setiap penulisan, kemas kini pangkalan data dan cache secara segerak. Cache sentiasa mengandungi data terkini. Pertukarannya: penulisan menjadi lebih perlahan (dua operasi), dan cache dipenuhi data yang mungkin tidak akan dibaca lagi.

Tulis tertangguh (tulis balik): semasa penulisan, kemas kini cache sahaja; pindahkan data ke pangkalan data secara tak segerak kemudian. Kaedah ini menjadikan penulisan sangat pantas tetapi berisiko kehilangan data jika cache gagal sebelum pemindahan berlaku. Kaedah ini digunakan untuk beban kerja yang berat pada penulisan dan apabila kehilangan sebahagian data boleh diterima (contohnya, kaunter paparan dan analitik).

# Write-through vs Write-behind comparison
strategies = {
    'Cache-aside (Lazy)': {
        'read':  'Check cache; miss => DB + populate cache',
        'write': 'Write DB; delete from cache (invalidate)',
        'consistency': 'Strong (invalidation ensures freshness)',
        'write_latency': 'Fast (one DB write)',
        'risk': 'Cache stampede on popular key expiry',
    },
    'Write-through': {
        'read':  'Always check cache; miss => DB',
        'write': 'Write DB AND cache atomically',
        'consistency': 'Strong (cache always has latest)',
        'write_latency': 'Slower (two writes per operation)',
        'risk': 'Cache polluted with rarely-read data',
    },
    'Write-behind': {
        'read':  'Check cache; miss => DB',
        'write': 'Write cache only; async flush to DB',
        'consistency': 'Eventual (flush may be delayed)',
        'write_latency': 'Very fast (cache write only)',
        'risk': 'Data loss if cache crashes before flush',
    },
}
for name, info in strategies.items():
    print(f'\n{name}:')
    for k, v in info.items(): print(f'  {k}: {v}')

Dasar Pengusiran Cache

Apabila cache penuh, dasar pengusiran menentukan entri yang perlu dikeluarkan. Dasar yang paling lazim:

  • LRU (Paling Lama Tidak Digunakan): keluarkan entri yang paling lama tidak diakses. Berfungsi dengan baik untuk beban kerja yang mempunyai lokaliti temporal. Digunakan oleh Redis secara lalai.
  • LFU (Paling Kurang Kerap Digunakan): keluarkan entri yang paling sedikit kali diakses. Lebih baik untuk beban kerja yang mempunyai sesetengah item yang sentiasa popular tetapi perkara ini tidak dapat dikenal pasti oleh LRU.
  • FIFO: keluarkan entri yang dimasukkan paling awal. Mudah tetapi berprestasi rendah untuk beban kerja web biasa.
  • Rawak: keluarkan entri secara rawak. Secara mengejutkan setanding dengan LRU dalam amalan untuk cache yang sangat besar.
# Implementing LRU cache
from collections import OrderedDict

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.cache = OrderedDict()  # maintains insertion/access order

    def get(self, key):
        if key not in self.cache:
            return -1
        self.cache.move_to_end(key)   # mark as recently used
        return self.cache[key]

    def put(self, key, value):
        if key in self.cache:
            self.cache.move_to_end(key)
        self.cache[key] = value
        if len(self.cache) > self.capacity:
            self.cache.popitem(last=False)   # evict LRU (oldest)

cache = LRUCache(3)
for k, v in [('a',1),('b',2),('c',3)]:
    cache.put(k, v)
print('Get a:', cache.get('a'))   # 1 (a now most recently used)
cache.put('d', 4)                  # evicts 'b' (LRU)
print('Get b:', cache.get('b'))   # -1 (evicted)
print('Get c:', cache.get('c'))   # 3

Rangkaian Penghantaran Kandungan (CDN)

CDN ialah rangkaian geografi teragih yang terdiri daripada pelayan pinggir (Titik Kehadiran, PoPs) yang menyimpan kandungan statik dan dinamik berdekatan dengan pengguna akhir. Daripada setiap permintaan pengguna merentasi perjalanan ke pelayan asal dalam satu pusat data, nod pinggir CDN menyampaikan kandungan daripada PoP terdekat — mengurangkan kependaman daripada ~200ms (merentas benua) kepada ~5ms (PoP berdekatan).

CDN penting untuk: aset statik (imej, CSS, JS), penstriman video (segmen HLS), serta semakin banyak respons antara muka pengaturcaraan aplikasi dan HTML yang dijana oleh pelayan. CDN menyemak tembolok pinggirnya; jika kandungan tiada dalam tembolok, CDN mengambilnya daripada pelayan asal dan menyimpannya untuk permintaan akan datang.

# CDN architecture flow
cdn_flow = [
    'User requests https://example.com/image.jpg',
    'DNS resolves to the nearest CDN PoP (e.g., Frankfurt for EU users)',
    'CDN edge checks its local cache:',
    '  HIT:  Return cached image directly (5ms latency)',
    '  MISS: Fetch from origin server (e.g., AWS S3 in us-east-1)',
    '        Cache image at edge with Cache-Control: max-age=86400',
    '        Future requests for this image served from edge (HIT)',
    'Cache-Control headers control CDN behaviour:',
    '  max-age=31536000 s-maxage=31536000  -- cache 1 year',
    '  no-cache                             -- always revalidate',
    '  private                              -- CDN must not cache (user-specific)',
]
for step in cdn_flow:
    print(step)

print('\nCDN providers: Cloudflare, AWS CloudFront, Fastly, Akamai')

Pengimbangan Beban: Pengagihan Trafik

Pengimbang beban mengagihkan permintaan masuk merentasi beberapa pelayan bahagian belakang, sekali gus menghalang mana-mana satu pelayan daripada menjadi titik kesesakan. Pengimbang beban juga menyediakan ketersediaan tinggi: jika satu pelayan gagal, pengimbang beban menghalakan trafik kepada pelayan yang sihat secara automatik (pemeriksaan kesihatan setiap 5-30 saat).

Pengimbang beban beroperasi pada lapisan OSI yang berbeza: Lapisan 4 (pengangkutan — menghalakan berdasarkan IP/nombor port, sangat pantas) dan Lapisan 7 (aplikasi — menghalakan berdasarkan laluan URL, pengepala, kuki, lalu membolehkan penghalaan yang lebih pintar). AWS ALB, Nginx dan HAProxy ialah pengimbang beban Lapisan 7 yang biasa digunakan. AWS NLB ialah pengimbang beban Lapisan 4.

# Load balancing algorithms
algorithms = {
    'Round Robin': {
        'how': 'Rotate through servers in sequence',
        'best_for': 'Stateless servers with similar capacity',
        'weakness': 'Does not account for server load or response time',
    },
    'Weighted Round Robin': {
        'how': 'Round robin but servers with more capacity get more requests',
        'best_for': 'Heterogeneous server fleet',
        'weakness': 'Static weights; does not adapt to runtime load',
    },
    'Least Connections': {
        'how': 'Send to server with fewest active connections',
        'best_for': 'Long-lived connections (WebSocket, streaming)',
        'weakness': 'More complex tracking of connection state',
    },
    'Consistent Hashing': {
        'how': 'Hash request key (user_id, session) to server',
        'best_for': 'Sticky sessions, cache locality per server',
        'weakness': 'Uneven distribution if hash space is not balanced',
    },
    'Random': {
        'how': 'Choose server at random',
        'best_for': 'Simple stateless workloads',
        'weakness': 'No guarantee of load balance in short windows',
    },
}
for alg, info in algorithms.items():
    print(f'{alg}: {info["how"]}')

Pencincangan Konsisten: Menambah dan Mengalih Keluar Nod

Pencincangan konsisten menyelesaikan masalah pengagihan semula kunci tembolok apabila pelayan ditambah atau dialih keluar. Dalam pencincangan modulo naif (server = hash(key) % n), perubahan pada n memetakan semula hampir semua kunci — lalu menyebabkan serbuan stampede pada tembolok. Pencincangan konsisten memetakan kedua-dua kunci dan pelayan ke dalam satu gelang; setiap kunci disampaikan oleh pelayan terdekat mengikut arah jam. Penambahan satu pelayan hanya memetakan semula kunci antara pelayan baharu dengan pendahulunya — kira-kira 1/n daripada semua kunci.

Nod maya meningkatkan pengagihan beban: setiap pelayan fizikal diberikan beberapa kedudukan pada gelang, supaya kunci tersebar dengan lebih sekata walaupun bilangan pelayan kecil.

import hashlib
import bisect

class ConsistentHashRing:
    def __init__(self, replicas=100):
        self.replicas = replicas      # virtual nodes per server
        self.ring = {}
        self.sorted_keys = []

    def add_server(self, server):
        for i in range(self.replicas):
            key = int(hashlib.md5(f'{server}:{i}'.encode()).hexdigest(), 16)
            self.ring[key] = server
            bisect.insort(self.sorted_keys, key)

    def remove_server(self, server):
        for i in range(self.replicas):
            key = int(hashlib.md5(f'{server}:{i}'.encode()).hexdigest(), 16)
            del self.ring[key]
            self.sorted_keys.remove(key)

    def get_server(self, item):
        key = int(hashlib.md5(item.encode()).hexdigest(), 16)
        idx = bisect.bisect(self.sorted_keys, key) % len(self.sorted_keys)
        return self.ring[self.sorted_keys[idx]]

ring = ConsistentHashRing()
for s in ['server-1', 'server-2', 'server-3']:
    ring.add_server(s)
for item in ['user:1', 'user:2', 'product:abc', 'session:xyz']:
    print(f'{item} => {ring.get_server(item)}')

Serbuan stampede pada Tembolok dan Penyelesaian

Serbuan stampede pada tembolok (atau gerombolan yang menggemparkan) berlaku apabila entri tembolok yang popular luput dan banyak permintaan serentak gagal menemui kandungan dalam tembolok pada masa yang sama, lalu membanjiri pangkalan data dengan pertanyaan yang sama. Penyelesaian:

  • Kunci saling eksklusif: hanya satu permintaan mengira nilai tersebut; permintaan lain menunggu
  • Pelupusan awal secara kebarangkalian: sedikit sebelum TTL, satu permintaan memilih secara rawak untuk menyegarkan tembolok, sekali gus menghalang pelupusan serentak
  • Sajian lama sambil pengesahan semula: sajikan kandungan lama dengan serta-merta sambil menyegarkan tembolok secara tak segerak
  • Penyegaran latar belakang: proses berasingan menyegarkan kunci popular sebelum kunci tersebut luput
import time, threading, random

# Probabilistic early expiry (XFetch algorithm)
class ProbabilisticCache:
    def __init__(self):
        self._cache = {}

    def get(self, key, ttl, recompute_fn, beta=1.0):
        if key in self._cache:
            value, expiry, delta = self._cache[key]
            # XFetch: decide to refresh early with probability proportional to delta/TTL
            remaining = expiry - time.time()
            if remaining > 0:
                early_refresh_score = delta * beta * (-1) * (remaining / ttl)
                if random.random() > (1 - early_refresh_score):  # simplified
                    pass  # could trigger async refresh here
                return value
        # Cache miss or expired
        start = time.time()
        value = recompute_fn()
        delta = time.time() - start          # computation time
        expiry = time.time() + ttl
        self._cache[key] = (value, expiry, delta)
        return value

print('XFetch: refresh probabilistically before expiry based on computation cost')
print('High-cost computations => refresh earlier to avoid stampede')
print('Low-cost computations => refresh closer to TTL')

Pembatalan Tembolok CDN

Pembatalan tembolok terkenal sukar: 'Hanya terdapat dua masalah sukar dalam sains komputer: pembatalan tembolok dan penamaan sesuatu.' Apabila kandungan berubah pada pelayan asal, nod pinggir CDN mesti menyampaikan versi baharu. Strategi:

  • Pelupusan berdasarkan TTL: biarkan kandungan luput secara semula jadi (mudah tetapi mempunyai tempoh kandungan lama)
  • Penerapan versi pada alamat: benamkan cincangan kandungan dalam alamat (contohnya, main.a3f2b.js); kandungan baharu = alamat baharu, jadi pembatalan tidak diperlukan
  • Pembersihan CDN: bersihkan alamat secara eksplisit melalui panggilan antara muka selepas penggunaan (pantas tetapi memerlukan penyepaduan antara muka CDN)
# Cache invalidation strategies for CDN/browser
strategies = [
    {
        'name': 'Long TTL + URL versioning (best for static assets)',
        'example': '<script src="/app.a3f2b1c.js"></script>',
        'ttl': 'Cache-Control: max-age=31536000 (1 year)',
        'how': 'Content hash in filename; new deploy = new URL; old URL cached forever (OK)',
    },
    {
        'name': 'Short TTL (for frequently changing content)',
        'example': '/api/v1/config',
        'ttl': 'Cache-Control: max-age=60 (1 minute)',
        'how': 'Simple; content is at most 60s stale; no invalidation needed',
    },
    {
        'name': 'CDN API purge (for news / social media)',
        'example': '/news/breaking-story.html',
        'ttl': 'Cache-Control: s-maxage=3600',
        'how': 'On publish, call CDN.purge(url); edge serves new version immediately',
    },
]
for s in strategies:
    print(f'{s["name"]}:')
    print(f'  Example: {s["example"]}')
    print(f'  TTL: {s["ttl"]}')
    print(f'  Strategy: {s["how"]}\n')

Seni Bina: Menggabungkan Kesemuanya

Lapisan aplikasi web yang diskalakan sepenuhnya menggunakan ketiga-tiga teknik bersama-sama: pengimbangan beban mengagihkan trafik, CDN menyerap permintaan aset statik dan permintaan antara muka pengaturcaraan aplikasi yang boleh ditembolokkan, manakala Redis menyimpan data dinamik dalam tembolok. Pangkalan data hanya menerima permintaan yang tidak ditemui dalam tembolok — biasanya 5-20% daripada semua permintaan.

Aliran permintaan biasa untuk antara muka pengaturcaraan aplikasi yang banyak membaca: pengguna → DNS → pinggir CDN (kandungan ditemui dalam tembolok: disampaikan serta-merta) → kandungan tiada dalam tembolok CDN → pengimbang beban → kumpulan pelayan aplikasi → tembolok Redis (kandungan ditemui: respons 1ms) → kandungan tiada dalam tembolok Redis → pangkalan data (10-50ms) → respons disimpan dalam tembolok Redis + CDN pilihan → pengguna. Setiap lapisan mengurangkan beban pangkalan data dengan ketara.

# Request flow with cache hit rates
request_flow = [
    ('Browser Cache',       '10%',  '0ms',   'Browser caches GET responses per Cache-Control'),
    ('CDN Edge Cache',      '60%',  '5ms',   'CloudFront/Fastly caches cacheable API responses'),
    ('Load Balancer',        None,  '1ms',   'Routes to healthy app server replica'),
    ('App Server',           None,  '2ms',   'Business logic, auth check'),
    ('Redis Cache',         '25%',  '1ms',   'Caches computed data, hot DB rows'),
    ('Database Read Replica','5%',  '10ms',  'Cache miss: query read replica'),
    ('Database Primary',    '0.1%', '15ms',  'Cache+replica miss: query primary (rare for reads)'),
]
print(f'{'Layer':30s} {'Hit Rate':10s} {'Latency':10s} {'Notes'}')
print('-'*80)
for layer, hit_rate, latency, note in request_flow:
    hr = hit_rate if hit_rate else '-'
    print(f'{layer:30s} {hr:10s} {latency:10s} {note}')
print('\nResult: DB sees ~5% of requests; Redis sees ~25%; CDN absorbs 60%; browser 10%')

Petua Temu Duga: Penembolokan dan Pengimbangan Beban

Apabila membincangkan penembolokan dalam temu duga reka bentuk sistem, sentiasa jelaskan: perkara yang perlu ditembolokkan (data popular, pengiraan yang mahal), tempat untuk menembolokkan (pelayar, CDN, aplikasi, tembolok pertanyaan pangkalan data), masa untuk membatalkan tembolok (semasa penulisan, apabila TTL luput, atau melalui penyegaran latar belakang), dan jaminan ketekalan yang boleh diterima. Tembolok mewujudkan tempoh ketidakselarasan — nyatakan perkara ini dengan jelas.

Untuk pengimbangan beban, nyatakan pilihan algoritma, pemeriksaan kesihatan, sesi melekat (jika diperlukan), serta sama ada penskalaan mendatar pelayan aplikasi tanpa keadaan boleh dilakukan. Jika aplikasi mempunyai keadaan (sambungan WebSocket, sesi), jelaskan cara keadaan itu diuruskan merentasi replika.

# Caching design questions checklist
cache_checklist = [
    'What data to cache? (read-heavy, expensive to compute, rarely updated)',
    'Cache layer: client-side / CDN / app-level / DB query cache?',
    'Cache invalidation strategy: TTL / event-driven / write-through?',
    'Eviction policy: LRU / LFU?',
    'Cache key design: ensure uniqueness, avoid hotspots',
    'Consistency window: acceptable staleness in seconds?',
    'Cache stampede prevention: mutex / stale-while-revalidate?',
    'Cache capacity: how much RAM needed for hot set?',
]
lb_checklist = [
    'Layer 4 vs Layer 7: routing by IP or by URL/headers?',
    'Algorithm: round robin / least-connections / consistent hashing?',
    'Health checks: interval, failure threshold, recovery',
    'Session stickiness: needed? Use cookie-based affinity or external session store',
    'Auto-scaling: scale out when CPU > 70%; scale in when < 30%',
]
print('Cache checklist:')
for item in cache_checklist: print(f'  [ ] {item}')
print('\nLoad balancer checklist:')
for item in lb_checklist: print(f'  [ ] {item}')

Semakan Pantas

Uji pemahaman anda tentang konsep Struktur Data & Algoritma — Persediaan Temu Duga Pengekodan daripada pelajaran ini.

Imbas Kembali Pelajaran

Dalam pelajaran ini, anda mempelajari bahawa: penembolokan menyimpan data popular dalam lapisan memori pantas (Redis, CDN) untuk menyerap sebahagian besar bacaan dan mengurangkan beban pangkalan data, pola tembolok-sampingan ialah pola yang paling lazim — kandungan tiada dalam tembolok bermaksud memuatkan daripada pangkalan data, kandungan ditemui bermaksud memulangkan dengan serta-merta, manakala penulisan bermaksud memadam daripada tembolok, dan pencincangan konsisten mengagihkan kunci tembolok merentasi nod supaya penambahan atau pengalihan keluar nod hanya memetakan semula ~1/n kunci dan bukannya memetakan semula segala-galanya. Seterusnya, kita mereka bentuk pengehad kadar dan suapan Twitter untuk menerapkan semua konsep reka bentuk sistem dalam masalah menyeluruh.

Percuma untuk bermula

Pelajari Persediaan Temu Duga Pengaturcaraan dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus
90
Pelajaran
360

Soalan Lazim

Adakah pelajaran “Pencachean, CDN dan Pengimbangan Beban” percuma?

Ya — teks penuh “Pencachean, CDN dan Pengimbangan Beban” boleh dibaca secara percuma di web ini. Untuk berlatih secara interaktif menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7, serta membuka kunci baki kursus Persediaan Temu Duga Pengaturcaraan, tingkat taraf kepada CoddyKit PRO. Kursus Persediaan Temu Duga Pengaturcaraan merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Pencachean, CDN dan Pengimbangan Beban”?

Tambahkan lapisan pencachean Redis, hantar aset statik ke CDN, dan agihkan trafik merentas replika menggunakan pengimbang beban round-robin dan pencincangan konsisten. Anda berlatih Persediaan Temu Duga Pengaturcaraan menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Persediaan Temu Duga Pengaturcaraan?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Persediaan Temu Duga Pengaturcaraan di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 3 daripada 4.

Berapa lamakah pelajaran “Pencachean, CDN dan Pengimbangan Beban” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Persediaan Temu Duga Pengaturcaraan ini?

Ya. Setiap pelajaran Persediaan Temu Duga Pengaturcaraan menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

  1. Rangka Kerja Temu Duga Reka Bentuk Sistem
  2. Penyimpanan Data Boleh Skala: SQL berbanding NoSQL
  3. Pencachean, CDN dan Pengimbangan Beban
  4. Reka Bentuk Pembatas Kadar dan Reka Bentuk Suapan Twitter
← Kembali ke Persediaan Temu Duga Pengaturcaraan