Fejlesztés

  • Cikk

Csatlakozás ion rugalmassága és kiszolgálói terhelés

Az ügyfélalkalmazások fejlesztésekor mindenképpen vegye figyelembe a kapcsolat rugalmasságának és a kiszolgáló terhelésének kezelésére vonatkozó ajánlott eljárásokat.

Fontolja meg a további kulcsokat és kisebb értékeket

Az Azure Cache for Redis kisebb értékekkel működik a legjobban. Ha több kulcsra szeretné elosztani az adatokat, fontolja meg a nagyobb adattömbök kisebb adattömbökre való felosztását. Az ideális érték méretéről ebben a cikkben talál további információt.

Nagy kérelem- vagy válaszméret

A nagy kérések/válaszok időtúllépést okozhatnak. Tegyük fel például, hogy az ügyfélen konfigurált időtúllépési érték 1 másodperc. Az alkalmazás egyszerre két kulcsot (például "A" és "B") kér (ugyanazzal a fizikai hálózati kapcsolattal). A legtöbb ügyfél támogatja a kérések vonalazását, ahol a rendszer az "A" és a "B" kérést egymás után küldi el anélkül, hogy a válaszukra vár. A kiszolgáló ugyanabban a sorrendben küldi vissza a válaszokat. Ha az "A" válasz nagy, akkor a későbbi kérések időtúllépésének nagy részét el tudja felemlegetni.

Az alábbi példában a rendszer gyorsan elküldi az "A" és a "B" kérést a kiszolgálónak. A kiszolgáló gyorsan megkezdi az "A" és a "B" válaszok küldését. Az adatátviteli idők miatt a "B" válasznak várnia kell az "A" válasz mögött, még akkor is, ha a kiszolgáló gyorsan válaszolt.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Ezt a kérést/választ nehéz mérni. Az ügyfélkódot a nagy kérések és válaszok nyomon követésére is használhatja.

A nagy válaszméretek felbontása eltérő, de a következőket tartalmazza:

  • Optimalizálja az alkalmazást nagy számú kisebb értékre, nem pedig néhány nagy értékre.
  • A virtuális gép (VM) méretének növelése a nagyobb sávszélességű képességek eléréséhez
    • Az ügyfél- vagy kiszolgálói virtuális gép nagyobb sávszélessége csökkentheti a nagyobb válaszok adatátviteli idejét.
    • Hasonlítsa össze a két gép aktuális hálózati használatát az aktuális virtuálisgép-méret korlátaival. Előfordulhat, hogy a nagyobb sávszélesség csak a kiszolgálón vagy csak az ügyfélen nem elegendő.
  • Növelje az alkalmazás által használt kapcsolatobjektumok számát.
    • Ciklikus időszeleteléses módszerrel különböző kapcsolati objektumokon keresztüli kéréseket végezhet.

Kulcsterjesztés

Ha Redis-fürtözést tervez használni, először olvassa el a Redis-fürtözés ajánlott eljárásait kulcsokkal.

Csőhálózat használata

Próbáljon meg olyan Redis-ügyfelet választani, amely támogatja a Redis-csövek használatát. A csőhálózat-készítés segít a hálózat hatékony kihasználásában és a lehető legjobb átviteli sebesség eléréséhez.

Kerülje a költséges műveleteket

Néhány Redis-művelet, például a KEYS parancs, költséges, ezért el kell kerülni. A hosszú ideig futó parancsokkal kapcsolatos megfontolandó szempontokért tekintse meg a hosszú ideig futó parancsokat.

Válasszon egy megfelelő szintet

Az éles rendszerekhez standard, prémium, nagyvállalati vagy enterprise flash szinteket használhat. Ne használja az alapszintű szintet az éles környezetben. Az alapszintű szint egyetlen csomópontrendszer, amely nem rendelkezik adatreplikálással és SLA nélkül. Ezen kívül használjon legalább C1 szintű gyorsítótárat. A C0-gyorsítótárak csak egyszerű fejlesztési/tesztelési forgatókönyvekhez használhatók, mert:

  • processzormagot használnak
  • kevés memória használata
  • hajlamosak a zajos szomszédproblémákra

