分布式存储

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

Redis数据量日益增大，使用的公司越来越多，不仅用于做缓存，同时趋向于存储这一块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，保证单实例内存增大带来的一系列问题，下面所列出的codis方案目前正在不断测试过程中，测试过程没有展示出来，主要从以下几点出发。 测试架构 和性能 ： 　　1、keepalived+haproxy故障测试 　　2、Zookeeper集群节点测试 　　3、Codis-proxy集群节点测试 　　4、Codis-server集群节点测试 　　5、脚本写入大量测试数据并模拟数据迁移 　　6、性能测试 下面具体介绍codis和其他几大集群方案 集群方案： 　　1、 主从高可用（该方案就是单实例形式，只是为了保证数据的安全，对于用户数据少，业务的前期可以采用，目前我司缓存架构就是采用该方案） 　　2、 客户端分片（典型代表：Jedis。自主写分片算法，代码掌握在自己手中，可控性强，但是需要专业的开发运维人员维护，技术要求和维护成本高） 　　3、代理分片（典型代表：Twemproxy，redis集群没有正式推出之前官网推荐的方案，也是目前使用最多的） 　　4、 Redis cluster（3版本推出的集群方案，历时四年之多的开发） 　　5、 Codis集群（豌豆荚15年开源的解决方案

引言 本文通过对卷类型的分析对比，来帮助读者选取生产环境最符合服务的挂载存储，命令可结合《 glusterfs详解及kubernetes 搭建heketi-glusterfs 》进行实验，下面进入正题 几种卷类型 基础卷：布式卷（distribute）、条带卷（stripe）、复制卷（replica）、纠错卷（Dispersed ） 复合卷：分布式条带卷（distribute stripe）、分布式复制卷（distribute replica）、条带复制卷（stripe replica）、分布式条带复制卷（distribute stripe） 一、基础卷 以下创建挂载卷，均可通过以下命令进行查看、启用、停止、删除 #查看已创建挂载卷 gluster volume info #启动挂载卷 gluster volume start gv0 #删除前，先停止挂载卷 gluster volume stop gv0 #删除挂载卷 gluster volume delete gv0 1. 布式卷（distribute voulme） 分布式模式，既DHT，是GlusterFS的默认模式，在创建卷时，默认选项是创建分布式卷。在该模式下，并没有对文件进行分块处理，而是通过hash算法分布到所有brick server上，只是扩大了磁盘空间，类似window中的跨区卷 distribute

用分布式存储VSAN实现Harbor Registry的高可用方案 陈实 张海宁 不久前，VMware发布了Docker容器数据卷的驱动（Docker Volume Driver for vSphere）1.0 beta版本，使得Docker宿主机能够直接在vSphere的数据存储(VSAN,VMFS,NFS等)中创建卷，并直接挂载到Docker容器中，可以解决Docker容器的数据持久化存储的问题。不仅可以提供存储，这些卷还能利用vSphere的“基于存储策略的管理（SPBM, Storage Policy Based Management）”, 按需设置更高的“可容忍主机故障数(FTT)”、设置更大的“条带数(SW)”等，以获得更高级别的数据保护和更好的性能。此驱动为开源项目，下载地址： https://github.com/vmware/docker-volume-vsphere 在容器应用架构中，Registry（容器镜像仓库）是必不可少的组件，负责保存和发布容器镜像，高效可靠的Registry是确保容器应用运行的基础。本文通过详细的步骤，来说明如何在分布式存储Virtual SAN (VSAN)中创建数据卷，并以开源企业级Harbor Registry为例，把镜像和数据库数据持久化到数据卷中，从而达到更好的数据保护和高可用性(HA)的目的。本文涉及的Harbor

基于GridFS构建分布式文件系统 首先看看什么是GridFS: GridFS is a mechanism for storing large binary files in MongoDB. There are several reasons why you might consider using GridFS for file storage: • Using GridFS can simplify your stack. If you’re already using MongoDB, GridFS obviates the need for a separate file storage architecture. • GridFS will leverage any existing replication or autosharding that you’ve set up for MongoDB, so getting failover and scale-out for file storage is easy. • GridFS can alleviate some of the issues that certain filesystems can exhibit when being used to store user uploads. For

