独家解读！京东高可用分布式流数据存储的架构设计——阅读笔记14

原文链接：https://mp.weixin.qq.com/s/3NU_BptIp5UrDUIKQzjVxw

数据库和中间件这类 PaaS 层的基础设施类软件，近些年的发展趋势是越来越专业化、精细化。只在一个很窄的领域内解决一两个特定的问题，但是在这个领域内，具备极致的性能和体验，可以以极高的性能的处理海量的数据。我们的流数据存储也是这样一种设计思路，它的功能非常的简单，就是存储流数据，但需要具备存储海量数据的能力，并且具备非常高的性能。

对于数据存储类的系统，决定其读写性能的根本因素是存储结构的设计。JournalKeeper 采用了一种非常简单高效的存储结构，

在 JournalKeeper 中，流数据是存储在磁盘中的，为了提高读写的性能，我们为其设计了一套定制的内存缓存系统。经测试，在正常读写的情况下，这套缓存的命中率约为 99.96%，几乎全部的读请求都可以命中缓存，提升了读性能的同时，还可以将几乎全部的磁盘 IO 用于数据写入，进一步提升了数据写入的性能。

在缓存页粒度的选择时，JournalKeeper 使用了最简单的策略：将整个文件缓存在内存中。无论是 Journal 文件还是 Index 文件，每个缓存页面对应一个文件。这种设计的优势在于，不需要再为缓存页编写单独的查找算法，只需要复用文件的查找算法即可，并且缓存页和文件的对应关系也变得非常简单。

对于计算密集型的应用，瓶颈资源是 CPU，理想情况下，最高效的方式 CPU 有几个核就起几个线程，这样才是最充分的利用 CPU 资源。启动了过多的线程，反而会有一部分 CPU 时间在 CPU 上下文切换被浪费掉了。但如果代码优化的不够好，比如说每次计算出一批结果后把计算结果写到磁盘里，在写磁盘等待 IO 的这段时间内，这个线程对应的 CPU 核心是处于闲置状态的。这种情况下启动更多的线程，操作系统会自动把 CPU 调度给其它线程，这样看起来提高并发确实带来了性能提升。但我们要知道，只不过是因为我们的代码优化的不够充分，操作系统替我们的程序做了一些调度优化而已，总体的性能并没有达到最优的状态。

系统的复杂度是容易被忽略的考量指标。过于复杂的设计更难于实现和维护，会大幅提高系统的总体拥有成本，因此在其它三个考量因素都可以接受的范围内，尽量采用简单的设计总是一个不错的选择。

JournalKeeper 不仅使用 Raft 来维护其元数据，Raft 协议也被用来维护存储的流数据的一致性。我们为对于每个数据流（可以理解为一个 Topic）都创建一个 Raft 集群，集群的每个节点为一个虚拟进程，Leader 节点提供流数据写入服务，所有节点都可以提供流数据的读服务。

并行复制的思路是，Leader 并行发送复制请求，Follower 中维护一个按照日志位置排序请求列表，按照日志位置串行处理这些复制请求，Leader 按照位置顺序处理响应。也就是说整个复制流程拆分成上面的 5 个小流程，其中 1、2、4 三个小流程可以并发，3、5 为了保证数据一致性不能并发，依然串行执行。对于并发后可能出现的乱序和数据空洞问题，可以通过对请求按照数据的位置进行排序和少量数据重传解决

转载于:https://www.cnblogs.com/liusx/p/11041074.html