存储系统

4.Ceph顶层架构总览此图来源于官网，很多网络上的资料也引用了这张图，但是并没有讲清楚出现在图中的和没有出现在图中的（但同样重要的）几个名词到底是什么含义，例如，RADOS、LIBRADOS、RADOSGW、RDB、CEPHFS、MON、OSD、MDS等等。读者要搞清楚Ceph的顶层架构，就首先要搞清楚这些名词代表的技术意义，以及这些技术的在Ceph顶层架构中所占据的地位。4-1.名词解释请看以下这张图对Ceph顶层架构抽象名词的功能细化：是不是这样看就要亲切多了。实际上我们一直讲的Ceph分布式对象存储系统只是上图中的RADOS部分（ReliableAutonomicDistributed

3-3.Ceph常用命令Ceph文件系统提供的运维命令主要是按照Ceph中的工作角色/工作职责进行划分的，例如有一套专门对OSD节点进行管理的命令、有一套专门对PG进行管理的命令、有一套专门对MDS角色进行管理的命令……您可以使用ceph–help进行命令列表的查看，本文我们对常用的命令进行描述，这些命令只是Ceph文件系统中的一部分命令，目的是保证在Ceph运行到生产环境后，您有能力定位常见问题，保证Ceph能够正常工作。这里说明一下，ceph-deploy中的命令主要进行Ceph中各角色的安装、删除。所以对Ceph文件系统的日常维护还是不建议使用ceph-deploy中的命令，而建议尽可能

3.连接到Ceph系统3-1.连接客户端完成Ceph文件系统的创建过程后，就可以让客户端连接过去。Ceph支持两种客户端挂载方式：使用Linux内核支持的mount命令进行的挂载方式；使用用户空间文件系统FUSE（FilesysteminUserspace）进行的网络磁盘挂载方式。这两种挂载方式的本质区别是，前者需要有Linux内核的支持，而后者只是工作在Linux上的一个应用软件。3-1-1.使用mount命令进行挂载这里要特别说明以下，CentOS6.X和CentOS7早期版本的内核都不支持使用mount命令直接进行Ceph分布式文件系统客户端的挂载，这主要是Kernel内核版本的原因，所

1.概述从本篇文章开始介绍一款现在非常火的分布式文件系统Ceph，包括这款文件系统的安装、基本使用场景、常用管理命令和重要工作原理。特别是讨论了PaxOS算法的基本理后，就更容易理解Ceph分布式文件系统中各种角色的工作原理。2.Ceph的安装部署本文将介绍Ceph分布式文件系统如何在CentOS7.X版本上一步一步完成安装，使读者在阅读过程中了解Ceph有哪些重要的子系统/工作模块，以及它们是如何关联工作的。请注意Ceph在Ubuntu等Linux操作系统上的安装过程和注意点大致相同，但如果读者和笔者同样选择在CentOS上安装Ceph，那么就请使用CentOS7.X的版本，因为这个版本是C

如上图所示，Server2在宕机前正在对log7、log8、log9进行Paxos，并且自身已经完成赋值过程（但是其它节点都还没有完成赋值过程，没有形成多数派）。这时Server2由于某些原因下线了。Server3通过选主过程拿到了ProposerLeader，但是它能获取到的最大logid为log6（因为现在存活的各个节点上最大的logid都是log6嘛），所以自己startworking的logid位置就是log7。就在这个时候，Server2节点又恢复了工作，且技术人员人工命令从新授予Server2节点ProposerLeader身份。这时在其上原有的log7、log8、log9虽然有值

2-3.Paxos算法变种上文（架构设计：系统存储（24）——数据一致性与Paxos算法（中））我们提到，Paxos算法的设计是为了解决多个Proposer针对一个具体提案产生的多个赋值，并最终帮助多个Proposer确定一个大家一致认可的赋值，最终达到一致性。从理论层面上说，如果多个Proposer一直不产生竞争起来，那么算法研究就没有意义。例如上文中提到的一个ProposerA的投票轮次编号始终从1000开始，其它Proposer的投票轮次编号始终从100开始，那样的话Paxos算法系统中其它Proposer发起的提案申请在第一轮就会被拒绝（在ProposerA的第一次提案申请到达Acce

