lru機制和持久化機制的區(qū)別？R:?；跀?shù)據(jù)日志操作的AOF(增量):是持久的。在打開模式下，app: AOF的三種同步方法Appendfsync總是在每次有數(shù)據(jù)修改時寫入AOF文件，這樣可以防止數(shù)據(jù)

lru機制和持久化機制的區(qū)別？

R:。

基于數(shù)據(jù)日志操作的AOF(增量):是持久的。在打開模式下，app: AOF的三種同步方法

Appendfsync總是在每次有數(shù)據(jù)修改時寫入AOF文件，這樣可以防止數(shù)據(jù)丟失，但是效率很低。比如1S里有1S1000個請求，效率會很低。

Appendfsync everysec每秒同步一次，這是AOF的默認(rèn)策略(缺點::可能會在1秒內(nèi)丟失數(shù)據(jù))。

Appendfsync no永遠(yuǎn)不會同步和高效，但是數(shù)據(jù)不會持久化。

建議善用everysec，既能保證數(shù)據(jù)同步，又能高效。

RDB(默認(rèn)情況下，全尺寸):采用定時持久化機制，但是服務(wù)器可能會因為某種原因宕機而丟失數(shù)據(jù)。

完全同步和增量同步:之間的區(qū)別

全:就是每天定時(避開高峰期)或者周期性的把數(shù)據(jù)拷貝到另一個地方。頻率不是很高，但可能會造成數(shù)據(jù)丟失。

增量:增量同步使用行為操作來同步數(shù)據(jù)，頻率非常高，對服務(wù)器同步的壓力非常大，可以保證數(shù)據(jù)不丟失。

redis為什么把數(shù)據(jù)放到內(nèi)存中？

為了快一點。Redis是單線程架構(gòu)，采用I/O復(fù)用的事件模型。單線程架構(gòu)避免了頻繁的上下文切換，但問題是如果一個操作很慢，就會導(dǎo)致?lián)砣?。?nèi)存和硬盤的讀寫速度不是一個數(shù)量級的，可以為redis提供更快的讀寫速度，保證redis的高性能。