A teljesítménytesztelést javasoljuk a megfelelő szint kiválasztásához és a kapcsolati beállítások érvényesítéséhez. További információ: Teljesítménytesztelés.

Az ügyfél a gyorsítótárral azonos régióban van

Keresse meg a gyorsítótárpéldányt és az alkalmazást ugyanabban a régióban. Ha más régióban lévő gyorsítótárhoz csatlakozik, az jelentősen megnövelheti a késést, így a megoldás megbízhatósága is csökkenhet.

Bár az Azure-on kívülről is csatlakozhat, ez nem ajánlott, különösen akkor, ha a Redist gyorsítótárként használja. Ha a Redis-kiszolgálót csak kulcs-/értéktárként használja, előfordulhat, hogy nem a késés az elsődleges szempont.

A gazdagépnév nem nyilvános IP-cím alapján

A gyorsítótárhoz rendelt nyilvános IP-cím skálázási művelet vagy háttérbeli fejlesztés eredményeként változhat. Javasoljuk, hogy explicit nyilvános IP-cím helyett a gazdagépnevet használja. A különböző szintekhez az alábbi űrlapok ajánlottak:

Szint Űrlap
Alap, Normál, Prémium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Válasszon egy megfelelő Redis-verziót

A Gyorsítótár létrehozásakor használt Redis alapértelmezett verziója idővel változhat. Előfordulhat, hogy az Azure Cache for Redis új verziót vezet be a nyílt forráskódú Redis új verziójának megjelenésekor. Ha az alkalmazáshoz a Redis egy adott verziójára van szüksége, javasoljuk, hogy a gyorsítótár létrehozásakor kifejezetten válassza a Redis-verziót.

A vállalati szintekre vonatkozó konkrét útmutatás

Mivel az Enterprise és az Enterprise Flash szintek a Nyílt forráskódú Redis helyett a Redis Enterprise-ra épülnek, a fejlesztési ajánlott eljárások között van néhány különbség. További információ: Ajánlott eljárások a nagyvállalati és vállalati flashszintekhez.

TLS-titkosítás használata

Az Azure Cache for Redis alapértelmezés szerint TLS-alapú titkosított kommunikációt igényel. A TLS 1.0-s, 1.1-s és 1.2-s verziói jelenleg támogatottak. A TLS 1.0 és 1.1 azonban az egész iparágra kiterjedő elavulás útján halad, ezért ha lehetséges, használja a TLS 1.2-t.

Ha az ügyfélkódtár vagy -eszköz nem támogatja a TLS-t, akkor a titkosítatlan kapcsolatok engedélyezése az Azure Portalon vagy a felügyeleti API-kon keresztül lehetséges. Olyan esetekben, amikor a titkosított kapcsolatok nem lehetségesek, javasoljuk, hogy helyezze a gyorsítótárat és az ügyfélalkalmazást egy virtuális hálózatba. A virtuális hálózati gyorsítótár forgatókönyvében használt portokról ebben a táblázatban talál további információt.

Azure TLS-tanúsítvány módosítása

A Microsoft úgy frissíti az Azure-szolgáltatásokat, hogy tLS-kiszolgálói tanúsítványokat használjon más hitelesítésszolgáltatóktól (CA-któl). Ez a változás 2020. augusztus 13-tól 2020. október 26-ig (becsült) fázisokban kerül bevezetésre. Az Azure azért módosítja ezt a módosítást, mert a jelenlegi hitelesítésszolgáltatói tanúsítványok nem egyike a CA/Browser Forum alapkonfigurációjának. A problémát 2020. július 1-jén jelentették, és világszerte több népszerű nyilvános kulcsú infrastruktúra-szolgáltatóra (PKI) vonatkozik. Az Azure-szolgáltatások által ma használt TLS-tanúsítványok többsége a Baltimore CyberTrust Root PKI-ből származik. Az Azure Cache for Redis szolgáltatás továbbra is a Baltimore CyberTrust roothoz van láncolt. A TLS-kiszolgáló tanúsítványait azonban 2020. október 12-től új köztes hitelesítésszolgáltatók (ICA-k) bocsátják ki.

