淘宝的KV存储系统的设计思路总结-tair系统
tair系统功能：（主要用来对付那些静态化相关资源）
1、作为架设在各类存储介质前边的一层系统
2、可以用来存储cache数据，也可以持久化数据
一、要解决的问题
1、当用户访问数据为海量的时候，并且并发太大的时候直接访问数据库会让数据库被穿透，直接宕机
2、淘宝的用户信息和产品信息数据调用量是海量
二、设计思路
1、初期设计思路
（1）、做一层cache来缓存数据，直接给apache增加一个mod来进行数据cache
缺点：当数据量太大的时候，存储能力以及命中率降低，海量数据的时候命中率如果在90%以下数据库可能就会被穿透。淘宝的tair需要做到99.98%的命中率
2、支持多个产品线的设计思路
因为是KV数据存储策略，在单个机房建立多个tair集群，每个集群由如下三个角色：对apache节点（client：就是应用访问节点）、config server（存储数据存放位置的：name server/node server）、data server（存储数据的）
这里client我们一般都是在apache应用服务器加一个mod模块扮演。但是他是面向多个config server 和data server的
存储规则如下：
a、只在一个主节点写，相当于mysql的Master/Slave策略，在主库写，在从库读
b、将数据写的位置通过 hash(key)%n 这类简单的方式计算出位置，并将信息存储到指定位置。这里可以拓展到hash到集群和集群中的指定节点
访问规则如下：
a、当用户访问的时候直接去查看client是否存储了信息所在的data server，如果没有，直接访问config server去获取，并cache到client，然后到指定的data server取得数据
b、当config server改变的时候，不通知client，但是通知data server，并让data server 缓存他最新的config server对他的版本标注。当client访问data server的时候做版本比对，如果版本出问题，重新访问config server获取dataserver最新位置
c、当client访问dataserver时候发现数据改变，将信息发送到代理server（invalidate host）上，做到本地其他机房数据得以删除，保证用户访问的时候得以更新
三、如何应对跨机房
1、网络延迟不可避免，在事务上尽量做到解耦
2、如果是北京上海的这类机房通过，直接通过数据库（例如：mysql）的操作日志（例如bin.log）的操作同步，将这些同步行为转换为对当地机房的数据清理动作
3、如果机房属于同城的机房，那么就用上边提到的invalidate host的方式做数据通知
四、tair某个集群出现问题时如何处理
1、直接将客户端的请求切刀其他的机房中。因为跨机房策略，除了主机房，其他机房都是只读的策略
2、tair出问题的节点需要快速的根据历史信息计算出最热的节点并恢复使用
五、一些常见的问题
1、某些key的过热访问处理
当某个商铺调用的信息太过频繁，可以做一定时间段内请求的归一，例如将300ms（注意，是毫秒）内的几百个上千个请求只想data server拿一次数据。
2、脏数据容忍
不同机房都会有脏数据问题，这个不可避免。这个受限于数据同步，但是在产品设计上保证一定的容忍度