1.redis

這個大家應該比較熟悉，一般用作快取伺服器。redis是一個key-value儲存系統。和Memcached類似，它支援儲存的value型別相對更多，包括string(字串)、list(連結串列)、set(集合)、zset(sorted set --有序集合)和hash（雜湊型別）。這些資料型別都支援push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支援各種不同方式的排序。與memcached一樣，為了保證效率，資料都是快取在記憶體中。區別的是redis會週期性的把更新的資料寫入磁碟或者把修改操作寫入追加的記錄檔案，並且在此基礎上實現了master-slave(主從)同步。

應用場景：

• 熱點資料快取（也就是我們常說的快取）

• 限時業務的應用：redis中可以使用expire命令設定一個鍵的生存時間，到時間後redis會刪除它。利用這一特性可以運用在限時的優惠活動資訊、手機驗證碼、單點登陸token等業務場景。

• 計數器相關問題：redis由於incrby命令可以實現原子性的遞增，所以可以運用於高併發的秒殺活動、分散式序列號的生成、具體業務還體現在比如限制一個手機號發多少條簡訊、一個介面一分鐘限制多少請求、一個介面一天限制呼叫多少次等等。

• 排行榜相關問題：關係型資料庫在排行榜方面查詢速度普遍偏慢，所以可以藉助redis的SortedSet進行熱點資料的排序。

  在奶茶活動中，我們需要展示各個部門的點贊排行榜， 所以我針對每個部門做了一個SortedSet,然後以使用者的openid作為上面的username,以使用者的點贊數作為上面的score, 然後針對每個使用者做一個hash,通過zrangebyscore就可以按照點贊數獲取排行榜，然後再根據username獲取使用者的hash資訊，這個當時在實際運用中效能體驗也蠻不錯的

• 分散式鎖：這個主要利用redis的setnx命令進行，setnx："set if not exists"就是如果不存在則成功設定快取同時返回1，否則返回0 ，這個特性在俞你奔遠方的後臺中有所運用，因為我們伺服器是叢集的，定時任務可能在兩臺機器上都會執行，所以在定時任務中首先 通過setnx設定一個lock，如果成功設定則執行，如果沒有成功設定，則表明該定時任務已執行。 當然結合具體業務，我們可以給這個lock加一個過期時間，比如說30分鐘執行一次的定時任務，那麼這個過期時間設定為小於30分鐘的一個時間 就可以，這個與定時任務的週期以及定時任務執行消耗時間相關。當然我們可以將這個特性運用於其他需要分散式鎖的場景中，結合過期時間主要是防止死鎖的出現。

• 延時操作： 比如在訂單生產後我們佔用了庫存，10分鐘後去檢驗使用者是夠真正購買，如果沒有購買將該單據設定無效，同時還原庫存。 由於redis自2.8.0之後版本提供Keyspace Notifications功能，允許客戶訂閱Pub/Sub頻道，以便以某種方式接收影響Redis資料集的事件。 所以我們對於上面的需求就可以用以下解決方案，我們在訂單生產時，設定一個key，同時設定10分鐘後過期， 我們在後臺實現一個監聽器，監聽key的實效，監聽到key失效時將後續邏輯加上。 當然我們也可以利用rabbitmq、activemq等訊息中介軟體的延遲佇列服務實現該需求。

• 分頁、模糊搜尋：redis的set集合中提供了一個zrangebylex方法，語法如下：

  ZRANGEBYLEX key min max [LIMIT offset count]
  

  通過ZRANGEBYLEX zset - + LIMIT 0 10 可以進行分頁資料查詢，其中- +表示獲取全部資料

  zrangebylex key min max 這個就可以返回字典區間的資料，利用這個特性可以進行模糊查詢功能，這個也是目前我在redis中發現的唯一一個支援對儲存內容進行模糊查詢的特性。

  前幾天我通過這個特性，對學校資料進行了模擬測試，學校資料60萬左右，響應時間在700ms左右，比mysql的like查詢稍微快一點，但是由於它可以避免大量的資料庫io操作，所以總體還是比直接mysql查詢更利於系統的效能保障。

• 點贊、好友等相互關係的儲存:Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要儲存一個列表資料，又不希望出現重複資料時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。 又或者在微博應用中，每個使用者關注的人存在一個集合中，就很容易實現求兩個人的共同好友功能。

  這個在奶茶活動中有運用，就是利用set儲存使用者之間的點贊關聯的，另外在點贊前判斷是否點贊過就利用了sismember方法，當時這個介面的響應時間控制在10毫秒內，十分高效。

• 佇列:由於redis有list push和list pop這樣的命令，所以能夠很方便的執行佇列操作。

  更多Redis相關技術文章，請訪問Redis資料庫使用入門教程欄目進行學習！

2.zookeeper

ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。ZooKeeper包含一個簡單的原語集，提供Java和C的介面。

• 資料釋出和/訂閱

