2018-03-22

新奇的編程方式,改變你對(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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市躯护,隨后出現(xiàn)的幾起案子惊来,更是在濱河造成了極大的恐慌,老刑警劉巖棺滞,帶你破解...
    沈念sama閱讀 221,888評(píng)論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件裁蚁,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡检眯,警方通過查閱死者的電腦和手機(jī)厘擂,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,677評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來锰瘸,“玉大人刽严,你說我怎么就攤上這事”苣” “怎么了舞萄?”我有些...
    開封第一講書人閱讀 168,386評(píng)論 0 360
  • 文/不壞的土叔 我叫張陵,是天一觀的道長(zhǎng)管削。 經(jīng)常有香客問我倒脓,道長(zhǎng),這世上最難降的妖魔是什么含思? 我笑而不...
    開封第一講書人閱讀 59,726評(píng)論 1 297
  • 正文 為了忘掉前任崎弃,我火速辦了婚禮,結(jié)果婚禮上含潘,老公的妹妹穿的比我還像新娘饲做。我一直安慰自己,他們只是感情好遏弱,可當(dāng)我...
    茶點(diǎn)故事閱讀 68,729評(píng)論 6 397
  • 文/花漫 我一把揭開白布盆均。 她就那樣靜靜地躺著,像睡著了一般漱逸。 火紅的嫁衣襯著肌膚如雪泪姨。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,337評(píng)論 1 310
  • 那天饰抒,我揣著相機(jī)與錄音肮砾,去河邊找鬼。 笑死循集,一個(gè)胖子當(dāng)著我的面吹牛唇敞,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 40,902評(píng)論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼疆柔,長(zhǎng)吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼咒精!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起旷档,我...
    開封第一講書人閱讀 39,807評(píng)論 0 276
  • 序言:老撾萬榮一對(duì)情侶失蹤模叙,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后鞋屈,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體范咨,經(jīng)...
    沈念sama閱讀 46,349評(píng)論 1 318
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,439評(píng)論 3 340
  • 正文 我和宋清朗相戀三年厂庇,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了渠啊。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,567評(píng)論 1 352
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡权旷,死狀恐怖替蛉,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情拄氯,我是刑警寧澤躲查,帶...
    沈念sama閱讀 36,242評(píng)論 5 350
  • 正文 年R本政府宣布,位于F島的核電站译柏,受9級(jí)特大地震影響镣煮,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜鄙麦,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,933評(píng)論 3 334
  • 文/蒙蒙 一典唇、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧胯府,春花似錦蚓聘、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,420評(píng)論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽与纽。三九已至侣签,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間急迂,已是汗流浹背影所。 一陣腳步聲響...
    開封第一講書人閱讀 33,531評(píng)論 1 272
  • 我被黑心中介騙來泰國(guó)打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留僚碎,地道東北人猴娩。 一個(gè)月前我還...
    沈念sama閱讀 48,995評(píng)論 3 377
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親卷中。 傳聞我的和親對(duì)象是個(gè)殘疾皇子矛双,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,585評(píng)論 2 359

推薦閱讀更多精彩內(nèi)容