NoSQL

ACID

在傳統(tǒng)數(shù)據(jù)庫系統(tǒng)中，事務(wù)具有ACID屬性(Jim Gray在《事務(wù)處理：概念與技術(shù)》中對事務(wù)進行了詳盡的討論)。

(1)原子性（Atomicity）：事務(wù)是一個原子操作單元，其對數(shù)據(jù)的修改，要么全都執(zhí)行，要么全都不執(zhí)行。

(2)一致性（Consistent）：在事務(wù)開始和完成時，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關(guān)的數(shù)據(jù)規(guī)則都必須應(yīng)用于事務(wù)的修改，以保持數(shù)據(jù)的完整性；事務(wù)結(jié)束時，所有的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（如B樹索引或雙向鏈表）也都必須是正確的。

(3)隔離性（Isolation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機制，保證事務(wù)在不受外部并發(fā)操作影響的“獨立”環(huán)境執(zhí)行。這意味著事務(wù)處理過程中的中間狀態(tài)對外部是不可見的，反之亦然。

(4)持久性（Durable）：事務(wù)完成之后，它對于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。

對于單個節(jié)點的事務(wù)，數(shù)據(jù)庫都是通過并發(fā)控制（兩階段封鎖，two phase locking或者多版本，multiversioning）和恢復機制（日志技術(shù)）保證事務(wù)的ACID特性。對于跨多個節(jié)點的分布式事務(wù)，通過兩階段提交協(xié)議（two phase commiting）來保證事務(wù)的ACID。

可以說，數(shù)據(jù)庫系統(tǒng)是伴隨著金融業(yè)的需求而快速發(fā)展起來的。對于金融業(yè)，可用性和性能都不是最重要的，而一致性是最重要的，用戶可以容忍系統(tǒng)故障而停止服務(wù)，但絕不能容忍帳戶上的錢無故減少(當然，無故增加是可以的)。而強一致性的事務(wù)是這一切的根本保證。

Data Replication

數(shù)據(jù)復制(data replication)屬于分布式計算的范疇，它并不僅僅局限于數(shù)據(jù)庫，但這里主要是指分布式數(shù)據(jù)庫的復制。

在多副本構(gòu)成的分布式數(shù)據(jù)庫系統(tǒng)中，其事務(wù)特性與單個數(shù)據(jù)庫系統(tǒng)的差別主要表現(xiàn)在原子性和一致性兩個方面。在原子性方面，要求同一分布式事務(wù)的所有操作在所有相關(guān)副本上要么提交，要么回滾，即除了保證原有的局部事務(wù)的原子性，還需要控制全局事務(wù)的原子性；在一致性方面，多副本之間需要保證單一副本一致性。

針對分布式事務(wù)的原子性和一致性這兩個復制協(xié)議中的核心問題，經(jīng)過近20年的研究，人們提出了各種各樣的復制協(xié)議。這些協(xié)議在外在功能和內(nèi)部實現(xiàn)兩方面都有較大的差別。據(jù)此，我們可以從這兩個大的方面進行分類說明。

從外在功能的角度看，可以從事務(wù)執(zhí)行的地點和時間兩個方面進行分類。從事務(wù)執(zhí)行的地點，可以分為兩類：主從(Priamry/Copy)方式和更新所有(Update-Anywhere)方式。

前者的處理過程一般是系統(tǒng)中僅僅指定一個Primary節(jié)點接受更新請求，在事務(wù)操作執(zhí)行完畢后，在事務(wù)提交前或后將操作廣播到其他Copy節(jié)點。

后者的處理過程稍微復雜，系統(tǒng)中的任何副本具有相同的地位，都可以接收Update請求，在檢測事務(wù)沖突、事務(wù)提交前或后將各個節(jié)點的Update傳播到其他副本節(jié)點。

Primary/Copy方式并發(fā)控制較為簡單，由Primary本地的事務(wù)控制即可實現(xiàn)，事務(wù)原子性的實現(xiàn)也較為簡單，一般由Primary節(jié)點作為協(xié)調(diào)節(jié)點來實現(xiàn)。但是，其缺陷也顯而易見：僅僅單個節(jié)點提供Update請求處理能力，對于Update密集類型的應(yīng)用，如OLTP，容易形成單點性能瓶頸。Update-Anywhere方式則與其相輔相成，可以通過多點提高事務(wù)吞吐率，但隨之而來的是多個分布式事務(wù)之間復雜的并發(fā)控制和原子性問題。

從事務(wù)提交的時間點看，可以分為積極(Eager)和消極(Lazy)兩類。其區(qū)別在于，前者是在事務(wù)提交前傳播更新，后者則是在提交之后才將事務(wù)操作傳播到其他副本。實際上，前者即通常所謂的同步復制(synchronous replication)，后者即所謂的異步復制(asynchronous replication)。

異步復制的優(yōu)點是可以提高響應(yīng)速度，但犧牲了一致性，一般實現(xiàn)該類協(xié)議的算法需要增加額外的補償機制。同步復制的優(yōu)點是可以保證一致性(一般通過兩階段提交協(xié)議)，但是開銷較大，可用性不好(參見CAP部分)，帶來了更多的沖突和死鎖等問題。值得一提的是Lazy+Primary/Copy的復制協(xié)議在實際生產(chǎn)環(huán)境中是非常實用的，MySQL的復制實際上就屬于這種。

CAP

在2000年的PODC（Principles of Distributed Computing）會議上，University of California, Berkeley的計算機科學教授Eric Brewer提出了著名的CAP理論。2002年，Seth Gilbert和Nancy Lynch證明了這一理論。CAP指的是：Consistency、Availability和Partition Tolerance。