主要的一個場景，比如配置中心。我們會將配置的相關資訊都存放在一箇中心，這樣我們的應用就不用每次修改引數就要進行重啟，使用了zk作用配置中心的資料推送更新，這樣我們就能方便的進行資料更新，每次將相關資料釋出到配置中心，然後由應用服務去訂閱，這樣就能動態的進行配置資料的更新。

• 負載均衡

可以基於ZK來實現DDNS動態域名解析服務，從而達到域名的動態新增、修改、刪除等。能夠基於域名服務，進行應用的負載，從而達到請求負載到各個應用中。

• 命名服務

命名服務，主要的應用場景在於rpc服務，比如dubbo等框架，可以將相應的服務註冊在zk上，這樣服務呼叫就可以根據其所命名的服務來提供對外服務等。

• 分散式協調/通知

對於一個在多臺機器部署執行的應用上，通常都需要一個協調者來控制整個系統的執行流程。比如分散式事務、機器間的互相協調等。這樣能將分散式協調的職責能從應用中分離出來，達到減少系統間的耦合性，提高系統的可擴充套件性。

• 叢集管理

在叢集環境中，機器和應用都是分散著進行部署，每次進行服務的上下線升級的過程中，都要手動進行叢集的管理，這樣造成人做的事比較重複性，並且也比較麻煩容易出錯。如果能使用zk來協助我們進行服務或機器進群的管理，這樣將能幫助我們解決需要繁瑣又麻煩的事。

• Master選舉

Master選舉，也就是在眾多機器或服務中，選舉出一個最終“決定權”的領導者，來獨立完成一項任務。比如有一項服務是需要對外提供服務，但是要保證高可用，我們就機會進行服務的多項部署，也就是做了一些備份，提高系統的可用性。一旦我們的主服務掛了，我們可以讓其它的備份服務進行重新選舉，這樣我們就能使整個系統不會因服務的掛掉而造成服務不可用。

• 分散式鎖

分散式鎖是控制分散式系統間同步訪問共享資源的一種方式。如果不同的系統或同一個系統的不同主機之間共享了同一個資源，那麼訪問這些資源的時候，需要使用互斥的手段來防止彼此之間的干擾，以保證一致性，這種情況就需要使用分散式鎖。

• 分散式佇列

使用zk來實現分散式佇列，分為兩大類：FIFO先進先出佇列、Barrier分散式屏障。FIFO佇列是一種很典型的佇列模型：先進入佇列的請求先完成操作後，才會處理後面的請求；Barrier分散式屏障，則是需要將佇列元素都集聚之後才進行統一的執行安排，否則只能等待。

3.fastDFS

fastDFS 是以C語言開發的一項開源輕量級分散式檔案系統，他對檔案進行管理，主要功能有：檔案儲存，檔案同步，檔案訪問（檔案上傳/下載）,特別適合以檔案為載體的線上服務，如圖片網站，視訊網站等

FastDFS由跟蹤伺服器(Tracker Server)、儲存伺服器(Storage Server)和客戶端(Client)構成。

應用場景

• 檔案儲存

4.MQ(Message Queue)

MQ（Message Queue）訊息佇列，是基礎資料結構中“先進先出”的一種資料結構。一般用來解決應用解耦，非同步訊息，流量削鋒等問題，實現高效能，高可用，可伸縮和最終一致性架構。想一下，生活中買東西，需要排隊，先排的人先買消費，就是典型的“先進先出”。

MQ（Message Queue）訊息佇列，是基礎資料結構中“先進先出”的一種資料機構。指把要傳輸的資料（訊息）放在佇列中，用佇列機制來實現訊息傳遞——生產者產生訊息並把訊息放入佇列，然後由消費者去處理。消費者可以到指定佇列拉取訊息，或者訂閱相應的佇列，由MQ服務端給其推送訊息。

MQ的作用

　訊息佇列中介軟體是分散式系統中重要的元件，主要解決應用解耦，非同步訊息，流量削鋒等問題，實現高效能，高可用，可伸縮和最終一致性架構。

• 解耦：一個業務需要多個模組共同實現，或者一條訊息有多個系統需要對應處理，只需要主業務完成以後，傳送一條MQ，其餘模組消費MQ訊息，即可實現業務，降低模組之間的耦合。

• 非同步：主業務執行結束後從屬業務通過MQ，非同步執行，減低業務的響應時間，提高使用者體驗。

• 削峰：高併發情況下，業務非同步處理，提供高峰期業務處理能力，避免系統癱瘓。

MQ的缺點

• 1、系統可用性降低。依賴服務也多，服務越容易掛掉。需要考慮MQ癱瘓的情況

• 2、系統複雜性提高。需要考慮訊息丟失、訊息重複消費、訊息傳遞的順序性

• 3、業務一致性。主業務和從屬業務一致性的處理

應用場景

