集中式和分布式
计算机系统规模越来越大，将所有业务单元集中部署在一台机器上处理，这样做非常简单但也存在很多问题可能带来系统大而复杂、难于维护、发生单点故障、扩展性差等问题，而分布式的出现大大减轻了集中式的负担，分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，各个主机之间通信和协调主要通过网络进行。
分布式将面临的问题：通信异常、网络分区、三态(成功、失败与超时)、节点故障
如何把应用从单机扩展到分布式？(大型分布式架构的演进过程)
a)单台服务器应用
存在问题：流量越来越大出现服务器性能问题
b)应用服务器和数据库服务器分离
存在问题：随着请求流量得进一步增大出现应用服务器性能问题
c)应用服务器集群（微服务）
存在问题：需要使用session+cookie维护用户，如何做请求转发（cdn，前端做负载均衡器）
d)负载均衡器
存在问题：随着流量的新增，数据库服务器由性能压力，数据库遇到瓶颈
e)数据库服务器集群
存在问题：数据库读写分离、数据库数据同步、数据库路由
f)搜索引擎集群
存在问题：搜索引擎的索引数据如何同步，实时增量/定时全量
g)缓存服务器
h)数据库水平/垂直拆分
i)应用服务器垂直拆分
存在问题：应用服务器交互调用问题
j)SOA服务（面向服务架构，应用服务拆分为服务节点，属于微服务）
构建分布式架构的重要因素
1)CDN加速静态访问
2)分布式存储
3)分布式搜索引擎
4)应用发布与监控
5)应用容灾及机房规划
6)系统动态扩容
事务
什么是事务？
事务是一种机制将一个活动的所有操作纳入一个不可分割的工作单元，任何一个操作不成功整个事务都不能成功提交，导致事务回滚。(事务本质是锁和并发的结合体)
MySQL事务特性
1.原子性：整个事务所作的全部操作要么全部提交成功，要么全部失败回滚
2.一致性：事务执行之前和之后都必须保持一致性
3.隔离性：一个事务在提交前的所有操作，其他事务是不可见（以性能为由，对一致性的破坏）
4.持久性：事务所作的修改将永远保存到数据中即便数据库出问题也不会丢失（提高系统的并行性）
并发问题
1.脏读：一个事务在进行修改，在事务完成提交前，数据处于不一致状态，另一个事务读取同一条数据如果不加以控制，第二个事务将读取到“脏”数据。
2.不可重复读：事务在读取某个时间段的数据，再次读取数据时发现数据已经发生变更或者某些数据被删除
3.幻读：事务按照相同查询条件读取以前数据，却其他事务按照相同的查询条件插入新数据
不可重复读和幻读的区别
不可重复读的侧重在于数据被修改，幻读的侧重在于数据进行增加、删除
事务隔离的四个级别
1.读不提交：所有事务读取的是未提交事务的执行结果
2.读提交：事务看到所有已经提交的变更
3.可重复读：事务在并发读取时看到的数据一致
4.可串行性：完全串行化读，每次读都需要获取表级共享锁，读写相互阻塞
并发事务处理
1.锁机制：乐观锁、悲观锁
悲观锁：在修改数据之前先锁定，在进行修改。悲观锁主要是共享锁和排他锁，多个事务可以共同访问一把锁，访问数据但只能读不能写(共享锁)。当一个事务获取数据的排他锁(写锁)，其他事务不能获取该数据行的其他任何锁。
优缺点：“先取锁在访问”的保守机制，为数据提供了安全保证。处理加锁会给数据库产生额外开销，增加死锁的可能性，还会减低并行性，一个事务锁定了该行数据之后，其他事务必须要等待该数据处理完之后才能处理。
乐观锁：数据在提交时，才会正式对数据的冲突与否进行检测，如果发现冲突，则返回错误信息让客户进行抉择。乐观锁对数据处理直到提交才锁定，所以不会产生任何锁和死锁。
2.mvcc多版本并发控制：通过一定机制生成一个同一时间的数据请求的数据快照，并定义级别的一致性读取。
分布式事务
分布式事务也就是将一个大的操作分割成许多小的操作分布在不同的服务器上，分布式事务和事务有着一样的特性，这些小的操作要么全部成功要么全部失败，保证不同数据库一致性。
分布式要解决的问题
a)多个事务之间的事务问题
b)多个事务之间数据一致性问题
c)多个事务任务调度问题
d)单个事务数据与缓存的一致性问题
e)数据库分库分表问题
f)分布式锁问题
CAP定理
一致性（C）：数据在各个节点上保持着一致性
可用性（A）：非故障节点在合理的时间给出合理的响应
分区容错性（P）：部分区域出现问题，整体依然能够运行
CAP三者是不可能共存的，在实际环境中网络存在波动P是必然存在的结果，当出现分区现象数据为了保持一致性则必须拒绝请求但A不允许，所以分布式理论上是不可能选择CA只能选择CP或者AP。
CP放弃了可用性，追求一致性和分区，符合zookeeper的理念。
AP放弃了一致性，追求可用性和分区，BASE则是根据该理念进行扩展。
分布式开发我常用的是CP，但大部分时间下我们都是在做CA，因为P出现的概率太低就算出现分区情况我们会做日志来保证A。
BASE定理
基本可用(Basically Available)：分布式系统中部分功能损坏了，但核心功能可以正常使用。
软状态(Soft state)：系统中允许存在中间状态，但又不影响系统的可用
最终一致性(Eventually consistent)：最后数据将会达到一致性
BASE解决了CPA延迟之后的一致性。
总结提问
1.ACID和CAP的 CA是一样的吗？
2.分布式事务常用的解决方案的优缺点是什么？适用于什么场景？
3.分布式事务出现的原因？用来解决什么痛点？
事务实践中的常见问题
1.多个事务谁先谁后？
2.如何故障恢复？
3.碰到死锁了怎么办？
