duxingxia356的专栏

转载 淘宝Oceanbase云存储系统实践

通俗地讲，云计算就是把基础设施以服务的形式打包对外销售，它是一种商业模式，而其中的云存储是技术难点。可以从两个维度分析云存储系统的特性：功能和可扩展性，这是一个“鱼和熊掌”不容易兼得的问题。不同的数据规模，不同的事务和一致性要求，不同的系统故障容忍度，都可能导致不同的存储系统设计。国外的互联网巨头Amazon、Google、Microsoft、Yahoo都有各自的云存储系统，国内的淘宝也研发了自己

转载 Linux 2.4.x 网络协议栈QoS模块(TC)的设计与实现

在传统的TCP/IP网络的路由器中，所有的IP数据包的传输都是采用FIFO（先进先出），尽最大努力传输的处理机制。在早期网络数据量和关键业务数据不多的时候，并没有体现出非常大的缺点，路由器简单的把数据报丢弃来处理拥塞。但是随着计算机网络的发展， 数据量的急剧增长，以及多媒体，VOIP数据等对延时要求高的应用的增加。路由器简单丢弃数据包的处理方法已经不再适合当前的网络。单纯的增加网络带宽也不能从根本

转载 怎么跳出MySQL的10个大坑

MySQL · 性能优化· Group Commit优化背景关于Group Commit网上的资料其实已经足够多了，我这里只简单的介绍一下。众所周知，在MySQL5.6之前的版本，由于引入了Binlog/InnoDB的XA，Binlog的写入和InnoDB commit完全串行化执行，大概的执行序列如下： InnoDB prepare （持有prepare_c

转载 原子性（CPU核\总线\周期\锁）

如何看Linux是多少位的CPUuname -anCPU的位宽一般是以 min{ALU位宽、通用寄存器位宽、数据总线位宽}决定的！也就是说CPU由ALU、通用寄存器、数据总线三者之中最少的位宽决定！所以CPU位宽与其寻址能力并不是挂钩的！32 位 x86 CPU 包括 8 个通用寄存器。64 位 x64 处理器有 16 个寄存器。 64 位处理器（以及为它们编写

转载 多线程程序中操作的原子性

04/15/2010并行编程原子操作、多核、多线程编程、线程安全0. 背景原子操作就是不可再分的操作。在多线程程序中原子操作是一个非常重要的概念，它常常用来实现一些同步机制，同时也是一些常见的多线程Bug的源头。本文主要讨论了三个问题：1. 多线程程序中对变量的读写操作是否是原子的？2. 多线程程序中对Bit field（位域）的读写操作是否是线程安全的？3. 程序员该如何使用

转载 关于单CPU，多CPU上的原子操作

https://software.intel.com/zh-cn/blogs/2010/01/14/cpucpu/所谓原子操作,就是"不可中断的一个或一系列操作" 。硬件级的原子操作：在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是" 原子操作"，因为中断只能发生于指令之间。这也是某些CPU指令系统中引入了test_and_set、test_

转载 8086 CPU 寄存器简介

引子打算写几篇稍近底层或者说是基础的博文，浅要介绍或者说是回顾一些基础知识，自然，还是得从最基础的开始，那就从汇编语言开刀吧，从汇编语言开刀的话，我们必须还先要了解一些其他东西，像  CPU ，内存这些知识点还是理解深刻一点的比较好，所以这一篇博文就绕着 80x86  CPU 中寄存器的基础部分下手，至于其他的一些将会在后续的博文中介绍 。同时在这里说明一下，本篇博文介绍的

转载 MySQL系列：innodb源码分析之内存管理

在innodb中实现了自己的内存池系统和内存堆分配系统，在innodb的内存管理系统中，大致分为三个部分：基础的内存块分配管理、内存伙伴分配器和内存堆分配器。innodb定义和实现内存池的主要目的是提供内存的使用率和效率，防止内存碎片和内存分配跟踪和调试。我们先来看看他们的关系和结构。以下是它的关系结构图：上图中的：ut_mem_block块是基础内存管理

转载 MySQL系列：innodb源码分析之mini transaction

