第九章 Tair
9.1 Tari总体架构
-
Client为客户端
-
Data Server负责数据存储,并根据Config Server的指示完成数据复制、迁移工作
-
Cofing Server维护了大量数据分布信息
9.2 Config Server简介
-
客户端会缓存从Config Server拿到的数据分布对照表,所以Config Server本身不会成为瓶颈。
9.3 Data Server
-
Data Server具备抽象的存储引擎层,可以很方便地添加新存储引擎。
9.4 Tair高可用和负载均衡
-
对照表
-
使用一致性hash算法存储数据
-
根据心跳检查确认是否重建对照表
-
在有节点宕机的情况下,Data Server会根据不同的约束规则重建对照表
-
c1:Data Server存储的主桶个数不能超过计算出来的主桶容量
-
c2:Data Server存储桶的总个数不能超过计算出来的容量
-
c3:Data Server存储的桶数量不能超过M/N,且(M/N+1)个同的Data Server数量不能超过计算出的最大个数+1,M为桶数、N为节点数
-
c4:存储相同数据的任何两个桶不能在同一个Data Server上
-
-
9.5 存储引擎
-
默认包含四个存储引擎:mdb(基于Memcached)、fdb(基于Firebird)、kdb(基于Kyoto Cabinet)、ldb(基于LevelDB)
-
mem_pool:用于内存管理
-
mem_cache:用于管理slab
-
cache_hash_map:用于存储hash表
-
mdb_area_stat:用于维护area的状态
-
第十章 EVCache探秘
-
Netfix公司在全球建立了EVCache分布式系统
-
EVCache的设计目的在于:微服务是依赖缓存,必须快速可靠地访问多种类型的数据,比如会员的观影历史,排行榜和个性化推荐,这些数据的更新与改变都必须复制到全世界各个地区,以便这些地区的用户可以快速访问。
-
对于非重要的数据,会严重依赖最终一致性模型进行复制,容忍一定时间的不一致。
-
-
2)操作中的元数据包括了key,但是不包括要缓存的数据本身,降低Kafka的消耗
-
4)操作通过key从缓存中获取数据
-
该复制流程只对SET操作生效
-
-
面向数据和时延的优化:冷热数据分离,将冷数据存放在L2(硬盘,SSD),热数据存在L1(RAM),这就是典型的两级缓存架构
10.2 EVCache的使用场景
10.3 EVCache的性能
-
全局复制时的性能
-
Kafka不存数据
-
SET操作不需要复制数据,只要向其他区域发送key的delete操作
-
中继服务使用久连接
-
调整TCP窗口大小,将多个消息汇集到一个请求以填满一个TCP窗口
-
-
Rend的性能
-
请求处理:286万请求/秒;数据插入:22k/秒;数据读取:21k/秒
-
第十一章 Aerospike原理及广告业务应用
-
数据索引存在RAM中,数据存与SSD或HDD中
11.2 Aerospike的具体实现
-
集群管理
-
集群视图:<cluster_key,succession_list>,culster_key为集群标识符,succession_list为该集群中节点标识符的集合
-
集群发现:
-
除了正常的心跳检测包外,节点间定期交换的其他消息也作为备用的二次心跳机制;
-
消息丢失的数量的加权移动平均值作为节点的健康评分
-
使用Paxos算法作为节点故障后的重排
-
-
11.4 Aerospike与Redis的对比
-
Redis需要开发人员自己管理分片,并提供负载均衡的分片算法;Aerospike可以自动处理分片工作
-
Redis中增加分片数量,并重构分片算法和数据,需停机;Aerospike可以动态增加数据卷和吞吐量,无需停机,
-
Redis中的复制及故障转移需要开发人员在应用层同步数据;Aerospike只需设置复制因子就能做到透明的数据复制和故障转移
-
Redis完全依赖内存,Aerospike在在内存中运行也可利用Flash/SSD存储的优点
-
Redis支持多种数据结构,Aerospike只支持单一的key/bins的结构
-
Redis社区更加成熟
-
Redis主要是需要高性能的架构中,Aerospike主要是为了广告系统存储用户属性数据而设计