Week 6 作业 02
分布式关系数据库
主从复制，实现读写分离。
一主多从
分摊负载
专机专用
便于冷备
高可用（对读高可以用）
主主复制
主主失效恢复
主主失效维护的过程
复制注意事项
主主复制两个数据不能并发写入，会出现逻辑问题。
复制只是增加了数据读并发的处理能力，没有增加写并发的能力和存储能力。
更新表结构会导致巨大的同步延迟。（复制的时候，禁止数据库alter table的指令，只是会安排工程师在特定的时间在各个主数据库进行表结构更新。）
数据分片（解决高并发写的能力）
分片目标
分片特点
分片原理
分片方法
硬编码实现数据分片（管理不容易，）
映射表外部存储
数据分片的挑战
需要大量的额外代码，处理逻辑因此便得更加复杂。
无法执行多分片的联合查询。
无法使用数据库的事务。(如果只有一部服务器在一个地方回滚就好了，可是分布在多个数据库，那么就需要多个数据执行回滚)
随着数据的增长，如何增加更多的服务器。（数据迁移会带来巨大挑战）
分布式数据库中间件
Cobar 架构
https://www.biaodianfu.com/cobar.html
https://www.cnblogs.com/davygeek/p/5710911.htm
l
CAP 原理
一致性Consistency 一致性是说，每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read receives the most recent write or an error），而不是过期数据，也就是说，数据是一致 的。
可用性Availability 可用性是说，每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过 这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系 统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是 最新的。
分区耐受性Partition tolerance 分区耐受性说，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依 然应该是可以操作的（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。
当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不 可用；要么我们继续写入数据，但是数据的一致性就得不到保证。 对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证 的，那么在可用性和一致性上就必须二选一。 当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个 错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个 数据，但是并不能保证这个数据是最新的。 所以，关于 CAP 原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下， 可用性和一致性无法同时满足。
CAP 原理与数据一致性冲突
最终一致性
解决方法:
最终一致写冲突: 简单冲突处理策略：根据时间戳，最后写入覆盖。
客户端冲突解决
投票解决冲突（Cassandra ）
Cassandra 分布式架构
Hbase 架构
Log Structed Merge Tree（LSM 树）
ACID 与 BASE
ACID (传统数据库比较强)
原子性（Atomicity）: 事务要么全部完成，要么全部取消。 如果事务崩溃，状态回到 事务之前（事务回滚）。
隔离性（Isolation）: 如果2个事务 T1 和 T2 同时运行，事务 T1 和 T2 最终的结果是 相同的，不管 T1和T2谁先结束，隔离性主要依靠锁实现。
持久性（Durability）: 一旦事务提交，不管发生什么（崩溃或者出错），数据要保存 在数据库中。
一致性（Consistency）: 只有合法的数据（依照关系约束和函数约束）才能写入数据 库。
BASE （NoSQL）
基本可用（Basically Available）系统在出现不可预知故障时，允许损失部分可用性，如 响应时间上的损失或功能上的损失。
Soft state（弱状态）软状态，指允许系统中的数据存在中间状态，并认为该中间状态的 存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步 的过程存在延时。
Eventually consistent（最终一致性）指系统中所有的数据副本，在经过一段时间的同步 后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达 到一致，而不需要实时保证系统数据的强一致性。
分布式一致 ZooKeeper
分布式系统脑裂
在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个 集群陷入混乱，数据损坏，本称作分布式系统脑裂。
Proposer 生成全局唯一且递增的 Proposal ID (可使用时间戳加Server ID)，向所有 Acceptors 发送 Prepare 请求，这里无需携带提案内容，只携带 Proposal ID 即可。 Acceptors 收到 Prepare 和 Propose 请求后
不再接受 Proposal ID 小于等于当前请求的 Prepare 请求。
不再接受 Proposal ID 小于当前请求的 Propose 请求。
ZooKeeper API
String create(path, data, acl, flags)
void delete(path, expectedVersion)
Stat setData(path, data, expectedVersion) (data, Stat) getData(path, watch)
Stat exists(path, watch)
String[] getChildren(path, watch)
void sync(path)
List multi(ops)
互联网搜索引擎整体架构
爬虫系统架构
爬虫禁爬协议
文档矩阵与倒排索引
文档与倒排索引
带词频的倒排索引
带词频与位置的倒排索引
Lucene 架构 (把倒排索引应用到数据库)
Lucene 倒排索引
Lucene
索引文件准实时更新 索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大 时效率很低，并且由于创建一次索引的成本很高，性能也很差。
Lucene 中引入了段的概念，将一个索引文件拆分为多个子文件，每个子文件叫做段，每 个段都是一个独立的可被搜索的数据集，索引的修改针对段进行操作。
新增：当有新的数据需要创建索引时，原来的段不变，选择新建一个段来存储新增的数据。
删除：当需要删除数据时，在索引文件新增一个 .del 的文件，用来专门存储被删除的数据 ID。当查询时，被删除的数据还是可以被查到的，只是在进行文档链表合并时，才把已经删 除的数据过滤掉。被删除的数据在进行段合并时才会被真正被移除。
更新：更新的操作其实就是删除和新增的组合，先在 .del 文件中记录旧数据，再在新段中添 加一条更新后的数据。
为了控制索引里段的数量，我们必须定期进行段合并操作
ElasticSearch 架构
索引分片，实现分布式
索引备份，实现高可用
API 更简单、更高级
ES 分片预分配与集群扩容 （就算只有一个服务器，分片都要预先规划）
源码
https://github.com/itisaid/sokeeper Web 应用
https://github.com/itisaid/cmdb 爬虫、倒排索引构建
Doris – 海量 KV Engine，用数据向决策者解说架构开发的重要性，通常赚钱的都是低技能开发。架构开发通常都是看不到
当前现状
网站关键业务有许多海量KV数据存储和访问需求。
**站 UDAS 使用。
存在问题：扩容困难、写性能较低、实时性低等
网站有多套 KV 方案，接口不统一，运维成本高。
**站 UDAS - BDB
**站 ： TT
飞天 KV Engine（Aspara）问题。
使用复杂
性能较低
产品需求
产品定位：海量分布式透明化KV存储引擎。
解决问题：
替换 UDAS：解决扩容迁移复杂，维护困难的问题。
**站海量 KV 数据存储
Global SEO ，1亿Product，2.4T 数据量
2011年底：3.1T
**站
WholeSale Global SEO
Product 数: 1600w，2.8T
2011年底： 3400w，5.8T
**站
风控用户行为日志：每月2亿，40G，增长很快。
产品目标 功能目标:
KV 存储 Engine
逻辑管理：Namespace
二级索引
非功能目标：
海量存储：透明集群管理，存储可替换
伸缩性：线性伸缩，平滑扩容
高可用：自动容错和故障转移
高性能：低响应时间，高并发
扩展性：灵活扩展新功能
低运维成本
易管理
可监控
约束： 一致性：最终一致性
技术指标
逻辑架构
二层架构 – Client、DataServer + Store
四个核心组件 – Client、DataServer、Store、Administration
KV Storage 概念模型
Machine：物理机
Node：分区单元，一台 Machine 可运行多个 Node。
Namespace：数据的逻辑划分 Tag，Client 可识别。数据管理无需识别。
关键技术点 – 数据分区
解决海量数据存储
客户端计算分区
分区算法（Partition Policy）
Client 向 Config Server 抓取分区配置
基于虚拟节点的分区算法
均衡性: 数据分布均衡
波动性: X/(M+X) ，优于一致性 Hash 的 X/M。( 用文件的方式来做迁移，把文件copy到新的服务器就可以了)
物理节点由2个扩充到3个，映射关系变化
基本访问架构 （Doris 是两个都要写入成功，事务才是成功，只要其中一个失败就是Rollback）
对等 Node 访问
双写保证可用性（W=2， R=1）
基于分区算法查找两个 Node
Copy 1 Node
Copy 2 Node
数据恢复和数据同步
Redo Log
Update Log
集群管理 – 健康检查和配置抓取
检查1：ConfigServer 对 DataServer心跳检查
检查2：Client 访问时 Fail 报告
其他 Client 定时配置抓取
关键技术点 - 可用性关键场景
瞬时失效
临时失效
服务端升级或者网络暂时不可用
失效机器在短时内可恢复（例如：2小时内)
恢复后数据和失效前一致
永久失效
机器下线
关键技术点－临时失效的 fail over
物理节点2临时失效，并在可接受时间内恢复
物理节点x：备用节点，临时存放失效的物理节点2的数据，物理节点2恢复后迁移回物理 节点2
物理节点2临时失效及恢复期间物理节点1承担所有read操作
关键技术点 – 永久失效 failover
每份 Data 写两份保证高可用：Copy 1， Copy2
一致性处理：version(timestamp) : Conflict Check & Merge
关键技术点 - 扩容实施数据迁移： 基本原理
集群扩容，新增Node X.
旧路由算法：Route1( key1) = { pn1, pn2 }
新路由算法：Route2( key1) = { pn1, pnx }
新旧算法有一个Node相同，因此只需要迁移一个Node.
Pn2 数据迁移到pnx，client 不再对pn2数据操作
R 操作只在pn1上
W/R 操作指向 {pn1, pnx }
Client对等节点中的一个pn1不变（路由算法保证）
在Group里面的所有服务器临时失效，重新计算hash，处理映射关系，然后对关系数据进行拷贝
关键技术点 - 扩容实时数据迁移：迁移过程
基本原理：基于遍历的路由对比迁移（描述见备注）
迁移时，计算两个 Route 算法。不相同则迁移。
采用改进的分区路由算法,减少迁移量: X(M+X )
数据可识别功能 - 逻辑数据结构
Namespace：一个业务实体数据的集合 Data Definition
Namespace的MetaData数据结构定义，满足“数据定义可描述“的需求。
Doris 和平台产品关系
产品规划（功能和版本）
Doris Q2 研发计划 -功能需求 数据模型
Key-Value 结构
Namespace 支持
数据访问
基本 KV API规范
KV Client：抽象API，调用框架
高性能通信
Doris Q2 研发计划 非功能需求
分区和线性伸缩：改进的分区路由算法
可用性：对等 Node，写2，Failover
透明集群管理和配置抓取
实时平滑扩容 • 存储可替换和 BDB 实现
管理和运维
集群管理
基本集群监控（接入 Dragoon）
Doris 0.1.0 项目计划
还未添加个人签名 2019.01.05 加入
还未添加个人简介
评论