2-1-1.Prapare准备阶段首先需要介绍几个在Acceptor角色上需要被持久化保存的数据属性：PrepareVote保存了当前Acceptor接收到的已完成投票授权的最大投票轮次AcceptedVote保存了当前Acceptor在赋值阶段完成投票赋值的投票轮次AcceptedValue保存了当前Acceptor在赋值阶段被赋予的值1、第一个阶段Proposer和Acceptor至少要完成一次网络通讯，其主要目的是确定针对提议X的当前投票轮次是否能被授权。换句话说，根据Acceptor在准备阶段的工作原则，即使确定当前投票轮次的编号值是大于Acceptor中记录的PrepareVote的

今年年初参加一家公司的面试，发生了一件有趣的事情。当我给面试官解释Ceph的运行原理时，提到了Ceph支持POSIX标准（PortableOperatingSystemInterface），面试官突然问道：“那简述以下POSIX协议如何工作的，如何对数据一致性提供保证”。额～～我一时语塞，POSIX标准工作在OS层，只有IEEE官方标准文档中有关于它工作原理的详细论述。我只有明确回答，我不清楚。还好面试官没有为难我，最终还是顺利拿到了这家公司的offer。不过这个坑不填上，我还是有点寝食不安啊。最纳闷的是，为什么会问和数据一致性的关系呢？过了几天我脑袋终于转过弯了，他当时问的不是POSIX，而

3、重要的代码片段图片服务系统工程的示例代码放置在http://download.csdn.net/detail/yinwenjie/9740380这里，读者可以自行进行下载。3-1、Nginx中的ProxyCache配置根据前文对图片服务系统的系统架构规划，Nginx充当了第三级缓存的作用和对图片请求服务的负载均衡作用，所以在Nginx配置文件中，至少需要对NginxProxyCache功能和UpStream功能进行配置。以下为主要的Rewrite部分和负载均衡部分的配置：......upstreamimageserver{server192.168.61.1:8080;server192.

1、概述之前的两篇文章介绍了图片系统的技术组件选型和技术方案设计，从这篇文章开始我们将搭建工程进行详细的编码开发和效果测试。这里要说明一下，由于文章篇幅的限制不可能贴出所有的代码，这样也不符合读者的阅读习惯。所以笔者的办法是，只通过后续的文章内容介绍详细的设计要点和代码片段，通过这些讲解读者基本可以清楚整个详细设计的思路，而整个图片服务工程代码会上传到了CSDN的下载区（http://download.csdn.net/detail/yinwenjie/9740380），如果对工程感兴趣那么读者可以直接下载——免费下载。2、简单的图片处理2-1、位图的构成基础由于我们将要进行的是图片处理操作，

3-5、其它技术选型说明3-5-1、关于关系型数据库关于持久化存储的数据库技术要注意一点，实际上它并不是图片服务的必要组件。例如，我们在进行设计时可以将图片访问的URL地址直接对应图片文件在服务器上的存储地址，并按照一定的规则将图片文件重命名成一个系统中唯一的文件名，最后再删除Redis和NginxProxyCache中可能存在的历史文件数据。这样就算没有数据库技术，也可以保证图片服务正常工作。但是在上文描述的图片服务需求中，产品团队还明确要求需要对用户上传的规律、活跃度等状态信息进行统计，需要对图片的物理磁盘读操作频度进行统计分析，所以一些结构化的数据还是需要做持久化存储的。就拿图片的每日访

1、概述图片服务系统是各种针对C端系统常见的子系统，它的特点是存储规模大请求频度高，且单张图片的读请求远远高于写请求。后续几篇文章我们将从图片服务系统的需求分析开始，一起来讨论如何进行这类系统的技术选型、概要设计和详细设计，以及在这个过程中需要关注的技术难点。虽然由于写作计划的变化，图片服务系统中所涉及的分布式文件系统原理、非关系型数据库原理都还没有讲到，但这些知识点也并不是组成整个图片服务的所有关键点，并且后续的文章中我们会尽快补上对这些知识点的介绍。图片服务系统的讲述会分为四篇文章，前两篇文章我们主要分析图片服务的需求、架构选型和技术方案，后两篇文章进行性能优化和详细设计部分的讲解。由于不

