导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “5F容错” 模式，下一篇将讲诉 “关联资源管控” 模式。

动机

5F容错模式设计思路

这里借用Dubbo里的概念讲述5种容错处理策略，我定义它们为5F容错法，下图是一个简单的分布式系统逻辑架构图。

导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “限流-横向限流” 模式，下一篇将讲诉 “容错” 模式。

动机

上一篇文章讲诉了纵向限流，那么为什么还需要横向限流呢？如下图所示：

解决限流不均匀问题 : 如上图所示纵向限流只解决了网关-服务1，网关-服务2，网关-服务N的纵向路径的限流问题，但是并没有解决 这几个服务路径的限流是否均匀的问题，比如在某些情况下，网关-服务1 QPS 是 200，网关-服务2 QPS是 500,网关-服务N QPS 是 20，但是服务1-服务N的配置都是一样的，很明显，这里的限流并不均匀。

更细粒度的用户/租户的限流问题 : 如上图所示，用户1-用户N都发请求到网关，但是想限制每个用户可以进入系统的请求的个数，这里纵向限流并没有办法统计并控制每个用户的可以进入系统的请求数，纵向限流只能限制整体的进入网关的请求数，因此需要一个计数中心用于登记每个用户的请求数，从而进行更细粒度的流量控制，控制每个用户的请求数。

横向限流模式

如下图，通常采用一个类似配置中心或分布式事务中心的方式实现横向限流。

• 如左图所示，将集群限流服务中心实现在一个网关实例里，与网关一起提供服务，好处是无需再独立部署一个限流实例，缺点是网关如果挂掉，那么限流服务也会一起挂掉，而且无法对网关进行横向限流，只实现了网关底下的服务的横向限流；

• 如右图所示，独立拉起一个集群限流服务中心实例，用于提供全局限流计数服务，好处是与业务解耦，缺点是在集群内增加了一个额外的服务实例，增加了系统复杂度。

横向限流模式设计思路

常用的横向限流算法有计数算法以及时间标签算法。

计数算法

如图所示，独立的限流服务中心，拉起一个独立的分布式配置中心/事务中心，在里头实现限流算法，比如固定窗口算法、滑动窗口算法、漏桶算法、令牌桶算法等用于全局计数，而且保证这个计数是全局唯一的，不管集群规模多大，保证每个服务所使用的计数器和计时器都是唯一的，服务拿到这个计数ID后在进行限流调度。

• CP模式：采用独立的限流中心，如果每个用户进入系统的请求都需要去远程的限流服务中心取一个计数返回，这就多了一个远程读取限流计数值的过程，很明显增加的这一步会影响请求的性能，但是在某些对限流可靠性比较苛刻的场景里，这是以牺牲请求性能的方式换取限流的可靠性；

• AP模式：计数还是在限流服务中心，但在本地维护了一个限流计数的缓存，这样每个用户进来的请求并不是去远程读取计数值，而是直接在本地获取限流计数，而这个限流计数是通过一个独立的调度线程维护着的，这里这个本地的限流计数与远程限流服务中心的限流计数是不保证一致性的，这种方式牺牲了限流的可靠性，但是保证了请求的性能，在对限流要求不是很苛刻的场景下比较合适，而且配合纵向限流，还是可以解决绝大部分的系统的限流调度问题的。

时间标签算法

计数算法只是实现了限制用户或者服务请求量的最大值，并不能提供最小值保障，因此基于时间标签的算法被提出，例如DMCLOCK算法[1]。
在dmclock算法里，不只实现了限流，还实现了用户权重的划分以及最小值的预留。

例如在云服务里，用户1与用户2，付费不一样，因此给提供的最大限流上限是不一样的，但是采用计数限流算法，并不能保证付费多的用户就一定能得到最低的服务质量保证，在系统负载高的时候，付费高的用户与付费低的用户一样难以得到服务资源保底，这是不合理的，因此需要一个可以预留资源的算法。如下图所示，系统里流量资源的调度可以按 “预留、权重、上限” 这三个维度进行调度。

例如，在时间标签算法里， 有三个用户：user1, user2,user3 根据付费的高低，给他们分别分配了不同的权重与预留值。如果系统里最大的QPS资源量是 4000，用户1与拥护2的QPS预留值是 1000，权重比例是 1：2：3.那么应当如何分配这些QPS资源？ 按dmclock算法可以这样计算：

用户1 ： (4000/(1+2+3)) 1 = 667 < 1000,但是保底的QPS是1000，因此分配了1000 QPS 给用户1.
用户2：( (4000-800) / (2+3)) 2 = 1200 QPS
用户 3：4000-1200 – 667 = 2133 QPS

