2018-03-22

2018-03-22 本文已影响45人 jiangmo

新奇的编程方式，改变你对编码的认知默认

并发

示例语言：ANI, Plaid
有些编程语言是默认情况下并发的，也就是说，每行代码都是并行执行的。
例如，假设你写了三行代码，A，B和C：

A;
B;
C;

在大多数编程语言中，A先执行，然后执行B，最后执行C。在像ANI这样的语言中，A，B和C都将同时执行。

ANI中代码行之间的控制流或排序，仅仅是代码行之间显式依赖关系的副作用。例如，如果B引用了A中定义的变量，则A和C将同时执行，而B只会在A完成后执行。

以下是ANI中的“Hello World”示例：
"Hello, World!" ->std.out
"Goodbye, World!" ->std.out
这两行代码并行执行，因此它们可以在控制台中以任何顺序结束。

现实中发生是有顺序的，如何控制？通过加锁控制

如：

s = [string\];
"Hello, World!" ->s;
\s ->std.out;

第一行声明一个“锁存（latch）”（锁存器有点像变量），调用 s它包含一个字符串; 第二行将文本赋值 "Hello, World!"给s; 第三行“解锁” s并将内容发送给std.out。在这里，您可以看到ANI的隐式程序排序：由于每行都依赖于前一行，因此此代码将按写入的顺序执行。

Apache Ignite 2.4.0 发布，内存数据组织平台

https://ignite.apache.org/download.cgi
memory-centric distributed database, caching, and processing platform
for transactional, analytical, and streaming workloads,
delivering in-memory speeds at petabyte scale

牛逼的不行了，无所不能

Is Ignite an in-memory database?
Yes
Is Ignite an in-memory data grid?
Yes
Is Ignite a distributed cache?
Yes
Is Ignite a distributed database?
Yes
Is Ignite an SQL database?
Not full
Is Ignite a disk or memory-only storage?
Both
Is Ignite a NoSQL database?
Not exactly
Is Ignite a transactional database?
Not fully
Is Ignite a multi-model database?
Yes
Is Ignite a key-value store?
Yes

功能多，nosql总线，内存计算是个框什么都可以往里装。hadoop，spark解决了大数据存储问题，但没解决大数据计算痛点，多功能分布式内存计算是趋势。从官网的下图可以看出ignite有数据网格，计算网格，服务网格，sql网格，数据结构，流计算，文件系统，高级集群等模块，都是放在内存操作，我想主要追求的是能快速分析处理数据，实时内存应用，不像hadoop基于硬盘文件，发个命令下去，等喝完茶才有结果。

对于结构化数据处理,MB级用excel,pandas,sqlite,access，GB级用mysql,oracle,sql server,postgresql，TB级用mongodb，greenplum，PB级用hadoop,spark,EB级自己想办法。数据量越大操作起来越费劲越费时，只适合事后慢慢分析，从spark开始内存计算就是为了解决太费时问题，Apache Beam也延续了这种趋势，ignite主要内存功能强大，更方便适用，用内存来聚合数据源，处理数据。随着时间的推移，移动互联网物联网的使用，数据会成指数增长，不上大内存根本跑不快，服务器内存价格只会越来越便宜，内存计算只会越来越流行。

特性介绍

https://www.zybuluo.com/liyuj/note/293596

超高性能键值存储数据库 Anna

Anna 是伯克利 RISE 实验室推出的键值存储数据库，也是一个具备惊人的存取速度、超强的伸缩性和优秀的一致性的 KVS。

Anna 的性能和伸缩性主要归功于它的完全无协调机制，节点工作进程有 90% 的工作负载是在处理请求，而其他大部分系统（如 Masstree 和英特尔的 TBB）只有不到 10% 的时间在处理请求，它们其余的 90% 时间花在了等待协调上。不仅如此，其他系统因为使用了共享内存，还会出现处理器缓存击穿问题。

Anna 不仅速度快，在一致性方面也达到了很高的水准。多年前，他们发布的事务协议 HATs 就已表明，无协调的分布式一致性和事务隔离性存在很大的提升空间，包括级联一致性和读提交事务级别。Anna 将 Bloom 的单格子组合设计模式移植到了 C++ 中，是第一个实现了上述所有级别一致性的系统。当然，也是因为设计上的简洁，才能达到如此快的速度。

Bedrock

基于 Anna 开发一个新的扩展系统，叫作 Bedrock。Bedrock 运行在云端，提供了无需人工干预、低成本的键值存储方案，而且是开源的。

无协调 actor 模型的伸缩性

在无协调 actor 模型中，每个 actor 对应一个线程，对任何一个共享状态都有自己的一份私有拷贝，并通过异步广播将更新通知给其他 actor。在多核服务器上，这种模型比传统的共享内存模型的性能要高出一个数量级。

一个对比实验，将 Anna 与其他基于共享内存的 TBB、Masstree 和自己实现的一个键值存储系统（姑且把它叫作“Ideal”）进行了对比。他们在 AWS 的 m4.16xlarge 实例上运行实验，每个实例配备了 32 核的 CPU。实验中使用了 1 百万个键值对，键的大小为 8 字节，值的大小为 1KB。在实验过程中，他们基于 zipfian 分布和各种系数生成不同的压力负载，模拟不同层次的冲突。
在第一次实验中，他们对比了 Anna 与 TBB、Masstree 和 Ideal 在单台服务器上的吞吐量。他们逐渐增加线程数量，直到达到服务器 CPU 核数的上限，并观察它们的吞吐量。

在高并发情况下，线程数与吞吐量的变化关系，其中 zipf 系数为 4

在高并发情况下，CPU 时间的使用情况。CPU 时间被分为 5 类：处理请求（RH）、原子指令（AI）、合并格子（LM）、广播（M）和其他。最右边一栏是 L1 缓存击穿数量（CM）。

从图中可以看出，在这样的负载压力下，TBB 和 Masstree 几乎失去了并行能力。因为大部分是更新操作，针对同一个键值的并行更新操作会被串行化，它们需要同步机制来防止多个线程同时更新同一个键值。因此，随着线程数量的增加，它们性能也只能趋于平缓。Ideal 虽然比 TBB 和 Masstree 的性能高出 6 倍，但相比 Anna，还是差了很多。尽管它没有使用同步机制，但在多个线程修改共享内存地址时，仍然存在缓存一致性方面的开销。

相反，在 Anna 中，更新操作是针对本地状态进行的，不需要进行同步，并定时通过广播进行变更交换。在高并发情况下，尽管它的性能仍然受限于其复制系数，但比基于共享内存的系统要好很多。Anna 有 90% 的 CPU 时间用于处理请求，花在其他方面的时间则很少。可见，Anna 的无协调 actor 模型解决了键值存储系统在多核环境里的伸缩性难题。

Ref：
https://www.oschina.net/news/94083/six-programming-paradigms-that-will-change-how?from=20180318
https://www.zhihu.com/question/33982387/answer/152497769
https://mp.weixin.qq.com/s/3WmGpZkEuSz-ox_2CPCsqg