一、MooseFS介绍 　　MooseFS主要由管理服务器（master）、元日志服务器（Metalogger）、数据存储服务器（chunkserver）构成。 管理服务器：主要作用是管理数据存储服务器，文件读写控制、空间管理及节点间的数据拷贝等。 元日志服务器：备份管理服务器的变化日志，以便管理服务器出问题时能恢复工作。 数据存储服务器：听从管理服务器调度，提供存储空间，接收或传输客户数据等。 MooseFS的读过程如图所示： 总结：MooseFS结构简单，适合初学者理解分布式文件系统的工作过程，但MooseFS具有单点故障隐患，一旦master无法工作，整个分布式文件系统 都将停止工作，因此需要实现master服务器的高可用（比如heartbeat+drbd实现） 　　　 二、集群部署： 主机环境:RHEL6.5 selinux and iptables disabled Master:172.25.10.2 (HA) 172.25.10.3 (HA) VIP 172.25.10.100 ##Metalogger: 192.168.0.77 Chunkserver: 172.25.10.6 172.25.10.7 172.25.10.8 Client: 172.25.10.4 172.25.10.5 (iSCSI) 生成 rpm,便于部署: # yum install gcc

前言 一般单机或者单数据库的项目可能规模比较小，适应的场景也比较有限，平台的访问量和业务量都较小，业务ID的生成方式比较原始但是够用，它并没有给这样的系统带来问题和瓶颈，所以这种情况下我们并没有对此给予太多的关注。但是对于大厂的那种大规模复杂业务、分布式高并发的应用场景，显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成，而且在分布式环境下这种方式已经无法满足业务的需求，不仅无法完成业务能力，业务ID生成的速度或者重复问题可能给系统带来严重的故障。所以这一次，我们看看大厂都是怎么分析和解决这种ID生成问题的，同时，我也将我之前使用过的方式拿出来对比，看看有什么问题，从中能够得到什么启发。 分布式ID的生成特性 在分析之前，我们先明确一下业务ID的生成特性，在此特性的基础上，我们能够对下面的这几种生成方式有更加深刻的认识和感悟。 全局唯一 ，这是基本要求，不能出现重复。 数字类型，趋势递增 ，后面的ID必须比前面的大，这是从MySQL存储引擎来考虑的，需要保证写入数据的性能。 长度短 ，能够提高查询效率，这也是从MySQL数据库规范出发的，尤其是ID作为主键时。 信息安全 ，如果ID连续生成，势必会泄露业务信息，甚至可能被猜出，所以需要无规则不规则。 高可用低延时 ，ID生成快，能够扛住高并发，延时足够低不至于成为业务瓶颈。 分布式ID的几种生成办法

花擦节 闪电购拼团狂欢节 微信中打开：http://www.52shangou.com/buyer/pintuan/index.html Codis作者黄东旭细说分布式Redis架构设计和踩过的那些坑们 2015-07-06 黄东旭 高可用架构 此文根据【QCON高可用架构群】分享内容，由群内【编辑组】志愿整理，转发请注明出处。 黄东旭，Ping CAP CTO，开源项目Codis的co-author。之前在豌豆荚从事infrastructure相关的工作，现在在创业公司PingCAP，方向依然是分布式存储领域(NewSQL)。 本次分享的内容主要包括五个大部分： Redis、RedisCluster和Codis; 我们更爱一致性; Codis在生产环境中的使用的经验和坑们; 对于分布式数据库和分布式架构的一些看法; Q & A环节。   Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正。 一、 Redis，RedisCluster和Codis    Redis ：想必大家的架构中，Redis已经是一个必不可少的部件

“数据不能丢，服务不能停”，可以说这句话道出了用户对数据库的核心能力的要求。然而，传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库，基于普通PC服务器，就能够做到传统高端硬件环境下的数据可靠性和服务可用性，而且还能做得更好！跟我们一起看看OceanBase的技术秘诀吧！ Part1 前言 说到数据可靠性和服务可用性，在数据库领域真是老生常谈的话题，可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求，可以借用OceanBase数据库创始人阳振坤老师的一句话：“数据不能丢，服务不能停”。可以说，这句话也道出了用户对数据库的一个核心能力要求：除了功能完善、使用方便之外，还要绝对安全、足够健壮。可以说，为了满足这两个看似简单的要求，在数据库领域诞生了大量的技术和论文，也让无数人绞尽了脑汁。 在传统的商业数据库产品（如Oracle、DB2）中，虽然也有一些行之有效的软件技术（如Redo Log、主从热备技术等）用来提高数据可靠性和服务可用性，但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器（如IBM 的Mainframe、AS400、Power等）和EMC、IBM等厂商的高端存储产品，能够很好的保证硬件的稳定性，因此也就成为了Oracle为代表的传统数据库产品的理想平台