分布式系统存在的意义：
1.向上扩展的性价比越来越低
2.单机扩展存在性能上升临界点
3.处于稳定性和也可用性考虑，单机会存在多方面的问题
复制代码
cpu。 内存 io
多cpu，多线程编程：有以下类型
1.互不通信的线程模型 ：速度最快 最安全
2.基于共享容器协同工作的模型
如：基于消息队列进行数据共享：线程间需要通信 意味着一个线程必须等待另一个线程执行完之后获取其结果才能执行 意味着无法并发
1.线程安全模型
如其他线程对共享的数据进行修改，不影响其他线程读取数据
2.线程不安全模型
解决方法：
1.加锁
2.cow ：copy on write 写时复制
3.通过事件协调的多线程模型
如：死锁的造成 就是这一种线程模型
线程： A,B
线程B 需要线程A触发某个事件才能够执行
4.多进程模型：
复制代码
IO： 1.网络io
1.多进程，每个进程响应一个请求
2.多线程，多进程：每个进程生成多个线程，每个线程相应一个请求
3.多进程，每个进程响应多个请求
基于socket实现网络通信开发，其实现方式：
BIO：block IO
一个进程或一个线程处理一个请求
NIO:Nonblocking IO
基于事件驱动(epoll)思想，采用 reactor模式
AIO：
基于事件驱动思想，采用proactor模型
2.磁盘io
复制代码
如何把应用从单机扩展到多机
输入设备的变化
输出设备的变化
控制器的变化
实现模式：
1.透明代理
lvs的nat
haporxy，nginx
2.旁路代理
3.名称服务
4.规则服务 通常用在数据库的拆分上的
master/slave机制
复制代码
运算器的变化
后端节点就是 将控制器和运算器分离，真正提供服务的是运算器 将单机系统中不宜扩展的运算器分散到多个节点上实现的 扮演单机模式中的运算器
复制代码
分布式系统实现难点：
缺乏全局时钟
面对故障时的独立性：一个主机有问题不影响全局
处理单点故障
事务处理
ACID 原子性，一致性，隔离性，持久性 判断是否支持事务的标准
2pc 两段式提交
BASE
CAP
PAXOS
复制代码
应用从资源占用角度分类
IO密集型
cpu密集型
session sticky：session粘性
cookie base 基于cookie
ip base 基于ip
session replication：session复制 构建session集群 不试用于大规模
session server：session 集中存储
复制代码
mysql主从面临问题：
1.数据复制问题
从服务器通常会落后主服务器
主服务器如果是多cpu可以，就可以并行的处理数据，但是记录二进制日志只能串行记录
从服务器复制日志只能是串行复制
2.应用选择数据源问题
mysql的innodb不支持全文索引，myisam支持，但是在在线平台上都需要支持事务
复制代码
搜索引擎实现全文搜索：
将mysql的数据读出，换一种方式存储，将其构成全文索引，用户查询时，都由搜索库来进行响应，这个搜索库也叫搜索引擎
减轻了当有大量用户访问时，对数据库的压力
复制代码
搜索引擎通常是在本地进行搜索
搜索引擎的处理速度，从数据库上读取数据，并且在本地上构建全文索引的速度，决定了你的搜索引擎是否能够及时搜索到新上架的商品了
复制代码
引入缓存
1.缓存命中
2.缓存穿透
3.缓存雪崩
1.文件缓存
varnish
2.数据缓存
key-value-store：mamecache
复制代码
数据库拆分
垂直拆分：
把数据库中不同的业务的数据拆分到不同的数据库中
水平拆分 ：要有拆分框架(规则服务器)-cobar淘宝的数据拆分框架
把单独表中的数据拆分到不同的数据库服务器上
如根据用户的id 大于500w的分到一台服务器id小于500w的分到另一个服务器
读写分离和水平拆分区别：
读写分离是解决读写压力过大问题的 水平拆分解决写压力过大问题
复制代码
应用本身拆分(服务化)
根据业务特性做拆分
根据用户来拆分
1.用户注册
2.用户登录
3.用户信息维护
把底层应用的调用进行拆分
异步：解耦
消息中间件：分布式系统中，完成消息发送和接收的基础性软件
MOM：message-oriented middleware
如加入消息队列
数据访问层：
拆分：
垂直拆分：将不同表分散到多个数据库上
单机ACID保证被打破，要么放弃事务，要么引入分布式事务
一些join查询操作变得非常困难，因为表可能在两个库中了
原来依赖于外键的约束无从保证
水平拆分
单机ACID保证被打破
一些join查询操作变得非常困难，因为表可能在两个库中了
原来依赖于外键的约束无从保证
自增序列的id号产生会有影响
针对单张表的查询有可能要跨库操作
复制代码
分布式事务的实现：
事务：事务的参与者。支持事务的服务器，资源服务器，事务管理器
分布式的模型及规范
x/open XA (分布式事务规范)
X/open DIP 分布式事务处理引用参考规范
三个组件
1.AP：应用程序，使用DTP模型的程序
2.RM：资源管理器，即DBMS系统
3.TM 事务管理器，负责协调和管理事务，提供给ap应用程序接口并管理资源管理器
2pc：两段式提交是一种协议
1.请求所有资源都准备的阶段
2.请求是所有资源都提交的阶段
任何一个阶段失败都执行回滚 因为是事务的
CAP：任何一种分布式系统最多只能满足下述三项中的两个属性
C: 一致性
A：可用性
P：网络分区容错性
分布式系统的目标
1.AP：大多数分布式系统都选择此项
2.CA
3.CP
分布式系统的每一步：加强A和P，在c上进行妥协(满足base模型)
BASE：
BA：Basically Availibale 基本可用
S: 接受一段时间的状态不同步(数据不一致)
E：Ecentually Consistent 最终一致
复制代码
服务器一致性：
N:节点个数
W：更新的时候需要确认已经被更新的节点个数
R：读数据的时候读取的节点个数
W + R > N -----> 强一致性
W = N ,R=1 ---> 最佳读
W = 1,R=N ---> 最佳写
W + R <= N ---> 弱一致性
举例 当是总共只有一台服务器时
写是这一台服务器 读也是这一台服务器 1+1 > 1 强一致
当有两台时，比如mysql的读写分离
写是一台服务器，读也是一台服务器 1 +1 =2 弱一致性
复制代码
![【MySQL数据库】数据库索引事务1.索引2.事务[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)