---

layout: post
title: "云计算系统的容错和故障恢复1 2"
category: Reading Notes

tags: ["读文章", "分布式系统"]

{% include JB/setup %}

  • 多副本的数据

    云计算分布式文件系统保存了数据的多个副本(GFS缺省保存3份)

  • Worker故障

    master通过内置的heartbeat/lease监控所有worker的状态,一旦确认某个worker故障,master会把该worker保存的数据的副本个数减一。

  • Master故障

    为了避免master成为系统的单点,master也有多个副本

  • 应用程序容错

    当应用程序需要使用数据时,云计算客户端库将询问云计算系统的master获得数据副本锁在的位置,并向其中一个副本(通常是与该客户端网络“距离”最近的)发出数据请求,如果该worker在开始或者中途出现故障或因为其他原因无法完成请求,则云计算客户端库会自动转向另外一个副本,这对上层应用是完全透明的。

2015/10/25

---

layout: post
title: "云计算之分布式计算系统"
category: Reading Notes

tags: ["读文章", "Map/Reduce", "分布式系统"]

{% include JB/setup %}

  1. Google创造性地把Map/Reduce模型成功地应用到了云计算系统中,极大地降低了云计算系统应用程序的开发难度且提高了云计算系统的并行度和运行效率,这就是云计算的分布式计算系统。

  2. 它的基本原理是:每个应用程序被分成map函数和reduce函数,都由应用程序开发者编写,map函数的输入是 < key, value >对,输出的是中间结果< key, value >对,云计算分布式计算系统对这些中间结果按reduce分组,然后传给对应的reduce函数,reduce函数以迭代器的方式接受这些中间结果并进行合并等处理,然后输出所需的内容。例如,以海量文档的单词个数的统计问题为例,map函数输出的中间结果可以是:< 单词,"1" >

云计算的分布式计算系统的主要优点是:

1. 应用程序开发者不需要设计、编写和调试并行程序

开发者只需要设计、编写和调试普通的串行程序,即map函数和reduce函数,调试通过后提交到云计算系统,由云计算分布式系统框架把他们分发到成百上千台计算机(云计算的worker)上运行,并汇总和返回运行后的结果。

云计算分布式计算系统的master根据用户设置自动把作业切分为许多map任务和reduce任务,然后以按需的方式分配map和reduce任务到所有的worker上,每个worker完成一个任务后就报告给master,master就给该worker再分配一个map或reduce任务,该worker执行新分配的任务...,如此直到所有任务执行完。

2. 适于异构集群

快的worker执行更多的任务,慢的worker执行较少的任务。

由于整个作业被切分成许多map任务和reduce任务,worker故障后,只要再次执行对应的map和reduce任务即可;master则定期记录检查点(checkpoint),一旦master异常,新的master读入最后一次检查点。

云计算的分布式计算系统也有自身的局限性。云计算分布式系统的易用和高效建立在Map/Reduce模型的基础上。Map/Reduce模型要求切分出来的map和reduce可以多次以任意顺序执行而没有副作用。绝大部分应用能够适用于该模型,不适合的应用也常常能够找到可用的近似算法。

2015/10/25

---

layout: post
title: "云计算之分布式表格系统"
category: Reading Notes

tags: ["读文章", "Big Table", "分布式系统"]

{% include JB/setup %}

云计算的分布式表格依赖于下层的分布式文件系统(如Google的GFS)提供可靠和高效的数据存储,也是分布式文件系统的主要使用者。

行是二进制串,最大长度为64Kb。对统一行内的数据的读写总是原子的。

分布式表格系统总是把整个表格按照行排序(字典序),然后按整行动态划分,每个划分后的块称为一个子表(tablet,在google的Bigtable中,每个子表一般不超过256MB),子表也是分布式表格系统的worker加载/卸载和负载平衡的基本单元。

例如在网页库表格中,行是网页的URL,但其中的域名部分被颠倒了,

例如maps.google.com/index.html变成了com.google.maps/index.html,

这样使得域名相似的网页聚集在一起,由于域名相似的网页在内容上往往有一定的相似性,因此可以产生更高的压缩倍率,并使得一些应用程序更加高效。

列按(column family)列族分组,同一列族内的单元格的内容常常相同,并用修饰词(qualifier)区分不同的单元格,即column="family:qualifier"。一个表格内的列族个数是有限的且一般由可打印字符组成,但修饰词(qualifier)的个数没有任何限制且可以是任意字符。

Bigtable还允许用户把内容相似或相关的列族组成局部群组(locality group),同一局部群组内的列族的数据常常存放在一起,这样可以加快他们的访问速度;用户还可以把某些局部群组设定为装入内存。

列族是权限控制的基本单元。也就是说数据添加,查找,修改都要合适的权限。

局部群组则是数据压缩的基本单元,用户可以对不同的局部群组指定不同的压缩算法或者同一压缩算法的不同参数。

