現在網際網路系統的特點：快！需求變化快，系統響應速度要快。像**、微博等有上億使用者的**每日有上千萬的訪問量；當電商節開始時如：618，當有熱點事件時如：明星官宣結婚等等,訪問量更是暴增。傳統的小**的架構根本無法滿足需求，這就需要改變傳統的架構模式來應對該問題,如：增加快取。
快取就是把資料從訪問速度慢的地方移到訪問速度快的地方。在計算中，快取是乙個高速資料儲存層，其中儲存了資料子集，且通常是短暫性儲存，這樣日後再次請求此資料時，速度要比訪問資料的主儲存位置快。通過快取，可以高效地重用之前檢索或計算的資料。
redis有相較memcached而已有更豐富的資料結構，有string、list、set、sorted set、hash等。
string資料結構是簡單的key一value型別，value其實不僅是string，也可以是數字；list就是鍊錶，相信略有資料結構知識的人都應該能理解其結構；set就是乙個集合，集合的概念就是一堆不重複值的組合。利用redis提供的set資料結構，可以儲存一些集合性的資料；sorted set的使用場景與set類似，區別是set不是自動有序的，而sortedset可以通 過使用者額外提供乙個優先順序(score)的引數來為成員排序，並且是插入有序的，即自動排序；hash是乙個string型別的field和value的對映表。
redis是cs架構，當我們安裝好後service後就直接利用client操作使用redis了。我們可以根據官方的命令文件體驗redis。
#安裝到/usr/local/redis目錄中安裝的檔案只有乙個bin目錄
make
install prefix=/usr/local/redis/
#建立配置檔案和data存放目錄
mkdir /usr/local/redis/conf /usr/local/redis/data
#進入安裝目錄
cd /usr/local/redis/
#帶配置檔案啟動
#檢視幫助文件
./redis-server --help
#使用redis自帶的客戶端即可使用redis
當我們要在專案的使用時，就需要調整下我們的系統架構，在資料訪問層加入redis，將資料庫的查詢結果放入redis中。
redis主要消耗的伺服器的記憶體資源，當redis記憶體需求超過機器的最大記憶體，一台機器就夠不用了；另外，當我們使用者超過一定數量時，單機的redis讀寫能力就達到瓶頸；最後我們還要考慮單節點故障的問題，如果單機redis出現問題我們的系統整體將崩潰。因此，需要分片儲存，保障我們系統的高可用。
而redis官方上剛好給出是redis的分布式集群解決方案–redis cluster（官方集群方案介紹），在3.0版本推出後有效地解決了redis分布式方面的需求，實現了資料在多個redis節點之間自動分片、故障自動轉移、擴容機制等功能。
當我們增加了快取後，若程式設計不當又會引發新的問題：我們修改資料的同時需要重新整理快取，當訪問和修改併發操作時就有可能引起資料庫的資料和快取的資料不一致的問題。
例如更新資料庫和和重新整理快取順序不當就會導致該問題，如1.先更新資料庫，再更新快取；2.先更新快取，再更新資料庫；3.先刪除快取，再更新資料庫。這三種方案都有可能導致資料庫的資料和快取的資料不一致。
通常採用的方式是先更新資料庫，再刪除快取（spring註解@caheevict 採用的是這種機制）和資料非同步同步（如：利用阿里巴巴的canai工具幫助實現資料非同步更新）
當現有redis需要擴容時，slot避免不鳥需要調整，slot調整有自動rebalance、reshard、手動遷移。
手動遷移過程如下，大致描述如下：
在遷移目的節點執行cluster setslot importing 命令，指明需要遷移的slot和遷移源節點。
在遷移源節點執行cluster setslot migrating 命令，指明需要遷移的slot和遷移目的節點
在遷移源節點執行cluster getkeysinslot獲取該slot的key列表。
在遷移源節點執行對每個key執行migrate命令，該命令會同步把該key遷移到目的節點。
在遷移源節點反覆執行cluster getkeysinslot命令，直到該slot的列表為空。
在遷移源節點和目的節點執行cluster setslot node ，完成遷移操作。
高效刪除十萬資料redis的set集合
應用場景 redis中儲存了set集合,資料是萬級別,最高2萬資料,現在需要刪除這個set集合,並且防止刪除過程中,cpu突然增加,影響其他服務。解決辦法有三種 1.為set集合設定過期時間,依賴redis定時器刪除 2.重置set集合並設定過期時間,依賴redis定時器刪除 3.直接刪除set集合...
億級流量專案 redis持久化的意義
redis持久化的意義當然是 故障恢復，當遇到為什麼要用的問題時候，想一想沒有用的場景怎麼樣，再想一想用了的場景怎麼樣 1.如果redis不做持久化，它是儲存在記憶體中的，如果機器宕機了，資料就直接沒有了，要恢復資料，只能大批量的讀取資料庫資料，這樣的動作很慢，增大了資料庫的壓力。因此，不做持久化處...
Spark灰度發布在十萬級節點上的實踐
持續整合是指，及時地將最新開發的且經過測試的 整合到主幹分支中。持續整合的優點 目前主流的 管理工具有，github gitlab等。本文所介紹的內容中，所有 均託管於私有的 gitlab 中。鑑於 jenkins 幾乎是 ci 事實上的標準，本文介紹的 spark ci cd u0026amp c...