(1)Consistency（一致性）：一致性是指數(shù)據(jù)的原子性，這種原子性在經(jīng)典的數(shù)據(jù)庫中是通過事務(wù)來保證的，當事務(wù)完成時，無論其是成功還是回滾，數(shù)據(jù)都會處于一致的狀態(tài)。在分布式環(huán)境中，一致性是說多個節(jié)點的數(shù)據(jù)是否一致。

(2)Availability（可用性）：可用性是指服務(wù)能一直保證是可用的狀態(tài)，當用戶發(fā)出一個請求，服務(wù)能在有限時間內(nèi)返回結(jié)果。

(3)Partition Tolerance（分區(qū)容錯性）：Partition是指網(wǎng)絡(luò)的分區(qū)。可以這樣理解，一般來說，關(guān)鍵的數(shù)據(jù)和服務(wù)都會位于不同的IDC。

CAP理論告訴我們，一個分布式系統(tǒng)不可能同時滿足一致性，可用性和分區(qū)容錯性這三個需求，三個要素中最多只能同時滿足兩點。三者不可兼顧，此所謂魚與熊掌不可兼得也！而對于分布式數(shù)據(jù)系統(tǒng)而言，分區(qū)容錯性是基本要求，否則就不稱其為分布式系統(tǒng)了。因此架構(gòu)設(shè)計師不要把精力浪費在設(shè)計如何能同時滿足三者的完美分布式系統(tǒng)上，而是應(yīng)該進行權(quán)衡取舍。這也意味著分布式系統(tǒng)的設(shè)計過程，也就是根據(jù)業(yè)務(wù)特點在C（一致性）和A（可用性）之間尋求平衡的過程，要求架構(gòu)師真正理解系統(tǒng)需求，把握業(yè)務(wù)特點。

BASE

BASE來自于互聯(lián)網(wǎng)的電子商務(wù)領(lǐng)域的實踐，它是基于CAP理論逐步演化而來，核心思想是即便不能達到強一致性(Strong consistency)，但可以根據(jù)應(yīng)用特點采用適當?shù)姆绞絹磉_到最終一致性(Eventual consistency)的效果。BASE是Basically Available、Soft state、Eventually consistent三個詞組的簡寫，是對CAP中C&A的延伸。BASE的含義：

(1)Basically Available：基本可用；

(2)Soft-state：軟狀態(tài)/柔性事務(wù)，即狀態(tài)可以有一段時間的不同步；

(3)Eventual consistency：最終一致性；

BASE是反ACID的，它完全不同于ACID模型，犧牲強一致性，獲得基本可用性和柔性可靠性并要求達到最終一致性。

CAP、BASE理論是當前在互聯(lián)網(wǎng)領(lǐng)域非常流行的NoSQL的理論基礎(chǔ)。

NoSQL

NoSQL領(lǐng)域的相關(guān)知識點參見如下思維導圖：

參考

http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed

http://www.cnblogs.com/hustcat/archive/2010/09/07/1820970.html

http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html

http://blog.csdn.net/yangbutao/article/details/8365695

http://www.cnblogs.com/me115/p/3835050.html

12306

http://www.csdn.net/article/2015-02-10/2823900

技術(shù)揭秘12306改造

https://www.zhihu.com/question/21217971/answer/17575573

超級計算機能不能用于12306？

Clojure

Clojure是Lisp語言在JVM上的實現(xiàn)。源代碼以.clj為后綴。

官網(wǎng)：

http://clojure.org/

Clojure的安裝主要有兩種方法：

1.

sudo apt-get install clojure1.6

2.Clojure的全部功能都被放在clojure-1.8.0.jar中，因此實際上并不需要安裝。所謂安裝，不過是下載jar，然后讓程序能夠找到j(luò)ar即可。因此，更好的辦法是利用我們下面提到的leiningen，自動下載相關(guān)依賴。

leiningen

leiningen是Clojure的自動管理工具。

官網(wǎng)：

http://leiningen.org/

project.clj是Leigingen為項目添加的配置文件，類似于Maven的pom.xml。

project.clj中可以定義項目所需的Clojure的版本，并自動下載依賴。因此，很多Clojure項目在依賴上，往往只寫leiningen和maven，根本就不提Clojure。這一點和其他編程語言，包括同為JVM語言的scala，還是差異挺大的。

Hello World

1.

lein new app hello

2.

cd hello

lein run

這里要注意路徑，一定要在project.cl所在的路徑下執(zhí)行l(wèi)ein命令，否則會報如下錯誤：

No :main namespace specified in project.clj.

參見：

https://tonydeng.github.io/2016/07/19/leiningen-clojure-hello-world/

JavaFX

JavaFX和Clojure的結(jié)合，本來不是什么新鮮的東西，然而由于相關(guān)環(huán)境（JDK、leiningen）的演進，網(wǎng)上的demo已經(jīng)大多不可用了。

這些變動主要包括：

1.由于JDK7的較新版本之后，JavaFX已經(jīng)集成到JDK中，因此JavaFX的運行時jar不再需要了。相關(guān)依賴需要去除。

2.由于leiningen新版本的改變，現(xiàn)在main函數(shù)必須在源代碼和工程文件中顯式定義。

代碼參見：

https://github.com/antkillerfarm/antkillerfarm_rubbish/tree/master/clojure/javafx

總結(jié)

以上是生活随笔為你收集整理的NoSQL, Clojure的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。