讲座主要内容
淘宝典型的架构应用
顶层load balance，业务分发
二层应用层，各类繁多的应用app
三层服务层SOA，使用多种中间件
四层存储层，MySQL Hbase Oceanbase， TFS
五层分析层，一些日志文件，数据备份，做数据挖掘，分析
侧面对每一层都有安全审计和监控管理。
CAP理论
a)
一致性 C
b)
可用性 A
c)
分区容忍性 P
最终一致性
举例：大v的微博消息，不需要粉丝在同一时刻都能看到。PUSH和PULL的策略，对活跃粉丝PUSH 对僵尸粉，等待刷时去PULL。
CAP的补充说明：整个机房掉电，这种可能1年只有1，2次，但对于大规模的集群而言，硬盘故障每天都有几十几百例，故障是必然存在的，可用性怎么保证？通过各个备份。
存储
淘宝的存储采用以下几种：
关系型数据库：MySQL，适用一些在线业务
NoSQL数据库：Hbase，Oceanbase，适用一些历史订单数据查询
分布式文件系统：TFS，零碎小文件分布式存储
举例谈及，淘宝的在线业务目前基本都是基于MySQL的，原先在oracle上的业务也都已经同步迁移到mysql数据库上了。以商品库，订单中心为例，迁移时间高达半年。
订单系统的历史数据（如三个月之前的数据），这种不太频繁被查询的数据，将其存放到支持容量更大的Hba<x>se数据库中，三个月之内的数据存放在mysql当中。经过对mysql的优化，可支持单表上亿条记录的查询性能。
MySQL
InnoDB存储引使用SSD擎
支持事务、行级锁、优化支持单表上亿条记录查询。
扩展方法
Scale up : 加内存，提高IOPS（换SSD，或PCIe Flash）
Scale out : 读写分离、sharding分库分表
Hbase
高性能写入、读性能也不错。
动态增加列。支持行级事务。（MangoDB不支持行级事务，库级）
应用案例：
在线：历史订单
离线：日志中心，Dump中心，消息
Oceanbase
可扩展的关系数据库，开源
支持跨行跨表事务，支持数千亿记录，数据百TB数量级的SQL查询
应用案例
宝贝收藏
直通车卖家报表
天猫评价
TFS
淘宝的分布式文件系统
案例：
交易快照、商品图片、SNS头像等图片。
缓存层
为缓解数据库存储上的压力，都会使用一层内存做缓存，承担大部分的查询任务。
缓存层淘宝使用的有TAIR，memcache，redis，LevelDB(google)。
中间件
中间件有多种，RPC中间件、数据库是间件、消息中间件。
RPC中间件
服务的远程调用实现像在本地一样执行。几种实现方法：
1.
TCP/IP长连接
2.
序列化/反序列化. JAVA Hessian，PB(Google)
3.
同步、异步调用、oneway、callback、可靠异步调用
软负载
配置中心
版本控制
可用性保证
故障检测、心跳检测、超时处理、功能降级（实例：广告大图变小图，减少后台压力，但减少了点击量）
举个实例：
淘宝调用支付宝。调用过程如下：
淘宝订单提交通过支付宝接口，发起远程调用，异步调用，淘宝直接返回。支付宝收到调用消息后，执行任务，完成后，通过消息中间件回调通知淘宝端。淘宝收到回调请求后继续处理剩余任务。完成配合。
配置中心功能：
当服务提供者发现故障时，怎么自动实现服务切换，以不影响业务呢？答案是心跳。服务提供者与配置中心有心跳信息，当配置中心认定某服务提供者挂掉时，会向集群广播，然后按照规则，将消息转发到存活的服务提供者去。
比如：刷新一个页面，半天不响应，但如何30s后再刷一次可能就正确加载了。
消息中间件
Notify
metaQ （RabbitQ）
TimeTunnel
数据库中间件
对应用层屏敝分库分表
使用规则引擎动态计算路由，选择正确的表
依赖于配置文件里的规则改变，可以在不重启情况下，改变数据库行为。