Feljegyzés

Ez a változás a nyilvános Azure-régiókban található szolgáltatásokra korlátozódik. Kizárja a szuverén (például Kína) vagy kormányzati felhőket.

Ez a változás hatással van rám?

A redis-hez készült Azure Cache-ügyfelek többségét nem érinti a változás. Az alkalmazás akkor lehet érintett, ha kifejezetten megadja az elfogadható tanúsítványok listáját, ezt a gyakorlatot tanúsítvány-rögzítésnek nevezzük. Ha a Baltimore CyberTrust Root helyett egy köztes vagy levéltanúsítványra van rögzítve, azonnal meg kell változtatnia a tanúsítványkonfigurációt.

Az Azure Cache for Redis nem támogatja az OCSP-hez való csatlakoztatást.

Az alábbi táblázat a hengerelt tanúsítványokra vonatkozó információkat tartalmazza. Az alkalmazás által használt tanúsítványtól függően előfordulhat, hogy frissítenie kell, hogy megakadályozza az Azure Cache for Redis-példányhoz való kapcsolódás megszakadását.

Hitelesítésszolgáltató típusa Aktuális Működés után (2020. október 12.) Művelet
Gyökér Ujjlenyomat: d4de20d05e66fc53fe1a50882c78db2852cae474

Lejárat: 2025. május 12. hétfő, 16:59:00

Tulajdonos neve:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Nem változik Egyik sem
Intermedierek Ujjlenyomatok:
CN = Microsoft IT TLS CA 1
Ujjlenyomat: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Ujjlenyomat: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Ujjlenyomat: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Ujjlenyomat: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Lejárat: 2024. május 20. péntek, 5:52:38

Tulajdonos neve:
Szervezeti egység = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = USA
 Ujjlenyomatok:
CN = Microsoft RSA TLS CA 01
Ujjlenyomat: 703d7a8f0ebf55aa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Ujjlenyomat: b0c2d2d13cdd56cdaa6ab6e2c0440be4a429c75

Lejárat: 2024. október 8. kedd, 12:00:00;

Tulajdonos neve:
O = Microsoft Corporation
C = USA
 Kötelező

Milyen műveleteket kell végrehajtanom?

Ha az alkalmazás az operációs rendszer tanúsítványtárolóját használja, vagy többek között kitűzi a Baltimore-gyökérkulcsot, nincs szükség műveletre.

Ha az alkalmazás rögzít egy köztes vagy levéles TLS-tanúsítványt, javasoljuk, hogy rögzítse a következő gyökereket:

Tanúsítvány Ujjlenyomat
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA főtanúsítvány-szolgáltató 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Tipp.

A köztes és a levéltanúsítványok is várhatóan gyakran változnak. Javasoljuk, hogy ne függjön tőlük. Ehelyett rögzítse az alkalmazást egy főtanúsítványra, mivel az ritkábban fordul elő.

A köztes tanúsítványok rögzítésének folytatásához adja hozzá a következőket a rögzített köztes tanúsítványok listájához, amely néhány továbbiat tartalmaz a jövőbeli módosítások minimalizálása érdekében:

A hitelesítésszolgáltató köznapi neve Ujjlenyomat
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaaaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c0440be4a429c75
Microsoft Azure TLS- kiállító CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
A Microsoft Azure TLS 02-es hitelesítésszolgáltatót bocsát ki e7eea674ca718e3befd90858e09f8372ad0ae2aa
A Microsoft Azure TLS 05-ös hitelesítésszolgáltatót bocsát ki 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
A Microsoft Azure TLS 06-os hitelesítésszolgáltatót bocsát ki 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Ha az alkalmazás kódban érvényesíti a tanúsítványt, módosítania kell, hogy felismerje a --- tulajdonságokat, például az újonnan rögzített tanúsítványok kiállítói, ujjlenyomati ---. Ennek a további ellenőrzésnek az összes rögzített tanúsítványra ki kell terjednie, hogy időtállóbb legyen.

Ügyféloldali kódtárra vonatkozó útmutató

További információ: Ügyfélkódtárak.

Következő lépések