基本的计算思路是，先保证最低的预留值，再根据权重划分剩下的资源，并且保证不要超过最大值。

算法实践

• 通常如非必要或者业务场景要求苛刻，纵向限流就够，实现横向限流会引入新的组件，增加复杂度，同时还影响系统性能；

• 如果必须实现横向限流，那么性能要求高就采用AP模式，限流可靠性要求高就采用 CP模式；

• 权衡利弊，根据业务场景合理组合纵向限流与横向限流，才是最佳实践。

小结

本文讲诉了服务治理里的 “横向限流”模式，在前一篇《分布式系统架构设计三十六式之服务治理-纵向限流模式》里讲诉了分布式系统服务治理的纵向限流模式。另作者能力与认知都有限，欢迎大家拍砖留念。

作者简介

常平，中科大硕，10年+数据相关经验，主要工作背景为分布式系统、存储、缓存、微服务、云计算以及大数据，现就职于DELL EMC。个人技术博客：https://changping.me

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh ，可以自由阅读、分享、转发、复制、分发等，限制是需署名、非商业使用（以获利为准）以及禁止演绎。

参考资料

[1]https://github.com/ceph/dmclock

导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “限流-纵向限流” 模式，下一篇将讲诉 “限流-横向限流” 模式。

动机

限流限的是什么

限流其原理是监控输入的请求量，当达到指定的阈值时对量进行控制，以避免系统被瞬时的请求量高峰冲垮，从而保障系统的高可用、高可靠。因此，限流的限的自然是“流”，对于不同的场景“流”是不同的：

• 网络限流，流指的是带宽、流量；
• I/O限流的“流”指的是TPS或QPS；
• 并发限流的“流”指的是并发请求数；
• 线程资源限流的“流”指的是线程数。

这些“流” 通常具有资源竞用性、延迟性、抖动性以及不可靠性的特征。资源竞用性以及不可靠性需要控制流的资源使用，延迟性、抖动性需要对“流”进行整形，削峰填谷，控制请求的指标波形图。

限流处理策略

• 直接拒绝：当请求量超过阈值后，新的请求就会被直接拒绝，方式为直接返回或者抛出异常。这种方式比较适合于对分布式系统的负载容量已知的情况下，比如通过全链路压测已经确定了准确的系统处理能力及系统容量，对应固定窗口、滑动窗口算法。

• 冷启动：当分布式系统长期处于低负载的情况下，请求量突发时，会把系统负载很快拉到很高的水准，这样就可能瞬间就把系统击垮。通过”冷启动”方式，让输入的请求量缓慢增加，在一个时间段内慢慢增加到系统所能承载的阈值上限，给冷系统一个预热的时间，避免系统被压垮，对应令牌桶算法。

• 匀速排队：匀速排队的方式也就是控制请求以均匀的速率通过，对应的是漏桶算法。

限流模式设计思路

如下图所示，在分布式系统里，限流通常可以按空间维度划分为纵向限流以及横向限流，本文讲述纵向限流，下一篇将讲诉 横向限流。

导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “降级” 模式。

动机

1. 某些时候系统会遇到负载过高的问题，当系统外来的或内部的负载过高超过预先定义的阈值，为了保证更重要的更紧急的业务的服务质量，希望将一些非核心的、不紧急的业务降低服务质量，从而释放一些额外的资源给紧急业务使用。比如一个分布式系统里的读、写、数据校验、空间回收都比较消耗资源，在白天为了保证读和写的服务质量，可以把数据校验的服务通过限流或减少线程数之类的方式使得可以调用的资源配额减少，从而释放部分资源给读和写使用，保证读写的服务质量。同样在读和写业务不繁忙的时候，降低读和写的资源配额，从而释放资源给空间回收使用，通过这种方式动态调整局部业务的服务质量从而保证关键业务的服务质量，提升用户体验。

2. 在云服务里“可用性”指标是一个非常重要的SLA指标，在可用性出现不达标的情况下需要根据SLA进行赔偿，因此，我们希望分布式系统不管出现怎么样的故障，比如服务器故障，磁盘故障，网络故障都能保持可用性，起码要保证单点故障不会造成系统故障，比如，在系统出现严重故障的时候，可以停止负载较高的写操作从而保证“读”或者“查询“服务。

降级模式

从故障处理角度来讲，服务降级简单来说就是这一功能或服务直接不能用，而在动态调整系统整体的服务质量的时候，降级是降低某些当前非重要或非核心业务的资源，从而释放部分资源给重要的或紧急的业务使用。

