《深入分布式缓存：从原理到实践》学习笔记（3）

第九章 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主要是为了广告系统存储用户属性数据而设计