大型互联网架构设计

构建快速的数据查询
应用到DB的数据写入与查询从双向通行变 成了单向通行，通行效率更高，大大避免 了相互影响。“借道”行驶的情况不再出 现
水平拆分的问题
对于核心业务，停机时间有限，庞大的数据无法 在短时间内迁移 无法在短时间内完成项目发布过程中的测试工作
大数据量核心业务数据迁移的思路
先采用异构的数据库读写分离，将数据复制到目 标Mysql结点上，验证可靠性，机器压力 将写压力从Oracle结点迁移到mysql各结点， oracle停止写 对于一些不太核心，业务不太复杂，相关影响点 不多的数据，可以直接进行迁移
数据模型详解
使用面向聚合的数据库处理不同聚合之间的关系，要比处 理同一聚合内部的关系更难。 图数据库将数据组织成一张由节点和边所组成的图，它们 适合处理关系复杂的数据结构。 在无模式数据库中，可以给记录随意新增字段，然而用户 在使用数据时，通常还是要遵循一套隐式模式。 面向聚合的数据库通常能够用不同方式重组主聚合 （primary aggregate）的数据，以计算出各种“物化视 图”。计算过程一般通过“映射化简”来实现。
Eventual Consistency
如果没有失败发生的话，“不一致性窗口” 的大小依赖于以下的几个因素： 交互延迟 系统的负载 以及复制技术中Replicate的个数（这个可 以理解为master/salve模式中，salve的个 数）
NOSQL简介
redis Mongodb Cassandra neo4j
Eventual Consistency
强一致性(即时一致性) 假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读 取操作都将返回最新值 弱一致性 假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C 的读取操作能读取到最新值。此种情况下有一个“不一致性窗口” 的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一 段时间。 最终一致性 最终一致性是弱一致性的一种特例。假如A首先write了一个值到 存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操 作更新同样的值的话，最终所有的读取操作都会读取到最A写入的 最新值。
Nosql崛起
对于开发者,在架构设计的过程中,面对的 不是单个的Nosql产品选择,而是在Nosql生 态圈中选择出最佳拍档
What? Nosql生态圈?!
Nosql生态圈
聚合数据模型
聚合是作为交互单元的数据集合。数据库 中的 ACID 操作以聚合为界。 键值数据库、文档数据库、列族数据库都 属于面向聚合的数据库。 聚合使数据库在集群上管理数据存储更为 方便。 如果数据交互大多在同一聚合内执行，则 应使用面向聚合的数据库 ；若交互操作需 要使用多种不同格式的数据，那么最好选 用“聚合无知式数据库”。
BASE是AP组合的延伸
BASE思想主要强调基本的可用性，如果你 需要高可用性，也就是纯粹的高性能，那 么就要以一致性或容错性为牺牲，BASE思 想的方案在性能上还是有潜力可挖的。
ebay架构分享:牺牲一致性来换取分布式架 构的可伸缩性
Eventual Consistency
Amazon popularized the concept of “Eventual Consistency”. Their definition is: The storage system guarantees that if no new updates are made to the object, eventually all accesses will return the last updated value. 典型场景: DNS Single Write/multi read Mastaer/Slave Web Cache
A
可用性是说服务能一直保证是可用的状态， 当用户发出一个请求，服务能在有限时间 内返回结果。 而这种可用性是不关乎结果的正确与否， 所以，如果服务一致返回错误的数据,其实 也可以称为其是可用的。
P
是指网络的分区 网络中的两个服务结点出现分区的原因很 多，比如网络断了、对方结点因为程序bug 或死机等原因不能访问
异构的读写分离
写库为集中式的oracle环境，提供数据安全性保障 读库使用mysql，采用数据切分，分库分表，每台mysql放 少量的数据，单个数据分片内部采用mysql复制机制 读库的超大memory容量，起到了很好的cache作用,在内 存中的数据查询性能远远高于在硬盘上的性能 Oracle到多台mysql按规则复制 分区键的选择至关重要，尽量让数据访问落在单台数据库 上 利用好当前的高端硬件，保护好自己的投资
CAP
C P
P: Tolerance of network Partition 分区容忍性(分布式) A: Availability 可用性 C: Consistency 一致性
A
C
一致性 是说数据的原子性,这种原子性在经典 ACID的数据库中是通过事务来保证的 当事务完成时,无论其是成功还是回滚,数 据都会处于一致的状态. 在分布式环境中,一致性是说多点的数据是 否一致.
Replication-复制级别
1. Row Level：5.1.5开始支持。mater记录每行数据的更 改日志，slave根据日志逐行应用。优点：数据一致性更 有保障。缺点：可能造成日志文件比较大 2. Statement Level：master记录每个执行的query语句以 及一些上下文信息，slave节点根据这些信息重新在slave 上执行。优点：binary log比较小。缺点：某些情况下数 据一致性难以保障 3. Mixed Level：MySQL根据情况选择哪种复制方式。 5.1.8开始支持
MySQL主从复制
一主一从复制示例图
MySQL主从复制
主服务器
从服务器1
从服务器2
从服务器3
从服务器N
一主多从复制示例图
MySQL主从复制
主服务器
从服务器1
从服务器2
从服务器3
从服务器4
链状主从复制示例图
双向复制
主服务器
主服务器
双向复制示例图
复制的优缺点
slave可以作为master的备份 是异步的，不会给master带来很大的压力，但某些情况下 ，当master宕掉时，可能有些数据还未复制到slave中去； 配置简单 master和slave相对独立，建立新的复制关系时不必停机； 当其中一方宕机，另一方还可以继续运转；宕机的一方经 过恢复后，重新建立复制关系，也不需要正在运转的一方 停机； 应用广泛，这是MySQL非常成熟的技术，大量的案例都使 用了复制； slave可以分流数据库读操作，但这需要应用程序分别处理 数据库的读和写； 可以对slave进行备份，而不影响master；特别是可以lock 所有表，然后做文件拷贝，甚至停止slave的MySQL服务， 然后做文件拷贝，数据量大时，比mysqldump速度快；
CAP
一个分布式系统不可能满足一致性，可用 性和分区容错性这三个需求,最多只能同时 满足两个。 原始证明: Brewer's CAP Theorem 我们也来推演证明一下?
CAP
CA 传统数据库 AP 大多数网站架构的选择 CP Redis MongoDB 用户对数据的不一致性是不敏感的(数字敏感 的场景除外)
MySQLReplication
MySQL-replication
MySQL的replication是异步的，适用于对数 据实时性要求不是特别关键的场景。slave 端的IO线程负责从master读取日志，SQL 线程专门负责在slave端应用从master读过 来的日志（早期MySQL用一个线程实现， 性能问题比较明显）。使用replication必须 启用binary log，MySQL用binary log向 slave分发更新
难题
数据库集群自动扩展仍然是个难题，但是是可以 忍受的，底层数据集群经过评估，扩展的频率并 不高 MySql DDL 操作不变，锁表，对写操作影响较大， 分了比较多的表，进一步加重了维护负担。
数据切分及整合方案
MySql Proxy Amoeba corba
多种存储方案
不同场景使用不同数据源
关系型数据库 kv 文档数据库 外部数据接口 …
分布式模型
数据分布式的两种方式
将不同的数据分片存放在多个服务器中，每一 个数据子集都专门由一台服务器负责 将数据复制到多个服务器上，每份数据都能在 多个节点找到
复制技术
主从复制 对等复制
一致性
更新一致性 读取一致性
NOSQL SYSTEM
生态圈图上有个CAP是什么意思?
CAP
CAP理论是由EricBrewer教授提出的，在设 计和部署分布式应用的时候，存在三个核 心的系统需求
Nosql崛起
这样的策略可以应对大多数场景,关键的是 它可以带来非常可观的执行效率提升! Nosql产品在设计上比较收敛,一般比较克 制增加新功能的加入,避免回到关系型数据 库的老路上
Nosql崛起
保持产品功能的简单,在细分方向上做到极 致,不仅仅是众多Nosql产品的特点 SQL Server那种一条龙服务的数据库产品 形式在Nosql产品中很少见到 这也是Linux设计思想的体现
Nosql崛起
大部分Nosql产品的共同点: 支持SQL不再是必选项,取而代之的是简单 的Key-Value存取模型 在关系型数据库的基础上大刀阔斧的做减 法,比如不支持事务; Nosql产品对性能的关注远远超过ACID,往 往只提供行级别的原子性操作,即对同一个 key的操作操作会是串行执行,保证数据不 会损坏;
BASE是AP组合的延伸
Basically Availble --基本可用 Soft-state --软状态/软事务 Eventual Consistency --最终一致性 巧合: BASE 碱性 ACID 酸性
BASE是AP组合的延伸
BASE模型牺牲高一致性，获得可用性或可 靠性： Basically Available基本可用 Soft state软状态 状态可以有一段时间不 同步，异步。 Eventually consistent最终一致，最终 数据是一致的就可以了，而不是时时一致。
高并发大容量数据存储设计
数据库里的数据
数据存在单台数据库中，用户，商品，交易等数 据都在一起，存在许多的关联查询，应用完全耦 合
用户 商品 评价 交易
收藏
连接数问题
无论是小型机还是更高端的存储，随着数据的飞 速增长，都带来瓶颈问题。当oracle数据库连接 数达到5000个以后就相当吃力了。
数据垂直拆分
数据库系统按照不同的业务数据进行一系列垂直 拆分，这种拆分方式具有如下的特点：
1.拆分方式简单，只需要把不同的业务数 据进行分离 2.避免了不同的业务数据读写操作时的相 互影响 3. 该业务内部及其所导致的问题依旧
用户 商品 交易 评价
Hale Waihona Puke Baidu直拆分问题
当单库iops达到几万次 单库连接数达到几千次 单库每秒SQL执行到几万次 搜索dump数据缓慢，DWETL缓慢 高端存储设备
复制的限制
一个master可以带多个slave；一个slave只 能有一个master；slave也同时可以作为 master，从而形成链式复制、双向复制、 环式复制。但双向复制和环式复制，在官 方文档中并不提倡，因为容易产生冲突， 冲突之后也没有自动解决的机制。
Replication-常用架构
1. Master-Slaves：通常都采用这种方式 2. Dual Master(Master-Master)：2个master节点互相同步 更新。因为MySQL的异步复制方式，为了防止数据冲突 造成的不一致性，一般仅将其中一台用于写操作，另一台 不用或仅用于读操作。目的是其中一台master停机维护或 者故障中断时可以使用另一台master 3. 级联复制(Master-Slaves-Slaves)：在Master Slaves中 ，如果slaves过多replication将增加master的负载，这时 可以让master只向其中几台slave分发更新日志，这几台 slave作为一级节点再向下级节点分发更新日志