在故障处理的时候，对比“熔断”，降级是更严重的故障处理方式，最后拿来兜底用的。比如某个功能出故障，“熔断”是不管怎么样，都希望这个功能还能救活，降级是发现试着救了几次发现还是救不活，就下狠心砍掉这个部分，断臂求生，起码要保证整体是活的，这样整体还有救活的希望。

从系统的角度来说降级有 读功能降级，写功能降级以及级联组件降级，还有自动降级或者人工降级。比如，在云服务里，为了保证高可用性，在出现系统级的故障后，可以把写功能降级，就是这个服务只能读，只能查询不能写了，因此在设计的比较好的云服务里，按时间的维度来度量可用性已经没有太大的意义，因为不管怎么样它都是服务可用的，系统都是活着的，起码部分服务可用，因此在云服务里更合理的新的衡量可用性的指标方式是请求失败比率。

降级模式设计思路

降级触发策略

• 超时降级：在超时重试的次数达到一个阈值后就触发降级；
• 失败比率降级：当某个服务的失败的比率达到一定比率后就开始降级；
• 系统故障降级：比如网络故障，硬盘故障，电源故障，服务器故障，数据中心故障等；
• 限流降级：某些访问量太大的场景会触发限流，当达到限流阈值后，请求也会被降级；
• 重要业务救急降级：比如为了保证读或者查询的功能，降低写或者数据校验的资源配额，从而实现读服务的质量保证。

降级处理措施

• 资源配额调度，调度不紧急的业务支援紧急的重要的业务；
• 抛出异常，直接抛出异常，打印出出错日志，然后就不管了，请求会丢失，这在需要保证幂等性的请求里不合适；
• 直接返回， 直接返回拒绝服务，这里请求也会丢失，这在需要保证幂等性的请求里不合适；
• 调用回退方法，调用出现服务降级时对应的业务处理逻辑，不同场景降级处理的逻辑不同，比如可以把请求再挂到等待队列里继续重试之类，这里需要根据业务场景合理设计回退方法；

降级分级策略

一般可以把降级的等级分为几个层次，比如P0级，P1级，P2级，P3级，级别越高表示问题越严重， 比如：

1. 重要业务救急降级可以定义为P0级降级，只是调度次要的资源去救急，并不会出现故障；
2. 限流降级可以定义为P1级降级，只是为了保证服务质量，而且如果不限流可能会出现系统负载过高从而出现故障；
3. 超时降级以及失败比率降级可以定义为P2级降级，出现小范围故障，触发P2级降级，保证小故障不蔓延不传播从而造成大范围的故障；
4. 系统故障降级可以定义为P3级降级，系统出现大范围故障，从而触发P3级降级，比如，此时可以只保证最低资源的的读请求服务，写和其他业务全部被禁止。

配置中心

如下图所示是一个简单的配置中心物理架构图：

导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “熔断” 模式。

动机

在分布式系统里经常会遇到这样的场景：

1. 系统负载突然过高，比如突发的访问量、过多的请求并发数以及过多的IO等都会造成某个节点故障，比如节点A，然后节点A挂了，又把负载转给节点B，然后节点B又负载过高，接着B又挂了，就这样一连串的挂过去从单点故障造成系统级的级联故障。

2. 当一个服务出现故障时，希望这个服务能在一个时间段内恢复，在请求被拒绝后隔一段时间再自动的去探测服务的可服务性。

对应这两个场景，我们希望在分布式系统里能避免级联故障、提供快速失败快速恢复服务的能力，因此，这里引出 “熔断模式” 。

熔断模式

熔断模式也称之为断路器模式，英文单词是“circuit breaker”，“circuit breaker”是一个电路开关，其基本功能是检测到电流过载就中断电路，在检测到电流正常时又能自动或手动恢复工作，从而保护断路器背后的电源设备安全。这里需要将”断路器“与 “保险丝”进行区分，断路器可以通过手动或自动的复位从而恢复正常工作，而保险丝是运行一次必须更换。

实现一个分布式系统通常会面临三大难题： 业务拆分与聚合，分布式事务以及故障传播性。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括：隔离、熔断、降级、限流、容错以及资源管控，本文将讲诉服务治理里的 “熔断”模式。

在分布式系统里 “熔断模式”的设计思想来源于此，当系统里响应时间或者异常比率或者异常数超过某个阈值时，比如超时次数或重试次数超过某个阈值就会触发熔断，接着所有的调用都快速失败，从而保证下游系统的负载安全，在断开一段时间后，熔断器又打开一点试着让部分请求负载通过，如果这些请求成功那么断路器就恢复正常工作，如果继续失败，则继续关闭服务走快速失败通道，接着继续这个过程直到重试的次数超过一定的阈值从而触发更为严重的“降级模式”。

