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
