数据的存储存储——性能（存储介质，数据格式，数据组织，索引，cache) ——扩展性 ——功能（索引，事务） ——一致性 ——可靠性 ——成本（物理，维护）性能存储介质特点数据组织磁带 内存 map,set,list,skip-list,memory-table,stm(支持内存事务)磁盘顺序读写强，随机读写差，block-Tress =>B+ 层数一样，性能稳定，中间节点只有索引，容易缓存，数据只在子节点，数据可以扫描SSD随机性能高，并行度高，擦除影响寿命SST(sst为何适合SSD)PCM 扩展性分片，元数据hash(事先分多)，range(hbase 热点)，一致性hash(不推荐，写不好)一般三个副本可以保证11个9，两副本大规模下3个9必丢数据可靠性复制，同步，故障恢复，故障发现，主动上报/心跳/lease一致性CAP是针对一条数据的ACID，最终一致性，sessioin一致性，单调一致性考虑高可用的备份，高性能的负载，地理就近，存储单机瓶颈等原因会从单机发展到分布式。架构（多主，单主等），困难：丢包/延迟，时钟不同步。会导致设计上再延时（同步，半同步，异步）和一致性（线性一致性，原子事务提交）上有一定取舍，并有通用调的方式来解决。这部分理论在后续案例后再讨论。先看存储的例子。1.redis=>codisredis单机基础内存跳表-list无索引，基本不支持事务redis的分布式1，代码中写；2，redis Cluster。请求不在的key要两次，先返回ip再请求一次3，代理分片，比如tuemproxy,codisredis clustercodis架构扩展性分片：hash元数据：codis-proxy中，用codis-dashboard控制，zk保持同步扩展:固定1024个slot。迁移是按照slot的维度迁移有两个阶段，第一阶段状态改为pre_m。若proxy都确认，将状态改m。向所在的redis-server发送迁移命可靠性codis-proxy的用zookeeper保证。client获取zk节点做负载均衡codis-group的主从用redis的哨兵模式一致性2.mysql=>proxy3.fusion4.leveldb/rockdb5.mongodb