熔断模式设计思路

下图是一个熔断模式的设计思路：

导读

日拱一卒，功不唐捐，分享是最好的学习，一个知识领域里的 “道 法 术 器” 这四个境界需要从 微观、中观以及宏观 三个角度来把握。微观是实践，中观讲套路，宏观靠领悟。本系列文章我把它命名为《分布式系统架构设计三十六式》，讲诉分布式系统里最重要的三十六个虚数的中观套路，而微服务的本质也是分布式，因此搞明白这三十六个最重要的知识点也就同时能搞明白微服务。

实现一个分布式系统通常会面临三大难题： 故障传播性、业务拆分与聚合以及分布式事务 。本系列中的服务治理章节主要是为了解决故障传播性的难题，它包括： 隔离、熔断、降级、限流、容错以及资源管控 ，本文将讲诉服务治理里的 “隔板” 模式。

动机

在分布式系统里通常将进程容器化以进行资源隔离，然后在同一个进程里的各种业务都共享线程池对外提供服务，这就经常会遇到这样的问题：

1. 业务A负载较高，抢占了线程池里的大部分线程资源，从而造成其他业务的服务质量下降；
2. 同一个进程内新加入一个业务，这个业务会抢占其他业务的资源，从而造成系统的不稳定，比如业务性能抖动；
3. 难以调试，比如同一个进程里的10个业务共享同一个线程池，当出现故障时难以通过简单的日志判断是哪个业务出了问题。

因此，我们希望找出一个机制解决这样的问题。

隔板模式

首先我来看一个英文单词“Bulkhead”，翻译成中文就是“舱壁”‘或“隔板”，在分布式系统里有个资源隔离的设计模式叫做”舱壁模式”或者“隔板模式”。

图片来源于引文[1]，版权归原作者所有

在造船的时候，”船农们“（对应码农）通常会把一个大的船舱用隔板分成N个小的空间，以便万一船体破裂或着火的时候，只有这个被分割开的小船舱受到影响，而其他的船舱是被隔离而不受影响的，从而提高整个船只的安全度。

同样这种隔板模式可以应用在分布式系统的资源隔离设计里，在分布式系统里，资源隔离通常按业务分为进程级别的隔离和线程级别的隔离，某些简单的服务质量要求不高的业务场景下实现进程级别的隔离就够了，但是在某些对服务质量要求较高的分布式场景下需要线程级别的细粒度隔离。

进程隔离

进程级别隔离通常指的是容器化隔离，比如通过使用docker实现业务进程之间的资源隔离。

线程隔离

线程级别隔离是指给每个跑在进程里的业务都按业务类型创建一个线程池，从而实现线程级别细粒度的资源隔离，线程隔离具有以下优势：

1. 提高业务可靠性，减少业务受其他业务影响的程度，当一个业务耗尽自身的线程资源后也不会影响另外一个业务的服务质量；
2. 降低新加入的业务的给系统带来的风险，比如当前系统的一个进程用例中有10个业务。当新加入一个业务时，必然会抢占此前10个业务的线程资源，从而给系统带来不稳定，比如性能抖动；
3. 利于调试，给每一个业务都分配一个线程池名称，当业务出故障时，通过线程池名称可以很方便地定位是哪个业务出了故障，并且通过监控线程池的请求失败次数、超时次数、拒绝请求次数等可以实时的反应当前业务服务质量。

事物都有二元性，线程池隔离，有利自然也有弊，线程池隔离也会引入额外的一些开销，开销类型有：

1. 对象分配，每个调用都会实例化一个新的线程对象及其中的关联对象，占用系统资源；
2. 并发，共享数据结构，计数器等，也占用系统资源；
3. 线程的执行开销：切换，调度，执行，同样也占用资源。

因此，线程池的隔离带来了好处但是也会引起一些顾虑，比如给每个业务都创建一个线程池是否会给系统带来太大的开销。通过Hystrix的数据分析可以得出结论是： “开销是有的，但是对比好处，通过权衡，其开销在一些要求不苛刻的场景可以忽略。”

线程池的开销分析

Hystrix官网[3]，统计了线程池带来的开销成本，如下图表示在单个API实例上以60个请求/秒执行一个HystrixCommand：

图片来源于引文[3]，版权归原作者所有

通过分析这个统计图（注意不同的颜色），我们可以看到：

1. 中位数（P50）和更低的场景下，对比不使用线程池隔离模式，隔离线程池基本没有成本开销。
2. 在P90的场景下，对比不使用线程池隔离模式，隔离线程池的耗时差距为3毫秒。
3. 在P99的场景下，对比不使用线程池隔离模式，隔离线程池的耗时差距为9毫秒。