时间戳是64位整数,可以用来表示真正的时间,这时它的单位是微秒,时间戳也可以是用户指定的任意值。

Bigtable采用了3层B+树结构来存储表格数据,第三层为用户数据层(user data tablets),第二层为元数据索引层(metadata tablets),用来索引用户数据tablets,第一层为根索引层(root tablet),用来索引第二层数据。根索引层和元数据索引层的主要数据被设置为装入内存,应用程序需要访问用户数据时,Bigtable会根据需要依次访问root tablet和metadata tablets,这使得系统仅仅在访问用户数据时才访问磁盘。

REFERENCE

2015/10/25

---

layout: post
title: "大规模云计算平台的技术挑战"
category: Reading Notes

tags: ["读文章", “云计算”]

{% include JB/setup %}

飞天大规模分布式计算平台是一个由多个组件所构成的复杂的分布式系统,其中的核心组件是以下两个子系统:

  1. 计算资源调度系统:管理和调度集群计算资源;在多个云服务间动态分配计算资源;自动检测服务器故障并迁移故障服务器上的服务。
  2. 分布式文件系统:管理集群的所有硬盘;合理地安排数据存放位置以兼顾性能和数据安全性;自动检测磁盘故障并复制数据以保证安全。

实现云计算平台的过程中所面临的技术挑战:

  1. 在不可靠硬件基础上提供高可靠的计算能力和存储能力;
  2. 提供高可用服务;
  3. 低成本运维海量硬件;
  4. 在线应用与离线应用共存;
  5. 克服节点间宽带的限制;
  6. 最大化利用计算资源,等等

一、不可靠的硬件是最基本的挑战:

集群规模达到上千台后,单机上的小规模事件变成了必然的、频繁发声的事件。我们称之为“硬”故障。还有一类称之为“软”故障,例如,硬盘可访问但速度只有正常的1/10、服务器没有宕机但程序运行缓慢、网络时好时坏等。

硬、软故障发声都会对系统的可靠性甚至可用性造成不良影响,因此如何及时有效地进行故障检测和恢复就变得比较关键。

检测“软”故障有两种思路。

一种是针对每种具体故障设计检测方法。

一种是从宏观现象来检测。

例子1:检测作业在某个服务器上执行特别缓慢的情况。
统计每个作业在每台服务器上的执行事件。因为输入数据被均匀地切片,每台服务器上的执行时间应该大致相同。如果某台服务器上的执行时间超过了平均时间的三倍,它就被标记为“缓慢”。如果各种不同作业在某台服务器上都“缓慢”,那么我们有充分的理由怀疑这台服务器有问题。调度系统会自动把这台服务器**加入黑名单**,不再用它执行作业。之后再自动或人工检查这些可疑服务器的具体故障原因。

例子2:检测磁盘读写慢的情况。
我们在分布式文件系统里也会统计每次磁盘访问的时间。如果某块磁盘有大比率的访问时间远远超过系统平均值,那么很有可能是这块磁盘快要发声故障了。文件系统此时会做三件事:
* 停止写新数据到这块磁盘,防止更多数据处于危险中;
* 开始为这块磁盘上的数据增加更多副本;
* 当这块磁盘上的所有数据都有额外的副本,就可以将它下线,待运维处理。

二、故障自动恢复的策略:

Amazon EC2大规模停机事件
事故起因是Amazon对集群网络做日常维护升级时操作错误,网络流量被全部切换到备用网络,导致备用网络过载。自动故障恢复机制检测到网络不同,以为服务器大量宕机,马上开始数据复制以替换‘宕机’的服务器上的数据副本,引发了‘镜像风暴’(大量服务器同时尝试创建数据镜像)。而由此增加的数据流量更加剧了网络过载,从而使故障在集群中蔓延,进入恶性循环。最终采取了包括暂时关闭自动故障恢复系统和增加硬件在内的多个措施。

我们的策略是限制故障自动恢复机制的作用范围:

  • 正常情况下,任何时候集群中都有且仅有很小比例的服务器发生故障,此时自动恢复有效,即使无效也不会造成灾难(上限是1%的硬盘);
  • 如果发生大规模故障,明智的策略是尽量降低系统负载,暂时禁止掉前面提到的自动恢复逻辑。

三、数据可靠性和实时性能优化:

为了保证数据安全性,文件系统对所有的数据均采用了多份拷贝。在创建文件时,用户可以指定文件数据的拷贝数目,文件系统会保证数据分布在不同节点和不同的机架上,使得单个硬件故障不会造成数据无法访问。

多副本技术被广泛采用但是会导致数据写入的延迟增大,因为只有当所有副本都写成功后才能结束一个写操作

可以通过文件日志文件来解决此问题。把日志文件写入磁盘,只要数据文件进入指定数量服务器的内存即可认为是写成功;后天线程随后会把内存中的数据批量写入磁盘。

REFERENCE

刘缙,朱家稷,张海勇,“大规模云平台的技术挑战”,淘宝,2012

