新奇的編程方式，改變你對(duì)編碼的認(rèn)知默認(rèn)

并發(fā)

示例語言：ANI, Plaid
有些編程語言是默認(rèn)情況下并發(fā)的誓斥，也就是說只洒，每行代碼都是并行執(zhí)行的。
例如劳坑，假設(shè)你寫了三行代碼毕谴，A，B和C：

A;
B;
C;

在大多數(shù)編程語言中距芬，A先執(zhí)行涝开，然后執(zhí)行B，最后執(zhí)行C框仔。在像ANI這樣的語言中舀武，A，B和C都將同時(shí)執(zhí)行离斩。

ANI中代碼行之間的控制流或排序银舱，僅僅是代碼行之間顯式依賴關(guān)系的副作用。例如跛梗，如果B引用了A中定義的變量寻馏，則A和C將同時(shí)執(zhí)行，而B只會(huì)在A完成后執(zhí)行核偿。

以下是ANI中的“Hello World”示例：
"Hello, World!" ->std.out
"Goodbye, World!" ->std.out
這兩行代碼并行執(zhí)行诚欠，因此它們可以在控制臺(tái)中以任何順序結(jié)束。

現(xiàn)實(shí)中發(fā)生是有順序的宪祥，如何控制聂薪？ 通過加鎖控制

如：

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

第一行聲明一個(gè)“鎖存（latch）”（鎖存器有點(diǎn)像變量），調(diào)用 s它包含一個(gè)字符串; 第二行將文本賦值 "Hello, World!"給s; 第三行“解鎖” s并將內(nèi)容發(fā)送給std.out蝗羊。在這里藏澳，您可以看到ANI的隱式程序排序：由于每行都依賴于前一行，因此此代碼將按寫入的順序執(zhí)行耀找。

Apache Ignite 2.4.0 發(fā)布翔悠，內(nèi)存數(shù)據(jù)組織平臺(tái)

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總線蓄愁，內(nèi)存計(jì)算是個(gè)框什么都可以往里裝。hadoop狞悲，spark解決了大數(shù)據(jù)存儲(chǔ)問題撮抓，但沒解決大數(shù)據(jù)計(jì)算痛點(diǎn)，多功能分布式內(nèi)存計(jì)算是趨勢(shì)摇锋。從官網(wǎng)的下圖可以看出ignite有數(shù)據(jù)網(wǎng)格丹拯，計(jì)算網(wǎng)格站超，服務(wù)網(wǎng)格，sql網(wǎng)格乖酬，數(shù)據(jù)結(jié)構(gòu)死相，流計(jì)算，文件系統(tǒng)咬像，高級(jí)集群等模塊算撮，都是放在內(nèi)存操作，我想主要追求的是能快速分析處理數(shù)據(jù)县昂，實(shí)時(shí)內(nèi)存應(yīng)用肮柜，不像hadoop基于硬盤文件，發(fā)個(gè)命令下去七芭，等喝完茶才有結(jié)果素挽。

對(duì)于結(jié)構(gòu)化數(shù)據(jù)處理,MB級(jí)用excel,pandas,sqlite,access，GB級(jí)用mysql,oracle,sql server,postgresql狸驳，TB級(jí)用mongodb，greenplum缩赛，PB級(jí)用hadoop,spark,EB級(jí)自己想辦法耙箍。數(shù)據(jù)量越大操作起來越費(fèi)勁越費(fèi)時(shí)，只適合事后慢慢分析酥馍，從spark開始內(nèi)存計(jì)算就是為了解決太費(fèi)時(shí)問題辩昆，Apache Beam也延續(xù)了這種趨勢(shì)，ignite主要內(nèi)存功能強(qiáng)大旨袒，更方便適用汁针，用內(nèi)存來聚合數(shù)據(jù)源，處理數(shù)據(jù)砚尽。隨著時(shí)間的推移施无，移動(dòng)互聯(lián)網(wǎng)物聯(lián)網(wǎng)的使用，數(shù)據(jù)會(huì)成指數(shù)增長(zhǎng)必孤，不上大內(nèi)存根本跑不快猾骡，服務(wù)器內(nèi)存價(jià)格只會(huì)越來越便宜，內(nèi)存計(jì)算只會(huì)越來越流行敷搪。

特性介紹

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

超高性能鍵值存儲(chǔ)數(shù)據(jù)庫 Anna

Anna 是伯克利 RISE 實(shí)驗(yàn)室推出的鍵值存儲(chǔ)數(shù)據(jù)庫兴想，也是一個(gè)具備驚人的存取速度、超強(qiáng)的伸縮性和優(yōu)秀的一致性的 KVS赡勘。

Anna 的性能和伸縮性主要?dú)w功于它的完全無協(xié)調(diào)機(jī)制嫂便，節(jié)點(diǎn)工作進(jìn)程有 90% 的工作負(fù)載是在處理請(qǐng)求，而其他大部分系統(tǒng)（如 Masstree 和英特爾的 TBB）只有不到 10% 的時(shí)間在處理請(qǐng)求闸与，它們其余的 90% 時(shí)間花在了等待協(xié)調(diào)上毙替。不僅如此曼振，其他系統(tǒng)因?yàn)槭褂昧斯蚕韮?nèi)存，還會(huì)出現(xiàn)處理器緩存擊穿問題蔚龙。

