一、Apache Cassandra介紹
為什麼要使用Cassandra?
● 分布式的海量資料存儲和處理
● 極高的性能
● 極緻的可靠性（去中心化的架構 無單點故障）
● 優秀的線性可擴充能力（無上限）
● 對多地多資料中心部署的原生支援
● 運維和管理需要了解的概念簡單
● 使用對開發者非常友好的類SQL語言CQL
● 強大的生态、活躍的國際社群
● 不斷緊跟最新技術趨勢（k8s、雲原生、多模、存儲計算分離）使得它持續具有強大的生命力
為什麼很多企業都會使用Cassandra資料庫？首先它是一個分布式的海量資料存儲的資料庫，我們這裡說的海量不止是幾十個TB，而是幾萬甚至幾十萬TB的資料庫體量，這個是傳統資料庫非常難以企及的水準。
然後它有極高的性能，這裡說的高性能指的是它每個讀寫操作通常都可以達到個位數毫秒級别，這跟很多其它的資料庫讀寫操作比起來，會有數量級的性能提升，對互動式應用的終端使用者體驗會是很大的提高。
再就是它的去中心的架構使得它天然具有無單點故障的優勢，這樣也就讓它有極緻的可靠性。Cassandra可以做到100%線上，在美國大型商企裡面有Cassandra叢集，在生産環境上線三年内都是100%線上。
另一點就是Cassandra優秀的線性可擴充能力是無上限的可擴充。我們在後面會看到一個紐約證券交易所應用案例裡面，對這種無限擴充的能力非常贊賞。
還有對多資料中心的原生支援，使得全球多地部署成為非常容易的事情，然後就是它的運維和管理需要了解的概念非常簡單，因為在Cassandra裡面它的每個節點都是對等的完全一樣，是以部署1個節點，跟部署10個或者500個節點其實差别并不大。
Cassandra沒有對其它系統群組件的過多依賴，隻需要UNIX主機和Java運作環境，這樣的話其實對容器化和雲原生的部署其實非常有利。另外Cassandra提供了一種對開發者非常友好的類SQL語言：CQL。通常僅需花上半天時間就可以快速上手。
Cassandra工資前10的位置
學習Cassandra的好處？
● 著名招聘網站DICE的年度工資調查，Cassandra一直被列為IT行業十大平均薪酬水準最高的技術之一
● 對分布式系統的了解和動手能力——校招面試必備技能
● 跟社群高手學習和交流
● 提高你在職場的競争力
Cassandra這麼多年在美國是非常熱門的技術，在IT行業平均薪酬僅次于人工智能和自然語言處理，學習Cassandra還可以非常容易的加深分布式系統的了解和動手能力，對于參加校招和社招來說也非常有利。Cassandra采用了非常有名的資料結構 LSM Tree，也就是Log-Structured Merge Tree。LSM Tree幾乎是大廠面試必考題目，Cassandra可以算工業界把LSM Tree用的最爐火純青的資料庫。在參與Cassandra社群、或者學習，源碼貢獻時，會有社群高手交流和學習的機會，能夠提高你在職場的競争力。
DBEngine全世界非常權威的資料庫的流行程度排名清單中，Cassandra一直在寬表資料庫裡面持續遙遙領先。
國際社群統計資料看到，在财富前100強企業裡面90%在使用Cassandra，美國著名職場社交網站LinkedIn上已有78000 Cassandra專業人士，每年都有20%增長。根據 DataStax公司統計，有72%的公司預計今年NoSQL使用會繼續增加。Cassandra在GitHub上有相關的docker鏡像，在一年多以前放上之後，每年都有186%的下載下傳量增長。目前DataStax Academy學院注冊學員167,490。一些相關的大廠亞馬遜、微軟都相繼推薦自己的Cassandra雲服務。
二、架構基礎和原理篇
Cassandra資料庫，資料分布在多個節點上。Cassandra起配僅需單節點，吞吐量每核每秒可達到幾千筆操作。生産環境通常會配置多節點，節點之間通過gossip協定進行通信，建構成一個hash token環。每個節點負責一部分token範圍，這些節點之間通過gossip來互相告知誰負責哪個token範圍，哪個節點是離線，哪個節點是新加入，這些都需要高效率的通信協定。有了gossip協定，每個節點都獨立自主，可以自發的學習所有其它節點的狀态，這也就是我們平常說的對等網絡p2p概念。P2p概念對Cassandra高可靠性和線性擴充非常重要，這也是Cassandra和其它資料的關鍵差別。
Cassandra資料庫非常吸引人的特性就是線性擴充。如果需要更多存儲容量或更多資料吞吐量，隻要增加節點就好。（圖為當年多倫多大學全球非常有名的資料庫組，做性能測評的時候，專門來檢測資料庫是不是确實能夠做到線性增長）。另外Cassandra資料庫在全球範圍流行的重要原因，可以一直加節點，對資料庫擴容基本上沒有上限，這樣的架構在雲計算時代非常便利。
Cassandra擴容通過水準擴充來進行，其它資料庫想增加處理能力就要加CPU或者記憶體、用更快的磁盤，垂直往節點上堆硬體讓單節點更快更強，但Cassandra設計不僅有Scale Up垂直擴充，還有Scale Out水準擴充，使用便宜的普通硬體，在資源不夠的情況下，增加節點，就可以讓吞吐量實作翻倍。
資料分布前
資料分布後
Cassandra分布可以使用如上圖示例，資料按照分區建(partition Key)寫入到Cassandra的多個節點，同樣的partition Key就會在存儲到同一個節點上。資料的分布是完全自動完成，應用隻需要持續寫入資料，就會自動被分布到叢集的各個節點上。
Cassandra環（Ring）的工作原理
Cassandra環（Ring）如何工作：想象下這裡有個環，每一個圓圈都代表一個節點，總共有6個節點，每個節點都配置設定了所負責的token範圍。我們這個例子裡面把token範圍取值簡化，假設環的token範圍加起來是0~100（實際應用中的整個token範圍非常大）。
每個節點負責一段token的範圍，比如說17号節點負責0~16，33号節點負責17~32，50号節點負責33~49，以此類推。我們特意用相同顔色把這個節點和它負責的範圍都用相同顔色标注出來。
如果現在有資料要被寫入，如token取值為59的資料。這6個節點中，将會有一個節點來負責處理這個寫入請求，本例假設是83号節點。這裡我們就管83号節點叫做Coordinator節點。Cassandra是無主架構，完全沒有什麼主節點、從節點這種角色，所有節點的地位都一樣，都可以同時扮演Coordinator節點，并都能存儲資料。
Coordinator節點誰當都可以，每筆操作不管是哪一個節點接受，它就成為Coordinator節點。用戶端也允許每個不同的讀寫操作都換一個Coordinator節點來接收，這也是Coordinator可以高并發高可靠的主要原因。
當然Coordinator節點接受操作後，它會把請求轉發給真正的副本存儲節點，也叫Replica node。那副本節點是如何計算出來的呢？剛剛說了67号節點所負責的token範圍：50~66。是以token值為59資料就會寫入到67号節點了。所有節點之間它們都是通過gossip協定，可以事先就知道所有節點各自負責哪個token範圍。這樣的情況下，83節點(Coordinator節點)就可以把資料轉發給67号節點(Replica node)。
Cassandra多副本
現在我們再來看一下存儲兩個副本，也就是複制因子Replication Factor為2的情況，副本節點是怎樣分布的呢，看到這個圖裡面現在多了一層環，跟剛才比較一下的話，現在對于每一個token範圍，都會有兩個節點負責。比如說67号節點，它還是負責token範圍為50~66，但現在83号節點，它也會負責50~66，看這個圖裡面第二道環所有的顔色都是往下移了一位。這個淺紫色不光是67号節點負責，83号節點也會負責它了。
資料寫入前
同時落到2個節點上去
如果取值為59的資料要寫入叢集，假設選擇了17号節點(coordinator節點)來寫入。剛剛說現在67号節點和83号節點同時對token範圍50~66負責，那麼這個寫操作都會同時落到這兩個節點上，它們同時成為了副本節點(Replica node)。
以此類推，當存儲三份副本，複制因子Replication Factor為3時，Cassandra環（Ring）會再多一層，又往下移了一位，寫操作就會同時落到三個節點上。
多副本的配置，在生産環境中應用的是非常普遍的。因為一份資料存儲多份，且分布在不同節點上的話，就為資料庫平穩處理節點故障的情況打下了基礎。
節點故障
如果我們有一個節點故障，這個資料庫會怎麼樣處理呢？我們還是把複制因子設成3。現在假設83号節點出現了故障停機，如果現在還是有兩個節點能通路到同樣的資料，這個時候如果coordinator節點收到一個新的寫操作，這個寫操作還是可以被轉發給兩個仍然線上的節點。如果是讀操作，它也可以從剩下的兩個節點讀出資料。
資料hence的形式緩存一筆資料
如圖所示，因為83号副本節點已故障，臨時不能線上。17号節點作為Coordinator節點，它會以hint的形式緩存一筆 token取值為59的資料。這樣的話當83号節點重新線上的時候，會有個叫hinted handoff的過程來自動把剛才83号節點離線期間沒有正确寫入的資料，自動重新補齊。
資料補齊
資料修複
而且Cassandra有多副本資料時，還可以實作副本間的自動修複，它會使得Cassandra資料庫在節點短期故障的情況下，資料可靠性和一緻性會大大提高。
總結：Cassandra的masterless這種架構，每個節點都完全平等，既可以扮演Coordinator節點，也可以扮演副本節點這個機制，使得資料的通路性能、可靠性和一緻性都大大提高。
Cassandra資料庫可以有好幾個資料中心，非常優秀的點就是這些資料中心是可以全球分布的。如圖（左）顯示我們同一個資料庫，有北美資料中心，也可以有歐洲的資料中心，還可以有亞太的資料中心。比如一個跨國公司，需要為全球幾大洲的終端使用者提供服務，這樣統一的全球資料庫就非常便利。比如中國使用者，可以就近通路亞太資料中心，可以大大減少延遲，提高使用者體驗。
比如，同一個資料庫跨三個資料中心，北美、歐洲、亞太部署。在寫資料的同時，隻需要寫到北美資料中心，Cassandra有一個很高效的複制機制，自動讓資料馬上複制到歐洲和亞太資料中心，Cassandra原生這種資料複制，完全不需要配置和操心，沒有什麼複雜的ETL，也不用遠端拷貝檔案，都是自動化的。
再看右圖，這個是混合雲和多雲的部署情況，我們看到這個Cassandra不管是阿裡雲還是亞馬遜，還是google，還是自己的私有資料中心，都可以把它構造成一個Cassandra資料庫，把所有這些資料中心連成一個完整資料庫。
為什麼這樣部署很優秀？因為可以防止資料被限制在一個雲服務提供商，可以自由移動，哪家的雲服務價格更有競争力就選哪一家，哪一家的服務更好就選哪一家。遷移的時候甚至完全都不用中斷資料服務，在今天公有雲和私有雲無處不在的時代的這樣的部署方式，會讓這個企業的架構會更靈活和更有競争力。
分布式系統裡面，Consistency一緻性、Availability可用性，還有Partition Tolerance分區容錯性三者隻能選二。作為分布式資料庫Partition Tolerance是必選項，分布式資料庫其實就是在 Consistency和Availability這兩個間選一個，Cassandra其實比較重視可用性，優點在于一緻性可調。用戶端的每個操作都可指定Consistency Levels，通常縮寫為CL，有的CL組合比如說Quorum讀和Quorum寫（超過半數讀寫成功，則傳回成功），可以做到強一緻性，但是也不犧牲可用性。
有不少領域的人對Cassandra的了解是有誤區，他們覺得Cassandra屬于AP系統，沒有強一緻性。其實Cassandra隻是優先保證可用性，它在可用性和一緻性之間是完全可調的。
Consistency Levels 一緻性級别怎樣定義？在生産環境裡面，大部分情況下我們都會使用RF = 3，這樣能讓資料庫在高可用、高性能之間達到最佳平衡。
一緻性級别跟複制因子緊密相關。如果我們這個複制因子為3，也就是有三份副本，當一次性級别設成1（CL等于one），則1個副本确認操作成功就給用戶端傳回這次操作是成功的。比如說用戶端，要寫入一條資料，首先把寫請求發給Coordinator節點，因為複制因子為3，Coordinator節點會把記錄發給三個副本節點，然後這三個副本節點都會向Coordinator節點确認寫入成功，可能會有先有後。但是不管是誰最先傳回寫入成功，Coordinator節點隻有滿足了一緻性級别等于1的要求，這個寫操作就會傳回給用戶端，認為是寫入成功了。
但如果一定級别設成Quorum（也就是說超過半數操作成功的意思），比如複制因子是3的話，Quorum在這裡就是3÷2+1，也是2。就是說三個節點，需要兩個都要确認操作成功才傳回成功。注意coordinator節點，仍然會同時轉發讀寫請求給三個副本節點，這次它會等待兩個節點的成功回複，然後才傳回用戶端這一次的操作是成功的。
注意：如果這裡不是寫操作，而是讀操作的話，Coordinator節點會比較副本節點傳回的資料，哪個資料的時間戳更新，它就會選哪個傳回。這個原則也叫做last write win（最後寫入者勝出的原則）。
最後我們再來看看一緻性級别設成ALL這種情況，也就是說所有副本都要成功傳回。Coordinator節點還是會同時轉發讀寫請求給三個副本節點，但它需要等待所有三個副本節點都成功傳回，才能跟用戶端傳回這一次的操作是成功的。需要指出一點，我們一般不推薦在生産環境中使用ALL這樣的一緻性級别，因為用了ALL以後，基本上就放棄了高可用性。因為隻要有一個副本節點故障，則讀寫請求就會失敗。如果需要高一緻性，但也不想犧牲高可用性，其實是有更好方法解決，比如使用3副本，Quorum讀寫一緻性。
既滿足強一緻性Consistency，也滿足高可用性。強一緻性的定義是隻要讀的一緻性級别加上寫的一緻性級别是大于複制因子的，這樣讀寫操作就是強一緻性的。放到圖裡面來說，就是讀和寫都使用Quorum，2+2大于3(副本數)這種情況。
如果你是三個副本寫入的時候，在三個副本裡面成功的已經确認了兩個，現在如果讀操作進來的時候，不管讀到的是哪兩個副本，其中必定至少有一個副本，已經成功收到了最新寫入的值。
我們剛才說過last write win(最後寫入勝出原則)，coordinator節點讀的時候，隻要有一個是最新寫的内容，就足以使它給用戶端傳回最新的資料，是以Quorum級别隻要是寫入成功了，Quorum級别的讀一定會讀到最新寫入的值的。
複制因子設成3，采用Quorum讀和Quorum寫，可以兼顧一緻性和高可用性，如果你是剛剛開始使用Cassandra，這種配置是你的首選，可以避免踩很多坑。
三、應用場景
如果你有資料庫彈性擴充的需求，你的資料庫和資料需要高吞吐量，有大量的這種寫操作和讀操作，像物聯網時間序列資料庫這樣的應用場景，使用Cassandra是一個非常完美的選擇。
如果你需要資料庫這種高可用性，你的應用程式是關鍵任務，比如像病人監護這樣的場景，絕對不能有資料丢失，必須每一秒都線上，這個也是非常适合使用Cassandra做底層的資料存儲。
如果你需要有這種分布式的資料庫來存儲資料，你希望你的資料是全球分布、自由流動，并且自動在資料中心之間複制，同時你還有合規方面的需求，比如說像歐洲的GDPR或者是中國這種個人資訊安全規範的，也就是說你需要限制其中一部分資料，隻能存放在某一個國家或者某個州的資料中心，這樣雖然你的資料庫是跨全球的，Cassandra它本身自帶這樣的功能，你可以很容易配置，既能符合全球分布又能做到合規。
最後從源于雲源生這個角度，如果你需要開發運作在雲上的應用程式，這個程式不光要運作在公有雲，也要運作在私有雲，或者是需要部署在多個雲服務服務商之間跨雲部署，Cassandra在國外是不少大的廠商會預設選擇的。
在很多不同的垂直領域，像能源、金融、服務、運輸、物流、媒體、電信、零售、餐飲、科技、網際網路，這全球知名的品牌大公司都在使用Cassandra。還有美國黑色星期五的零售網站最大的4個網站 裡面有3個在使用Cassandra來幫助它們處理峰值。全球前15的大銀行有9個在使用Cassandra來處理它的關鍵業務。美國4大航空公司有3個在運作Cassandra。
Cassandra在各個知名公司應用場景不一樣，主要有物流和資産管理、欺詐監測和風控、庫存和商品名錄管理、性能監測管理、實時支付、供應鍊管理、客戶360、數字娛樂等。
2年前蘋果公司分享16萬台Cassandra節點，存儲超上百個PB資料，有上千個叢集。
像 Facebook的Instagram使用Cassandra應用案例，比較像我們的微信朋友圈，使用Cassandra存儲使用者他關注的所有的人新釋出的資訊，是百萬以上級别每秒的寫入操作，當然現在肯定吞吐量是更大，讀延遲的要求也比較高，可以看到它平均要在20個毫秒之内成功，因為會影響終端使用者的體驗。這個界面你可以看到它還使用Cassandra計數器類型，來記錄點贊的次數。
紐約證券交易所，每天會發生36億手股票交易，核心系統使用Cassandra資料庫的能力。特意提出來在他們部署環境裡面能夠scale infinitely，也就是說可以無限擴容能力對他來說是非常重要的。
像紐約證券交易所，像這麼大的這種應用場景，Cassandra都能夠很好的處理他們的需求。
四、趨勢展望
從DataStax角度來說，現在正在設計一個面向未來的這種資料架構，當然這個核心依然是Cassandra，但是在這個基礎之上，我們希望能夠讓應用程式的開發人員能夠解放出來，讓他們使用比較熟悉的資料接口。暴露給開發人員多種接口，比如GraphQL、restful接口、甚至是文檔資料庫接口。