架构

架构师的职责： 需求->设计（考虑风险、质量、技术）->执行

方法：分层（）+分区（业务） 深度优先：减少沟通和风险

分布式系统-CAP理论

C - Consistency      

• 原子性: 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
• 一致性: 在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
• 隔离性: 两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。 两个事务不会发生交互。
• 持久性: 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

• Basic Availability：基本可用
• Soft-state ：软状态/柔性事务，可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的
• Eventual consistency：最终一致性，最终整个系统（时间和系统的要求有关）看到的数据是一致的。

这些ACID特性对于大型的分布式系统来说，适合高性能不兼容的。比如，你在网上书店买书，任何一个人买书这个过程都会锁住数据库直到买书行为彻底完成（否则书本库存数可能不一致），买书完成的那一瞬间，世界上所有的人都可以看到熟的库存减少了一本（这也意味着两个人不能同时买书）。这在小的网上书城也许可以运行的很好，可是对Amazon这种网上书城却并不是很好。

 

而对于Amazon这种系统，他也许会用cache系统，剩余的库存数也许是之前几秒甚至几个小时前的快照，而不是实时的库存数，这就舍弃了一致性。并且，Amazon可能也舍弃了独立性，当只剩下最后一本书时，也许它会允许两个人同时下单，宁愿最后给那个下单成功却没货的人道歉，而不是整个系统性能的下降。

ACID是强一致性:银行必须保证数据一致    BASE: 事务的软状态和弱一致性 游戏对数据一致要求较低

ACID是悲观的，并强制保证每一个操作完毕后的一致性，而BASE是乐观的，它接受该数据库的一致性将处在不定的状态中。在BASE中，强调可用性的同时，引入了最终一致性这个概念，不像ACID，并不需要每个事务都是一致的，只需要整个系统经过一定时间后最终达到是一致的。Amazon的卖书系统，也许在卖的过程中，每个用户看到的库存数是不一样的，但最终买完后，库存数都为0。再比如SNS网络中，C更新状态，A也许可以1分钟才看到，而B甚至5分钟后才看到，但最终大家都可以看到这个更新。

A - Availability           12306某个时间不能访问（牺牲可用性）

P - Partition Tolerance                某个服务器节点故障，依然可以正常运行

网站流量分析：PV(page view),UV,IP

大型系统架构的目标

高可用性、可伸缩性（）、高性能

大规模高并发系统架构设计：

服务器集群和负载均衡

高可用性

缓存架构

数据库架构

存储架构

消息队列

非结构化存储

安全架构

监控预警系统

统一配置管理

统一日志管理

 

1.服务器集群和负载均衡

对于大负载web服务器来讲，CPU和IO处理能力是一个瓶颈。依靠一个“超级”服务器不如综合利用旧有的服务器（摩尔定律：每过多长时间速度快一倍，价格降低）

DNS负载均衡：操作简单，缺少灵活性（DNS缓存）第一道负载均衡

NAT负载均衡

   硬件四层交换和软件四层交换 LVS+keepalived   不支持动静分离  扩展NAT:返回不用通过NAT服务器

反向代理服务器

     ngnix、apache httpd   client->internet->反向代理服务器->内容服务器

　　一次代理要打开两个连接

　　前端nginx+keepalived 后端lVS+keepalived

　　nginx和LVS对比

 　　session管理：

　　session复制与共享　　cookie无状态化

　　memcache缓存服务器保存session

缓存架构

本质：两端速率不一致

1.浏览器缓存

ETag. lastmodified是否修改

cache-control

2.服务器本地缓存

　　动静分离

　　页面片段缓存

3.反向代理服务器缓存

   缓存命中率

   1)squid

　2)　CDN

　　　　DNS+多个缓存服务器

4.数据缓存

memcache 分布式算法：根据服务器数量求余，散列算法

redis

5.数据库缓存

本身的 缓存

数据库连接驱动的缓存 hibernate

图片服务器、静态html

 

 

数据库集群

　　share-disk单活技术   仅保证高可用性

　　双活oracle rac 

　　share-nothing

　　　　a.不可负载均衡-需要同步，性能没有提高   从slave读，在主数据库写

　　　　Master innodb -> backup slave innodb -> query slave myisam

　　　　mysql proxy \ mysql 读写分离 复制策略 ：同步、半同步、异步、延迟       

　　　　读写分离优点： 防腐化，（故障恢复）主从切换，数据分析（实时性要求不高，可以从slave读）（实时性要求不高，可以从master读）

　　　　b.负载均衡

　　　　2个master写，多个slave读 HA proxy     master slave / master cluster  数据分片/不分片 (如根据id分布）  

　　　　结合 master1-slave11 slave 12  master2-slave21 slave22

　　　　dal服务器 代理 读写分离，负载均衡，失效转移。。

数据库拆分 sharding

　　分库一般针对开源数据库

　　垂直拆分-业务模块 分布式事务

　　水平拆分

　　　　读写前判断分区，切分复杂

　　　　跨分片处理 不能join

　　　　数据冗余

　　　　主键 不能自增

 

　　　　基于路由表切分  存储到独立cache如memcached

RAID 0,1,5,10

磁盘存储结构 NAS,DAS

 

 

异步

提高响应时间，解耦