1、概述通过上一篇文章（《架构设计：系统存储（17）——Redis集群方案：高可用》）的内容，Redis主从复制的基本功能和进行Redis高可用集群监控的Sentinel基本功能基本呈现给了读者。虽然本人并不清楚上一篇根据笔者实际工作经验所撰写的文章有什么重大问题，导致那么多朋友集体点踩而且截止目前又没有任何人愿意为笔者指出这些问题，但是这不会影响笔者继续学习、总结技术知识的热情。从这篇文章开始我们一起来讨论Redis中两种高性能集群方案，并且在讨论过程中将上一篇文章介绍的高可用集群方案结合进去。这两种高性能集群方案是：Twemproxy和Redis自带的Cluster方案。另外还是希望各位读

1、概述从本篇文章开始，我们将向读者介绍几种Redis的高可用高负载集群方案。除了介绍Redis3.X版本中推荐的原生集群方案外，还会介绍使用第三方组件搭建Redis集群的方法。本文我们会首先介绍Redis的高可用集群方案。2、Redis高可用方案Redis提供的高可用方案和我们介绍过的很多软件的高可用方案类似，都是使用主从节点的思路。即是有一个Master节点在平时提供服务，另外一个或多个Slave节点在平时不提供服务（或只提供数据读取服务）。当Master节点由于某些原因停止服务后，再人工/自动完成Slave节点到Master节点的切换工作，以便整个Redis集群继续向外提供服务。既然是要

3-4、事件功能和配置项Redis从2.X版本开始，就支持一种基于非持久化消息的、使用发布/订阅模式实现的事件通知机制。所谓基于非连接保持，是因为一旦消息订阅者由于各种异常情况而被迫断开连接，在其重新连接后，其离线期间的事件是无法被重新通知的（一些Redis资料中也称为即发即弃）。而其使用的发布/订阅模式，意味着其机制并不是由订阅者周期性的从Redis服务拉取事件通知，而是由Redis服务主动推送事件通知到符合条件的若干订阅者。Redis中的事件功能可以提供两种不同的功能。一类是基于Channel的消息事件，这一类消息和Redis中存储的Keys没有太多关联，也就是说即使不在Redis中存储任

1、综述Redis是一款内存数据库，所谓内存数据库是指它存储数据的主要介质是内存而非传统意义的磁盘，后者只用于辅助功能。Redis可以当作NoSQL数据库，缓存和消息代理来使用，目前各行业实践中使用Redis最多的场景还是把它当成缓存子系统，例如存储在线用户的登录情况，存储1小时内提交的订单情况等，缓存图片路径或者图片内容等等；其次较多的场景是作为消息代理来使用，例如DUBBO支持使用Redis进行事件订阅和通知。Redis的发起者是SalvatoreSanfilippo，最初开发它的目的就是为了解决快速存储和查询社交网站上常见的好友关系数据。目前Vmware在资助着Redis项目的开发和维护

4-6、主要分片规则上文提到MyCat的逻辑表支持多种分片规则，表现于schema配置文件中中table标签的rule属性。本节将以MyCatVersion1.6版为基础，介绍几种经常使用的分片规则，这些分片规则都通过rule.xml文件进行定义和配置。4-6-1、分片枚举sharding-by-intfile......<tableRulename="sharding-by-intfile"><rule><!--columns表示分片计算时的取值列，记得设置成您的数据表列名--><columns>sharding_id&lt

4-3、使用MyCat配置横向拆分之前文章中我们介绍了如何使用MyCat进行读写分离，类似的关系型数据库的读写分离存储方案可以在保持上层业务系统透明度的基础上满足70%业务系统的数据承载规模要求和性能要求。比起单纯使用LVS+Replicaion的读写分离方案而言最大的优势在于更能增加对上层业务系统的透明性。当然如果您觉得单个MyCat节点在高可用范畴或者性能范畴上还需要增强，还可以使用Keepalived、LVS等组件在多个MyCat节点上组成高可用集群或者负载集群。但是这个方案也有一个明显的问题，那就是它没有解决数据存储规模的瓶颈。如果单个节点上某个单表的数据规模超过了千万级，那么这个节点

