伯克利的Anna

最近阅读了两篇伯克利Anna的论文，写下感受。

https://dsf.berkeley.edu/jmh/papers/anna_ieee18.pdf

https://www.vikrams.io/papers/anna-vldb19.pdf

Anna18

ACI

Anna要求其所传输的数据符合ACI（Associativity, Commutativity和Idempotence）特性。所谓ACI特性就是满足如下（latttice）三个特质 ：

结合律：a+(b+c) = (a+b)+c  uesr request之间的组合任意 结果一致

交换律：a+b=b+a user request之间的顺序不重要

幂等： a+a=a 重复的uesr requset 不会影响最终结果

Actor model

Actor model是一种编程模型.分布式系统中需要通信交互的每一个节点看成一个actor，actor之间的信息交互全部通过message queue。Actor model不带任何锁和memory barrier（Anna多核）。actor之间的通信是异步、乱序、可重发的。

Anna的具体实现：

Lattice（我觉得这就是一个拓扑结构）

Anna每个server的所有数据都存在一个MapLattice<key, value>对象中。key是一个集合，新来的数据new_ml<a, v>如果a不在key中，那么整个new_ml<a, v>添加进MapLattice中；如果a在key中已有，Anna会调用v的merge方法，把v和原来的值按merge方法合并。其中value对应一个ValueLattice对象。

如果数据源头是起点，最终结果为重点。根据Anna的数据结构性质，来看，那么Anna集群李所有的server和这两点构成一个端到端的拓扑结构。所以只要数据源满足Lattice特性，Actor model就可以做到不加锁。

Anna19

Ann18改进的原因：

1容量不够被云吊打

2数据倾斜问题，访问数据集中在一部分server上，云资源没有被充分利用

3数据热点问题。冷热无常，动态变化。

由monitoring system/policy engine，routing service，cluster management system和storage kernel组成。

monitoring system/policy engine监控集群状态，动态调整数据分布。

cluster management system是负责执行policy engine的指令，进行资源的添加释放等操作。

Storage在Anna18的基础上增加了很多内容。tier，不同tier对应不同的存储结构，比如内存tier 、硬盘tier。

一个storage node包含多个worker thread，每个worker thread有自己的私有数据结构保存数据，worker thread之间通过message queue通讯，不共享任何内存数据结构。

Global hash ring 就是之前的hash ring，因为Anna在云上有多少个worker是动态变化的，所以又新增了 local hash ring的概念。

policy engine做的就是获取集群的使用情况。然后根据用户的配置和预定的规则作出弹性变化、热键复制和数据移动。可以用机器学习的方法替代基于规则的方法。

总结

优点：

多核

云环境下多核处理明显较以往的单机存储引擎有大的提升。

多级存储

以往的分布式系统，都没有考虑过多级存储的问题。把问题抛给用户是不合理的，serverless的兴起，后端即服务发展起来后，这些问题是应该有FaaS服务解决的。Anna的多级存储就是为了serverless而生。

问题：

同步

Anna的通信 message 使用的是ZeroMQ，作者提到这种同步机制类似goosip（八卦）。这种同步机制比较弱，情况可能会导致有些的actor一辈子也得不到同步或者是非常非常慢。

动态规划

  没有合适的规则以及数据模型确定冷热数据以及资源倾斜问题，需要大量数据建模。