到目前为止,三歪也已经接触到了不少的中间件了,比如说「Elasticsearch」「Redis」「HDFS」「Kafka」「HBase」等等。 可以发现的是,它们的持久化机制都差不得太多。今天想来总结一下,一方面想来回顾一下这些组件,一方面给还没入门过这些中间件的同学总结一下持久化的”套路“,后面再去学习的时候就会轻松很多。
持久化下面我们就直接来分别回顾一下各个中间件/组件的持久化机制,最后再总结就好了(三歪相信大家应该也能从回顾中看出些端倪) 为什么要持久化?原因也很简单:数据需要存储下来,不希望出了问题导致数据丢失 ElasticsearchElasticsearch是一个全文搜索引擎,对模糊搜索非常擅长。 Elasticsearch在写数据的时候,会先写到内存缓存区,然后写到 Kafka众所周知,Kafka是一个高吞吐量的消息队列,那它是怎么持久化的呢?
没错Kafka用的是文件系统来存储的。 在Kafka官网上其实也说了,Kafka的持久化依赖操作系统的 HDFSHDFS是分布式文件系统,能存储海量的数据,那HDFS在写入数据的时候是怎么样的呢? HDFS Client客户端无论读写都需要走到 所以,在HDFS写数据,需要先去 为了提高 RedisRedis是基于内存的,如果不想办法将数据保存在硬盘上,一旦Redis重启(退出/故障),内存的数据将会全部丢失。 我们肯定不想Redis里头的数据由于某些故障全部丢失(导致所有请求都走MySQL),即便发生了故障也希望可以将Redis原有的数据恢复过来,所以Redis有
AOF持久化功能的实现可以分为3个步骤:
HBaseHBase是一个能存储海量数据的数据库。 HBase在写数据的时候,会先写到 我们写数据的时候是先写到内存的,为了防止机器宕机,内存的数据没刷到磁盘中就挂了。我们在写 MySQLMySQL我们用得最多的 MySQL引入了 总结看完上面常见的中间件/组件的持久化方式,应该就不用我多说了吧?思想几乎都是一样的,只是他们记录“log”的名字不一样而已。 先写buffer,然后顺序IO写Log。防止buffer的数据还没刷到磁盘,宕机导致数据丢失。 对于Log文件,中间件也不会放任它们一直膨胀,导致体积很大:
各类知识点总结
|
|