• 應用解耦（非同步）：系統之間進行資料互動的時候，在時效性和穩定性之間我們都需要進行選擇。基於執行緒的非同步處理，能確保使用者體驗，但是極端情況下可能會出現異常，影響系統的穩定性，而同步呼叫很多時候無法保證理想的效能，那麼我們就可以用MQ來進行處理。上游系統將資料投遞到MQ，下游系統取MQ的資料進行消費，投遞和消費可以用同步的方式處理，因為MQ接收資料的效能是非常高的，不會影響上游系統的效能，那麼下游系統的及時率能保證嗎？當然可以，不然就不會有下面的一個應用場景。

• 通知

這裡就用到了前文一個重要的特點，釋出訂閱，下游系統一直在監聽MQ的資料，如果MQ有資料，下游系統則會按照 先進先出 這樣的規則， 逐條進行消費 ，而上游系統只需要將資料存入MQ裡，這樣就既降低了不同系統之間的耦合度，同時也確保了訊息通知的及時性，而且也不影響上游系統的效能。

• 限流

上文有說了一個非常重要的特性，MQ 資料是隻有一條資料在使用中。 在很多存在併發，而又對資料一致性要求高，而且對效能要求也高的場景，如何保證，那麼MQ就能起這個作用了。不管多少流量進來，MQ都會讓你遵守規則，排除處理，不會因為其他原因，導致併發的問題，而出現很多意想不到髒資料。

• 資料分發

MQ的釋出訂閱肯定不是隻是簡單的一對一，一個上游和一個下游的關係，MQ中介軟體基本都是支援一對多或者廣播的模式，而且都可以根據規則選擇分發的物件。這樣上游的一份資料，眾多下游系統中，可以根據規則選擇是否接收這些資料，這樣擴充套件性就很強了。
PS:上文中的上游和下游，在MQ更多的是叫做生產者（producer）和消費者（consumer）。

• 分散式事務

分散式事務是我們開發中一直儘量避免的一個技術點，但是，現在越來越多的系統是基於微服務架構開發，那麼分散式事務成為必須要面對的難題，解決分散式事務有一個比較容易理解的方案，就是二次提交。基於MQ的特點，MQ作為二次提交的中間節點，負責儲存請求資料，在失敗的情況可以進行多次嘗試，或者基於MQ中的佇列資料進行回滾操作，是一個既能保證效能，又能保證業務一致性的方案，當然，這個方案的主要問題就是定製化較多，有一定的開發工作量。

5.kafka

kafka是由Apache軟體基金會開發的一個開源分散式流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者在網站中的所有動作流資料。 這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理，也是為了通過叢集來提供實時的訊息。

優勢

• 高吞吐量、低延遲：kafka每秒可以處理幾十萬條訊息，它的延遲最低只有幾毫秒；

• 可擴充套件性：kafka叢集支援熱擴充套件；

• 永續性、可靠性：訊息被持久化到本地磁碟，並且支援資料備份防止資料丟失；

• 容錯性：允許叢集中節點故障（若副本數量為n,則允許n-1個節點故障）；

• 高併發：支援數千個客戶端同時讀寫。

應用場景

• 日誌收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一介面服務的方式開放給各種consumer；

• 訊息系統：解耦生產者和消費者、快取訊息等；

• 使用者活動跟蹤：kafka經常被用來記錄web使用者或者app使用者的各種活動，如瀏覽網頁、搜尋、點選等活動，這些活動資訊被各個伺服器釋出到kafka的topic中，然後消費者通過訂閱這些topic來做實時的監控分析，亦可儲存到資料庫；

• 運營指標：kafka也經常用來記錄運營監控資料。包括收集各種分散式應用的資料，生產各種操作的集中反饋，比如報警和報告；

• 流式處理：比如spark streaming和storm。

6.ELK

ELK是Elasticsearch、Logstash、Kibana三大開源框架首字母大寫簡稱。市面上也被成為Elastic Stack。其中Elasticsearch是一個基於Lucene、分散式、通過Restful方式進行互動的近實時搜尋平臺框架。像類似百度、谷歌這種大資料全文搜尋引擎的場景都可以使用Elasticsearch作為底層支援框架，可見Elasticsearch提供的搜尋能力確實強大,市面上很多時候我們簡稱Elasticsearch為es。Logstash是ELK的中央資料流引擎，用於從不同目標（檔案/資料儲存/MQ）收集的不同格式資料，經過過濾後支援輸出到不同目的地（檔案/MQ/redis/elasticsearch/kafka等）。Kibana可以將elasticsearch的資料通過友好的頁面展示出來，提供實時分析的功能。

通過上面對ELK簡單的介紹，我們知道了ELK字面意義包含的每個開源框架的功能。市面上很多開發只要提到ELK能夠一致說出它是一個日誌分析架構技術棧總稱，但實際上ELK不僅僅適用於日誌分析，它還可以支援其它任何資料分析和收集的場景，日誌分析和收集只是更具有代表性。並非唯一性。我們本教程主要也是圍繞通過ELK如何搭建一個生產級的日誌分析平臺來講解ELK的使用。

應用場景

• 分散式部署專案，需要收集日誌。

• 微服務架構專案，收集各個服務的日誌。

• 大資料行業。