Anna 不僅速度快冰评，在一致性方面也達(dá)到了很高的水準(zhǔn)。多年前木羹，他們發(fā)布的事務(wù)協(xié)議 HATs 就已表明甲雅，無協(xié)調(diào)的分布式一致性和事務(wù)隔離性存在很大的提升空間，包括級(jí)聯(lián)一致性和讀提交事務(wù)級(jí)別坑填。Anna 將 Bloom 的單格子組合設(shè)計(jì)模式移植到了 C++ 中抛人，是第一個(gè)實(shí)現(xiàn)了上述所有級(jí)別一致性的系統(tǒng)。當(dāng)然脐瑰，也是因?yàn)樵O(shè)計(jì)上的簡(jiǎn)潔妖枚，才能達(dá)到如此快的速度。

Bedrock

基于 Anna 開發(fā)一個(gè)新的擴(kuò)展系統(tǒng)苍在，叫作 Bedrock绝页。Bedrock 運(yùn)行在云端，提供了無需人工干預(yù)寂恬、低成本的鍵值存儲(chǔ)方案续誉，而且是開源的。

無協(xié)調(diào) actor 模型的伸縮性

在無協(xié)調(diào) actor 模型中初肉，每個(gè) actor 對(duì)應(yīng)一個(gè)線程酷鸦，對(duì)任何一個(gè)共享狀態(tài)都有自己的一份私有拷貝，并通過異步廣播將更新通知給其他 actor牙咏。在多核服務(wù)器上臼隔，這種模型比傳統(tǒng)的共享內(nèi)存模型的性能要高出一個(gè)數(shù)量級(jí)。

一個(gè)對(duì)比實(shí)驗(yàn)妄壶，將 Anna 與其他基于共享內(nèi)存的 TBB摔握、Masstree 和自己實(shí)現(xiàn)的一個(gè)鍵值存儲(chǔ)系統(tǒng)（姑且把它叫作“Ideal”）進(jìn)行了對(duì)比。他們?cè)?AWS 的 m4.16xlarge 實(shí)例上運(yùn)行實(shí)驗(yàn)盯拱，每個(gè)實(shí)例配備了 32 核的 CPU盒发。實(shí)驗(yàn)中使用了 1 百萬個(gè)鍵值對(duì)，鍵的大小為 8 字節(jié)狡逢，值的大小為 1KB宁舰。在實(shí)驗(yàn)過程中，他們基于 zipfian 分布和各種系數(shù)生成不同的壓力負(fù)載奢浑，模擬不同層次的沖突蛮艰。
在第一次實(shí)驗(yàn)中，他們對(duì)比了 Anna 與 TBB雀彼、Masstree 和 Ideal 在單臺(tái)服務(wù)器上的吞吐量壤蚜。他們逐漸增加線程數(shù)量即寡，直到達(dá)到服務(wù)器 CPU 核數(shù)的上限，并觀察它們的吞吐量袜刷。

在高并發(fā)情況下聪富，線程數(shù)與吞吐量的變化關(guān)系，其中 zipf 系數(shù)為 4

在高并發(fā)情況下著蟹，CPU 時(shí)間的使用情況墩蔓。CPU 時(shí)間被分為 5 類：處理請(qǐng)求（RH）、原子指令（AI）萧豆、合并格子（LM）奸披、廣播（M）和其他。最右邊一欄是 L1 緩存擊穿數(shù)量（CM）涮雷。

從圖中可以看出阵面，在這樣的負(fù)載壓力下，TBB 和 Masstree 幾乎失去了并行能力洪鸭。因?yàn)榇蟛糠质歉虏僮餮ⅲ槍?duì)同一個(gè)鍵值的并行更新操作會(huì)被串行化，它們需要同步機(jī)制來防止多個(gè)線程同時(shí)更新同一個(gè)鍵值卿嘲。因此颂斜，隨著線程數(shù)量的增加，它們性能也只能趨于平緩拾枣。Ideal 雖然比 TBB 和 Masstree 的性能高出 6 倍，但相比 Anna盒让，還是差了很多梅肤。盡管它沒有使用同步機(jī)制，但在多個(gè)線程修改共享內(nèi)存地址時(shí)邑茄，仍然存在緩存一致性方面的開銷姨蝴。

相反，在 Anna 中肺缕，更新操作是針對(duì)本地狀態(tài)進(jìn)行的左医，不需要進(jìn)行同步，并定時(shí)通過廣播進(jìn)行變更交換同木。在高并發(fā)情況下浮梢，盡管它的性能仍然受限于其復(fù)制系數(shù)，但比基于共享內(nèi)存的系統(tǒng)要好很多彤路。Anna 有 90% 的 CPU 時(shí)間用于處理請(qǐng)求秕硝，花在其他方面的時(shí)間則很少≈拮穑可見远豺，Anna 的無協(xié)調(diào) actor 模型解決了鍵值存儲(chǔ)系統(tǒng)在多核環(huán)境里的伸縮性難題奈偏。

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