但是从上图可以看出，成本增加的幅度远小于单独一个线程的执行时间增加的幅度，当未使用线程池隔离的线程执行时间从2ms跳到28ms时，线程池隔离的耗时成本从0ms跳到9ms。

因此，对于大多数的使用场景而言，在P90及以上的线程池隔离带来的开销被认为是可接受的，从而获得资源隔离带来的好处。

但是在某些场景这样的开销可能过高，比如缓存场景，在这种情况下，可以选用信号量来进行隔离，缺点是信号量不允许设置超时，难以实现熔断、降级之类的服务治理行为。

小结

本文讲诉了服务治理里的 “隔板”模式，在下一篇将讲诉分布式系统服务治理的熔断模式。另作者能力与认知都有限，欢迎大家拍砖留念。

作者简介

常平，中科大硕，10年+数据相关经验，主要工作背景为分布式系统、存储、缓存、微服务、云计算以及大数据，现就职于DELL EMC。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] https://en.wikipedia.org/wiki/Bulkhead_(partition)

[2] http://writing.engr.psu.edu/uer/bassett.html

[3] https://github.com/Netflix/Hystrix/wiki/FAQ%20:%20General

ceph逻辑架构图

ceph后端支持多种存储引擎，以插件化的形式来进行管理使用，目前支持filestore，kvstore，memstore以及bluestore，目前默认使用的是filestore，但是目前bluestore也可以上生产。下图是ceph的逻辑架构图：

Firestore存在的问题是：

1. 在写数据前需要先写journal，会有一倍的写放大；

2. 若是另外配备SSD盘给journal使用又增加额外的成本；

3. filestore一开始只是对于SATA/SAS这一类机械盘进行设计的，没有专门针对SSD这一类的Flash介质盘做考虑。

而Bluestore的优势在于：

1. 减少写放大；

2. 针对FLASH介质盘做优化；

3. 直接管理裸盘，进一步减少文件系统部分的开销。

但是在机械盘场景Bluestore与firestore在性能上并没有太大的优势，bluestore的优势在于flash介质盘。

FileStore逻辑架构

下图为ceph filestore逻辑架构图：

1. 首先，为了提高写事务的性能，FileStore增加了fileJournal功能，所有的写事务在被FileJournal处理以后都会立即callback(上图中的第2步)。日志是按append only的方式处理的，每次都是被append到journal文件末尾，同时该事务会被塞到FileStore op queue；

2. 接着，FileStore采用多个thread的方式从op queue 这个 thread pool里获取op，然后真正apply事务数据到disk（文件系统pagecache）。当FileStore将事务落到disk上之后，后续的读请求才会继续(上图中的第5步)。

3. 当FileStore完成一个op后，对应的Journal才可以丢弃这部分Journal。对于每一个副本都有这两步操作，先写journal，再写到disk，如果是3副本，就涉及到6次写操作，因此性能上体现不是很好。

Bluestore逻辑架构

下图为ceph bluestore逻辑架构图：

1. Bluestore实现了直接管理裸设备的方式，抛弃了本地文件系统，BlockDevice实现在用户态下使用linux aio直接对裸设备进行I/O操作，去除了本地文件系统的消耗，减少系统复杂度，更有利于Flash介质盘发挥性能优势；

2. 为了惯例裸设备就需要一个磁盘的空间管理系统，Bluestore采用Allocator进行裸设备的空间管理，目前支持StupidAllocator和BitmapAllocator两种方式；

3. Bluestore的元数据是以KEY-VALUE的形式保存到RockDB里的，而RockDB又不能直接操作裸盘，为此，bluestore实现了一个BlueRocksEnv，继承自EnvWrapper，来为RocksDB提供底层文件系统的抽象接口支持；

4. 为了对接BlueRocksEnv，Bluestore自己实现了一个简洁的文件系统BlueFS，只实现RocksDB Env所需要的接口，在系统启动挂在这个文件系统的时候将所有的元数据都加载到内存中，BluesFS的数据和日志文件都通过BlockDevice保存到底层的裸设备上；

5. BlueFS和BlueStore可以共享裸设备，也可以分别指定不同的设备，比如为了获得更好的性能Bluestore可以采用 SATA SSD 盘，BlueFS采用 NVMe SSD 盘。

2018年2月12日到2019年2月11日，刚好满一年，不知不觉间居然写了35770行代码，

2018-02-12 ~ 2019-02-11， 刚好入职EMC满一年，里程碑两件：

1，个人代码量突破3万5千行，排列第一；

2，专利公司内部通过且美国专利局审核中2个。