架构视角-文件的通用存储原理

    架构师是互联网行业高薪又紧俏的资源。成为架构师最基本的是设计能力。设计与设计的区别主要体现在两方面：

1，深度：要解决哪些问题？这个问题背后的根本问题是什么？还有什么问题没有发现？对应的能力是发现和解决问题的能力。

2，体系：要解决的问题的属于哪一类的问题？这类问题能否进一步抽象，让系统解决更大的问题？对应的抽象归纳和体系化思维的能力。

    

    而做架构的基本功就是研究成熟成功的系统，并总结归纳为一种设计方法添加到自己的设计库中。今天我们来看看文件存储机制的通用实现及原理-谈Kafka、Redis、基于Lucene的搜索引擎等中间件和数据库的文件存储机制。如果你有九年义务教育以上学历，并且觉得看不懂这篇文章，请给我留言~~

    顺便插一句，不知道大家有没有奇怪静儿最近都没有写高可用方面的文章。事情是这样的，对于高可用的很多设计、架构，静儿都在进行专利申请中，为了避免对公司造成影响和损失，暂时处于多想不说的阶段。

 

    一个商业化中间件的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面先介绍一下各个中间件的存储机制。看不懂可直接跳到最后。

 

各个中间件的存储机制

 

    

1Kafka  

    

    Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协议的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

设计特点

• Kafka把topic中一个partition(大块)大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完的文件，减少磁盘占用。

• 通过索引信息可以快速定位message和确定response的最大大小。

• 通过index(索引)元数据全部映射到memory（内存），可以避免segment file（文件片段）的IO磁盘操作。

• 通过索引文件稀疏存储，可以大幅降低index文件元数据占用