4、改进方式三：MyCat数据库中间件在上文中我们介绍了MySQL读写分离集群的持续优化方式。按照这样的方式，集群中负责读写分离的MySQL节点基本上能够分别实现真对上层业务系统访问的透明化。这样的MySQL集群方式已经可以承载读者遇到的大部分业务系统的结构化数据规模，但整个集群方案还有一些明显的问题：首先就是业务开发人员始终还是需要分配一定的精力去分别管理读操作会话和写操作会话的数据库连接；其次这个集群方案主要解决的是单张数据表数据量不大条件下的MySQL读写性能（千万级数据，还有一个前提是数据表本身拥有符合业务要求的索引结构且数据节点的性能配置合理），如果数据库中单张数据表的规模达到了亿级

1、MySQL主从方案业务层的问题在之前的文章中，我们提到MySQL一主多从集群模式下，对上层业务系统的访问带来了一些问题。本编文章中我们将深入分析这个问题，并介绍如何对这个问题进行改进。MySQL一主多从集群对上层业务系统带来的主要问题是，上层业务系统需要自行控制本次MySQL数据操作需要访问MySQL集群中的哪个节点。产生这个问题的主要原因，是因为MySQL一主多从集群本身并没有提供现成功能，将集群中的节点打包成统一服务并向外提供。在上图所示的MySQL集群中，有一个Master节点负责所有的写事务操作，还有两个Salve节点分别负责订单模块的读操作和用户模块的读操作，而这个架构方案中由于

1、概述从本篇文章开始我们将花一定的篇幅向读者介绍MySQL的各种服务集群的搭建方式。大致的讨论思路是从最简的MySQL主从方案开始介绍，通过这种方案的不足延伸出更复杂的集群方案，并介绍后者是如何针对这些不足进行改进的。MySQL的集群技术方案特别多，这几篇文章会选择一些典型的集群方案向读者进行介绍。2、MySQL最简单主从方案及工作原理我们讲解的版本还是依据目前在生产环境上使用最多的Version5.6进行，其中一些特性在Version5.7和最新的Version8.0中有所改进，但这不影响读者通过文章去理解构建MySQL集群的技术思路，甚至可以将这种机制延续到MariaDB。例如马上要提到

4-3-3-3、避免死锁的建议上一篇文章我们主要介绍了MySQL数据库中锁的基本原理、工作过程和产生死锁的原因。通过上一篇文章的介绍，可以确定我们需要业务系统中尽可能避免死锁的出现。这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议。正确使用读操作语句经过之前文章介绍，我们知道一般的快照读是不会给数据表任何锁的。那么这些快照读操作也就不涉及到参与任何锁等待的情况。那么对于类似insert…select这样需要做当前读操作的语句（但又不是必须进行当前读的操作），笔者的建议是尽可能避免使用它们，如果非要进行也最好放到数据库操作的非高峰期进行（例如晚间）。基于索引进行写操作，避免基于表

4-3、InnoDB中的锁虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的，在索引、表结构、配置参数一定的前提下，InnoDB引擎加锁过程是一样的，所以理论上来说也就不存在“锁机制能够提升性能”这样的说法。但如果技术人员不理解InnoDB中的锁机制或者混乱、错误的索引定义和同样混乱的SQL写操作语句共同作用，那么导致死锁出现的可能性就越大，需要InnoDB进行死锁检测的情况就越多，最终导致不必要的性能浪费甚至事务执行失败。所以理解InnoDB引擎中的锁机制可以帮助我们在高并发系统中尽可能不让锁和死锁成为数据库服务的一个性能瓶颈。4-3-1、InnoDB中的锁类型本文讲解的锁机制主要依据

4、影响SQL性能的要素MySQL数据库的性能不止受到性能参数和底层硬件条件的影响，在这两个条件一定的情况下，开发人员对SQL语句的优化能力更能影响MySQL数据库的性能。由于MySQL中不同数据库引擎对SQL语句的处理过程不尽相同，所以对SQL语句的优化就一定要首先确定使用的数据库引擎的类型。例如MyISAM引擎中统计某一个数据表的总行数时，只需要读取出已保存好的数据总行数就OK了。但InnoDB引擎要完成这个动作，就必须进行tablescan/indexscan，而是否为被扫描的字段创建了索引又直接影响了扫描速度。本文我们和读者一起来讨论一下InnoDB数据引擎下SQL语句常见的工作方式和