2015/10/25

---

layout: post
title: "Sql中的ACID"
category: Reading Notes

tags: ["关系型数据库", "读文章"]

{% include JB/setup %}

理解原子性(Atomicity)

原子性意味着数据中的事务执行是作为原子。即不可再分,整个语句要么执行,要么不执行,不会有中间状态。

    CREATE TABLE  TestForAtom
    {
        col1 int
        CONSTRAINT chk_TestForAtom
        CHECK(col1 = 5)
    }

-- 插入的两个数据中有一个违反了check约束

    INSERT INTO TestForAtom(col1) values(5),(6)

-- 虽然有一条数据符合规范,但另一条数据6并不符合check约束

-- 从而造成没有任何数据可以插入,保证了原子性

    SELECT * FROM TestForAtom

SQL SERVER提供了两大类方式来保证自定义事务的原子性:
1. 通过SET XACT_ABORT ON来设置事务必须符合原子性
利用设置XACT_ABORT选项设置为ON,来设置所有事务都作为一个原子处理。

    SET XACT_ABORT ON
    BEGIN TRANSACTION
    -- 正确的语句
    INSERT INTO TestForAtom(col1)
    VALUES (5)
    -- 违反check约束的语句
    INSERT INTO TestForAtom(col1)
    VALUES (6)
    COMMIT
    go
    SELECT * FROM TestForAtom
  1. 按照用户设置进行回滚(ROLLBACK)
    这种方式具有更高的灵活性,开发人员可以自定义在什么情况进行ROLLBACK,利用TRY CATCH语句和@@ERROR进行判断都属于这种方式

    BEGIN TRANSACTION
    -- Try语句成功则Commit
    BEGIN TRY
    -- 正确的语句
    INSERT INTO TestForAtom(col1)
    VALUES (5)
    -- 违反check约束的语句
    INSERT INTO TestForAtom(col1)
    VALUES (6)
    COMMIT
    END TRY
    -- 捕捉到错误后执行Catch中的Rollback
    BEGIN CATCH
    ROLLBACK
    END CATCH
    

理解一致性(Consistency)

一致性,即在事务开始之前和事务结束之后,数据库的完整性约束没有被破坏。

一致性分成两个层面

  1. 数据库机制层面 数据库层面的一致性是,在一个事务执行之前和之后,数据会符合你设置的约束和触发器设置,这一点是有SQL SERVER进行保证的。
  2. 业务层面 对于业务层面来说,一致性是保持业务的一致性。这个业务一致性需要由开发人员进行保证,很多业务方面的一致性可以通过转移到数据库机制层面进行保证。比如,产品只有两个型号,则可以转移到使用CHECK约束使某一列必须只能村这两个型号。

理解隔离性(Isolation)

隔离性。事务的执行是互不干扰的,一个事务不可能看到其他事务运行时,中间某一时刻的数据。

事务之间的互相影响的情况分为几种,分别为脏读(Dirty Read),不可重复读,幻读

  • 脏读:脏读意味着一个事务读取了另一个事务未提交的数据,而这个数据是有可能回滚的。

两个事务,事务A插入一条数据,但未提交,事务B在此期间进行了读取,读取到了事务A未提交的数据,造成脏读。

  • 不可重复读(Unrepeatable Read):不可重复读意味着,在数据库访问中,一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。

事务B中对某个查询执行两次,当第一次执行完时,事务A对其数据进行了修改。事务B中再次查询时,数据发声了改变。

  • 幻读(phantom read):幻读是指事务不是独立执行时发生的一种现象。例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发声操作第一个事务的用户发现表中还有没有修改的数据行,就好像发声了幻觉一样。

事务B更新表中所有数据,在此期间事务A插入了一条数据,事务B再次查询后,发现居然还有没有修改的数据,产生幻读。

为了避免上述几种事务之间的影响,SQL Server通过设置不同的隔离等级来进行不同程度的避免。因为高的隔离等级意味着更多的锁。
SQL Server提供了5种选项来避免不同级别的事务之间的影响

隔离等级由低到高分别为

  • Read Uncommited(最高的性能,但可能出现脏读,不可重复读,幻读)
  • Read commited(可能出现不可重复读,幻读)
  • Repeatable Read(可能出现幻读)
  • Serializable(最低的性能,一次只能执行一个事务,但避免了上述所有情况)
  • SNOPSHOT(这个是通过在tempDB中创建一个额外的副本来避免脏读,不可重复读,会给tempDB造成额外负担)

理解持久性(Durability):

持久性,意味着事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。

SQL SERVER通过write-ahead transaction log来保证持久性。write-ahead transaction log的意思是,事务中对数据库的改变在写入到数据库之前,首先写入到事务日志中。而事务日志是按照顺序排号的(LSN)。当数据库崩溃或者

REFERENCE

CareySon. "浅谈SQL SERVER中事务的ACID", 博客园, 2012

2015/10/25