|
|
Redis windows 64 bit download, ametlik allalaadimise aadress
h ttps:// www.itsvse.com/thread-2576-1-1.html
Kolm võimalust Redise käivitamiseks
h ttps:// www.itsvse.com/thread-4008-1-1.html
Erinevus redis'is salvestamise ja bgsave vahel
h ttps:// www.itsvse.com/thread-4010-1-1.html
Redis 5.0.3 CentOS 7 õpetus
h ttps:// www.itsvse.com/thread-7201-1-1.html
1, eessõna
Hiljuti kasutati Redis't vahemäluna ühes projektis, et hõlbustada andmete jagamist mitme äriprotsessi vahel. Kuna Redise andmed on salvestatud mällu, siis kui te ei konfigureeri püsivust, siis andmed kaovad pärast redise taaskäivitamist, seega tuleb sisse lülitada redise püsivuse funktsioon, et salvestada andmed kettale, kui redis taaskäivitub, siis saate andmed taastada kettalt. redis pakub kahte võimalust püsivuse tegemiseks, üks on RDB püsivus (põhimõte on Reids in the RDB persistence (põhimõte on dumpida mälus olevad andmebaasi kirjed Reidide kettale korrapäraste ajavahemike järel) ja teine on AOF persistence (põhimõte on kirjutada Reidide operatsioonilogid faili appendina). Milline on siis nende kahe püsivusmeetodi vahe, kuidas valida? Enamik online pilk on tutvustada kahte võimalust, kuidas konfigureerida, kuidas kasutada, ei ole sissejuhatus erinevus nende kahe vahel, milliseid rakendusskeene kasutada.
2, erinevus nende kahe vahel
RDB püsivus viitab määratud ajaintervall on mälu hetkeseade andmekogumi kirjutatud kettale, tegelik operatsiooniprotsess on kahvel alamprotsessi, kõigepealt kirjutada andmekogumi ajutise faili, kirjutada edukas, ja seejärel asendada eelmise faili binaarne kokkusurutud ladustamise.
AOF püsivus logide kujul, et salvestada iga serveri poolt käsitletud kirjutamis- ja kustutamisoperatsioon, päringuoperatsioone ei salvestata, salvestatakse tekstina, saate faili avada, et näha üksikasjalikke operatsioonide kirjeid.
3、Kahe eelised ja puudused
Millised on RDB eelised?
1). Kui see lähenemisviis on kasutusele võetud, siis kogu teie Redise andmebaas sisaldab ainult ühte faili, mis sobib ideaalselt failide varundamiseks. Näiteks võite kavatseda arhiveerida viimase 24 tunni andmed kord tunnis ja samuti arhiveerida viimase 30 päeva andmed kord päevas. Sellise varundamisstrateegiaga saame katastroofilise süsteemirikke korral väga lihtsalt taastuda.
2). Katastroofide taastamiseks on RDB väga hea valik. Sest me saame väga lihtsalt ühe faili kokku suruda ja seejärel kanda selle teisele andmekandjale.
3). Maksimaalne jõudlus. Redise teenusprotsessi puhul on püsivusprotsessi käivitamisel ainus asi, mida ta peab tegema, on lapselise protsessi forkistamine ja seejärel lõpetab lapseline protsess püsivusprotsessi töö, mis võib suuresti vältida teenusprotsessi IO-operatsioonide sooritamist.
4). Võrreldes AOF-mehhanismiga käivitub RDB tõhusamalt, kui andmekogum on suur.
Millised on RDB puudused?
1). Kui soovite tagada andmete kõrget kättesaadavust, st vähendada andmekaotust, siis ei ole RDB hea valik. Selle põhjuseks on see, et kui süsteem langeb enne ajastatud püsivust, lähevad kaduma kõik andmed, mida ei ole eelnevalt olnud aega kettale kirjutada.
2). Kuna RDB abistab andmete püsivust alamprotsesside hargnemisega, võib see põhjustada kogu serveri tööseisakut sadade millisekundite või isegi 1 sekundi jooksul, kui ja kui andmekogum on suur.
Millised on AOF-i eelised?
1). See mehhanism toob kaasa suurema andmeturbe, st andmete püsivuse. 3 sünkroonimisstrateegiat on Redis'is olemas, st sünkroonimine sekundis, sünkroonimine muutmise kohta ja sünkroonimata jätmine. Tegelikult toimub ka sekundipõhine sünkroniseerimine asünkroonselt ja selle tõhusus on samuti väga kõrge, erinevus seisneb selles, et kui süsteem on alla käinud, siis lähevad selle sekundi jooksul muudetud andmed kaduma. Teisalt võib muutuste kaupa sünkroonimist pidada sünkroonseks püsivuseks, st iga kord, kui andmed muutuvad, salvestatakse need kohe kettale. See lähenemisviis on ootuspäraselt kõige ebatõhusam tõhususe seisukohalt. Mis puutub mittesünkroniseeritud, siis ei ole vaja rohkem öelda, ma arvan, et me kõik saame sellest korralikult aru.
2). Kuna see mehhanism kasutab logifaili kirjutamiseks append-režiimi, siis isegi kui kirjutamise ajal tekib seisak, ei hävita see logifailis juba olemasolevat sisu. Kui me aga kirjutame selle operatsiooni käigus ainult pool andmetest ja seejärel tekib süsteemi kokkuvarisemise probleem, siis ärge muretsege, enne Redise järgmist käivitamist saame kasutada redis-check-aof tööriista, mis aitab meil lahendada andmete järjepidevuse probleemi.
3). Kui logi on liiga suur, võib Redis automaatselt aktiveerida ümberkirjutamismehhanismi. See tähendab, et Redis kirjutab muudetud andmed pidevalt append-režiimis vanasse kettafaili ja samal ajal loob Redis uue faili, et registreerida, milliseid muudetud käske on vahepeal täidetud. Seetõttu saab ümberkirjutamise ajal paremini tagada andmete turvalisuse.
4). AOF sisaldab selgelt vormistatud, kergesti arusaadavat logifaili, mis salvestab kõik muudatused. Tegelikult saame seda faili kasutada ka andmete rekonstrueerimise lõpuleviimiseks.
Millised on AOF-i puudused?
1). AOF-failid on tavaliselt suuremad kui RDB-failid sama arvu andmekogumite puhul. RDB suudab suuri andmekogumeid kiiremini taastada kui AOF.
2). Sõltuvalt sünkroniseerimisstrateegiast kipub AOF töötama aeglasemalt kui RDB. lühidalt öeldes on sünkroonimisstrateegia tõhusam ja sünkroonimise väljalülitamise strateegia sama tõhus kui RDB.
Nende kahe vahel valiku tegemise kriteeriumiks on see, kas süsteem on valmis ohverdama mõningast jõudlust suurema vahemälu järjepidevuse nimel (AOF) või kas ta on valmis kirjutama operatsioone sageli, ei võimalda suurema jõudluse nimel varukoopiaid, mida tuleb käivitada käsitsi, kui on aeg salvestada, ja seejärel teha varukoopiaid (RDB). rdb see on lõpuks järjepidevam tähenduses. Tootmiskeskkond on aga tegelikult pigem nende kahe kombinatsioon.
4, tavaliselt kasutatav konfiguratsioon
RDB püsivuse konfiguratsioon
Redis teeb andmehulga hetkeseisu dump'i dump.rdb faili. Lisaks saame ka muuta Redis server dump snapshotide sagedust läbi konfiguratsioonifaili, pärast 6379.conf faili avamist otsime salvestada, näete järgmist konfiguratsiooniteavet:
AOF püsivuse konfiguratsioon
Redise konfiguratsioonifailis on kolm sünkroniseerimise tüüpi, need on järgmised:
Täielik konfiguratsioon:
Testkataloogi alla luuakse uus fail "appendonly.aof" järgmiselt:
|
Paari: datatables tabeli eksport excel, csv ja printidaJärgmine artikkel: SQL Server määrata tehingu isolatsioonitase
|
发表于 2021-2-4 13:47:27
l 
发表于 2021-9-22 20:26:16