三歪吐血總結(jié)了各個中間件是如何實現(xiàn)持久化的
到目前為止，三歪也已經(jīng)接觸到了不少的中間件了，比如說「Elasticsearch」「Redis」「HDFS」「Kafka」「HBase」等等。
可以發(fā)現(xiàn)的是，它們的持久化機(jī)制都差不得太多。今天想來總結(jié)一下，一方面想來回顧一下這些組件，一方面給還沒入門過這些中間件的同學(xué)總結(jié)一下持久化的”套路“，后面再去學(xué)習(xí)的時候就會輕松很多。
這些中間件我的GitHub目錄都是在的:
https://github.com/ZhongFuCheng3y/3y
https://gitee.com/zhongfucheng/Java3y
持久化
下面我們就直接來分別回顧一下各個中間件/組件的持久化機(jī)制，最后再總結(jié)就好了（三歪相信大家應(yīng)該也能從回顧中看出些端倪）
為什么要持久化？原因也很簡單：數(shù)據(jù)需要存儲下來，不希望出了問題導(dǎo)致數(shù)據(jù)丟失
Elasticsearch
Elasticsearch是一個全文搜索引擎，對模糊搜索非常擅長。
Elasticsearch在寫數(shù)據(jù)的時候，會先寫到內(nèi)存緩存區(qū)，然后寫到translog緩存區(qū)，每隔5s將translog緩沖區(qū)的數(shù)據(jù)刷到磁盤中
Kafka
眾所周知，Kafka是一個高吞吐量的消息隊列，那它是怎么持久化的呢？
Kafka relies heavily on the filesystem for storing and caching messages.
沒錯Kafka用的是文件系統(tǒng)來存儲的。
在Kafka官網(wǎng)上其實也說了，Kafka的持久化依賴操作系統(tǒng)的pagecache和順序?qū)?/strong>來實現(xiàn)的。
HDFS
HDFS是分布式文件系統(tǒng)，能存儲海量的數(shù)據(jù)，那HDFS在寫入數(shù)據(jù)的時候是怎么樣的呢？
HDFS Client客戶端無論讀寫都需要走到NameNode去獲取/增刪改文件的元數(shù)據(jù)，而NameNode則是專門維護(hù)這些元數(shù)據(jù)的地方。
所以，在HDFS寫數(shù)據(jù)，需要先去NameNode上詢問這些切分好的block往哪幾個DataNode上寫數(shù)據(jù)。
為了提高NameNode的效率，在寫數(shù)據(jù)的時候，NameNode實際上是操作的是內(nèi)存，然后涉及到增刪改的數(shù)據(jù)順序寫到editlog日志文件上
Redis
Redis是基于內(nèi)存的，如果不想辦法將數(shù)據(jù)保存在硬盤上，一旦Redis重啟(退出/故障)，內(nèi)存的數(shù)據(jù)將會全部丟失。
我們肯定不想Redis里頭的數(shù)據(jù)由于某些故障全部丟失(導(dǎo)致所有請求都走M(jìn)ySQL)，即便發(fā)生了故障也希望可以將Redis原有的數(shù)據(jù)恢復(fù)過來，所以Redis有RDB和AOF的持久化機(jī)制。
RDB：基于快照，將某一時刻的所有數(shù)據(jù)保存到一個RDB文件中。
AOF(append-only-file)，當(dāng)Redis服務(wù)器執(zhí)行寫命令的時候，將執(zhí)行的寫命令保存到AOF文件中。
AOF持久化功能的實現(xiàn)可以分為3個步驟：
- 命令追加：命令寫入aof_buf緩沖區(qū)
- 文件寫入：調(diào)用flushAppendOnlyFile函數(shù)，考慮是否要將aof_buf緩沖區(qū)寫入AOF文件中
- 文件同步：考慮是否將內(nèi)存緩沖區(qū)的數(shù)據(jù)真正寫入到硬盤
HBase
HBase是一個能存儲海量數(shù)據(jù)的數(shù)據(jù)庫。
HBase在寫數(shù)據(jù)的時候，會先寫到Mem Store，當(dāng)MemStore超過一定閾值，就會將內(nèi)存中的數(shù)據(jù)刷寫到硬盤上，形成StoreFile，而StoreFile底層是以HFile的格式保存，HFile是HBase中KeyValue數(shù)據(jù)的存儲格式。
我們寫數(shù)據(jù)的時候是先寫到內(nèi)存的，為了防止機(jī)器宕機(jī)，內(nèi)存的數(shù)據(jù)沒刷到磁盤中就掛了。我們在寫Mem store的時候還會寫一份HLog
MySQL
MySQL我們用得最多的InnoDB引擎是怎么存儲的呢？它有redo log來支撐持久化的功能。
MySQL引入了redo log，內(nèi)存寫完了，然后會寫一份redo log，這份redo log記載著這次在某個頁上做了什么修改。
總結(jié)
看完上面常見的中間件/組件的持久化方式，應(yīng)該就不用我多說了吧？思想幾乎都是一樣的，只是他們記錄“l(fā)og”的名字不一樣而已。
先寫buffer，然后順序IO寫Log。防止buffer的數(shù)據(jù)還沒刷到磁盤，宕機(jī)導(dǎo)致數(shù)據(jù)丟失。
對于Log文件，中間件也不會放任它們一直膨脹，導(dǎo)致體積很大：
- 在Redis里邊，會對AOF文件進(jìn)行重寫
- 在HDFS里邊，
editlog會定時生成fsimage - 在Elasticsearch里邊，
translog會根據(jù)閾值觸發(fā)commit操作 - .....
各類知識點總結(jié)
下面的文章都有對應(yīng)的原創(chuàng)精美PDF，在持續(xù)更新中，可以來找我催更~
- 92頁的Mybatis
- 129頁的多線程
- 141頁的Servlet
- 158頁的JSP
- 76頁的集合
- 64頁的JDBC
- 105頁的數(shù)據(jù)結(jié)構(gòu)和算法
- 142頁的Spring
- 58頁的過濾器和監(jiān)聽器
- 30頁的HTTP
- 42頁的SpringMVC
- Hibernate
- AJAX
- Redis
- ......
掃碼或者微信搜Java3y 免費領(lǐng)取原創(chuàng)思維導(dǎo)圖、精美PDF。在公眾號回復(fù)「888」領(lǐng)取，PDF內(nèi)容純手打有任何不懂歡迎來問我。
原創(chuàng)電子書
原創(chuàng)思維導(dǎo)圖
 |
|
