GeekBand C++系统设计与实践 第二周

4.搭建大规模可扩展系统

大纲

• 分布式系统
• 数据库系统
• 经典架构
• 设计原则：CAP理论
• 一致性介绍
• 关系型数据库
• ACID vs. BASE
• sharding 分片
• MYSQL数据库
• Cassandra
• 实时系统：Kafka，Storm

** What is Scalability **

扩展性，当遇到许多用户的同时访问，不影响原有性能。平衡负载。性能是单个的用户体验，可扩展是在系统的层面，整体的访问效果，更在乎一个统计量，例如一个网站，90%用户访问时的响应时间。

Distributed System

Classic Master/Slave

4.png

如何检测一台机器是否宕机？

• 第一种情况，Slave工作节点宕机，这个时候Master节点需要能检测出来，并把该Slave的工作迁移到另外一台机器上。
  • 一般是由于某个时段过于繁忙，造成机器的“假死”，假死后，Master节点已经把工作迁移到别的工作节点上，而它本身确认为还可以继续提供服务，多个节点服务于同一份数据，这个时候就容易造成数据不统一。
  • 一种解决办法是使用一种lease，当工作节点拥有lease时，才能提供服务，否则则会主动下线，避免了数据不统一。当工作节点的lease快到期的时候，则会主动向Master节点申请lease，Master会检查是否合法，如果失效，则进行服务迁移。
• 第二种情况，Master节点宕机，此时需要备用的Master节点能够加测到，以替换该Master节点对外继续服务。
  • 主备节点可以维持一种heartbeat，这样的话当heartbeat中断后，备用节点就可以提升为主节点，继续服务。
• 分布式的一致性问题，分布式锁
  • Chubby
  • Zookeeper

CAP Theorem

• Consistency 不同的客户端对同一份数据总是拥有同样的view，一致性。
• Availability 所有的客户端总是可以读写，高可用。
• Partition tolerance 分区的可容忍性，跨全球物理网络的分区，系统扔工作良好，分布式。

Pick any two. You can't have all three.

5.png

Real world examples of CAP

• Amazon's Dynamo. AP: Data become consistent over time.
• Google's BigTable. CP
• Hbase. CP
• DynamoDB. AP
• CA 一般应用于事物，高可用，强一致性。

Database System

Relational DBMS

传统系统的事物必须拥有如下特性：

Earlier System were designed for ACID properties:

• A Atomic，原子性，要不操作完成，要不什么都不操作
• C Consistent，一致性，由数据库内部保障或应用保障
• I Isolated，隔离性，每个事务之间都隔离，每个事务都不能看到别的事务的中间状态
• D Durable，持久性

ACID vs. BASE

"Basically Available, Soft state, Eventually consistent"
在微博系统中，A发了一个消息，他自己马上可以看到，但是关注A的人，只要在一定时间能可以看到就可以了，并不是要求马上就可以看到。

应用拆分

6.png

• 系统拆分，尽量保障子系统的功能的垂直
• 要十分小心循环依赖，有可能启动失败

数据库拆分

• Horizontal Scaling（Sharding）
  • 当某个表数据量非常大时，则需要水平分表，对应用的影响较大
  • 使用 Database Access Layer来屏蔽底层数据的存储对应用的影响
• Functional Scaling（Scale out）

Stateless

Session Vs. Cookie

7.png

异步通信

RPC

8.png

有效利用Cache

9.png

Consistency & Replication

• 为了达到可靠性，需要把数据复制到多个数据源。
• 当需要修改某个数据，就带来了问题，是否能保障同时修改。
  • 读取的时候，读多份，当超过一半的数据源一致，则认为其可靠。
  • 写入的时候可以写入到日志，最终通过异步方式写入。

一致性

• 强一致性 系统中某个数据被更新后，后续任何对该数据的操作，都应该拿到是该数据更新过的数据。传统关系型数据库。
• 弱一致性 系统中某个数据被更新后，后续对该数据的操作，不一定拿到的是更新后的值，有一个窗口期。
• 最终一致性 属于弱一致性的一种。

Consistent Hashing

Distributed Hash Table

10.png

• 良好的分布式哈希，应该具有单调性，在服务器节点的增减，不应该造成哈希的重定位。

一致性hash算法

11.png

• 将服务器和数据都记性hash计算，假设分布在一个连续的hash环上，对数据进行hash后，定位在hash环上的一个点，然后就行顺时针移动，把它交由在hash环上遇到的第一个服务器去处理，不会因为服务器节点的变化引起哈希重定位。

容错性和扩展性

12.png

• 当Server3 宕机后，对原数据A,B,C都不会造成影响，只有数据D又影响。

13.png

• 当增加一台Server4，只影响了数据B，其他也不会造成影响，具有较好的容错性和扩展性。

虚拟节点

14.png

• 如图所示，Server1和Server2分布不均匀，导致Server1的压力非常大。

15.png

• 一种解决办法，对一台Server多次hash，形成多个虚拟节点，这样可以均衡负载。

一致性hash案例

16.png

• Cassandra
• Amazon's Dynamo
• HBASE
• MongoDB

NoSQL Database

• 水平分区
• gets() sets()
• key/value
• 不支持jion等
• 亿级的数据

Cassamdra

17.png

Write Data Flows

18.png

分布式系统设计模式

19.png

20.png

Scalability Principle

21.png

4.大数据系统

大纲

• 大数据系统：Hadoop
• MapReduce，BigTable，GFS三篇Paper
• Spark入门
• 海量数据处理技巧
• 聊天系统设计
• 估算机器

Hadoop 理念的产生

Google三辆马车

• MapReduce：简易的数据处理在大型的集群
• Google File System
• BigTable：结构化书分布式存储

GFS

22.png

• GFS msater 主服务器
  • 维护File namespace
  • 创建chunk的64位唯一句柄
  • 维护GFS到chunk的映射信息，chunk的位置信息
  • 整个系统的全局控制，租约的管理，lease
  • 垃圾回收
  • chunk的复制，备份
  • 与chunkserver维持heartbeat
• GFS chunkserver 数据块服务器
  • GFS的文件被划分为固定大小的数据块
• GFS client 客户端
  • 首先访问master节点，获得chunk handle，chunk locations
  • 然后访问chunkserver，获得数据

MapReduce

23.png

Big Table

24.png