Redis ir uzlabota atslēgas-vērtības datu bāze. Tas ir līdzīgs memcached, bet datus var saglabāt un datu veidi ir bagāti. Ir virknes, saistītie saraksti, kopas un sakārtotas kolekcijas. Tas atbalsta kolekciju summēšanas, krustošanās un papildināšanas (atšķirības) aprēķināšanu servera pusē, kā arī atbalsta dažādas šķirošanas funkcijas. Tātad Redis var uzskatīt arī par datu struktūras serveri.
Visi Redis dati tiek glabāti atmiņā un pēc tam laiku pa laikam tiek saglabāti diskā asinhroni (to sauc par "daļēji noturīgu režīmu"); Katru datu izmaiņu var ierakstīt tikai pievienošanas failā (AOF) (to sauc par "pilnas noturības režīmu").
Pirmā metode ir failu momentuzņēmums: noklusējuma redis saglabās datus diskā momentuzņēmuma veidā (binārais fails, dump.rdb, šo faila nosaukumu var norādīt), un konfigurācijas faila formāts ir: saglabāt N M nozīmē, ka N sekunžu laikā redis uzņems momentuzņēmumu diskā, ja vismaz M izmaiņas notiek redis. Protams, mēs varam arī manuāli veikt saglabāšanu vai bgsave (asinhronu), lai uzņemtu momentuzņēmumus.
Šeit ir īss ievads par to, kā tas darbojas: Kad Redis ir jāsaglabā, Redis dakšas bērna procesu; Bērna process ieraksta datus pagaidu RDB failā diskā; Kad apakšprocess pabeidz pagaidu faila rakstīšanu, tas aizstāj oriģinālo RDB, kam ir kopēšanas rakstīšanas priekšrocība
Ir arī noturības metode Addend-only:filesnapshotting metode Kad redis ir nenormāli miris, jaunākie dati tiks zaudēti (zaudēto datu apjoms ir atkarīgs no jūsu saglabāšanas politikas konfigurācijas), tāpēc tas ir tā lielākais trūkums, kad biznesa apjoms ir liels, zaudēto datu ir daudz. Tikai pievienošanas metode var sasniegt visus datu zudumus, bet redis veiktspēja ir sliktāka. AOF var saglabāt visā procesā, tas ir jāieslēdz tikai konfigurācijas failā (noklusējums ir nē), addendonly jā Pēc AOF iespējošanas, katru reizi, kad redis izpilda komandu, lai modificētu datus, tas tiks pievienots aof failam, un, kad redis tiek restartēts, AOF fails tiks nolasīts "replay", lai atjaunotu pēdējo brīdi pirms redis aizvēršanas.
LOG pārrakstīšana Tā kā AOF fails kļūst arvien lielāks, kad dati tiek modificēti, daudzi no tiem ieraksta izmaiņas atslēgā. Tāpēc redis ir interesanta iezīme: rekonstruējiet AOF failu fonā, neietekmējot klienta puses darbību. Izpildot BGREWRITEAOF komandu jebkurā laikā, disks ierakstīs īsāko komandu secību pašreizējā atmiņā, un šīs komandas var pilnībā izveidot pašreizējo datu situāciju bez nevajadzīgām izmaiņām (piemēram, stāvokļa izmaiņām, skaitītāja izmaiņām utt.), samazinot AOF faila lielumu. Tātad, lietojot OF, redis iesaka izmantot arī BGREWRITEAOF.
Ir trīs veidi, kā atsvaidzināt AOF failu, skatiet konfigurācijas parametru appendfsync: appendfsync vienmēr izsauc fsync, lai izskalotu AOF failu katru reizi, kad tiek iesniegta modifikācijas komanda, kas ir ļoti, ļoti lēna, bet arī ļoti droša; appendfsync everysec izsauc fsync katru sekundi, lai ātri izskalotu AOF failu, bet sekundes laikā var zaudēt datus; appendfsync nav atkarīgs no operētājsistēmas, lai atsvaidzinātu, redis aktīvi neatsvaidzina OV, kas ir ātrākais, bet drošība ir slikta. Atsvaidzināšana sekundē ir ieteicama pēc noklusējuma, lai tiktu ņemts vērā gan ātrums, gan drošība.
Tas var būt saistīts ar sistēmas iemesliem, ka AOF ir bojāts, redis vairs nevar ielādēt šo OF OV, varat veikt tālāk norādītās darbības, lai to labotu: Pirmkārt, izveidojiet AOF faila dublējumu un kopējiet to citā vietā; Labojiet oriģinālo OF failu, izpildiet: $redis-check-aof –fix; Varat izmantot komandu diff –u, lai redzētu, kur faili ir nekonsekventi pirms un pēc labošanas. Restartējiet Redis pakalpojumu.
Kā darbojas LOG Rewrite: Tas pats izmanto copy-on-write: vispirms redis dakšas bērna procesu; Bērna process ieraksta jaunāko AOF pagaidu failā; Vecāku process pakāpeniski raksta jaunākās izpildītās izmaiņas atmiņā (šobrīd vecais AOF joprojām ir rakstīts, un to ir droši pārrakstīt, ja tas neizdodas); Kad bērna process pabeidz pagaidu faila pārrakstīšanu, vecākprocess saņem signālu un ieraksta iepriekšējās pakāpeniskās izmaiņas atmiņā pagaidu faila beigās. Redis pārdēvē veco OF failu, pārdēvē pagaidu failu un sāk rakstīt jaunajā OF.
Visbeidzot, tikai gadījumam (mašīnas avārijas vai diska avārijas), atcerieties regulāri dublēt *rdb *.aof failu, kas ģenerēts, izmantojot failu momentuzņēmumu vai tikai pievienot attālajai mašīnai. Es izmantoju crontab, lai SCP ik pēc pusstundas. Es neizmantoju redis galveno vergu funkciju, jo pusstundas dublēšanai vajadzētu būt labi, un man šķiet, ka tas ir mazliet mašīnas izšķērdēšana, ja jums ir galvenais vergs. Tas galu galā ir atkarīgs no lietojumprogrammas.
|
Publicēts 24.08.2017 16:37:45
|
|
|