日志是innodb一个非常重要的模块，在innodb中有两类日志：redo log和undo log。其中redolog日志是用来做数据异常恢复和数据库重启时页数据同步恢复的，redo log是建立在在mini transaction基础上。数据库在执行事务时，通过minitransaction产生redo log来保证事务的持久性。1.mini transaction三个协议  

转载 MySQL系列：innodb源码分析之redo log恢复

在上一篇《innodb源码分析之重做日志结构》中我们知道redo log的基本结构和日志写入步骤，那么redo log是怎么进行数据恢复的呢？在什么时候进行redo log的日志推演呢？redo log的推演只有在数据库异常或者关闭后，数据库重新启动时会进行日志推演，将数据库状态恢复到关闭前的状态。那么这个过程是怎么进行的呢？以下我们逐步来解析。1.recv_sys_t结构 i

转载 MySQL系列：innodb源码分析之重做日志结构

在innodb的引擎实现中，为了实现事务的持久性，构建了重做日志系统。重做日志由两部分组成：内存日志缓冲区(redo log buffer)和重做日志文件。这样设计的目的显而易见，日志缓冲区是为了加快写日志的速度，而重做日志文件为日志数据提供持久化的作用。在innodb的重做日志系统中，为了更好实现日志的易恢复性、安全性和持久化性，引入了以下几个概念：LSN、log block、日志文件组、che

转载 MySQL系列：innodb源码分析之page结构解析

在表空间结构分析当中，我们知道innodb的最小物理存储分配单位是page页，在MySQL-3.23版本的源码中，页只有两种页，一种是index page，一种是undo page。其类型值定义在fil0fil.h当中。                FIL_PAGE_INDEX                         数据索引页，在表空间的inode page和xdes pa

转载 MySQL系列：innodb源码分析之文件IO

innodb作为数据库引擎，自然少不了对文件的操作，在innodb中所有需要持久化的信息都需要文件操作，例如：表文件、重做日志文件、事务日志文件、备份归档文件等。innodb对文件IO操作可以是煞费苦心，其主要包括两方面，一个是对异步io的实现，一个是对文件操作管理和io调度的实现。在MySQL-5.6版本的innodb还加入了DIRECT IO实现。做了这么多无非是优化io操作的性能。在inno

转载 MySQL系列：innodb源码分析之表空间管理

innodb在实现表空间（table space）基于文件IO之上构建的一层逻辑存储空间管理，table space采用逻辑分层的结构：space、segment inode、extent和page.在实现层的逻辑使用了磁盘链表这种结构来管理逻辑关系。我们先来介绍磁盘链表。1.磁盘链表磁盘链表的实现fut0lst.*文件当中， innodb为了管理表空间和索引模块，定义了一个基于磁

转载 mysql日志 二

- 数据是什么  从不同的角度和层次来看，我们可以将数据库中的数据看作：  A. 关系数据  B. 元组或对象  C. 存在Page中的二进制序列  因此Log中也可以记录不同的内容：- 物理的日志(Physical Log)  A. 记录完整的Page  B. 记录Page中被修改的部分(page中的偏移,内容和长度).  优点：因为恢复时

转载 mysql日志 一

1.  概述很多企业选择MySQL都会担心它的数据丢失问题，从而选择Oracle，但是其实并不十分清楚什么情况下，各种原因导致MySQL会丢失部分数据。本文不讨论Oracle和MySQL的优劣，仅仅关注MySQL丢失数据的几种情况。希望能够抛砖引玉，让各位MySQL大牛们梳理出MySQL最安全或者性价比合适的适合各种应用场景的方案。2.  问题定义一般我们希望把一系列的数据作为一个

转载 云存储中的数据完整性校验——综述

问题的提出云存储就是将储存资源放到云上供人存取的一种新兴方案。使用者可以在任何时间、任何地方，透过任何可连网的装置连接到云上方便地存取数据。大量的用户数据都是放在云服务器上，对数据的安全性保障是提高云服务商服务质量及用户愿意享受云存储服务的前提和保障。在云计算出现以前，用户的数据通常保存在本地。如果用户想确定自己的数据是否完整，最简单的方法是亲自查看一下数据，就可以知道

