每一次操作之前都會(huì)記錄日志，防止中斷造成數(shù)據(jù)丟失。操作如下：A 記錄日志B redis 計(jì)數(shù)+1C 清除日志1、如果執(zhí)行完A中斷，啟動(dòng)之后檢查日志，可以再次執(zhí)行操作B，數(shù)據(jù)不丟失。2、如果執(zhí)行完b就中斷，那么日志恢復(fù)之后就會(huì)多執(zhí)行一次b，數(shù)據(jù)雖然不丟失，但是造成重復(fù)數(shù)據(jù)。題目原本是斷電，后來(lái)可能都圍繞斷電回答了，其實(shí)斷電概率還是挺小的，主要是應(yīng)用執(zhí)行的時(shí)候突然被用戶終止運(yùn)行，或者程序崩潰等等造成的數(shù)據(jù)丟失?？丛u(píng)論還有人抬扛的。實(shí)際上，很多數(shù)據(jù)庫(kù)都有類似的機(jī)制防止突然中止造成數(shù)據(jù)丟失。。1、比如 leveldb ：log文件在LevelDb中的主要作用是系統(tǒng)故障恢復(fù)時(shí)，能夠保證不會(huì)丟失數(shù)據(jù)。因?yàn)樵趯⒂涗泴?xiě)入內(nèi)存的Memtable之前，會(huì)先寫(xiě)入Log文件，這樣即使系統(tǒng)發(fā)生故障，Memtable中的數(shù)據(jù)沒(méi)有來(lái)得及Dump到磁盤(pán)的SSTable文件，LevelDB也可以根據(jù)log文件恢復(fù)內(nèi)存的Memtable數(shù)據(jù)結(jié)構(gòu)內(nèi)容，不會(huì)造成系統(tǒng)丟失數(shù)據(jù)，在這點(diǎn)上LevelDb和Bigtable是一致的。相關(guān)文章：https://www.cnblogs.com/haipp...2、還有elasticsearch：如果沒(méi)有用 fsync 把數(shù)據(jù)從文件系統(tǒng)緩存刷（flush）到硬盤(pán)，我們不能保證數(shù)據(jù)在斷電甚至是程序正常退出之后依然存在。為了保證 Elasticsearch 的可靠性，需要確保數(shù)據(jù)變化被持久化到磁盤(pán)。相關(guān)文章：https://www.elastic.co/guide/...3、還有rabbitmq的防止丟消息和重復(fù)消費(fèi)：相關(guān)文章：https://www.jianshu.com/p/5ad...