redis高級應用
一、事務
Redis的事務相對不是很完善，下面通過實例來看一下redis事務的問題在哪？
事務正常執行：
事務執行出現問題：
以上實踐可以看出redis雖然有事務，但是事務的機制并不完善，這是需要改進的地方。
一旦是數據庫就會涉及到并發的問題，一般是使用鎖類解決并發問題，鎖分為悲觀鎖和樂觀鎖。在redis使用事務和watch監聽一起達到樂觀鎖的效果，實例的完成需要開啟兩個會話。
實例：左側為session2，右側為session1
1、Session1添加監聽，開啟事務
2、session2中對age進行修改
3、session1中添加事務隊列，修改age
4、執行事務，獲取age的值
在session1中對age添加了監聽，在監聽后如果age的值被改變session1中對age再次做修改則無法提交。
二、發布訂閱消息
存儲引擎
Cassandra使用了一種類似于日志結構合并樹的存儲結構，而不是像傳統關系型數據庫那樣使用B-Tree。Cassandra避免寫之前讀。寫前讀，尤其是大型的分布式系統中，可能導致讀取性能的延遲和其他問題。例如，兩個客戶端同時讀。一個以覆蓋的方式更新A，另一個以覆蓋的方式更新B，同時刪除A的更新。這種競爭條件會導致模棱兩可的查詢結果—雖然更新都是對的。
在Cassandra中為了避免寫前讀，存儲引擎組在內存中進行插入和更新操作，然后在間隔的時候，依次將數據以追加的模式寫入磁盤。一旦寫入磁盤，數據就是不可變的，而且永遠不會覆蓋。讀取數據需要結合這些不可變的、順序寫入的數據，以此發現正確的查詢結果。你可以在寫之前使用輕量級事務(LWT)來檢查數據的狀態。然而，此功能只被推薦用于有限的場合。
日志結構引擎避免了覆蓋，使用了順序IO來更新數據，對于寫數據到固態硬盤和普通硬盤來說，是至關重要的。在HDD上，隨機寫比順序寫涉及到更多的查找操作。所導致的害處是實在的。由于Cassandra順序寫不可改變的文件，因此避免了寫放大和磁盤故障，數據庫容納便宜的，消費者固態硬盤尤其好。在很多其他數據庫上，寫入放大是在SSD上是一個問題。
Cassandra如何讀和寫數據
Understanding howCassandra stores data.
要想管理和訪問Cassandra的數據，理解Cassandra如何存儲數據是非常重要的。hinted handoff的特性增加了Cassandra的性能，而且ACID(原子性，一致性，隔離性，持久性)的非一致性的數據庫屬性是理解讀和寫的關鍵概念。在Cassandra里，一致性的意思是如何保持最新，和在所有副本上的行的數據保持同步。
用于開發數據存儲和索引的應用程序的客戶端工具和應用編程接口(API)都是可用的。
數據如何寫？
Understand how Cassandrawrites and stores data.
Cassandra在寫路徑上處理數據分為好幾個階段，以立即寫日志開始，以寫數據到磁盤結束。
? 寫數據日志至commit log
? 寫數據至memtable
? 從memtable刷新數據
? 存儲數據值磁盤的SSTables
日志寫入和memtable存儲
當一個寫發生時，Cassandra把數據存儲到內存中的一個叫做memtable的結構里，而且為了提供可配置的持久化，它也將寫入到磁盤的commit log里。Commit log接收Cassandra節點的每一個寫操作，這些持久化的寫操作永久存在，即使節點出現故障。Memtable是一個數據分區的寫回緩存，Cassandra通過key查找。Memtable存儲已排好序的寫操作，直到達到配置的限制，然后再刷新。
從memtable刷新數據
刷新數據，Cassandra會按照memtable排序的順序把數據寫入磁盤。同時一個分區索引也會在磁盤上被創建，可以把token值映射到磁盤的某個位置上。當memtable的內容超過了配置好的閾值或者commit log的空間超過了commitlog_total_space_in_mb，這時memtable會進入一個會刷新到磁盤的隊列中。該隊列可以使用cassandra.yaml文件里的memtable_heap_space_in_mb或者memtable_offheap_space_in_mb來配置。如果將要刷新的數據超過了memtable_cleanup_threshold的值，Cassandra會阻塞寫操作，直到下一個刷新成功。你可以使用
nodetool flush或者nodetooldrain(不需要監聽其他節點，刷新memtables)直手動刷新一個表。為了減少commit log的重播時間，推薦最佳實踐是在你啟動節點之前刷新memtables。如果一個節點停止工作，在它停止之前重新提交commit log恢復memtable寫。
commit log里的數據在相應的memtable里的數據刷新到磁盤的SSTable里以后，會進行合并。
Storingdata on disk in SSTables
每一個表都維護著一個Memtables和SSTables。commit log是所有的表共享的。SSTables是不可變的，在memtable刷新過后不會再重新寫入。因此，一個分區通常保存在多個SSTable文件里。大量其他的SSTable結構存在著，以協助讀操作。
對于每一個SSTable，Cassandra會創建這些結構：
數據 (Data.db)
SSTable的數據。
主要索引 (Index.db)
行鍵的索引，有指針指向他們在數據文件中的位置
Bloom過濾器(Filter.db)
內存中存儲的一個結構，在數據進入磁盤的SSTables之前檢查數據是否存在于memtable里。
Compression信息(CompressionInfo.db)
一個文件，包含未壓縮的數據長度，塊偏移量和其他的壓縮信息。
統計 (Statistics.db)
統計SSTable的內容元數據。
文摘 (Digest.crc32, Digest.adler32, Digest.sha1)
包含數據文件的adler32校驗和的文件
CRC(CRC.db)
包含在一個未壓縮文件里的塊的CRC32的文件。
SSTable索引摘要(SUMMARY.db)
保存在內存中的分區索引的示例。
SSTable表的內容 (TOC.txt)
存儲sstable表的內容所有組件列表的文件。
第二索引 (SI_.*.db)
內置第二索引，一個SSTable里可存在多個第二索引。
SSTables是存儲在磁盤上的文件。SSTable文件的命名規則在Cassandra2.2和后來的版本中發生了改變，為了縮短文件路徑。數據文件存儲的位置隨著安裝方式的不同而不同。對于每一個鍵空間，數據目錄內的目錄存儲每一個表。例如，/data/data/ks1/cf1-5be396077b811e3a3ab9dc4b9ac088d/la-1-big-Data.db代表一個數據文件。開始表示鍵空間的名稱，以區分流空間或者批量加載數據。這個例子中的十六進制字符串5be396077b811e3a3ab9dc4b9ac088d，追加到表名稱后面，來表示唯一的表ID。
Cassandra為每一個表創建一個子目錄，這樣你可以使用一個表來選擇物理驅動器或數據量。這樣就提供了把表轉移到更快的媒介上的能力來獲得更好的性能，比如SSD，而且在存儲層上在所有附加的存儲設備上劃分表以獲得更好的I/O平衡。
數據是如何保持的?
Cassandra processes dataat several stages on the write path. Compaction to maintain healthy SSTables isthe last step in the write path process.
Cassandra寫過程把數據存儲到一個叫做SSTables的結構里。SSTables是不可變的。Cassandra為新插入的或者更新的數據寫入一個新時間戳的版本到新的SSTables里，而不是使用插入或者更新的數據去覆蓋已存在的行。同樣，Cassandra也不刪除空間：代替的是，Cassandra把需要刪除的數據標記為tombstone(墓碑)。
隨著時間的推移，Cassandra可能為每一行寫了很多的版本，每一個都在不同的SSTable里。每一個版本都有一個不同的時間戳作為唯一的標志存儲。這意味著Cassandra必須有越來越多的SSTables來檢索數據的一整排。
為了保持數據庫的健壯性，Cassandra周期性的合并SSTables和丟棄舊的數據。這個過程叫做compaction。
Compaction
Compaction通過分區鍵來合并每一個SSTable里的數據，使用最近的時間戳來選擇數據的版本。合并的過程是永久的。因為每一個SSTable里的行是通過分區鍵排序的，因此合并過程并不使用隨機I/O。在移除已刪除的列和行以后，compaction過程把SSTables合并到一個單一的SSTables里。舊的SSTables文件只要等待使用文件完成讀取以后就會被刪除。
Compaction會導致一個臨時的磁盤占用和磁盤I/O，這是舊的和新的SSTables同時存在。當它完成以后，compaction釋放舊的SSTables占用的磁盤空間。它通過壓縮過的SSTables替換舊SSTables來提高了讀性能。Cassandra甚至可以在完成寫之前直接從新的SSTable里讀取數據，而不是等待整個compaction過程完成以后。
當Cassandra處理讀和寫的時候，它在頁緩存里使用新SSTables替換掉舊的SSTables。緩存新的SSTables，把讀操作導向新的SSTables是一個漸進的過程-它不會導致戲劇性的緩存丟失。Cassandra提供了可預見的高性能，即使在高負載下。
Compaction策略
Cassandra支持不同的compaction策略。每一個都有自己的優勢。理解每一種策略是如果工作的，對于選擇適合你自己應用程序工作負載的策略是至關重要的。雖然下面的每一種選擇都是以廣義的建議開始的，但是有很多復雜的因素影響了compaction策略的選擇。有關更多關于每一種策略相對的優勢，和指定使用用例的討論的更多信息，參考:哪一種compaction策略是最好的？
SizeTieredCompactionStrategy(STCS)
推薦用于寫密集工作負載
當一組(默認4)相似大小的SSTables累積起來的時候，SizeTieredCompactionStrategy(STCS)初始化compaction。該compaction策略合并這些SSTables成一個更大的SSTable。然后這個更大的SSTables依次合并成一個更大的SSTables。在任何給定的時間里，幾個大小不等的SSTables同時存在。
當這個策略在一個寫密集的工作負載下運行的很好的時候，它使讀變得更慢，因為按大小合并的過程并不傾向于按行分組數據。因為這個原因，它更可能是一個特殊行的數據可能分布在很多的SSTables里。同樣，移除已被刪除的數據的發生是不可預知的，因為SSTable的大小是compaction過程的觸發器，而且SSTables增長的速度可能還不能達到合并和移除舊數據的條件。由于最大的SSTables大小會增長，磁盤compaction空間數量需要同時既容納新的，也要容納舊的SSTables，可能超過一個典型的節點的磁盤空間大小。
? Pros:壓縮寫密集工作負載很不錯
? Cons:可以保持過時的數據太長。需要的內存量隨著時間的推移而增加。
看文倉www.kanwencang.com網友整理上傳,為您提供最全的知識大全,期待您的分享，轉載請注明出處。
歡迎轉載：http://www.kanwencang.com/bangong/20170114/87380.html
文章列表
留言列表