转载 大规模分布式系统问题集及解决方案(学习)

大规模分布式系统问题集及解决方案单点一致性更新问题问题描述：当多个用户同时更新某个数据时，如何保证最终数据的一致性。如用户A,B更新数据D，A->D+1, B->D+1，最终结果D+2。解决方案：采用数据版本保证所有的更新都基于最新版本的数据。如原始数据(D，n)，A，B均拿到(D，n)，A更新后，数据(D+1，n+1)；此时B版本过时，更新失败，强制刷新数据后，更新数据为(D+2,n

转载 GFS架构分析

Google文件系统（Google File System，GFS）是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。GFS是Google云存储的基石，其它存储系统，如Google Bigtable，Google Megastore，Google Percolator均直接或者间接地构建在GF

转载 Understanding HBase and BigTable

Understanding HBase and BigTableThe hardest part about learning HBase (the open source implementation of Google's BigTable), is just wrapping your mind around the concept of what it actually is.

转载 从Google Spanner漫谈分布式存储与数据库技术

Spanner的设计反映了Google多年来在分布式存储系统领域上经验的积累和沉淀，它采用了MegastoreDull the shows. Is elocon over the counter I’ve more. Already is http://www.evacloud.com/kals/pharmacy-canada-cialis/ were manufacturing

转载 DRY原则和Shy原则

保障可维护性的主要诀窍是遵循DRY原则和Shy原则。 在一个系统的整个生命周期里，理解和改动这类维护工作的比例一般非常之高。为了维护的方便，要尽量将系统划分为可以独立理解与改动的模块。这就要在设计的时候注重DRY原则与Shy原则。不过，这两条原则有一定的冲突，并不总能兼得，于是在追求的时候要重视分寸。维护者的两大困扰有两种情况会给维护者增添很大的麻烦：一种是为了调整一个效果，要改动

转载 hadoop

1          Hadoop1          Hadoop是什么Hadoop原来是Apache Lucene下的一个子项目，它最初是从Nutch项目中分离出来的专门负责分布式存储以及分布式运算的项目。简单地说来，Hadoop是一个可以更容易开发和运行处理大规模数据的软件平台。下面列举hadoop主要的一些特点： 1         扩容能力（Scalabl

转载 分布式系统漫谈一 ——　Google三驾马车: GFS,mapreduce,Bigtable

分布式系统漫谈一 ——　Google三驾马车: GFS,mapreduce,Bigtable 谈到分布式系统，就不得不提Google的三驾马车:Google fs[1],Mapreduce[2],Bigtable[3]。虽然Google没有公布这三个产品的源码，但是他发布了这三个产品的详细设计论文。而且，Yahoo资助的Hadoop也有按照这三篇论文的开源Java实现:Ha

转载 谷歌技术"三宝"之谷歌文件系统

题记：初学分布式文件系统，写篇博客加深点印象。GFS的特点是使用一堆廉价的商用计算机支撑大规模数据处理。虽然"The Google File System " 是03年发表的老文章了，但现在仍被广泛讨论，其对后来的分布式文件系统设计具有指导意义。然而，作者在设计GFS时，是基于过去很多实验观察的，并提出了很多假设作为前提，这等于给出了一个GFS的应用场景。所以我们自己在设计分布式系统时，一

转载 谷歌技术"三宝"之MapReduce

江湖传说永流传：谷歌技术有"三宝"，GFS、MapReduce和大表（BigTable）！谷歌在03到06年间连续发表了三篇很有影响力的文章，分别是03年SOSP的GFS，04年OSDI的MapReduce，和06年OSDI的BigTable。SOSP和OSDI都是操作系统领域的顶级会议，在计算机学会推荐会议里属于A类。SOSP在单数年举办，而OSDI在双数年举办。那么这篇博客就来

转载 谷歌技术"三宝"之BigTable

2006年的OSDI有两篇google的论文，分别是BigTable和Chubby。Chubby是一个分布式锁服务，基于Paxos算法；BigTable是一个用于管理结构化数据的分布式存储系统，构建在GFS、Chubby、SSTable等google技术之上。相当多的google应用使用了BigTable，比如Google Earth和Google Analytics，因此它和GFS、MapRed

转载 分布式基础学习【二】 —— 分布式计算系统（Map/Reduce）

分布式式计算，同样是一个宽泛的概念，在这里，它狭义的指代，按Google Map/Reduce框架所设计的分布式框架。在Hadoop中，分布式文件系统，很大程度上，是为各种分布式计算需求所服务的。我们说分布式文件系统就是加了分布式的文件系统，类似的定义推广到分布式计算上，我们可以将其视为增加了分布式支持的计算函数。从计算的角度上看，Map/Reduce框架接受各种格式的键值对文件作为输入，读取计算

转载 分布式基础学习【一】 —— 分布式文件系统

分布式基础学习所谓分布式，在这里，很狭义的指代以Google的三驾马车，GFS、Map/Reduce、BigTable为框架核心的分布式存储和计算系统。通常如我一样初学的人，会以Google这几份经典的论文作为开端的。它们勾勒出了分布式存储和计算的一个基本蓝图，已可窥见其几分风韵，但终究还是由于缺少一些实现的代码和示例，色彩有些斑驳，缺少了点感性。幸好我们还有Open Source，还

转载 MongoDB

1.1、为什么要用NoSQL1.1.1、NoSQL简介NoSQL，全程Not Only SQL，指的是非关系型的数据库，这类数据库主要有这些特点：非关系型的、分布式的、开源的、水平可扩展的，原始的目的是为了大规模web应用，这场全新的数据库革命运动早期就有人提出，发展至2009年趋势越发高涨，NoSQL的拥护者们提倡运用非关系型的数据存储，通常的应用如：模式自由、支持建议复制、简单

转载 分布式流式计算平台-S4

关于yahoo s4有官方网站：http://s4.io/， 也可以查看英文paper: S4:Distributed Stream Computing Platform, 中文翻译：http://wenku.baidu.com/view/fdfa4ef7f61fb7360b4c653a.html， 不过看完paper以后再看一下这篇文章能够让你对s4理解的更好些。下面内容来源于：ht

转载 Key-value存储

Key-value存储简介具备高可靠性及可扩展性的海量数据存储对互联网公司来说是一个巨大的挑战，传统的数据库往往很难满足该需求，并且很多时候对于特定的系统绝大部分的检索都是基于主键的的查询，在这种情况下使用关系型数据库将使得效率低下，并且扩展也将成为未来很大的难题。在这样的情况下，使用Key-value存储将会是一个很好的选择。它被广泛应用于缓存，搜索引擎等等领域。所谓的Key-Val

转载 立体化监控

转载 Linux性能指标

一、CPU1、良好状态指标CPU利用率：User Time User Time + System Time 。上下文切换：与CPU利用率相关联，如果CPU利用率状态良好，大量的上下文切换也是可以接受的。可运行队列：每个处理器的可运行队列。2、监控工具vmstat$ vmstat 1procs -----------memory---------- -

转载 百度、新浪、Mixi、Apache社区赞助的开源key-value分布式存储系统

key-value分布式存储系统查询速度快、存放数据量大、支持高并发，非常适合通过主键进行查询，但不能进行复杂的条件查询。如果辅以Real-Time Search Engine（实时搜索引擎）进行复杂条件检索、全文检索，就可以替代并发性能较低的MySQL等关系型数据库，达到高并发、高性能，节省几十倍服务器数量的目的。以MemcacheDB、Tokyo Tyrant为代表的key-value分布式存

转载 分布式文件系统设计主要关注几个方面

分布式文件系统设计主要关注几个方面：设计特点、分布式能力、性能、容灾、维护和扩展、成本 分布式文件系统主要关键技术：全局名字空间、缓存一致性、安全性、可用性、可扩展性 其他关键技术：文件系统的快照和备份技术、热点文件处理技术、元数据集群的负载平衡技术、分布式文件系统的日志技术  一、GFS（google file sy