3-3、突破I/O性能为了解决上一节中提到的I/O性能问题，本文这里基于之前介绍的块存储方案的知识，列出这个问题的几种解决方案。除了根据I/O吞吐量要求对MySQL数据库特别是InnoDB引擎的配置参数进行更改以外，本文提到的硬件层解决方法所需要花费的资金和能够得到的I/O性能和扩展能力基本上成正比。3-3-1、对MySQL中的I/O相关参数进行调整上一节我们已经对InnoDB数据库引擎（以下简称InnoDB引擎）进行事务操作时的I/O过程进行了简单说明，主要介绍了Logflush和Pagesflush两个过程。如果我们需要挖掘正式生产环境上MySQL数据库服务的性能潜力，那么对MySQL数据

1、MySQL概述从本文开始我们将讨论建立在块存储方案之上的关系型数据库的性能优化方案和集群方案。关系型数据库的选型将以创业公司、互联网行业使用最广泛的MySQL数据为目标，但是MySQL的安装过程和基本使用方法等知识并不在我们讨论的范围内。后续几篇文章我们首先讨论影响单个MySQL节点性能的主要因素，然后介绍MySQL读写分离、数据表横纵拆分的原理和技术方案。MySQL数据库目前已被Oracle收购，并发展处多个版本。目前使用最广泛且免费的MySQL版本是MySQLCommunity（社区版），另外还有三个付费的MySQL版本MySQLStandard（MySQL标准版）、MySQLEnte

6-2、Ext2和Ext3的区别在上文6-1小节中介绍的Ext文件系统结构主要适用于Ext2和Ext3文件系统，这两个版本的Ext文件系统在数据组织结构上基本上没有什么变化。Ext3文件系统相对于Ext2文件系统所做的主要优化在数据写入策略上。6-2-1、Ext2写入过程概要Linux操作系统为了加快I/O操作过程，当有文件需要写入文件系统时Linux操作系统并不会立刻将文件数据实际写入datablock，而是存储到一个内存区块中。如果您通过top命令或者Free命令，就可以看到这个名叫cachememory的内存区块。[root@lab-backup~]#freetotalusedfrees

5-2、磁盘阵列设备目前磁盘阵列设备被广泛应用在从民用级计算到工业级计算的各个基础领域，本小节的内容就带各位读者进行一些概要性了解。集成在主板上的阵列控制器最廉价的，也是在民用级市场上最普遍的做法，是将阵列控制器直接集成在主板上。RAID0、RAID1、RAID5、RAID10等阵列组织结构都可以在这种集成方式下提供支持。这些主板的价格可以做得很亲民，但是这样的阵列控制器集成方案也存在比较明显的问题：支持的磁盘数量有限制，总的I/O吞吐性能也存在瓶颈。磁盘阵列盒另一种做法是将阵列控制器至于计算机以外，民用级市场和企业级市场上也经常使用这种集成方式，并且效果要好得多，因为至少从可集成的磁盘数量上

4-2、固态硬盘工作过程本小节我们要解决一个关键问题：既然机械硬盘和固态硬盘从工作原理、制作工艺、技术规范等多个方面都完全不一样，那为什么无论硬件层是使用机械硬盘还是固态硬盘操作系统却都可以进行识别，并在其上进行数据读写呢？这个问题中，计算机系统不同层次对数据操作最小单位的定义不一致都还是一个小问题：虽然机械硬盘上数据操作单元为512字节、固态硬盘上数据操作单元为4KB、操作系统层面定义的数据操作单元可能是1KB\2KB\4KB\8KB等等。但是只要这些层次上的文件起始地址都是固定的，则各层的地址对应关系就可以找到的。也就是说操作系统上的地址X可以映射到机械硬盘的地址Y又或者映射到固态硬盘的地

1、概述在“系统存储”专题中，我们将按照“从上至下”的顺序向读者介绍整个“系统存储”体系。在这个专题中我们将至少介绍机械硬盘的主要结构、磁盘阵列的分类、操作系统的EXT文件系统、NAS文件共享存储方案、分布式文件系统重要技术点和分布式文件系统示例。最后如果有时间我们将自行设计一款分布式文件系统。下图可以大致描述笔者的写作思路：本专题首先会花费几篇文章向读者介绍块存储的知识，包括最底层机械硬盘、固态硬盘的构造结构和工作过程。块存储的知识中我们还将介绍磁盘阵列技术，包括磁盘阵列的组织方式和设备类型。最后块存储知识中我们介绍操作系统中的文件系统，包括EXT系列文件系统和XFS文件系统（会顺带提到Wi