我們有很多的手段保證數(shù)據(jù)的安全，但是要保證100%安全這是不可能的。畢竟在系統(tǒng)運(yùn)行的過程中，服務(wù)器可以出的問題千奇百怪，只能說盡可能的讓數(shù)據(jù)盡可能的出出現(xiàn)丟失。
單純的保證數(shù)據(jù)庫本身的數(shù)據(jù)不丟失的話，最直接的方式就是通過建立主從庫，實(shí)現(xiàn)數(shù)據(jù)的熱備
一般情況下，小的系統(tǒng)我們并不會考慮數(shù)據(jù)的熱備，一般只是在每天定時(shí)進(jìn)行冷備而已，也就是設(shè)置一個(gè)定時(shí)器，然后到時(shí)間就同步數(shù)據(jù)。不過這樣做的話，一單系統(tǒng)的數(shù)據(jù)庫出現(xiàn)異常，那么我們的數(shù)據(jù)就會回滾到上一個(gè)備份的時(shí)間點(diǎn)，影響范圍就會比較大。
因此，對于數(shù)據(jù)量大一點(diǎn)的系統(tǒng)，我們就會進(jìn)行主從庫的設(shè)置，不過通常情況下，我們做了主從庫都會做讀寫分離。
現(xiàn)在不管是哪種數(shù)據(jù)庫，都提供了數(shù)據(jù)庫之間訂閱同步的機(jī)制。以Mysql為例，我們先設(shè)置一個(gè)Master主庫，然后在基于這個(gè)主庫設(shè)置1個(gè)到多個(gè)Salve從主，從庫通過在主庫的SQLLog日志進(jìn)行監(jiān)聽，一旦有SQL執(zhí)行，就會記錄一個(gè)二進(jìn)制的Log，從庫發(fā)現(xiàn)了這個(gè)Log，也會同時(shí)執(zhí)行同樣的操作，這樣就實(shí)現(xiàn)了數(shù)據(jù)的熱備。
但是，這種熱備的機(jī)制并不能100%保證數(shù)據(jù)不丟失。因?yàn)?，我們在寫入主庫的時(shí)候如果出現(xiàn)異常，導(dǎo)致SQLLog還沒有記錄，那么從庫是不可能有數(shù)據(jù)記錄的。當(dāng)然，此后的數(shù)據(jù)不會有影響，因?yàn)檫@是從庫會變?yōu)橹鲙靵碛涗浐罄m(xù)數(shù)據(jù)。同樣，如果主從庫一起宕機(jī)，那也只有涼涼。
那么，為了讓數(shù)據(jù)庫的數(shù)據(jù)更加安全，就需要把數(shù)據(jù)保證的機(jī)制提前，不能單純的依靠數(shù)據(jù)庫來實(shí)現(xiàn)，那么我們可以加入隊(duì)列來試試。
隊(duì)列并不是針對于數(shù)據(jù)的，隊(duì)列其實(shí)是用來保證消息的安全穩(wěn)定的。自然，當(dāng)請求沒有被寫入到數(shù)據(jù)庫是，都是以消息的形態(tài)存在，我們就可以考慮隊(duì)列來保證數(shù)據(jù)安全。
在數(shù)據(jù)庫訪問層，或者再靠前，到服務(wù)層，我們都可以加入MQ，讓每一個(gè)請求都通過MQ來順序的處理，一但數(shù)據(jù)庫宕機(jī)了，MQ的執(zhí)行就會失敗，這時(shí)，失敗的記錄會被保存在MQ里面，并不會丟失，一但數(shù)據(jù)庫重啟，我們可以再次執(zhí)行MQ中的消息，保證數(shù)據(jù)被成功的寫入到數(shù)據(jù)庫中。
首先，我們在插入數(shù)據(jù)庫前，把插入的操作變?yōu)橄蜿?duì)列對添加一個(gè)消息，然后，我們不同隊(duì)列建立不同的消費(fèi)者，消費(fèi)者對隊(duì)列的消息進(jìn)行執(zhí)行，再往數(shù)據(jù)庫里面插入數(shù)據(jù)。
對于我們的服務(wù)層，我們只要把消息插入到了隊(duì)列中，即視為成功，返回成功的消息。這樣，雖然我們的數(shù)據(jù)處理會有一點(diǎn)點(diǎn)的延時(shí)，并且在事務(wù)的控制上難度會變大，可能需要建立補(bǔ)償機(jī)制，但是我們的數(shù)據(jù)安全就更加高了。
并不是的。消息服務(wù)器也可能會宕機(jī)，消息也有可能出現(xiàn)丟失的情況，所以并不能保證100%的安全。
如果我們還需要做的更好，我們還可以加上MongoDB來做日志
MongoDB是一個(gè)非關(guān)系型數(shù)據(jù)庫，在我們現(xiàn)在的系統(tǒng)中應(yīng)用非常廣。最多的應(yīng)用場景就是用來記錄日志。那么，日志就是一個(gè)幫助我們避免消息丟失的有效方式了。
我們對服務(wù)層的每個(gè)請求報(bào)文，都用MongoDB記錄請求的報(bào)文，再在請求處理完成返回結(jié)果的時(shí)候，記錄一個(gè)消息的處理結(jié)果（成功或失?。@樣，我們就能夠很直觀的看到每天發(fā)生的請求，處理的請求情況了。
當(dāng)有服務(wù)處理失敗了，不管是數(shù)據(jù)庫的問題還是其他的問題，我們都可以對異常進(jìn)行排查，然后再根據(jù)報(bào)文進(jìn)行消息的重推。這樣，我們的數(shù)據(jù)就會更加的安全了。